Subject: Re: [dane] Meeting plans for Buenos Aires?

From: Benno Overeinder <[email-masked]>
Date: Wed, 3 Feb 2016 10:22:59 +0100

Hi all,

> On 21 Jan 2016, at 19:32, Olafur Gudmundsson <[email-masked]> wrote:
> 
> Everyone, 
> 
> The chairs and AD want to see discussion on the future of the working group. 
> Please bring to the table what you see the group can/should do. 
> It  is up to the participants to set the direction for the group. 
> If the group continues we will recharter to reflect the direction. 
> 
> To facilitate f2f discussion on this topic, the chairs have requested  a 1 hour slot in BA, BUT PLEASE start the conversation here. 
> 

Besides all the potential work Shumon summarised, I do see a serious interest and actual work starting off to use DANE TLSA & SMIMEA to realise secure email services.  Also the Electronic ID (EID) community is interested to explore and actually use DANE as a building block for EID services.  With the uptake of DANE in applications, I guess there will be relevant work to be done in extending DANE to fit new requirements and use-cases.

— Benno

-- 
Benno J. Overeinder
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 4 Feb 2016 08:06:36 -0800

On 1/21/2016 11:18 AM, Shumon Huque wrote:
> Lastly, new protocols take a long time to get deployed. Look at IPv6
> - I'm speaking from experience, having first deployed it in
> production in 2002. And it's still largely undeployed. Shutting down
> the DANE working group while the protocol is still in its infancy,
> and while there is still potential work in the queue, sends the wrong
> message in my opinion.

If there is work to do, then where is the draft charter text describing 
the problem and nature of work to be done, timeline for completion, 
indication of who is asking for the work, indication of who will do the 
work, and indication of who will adopt (use) the work?

In terms of overseeing adoption of an IETF specification, that's not the 
job of the IETF.  That's the job of whatever Internet constituency(ies) 
want to see the adoption.  The IETF work is a segment of an industry 
process.  Simplistically, it divides into :  1) formulate the needs, 2) 
design a solution, 3) deploy the solution.  The IETF is (only) step #2.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Shumon Huque <[email-masked]>
Date: Thu, 4 Feb 2016 11:38:53 -0500

> work, and indication of who will adopt (use) the work?

I would be happy to send draft charter text for some of the work items I
mentioned in my previous note. We're still in the discussion phase at the
moment. I assume charter revision proposals will follow promptly if there
is interest.

Arguably some of the work like new uses of the existing TLSA server spec
by other applications could be done in other IETF working groups. But the
first
item, augmenting the TLSA spec to support client authentication, feels like
a
core DANE working group item, so I would like that work at least to be done
here.

> design a solution, 3) deploy the solution.  The IETF is (only) step #2.

Sure - I wasn't suggesting IETF was the venue for deployment issues and
advocacy. We should have a non IETF dane-ops list for that sort of thing. I
was merely talking about the impression being sent by the shutdown. And
there is a queue of plausible protocol development work.

-- 
Shumon Huque

---

From: Dan York <[email-masked]>
Date: Thu, 4 Feb 2016 16:55:43 +0000

First... +100 to what Shumon said!  We are at the stage of DANE deployment where, while the protocol may be well-developed, the deployment is only now beginning... and I think it would send a wrong message to kill of the group now.

But to answer Dave...

On Feb 4, 2016, at 11:06 AM, Dave Crocker <[email-masked]<mailto:[email-masked]>> wrote:

If there is work to do, then where is the draft charter text describing the problem and nature of work to be done, timeline for completion, indication of who is asking for the work, indication of who will do the work, and indication of who will adopt (use) the work?

Good point.  Perhaps the action here is to update the DANE WG Charter with the deliverables such as the ones Shumon indicates.   All of the milestones on the existing charter ( https://datatracker.ietf.org/wg/dane/charter/ ) have been completed and so by the process it would make sense to declare victory and shut the group down.

In terms of overseeing adoption of an IETF specification, that's not the job of the IETF.  That's the job of whatever Internet constituency(ies) want to see the adoption.  The IETF work is a segment of an industry process.  Simplistically, it divides into :  1) formulate the needs, 2) design a solution, 3) deploy the solution.  The IETF is (only) step #2.

Yes, BUT...  the reality is that during the deployment (step 3) of the solution there are very frequently issues discovered that were not anticipated in the original development of the protocol.  Changes that need to be made to the protocol are identified.  Additional uses cases are often found.  Ways to extend a protocol are discovered. New guidance is developed.  All of those are pieces of information that can be fed back into the IETF process to wind up with a better solution (step #2).

We've in fact *already* seen this within DANE with some of the work that Viktor and Wes have fed back into the group based on their work with DANE in SMTP.

The question is - if the DANE working group shuts down, where does that feedback go so that DANE could be improved?

Right now, I'm seeing a good bit of interest in DANE out in the wider industry.  I'd like to make the process for incorporating that feedback during deployment as efficient and fast as possible.  To me, keeping the DANE WG around for a bit more would be one way to make sure that the feedback loop is out there.

Alternatively, for IPv6, there is the V6OPS WG where these kind of operations/deployment issues can be brought.  For "DNS" in general there is DNSOP.  Could DANE issues be brought there?  I guess so if the charter were updated... but that then throws even more into an already packed WG.

Or... we could close the DANE WG and wait around until there were enough issues to merit opening up a new DANE-related WG (similar to how EPPEXT was eventually formed after PROVREG shut down).

I agree that "waiting for feedback from deployment" is NOT a reason to keep a WG on the books ALONE, but given points by Shumon and others I *do* think there is enough DANE-related work to keep the WG going... which then also can be that potential feedback mechanism.

My 2 cents,
Dan
--
Dan York
Senior Content Strategist, Internet Society
[email-masked]<mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked]<mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/

---

From: "John Levine" <[email-masked]>
Date: 4 Feb 2016 23:06:40 -0000

>First... +100 to what Shumon said!  We are at the stage of DANE deployment where, while the protocol may be
>well-developed, the deployment is only now beginning... and I think it would send a wrong message to kill
>of the group now.

I'm sorry, but this shows a complete misunderstanding of what a
working group is and how the IETF works.  WGs exist to develop
standards, following their charters.  The whole reason that WGs have
charters is so they don't just drift on forever.

If, as it appears, DANE has finished the work in its charter, it's
time to shut it down.  In the past, some WG's mailing lists have
stayed open for discussions of topics related to the former WG's work.
It looks line DANE could be a candidate for that.

R's,
John

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 5 Feb 2016 00:43:17 +0000

Hi folks,
 so ...
ogud + friendly AD:
There seems some serious reluctance to re-charter DANE to do more work (for reasons I'd love to see spelt out).
The question's been asked, but I haven't seen a detailed answer.

Shumon/Bello/Melinda/...:
Given that reluctance, if you want to do some work, develop a charter though the BOF
process (same as keyassure/DANE did), convince the ADs, and get a ->new<- WG for this new work.
[maybe called SWEDE?]

John:
 As for the use of keeping the ML open after the WG has died: remind me again how successful that has been in the IETF.

all the best,
  Lawrence

On 4 Feb 2016, at 23:06, John Levine <[email-masked]> wrote:
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: "John R Levine" <[email-masked]>
Date: 4 Feb 2016 20:14:49 -0500

> As for the use of keeping the ML open after the WG has died: remind me again how successful that has been in the IETF.

It varies.  Of the ones I can think of, the ietf-smtp list is useful as a 
place to kick around proposed SMTP changes, such as a current discussion 
about whether a compressed data extension would be a good idea and if so 
how to do it.  There are certainly plenty that either have no traffic, or 
the messages aren't interesting.

It doesn't make any difference to me whether the dane list stays open, but 
if there is more left to say about publishing stuff in the DNS secured by 
DNSSEC, it'd be as good a place as any.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 5 Feb 2016 01:28:00 +0000

On Thu, Feb 04, 2016 at 08:14:49PM -0500, John R Levine wrote:

> about whether a compressed data extension would be a good idea and if so how
> to do it.  There are certainly plenty that either have no traffic, or the
> messages aren't interesting.
> 

We still have client DANE auth on the charter and Shumon's draft
(I'm taking a back seat this time) is in early stages of development.
And the TLS working group might soon be looking at the DANE stapling
extension, it may useful to have some veterans here to provide
feedback to the TLS WG.

So some work still remains, even though things are quite slow just
now.

At this time most of my energy is on the deployment side, in
particular at present on getting OpenSSL 1.1.0 out the door.

It seems that Claus Assmann has started looking at the DANE support
in 1.1.0, if anyone else has started testing it and has feedback,
feel free to share.  The alpha3 release scheduled for next week
might be a good time to get your feet wet.

Note, OpenSSL 1.1.0 provides peer chain verification via application
provided TLSA records, obtaining and (DNSSEC) validating those TLSA
records is up to the application.  There are opportunities here
for more "feature-complete" libraries that provide the "missing"
glue and provide a more integrated interface that does that does
the TLSA lookup with either in-application DNSSEC validation or
AD-bit trust from a local resolver, and then uses OpenSSL to do
the DANE TLS bits.

-- 
	Viktor.

---

From: Shumon Huque <[email-masked]>
Date: Thu, 4 Feb 2016 20:37:25 -0500

> process (same as keyassure/DANE did), convince the ADs, and get a ->new<-

Thanks for the suggestion! I'd prefer to try to recharter the current group
with any new work items first, before this more drastic option. But glancing
at the current charter just now, it might already cover some of the work
that I outlined earlier.

-- 
Shumon Huque.

---

From: Shumon Huque <[email-masked]>
Date: Thu, 4 Feb 2016 20:48:43 -0500

On Thu, Feb 4, 2016 at 8:28 PM, Viktor Dukhovni <[email-masked]>
wrote:

> > >As for the use of keeping the ML open after the WG has died: remind me
> again how successful that has been in the IETF.
> >
> how

Hmm, I hadn't noticed until you mentioned it, that client DANE records
are already in the current charter, so this piece is already covered. I hope
to request a call for working group adoption of our draft on this topic in
the near future.

> AD-bit trust from a local resolver, and then uses OpenSSL to do

I've written some code using the new OpenSSL 1.1.0 DANE APIs
that already does this (both the application validation version using
getdns and one that inspects AD bit from a trusted resolver using ldns).
I'll send you a separate note off list about this with some feedback.

Also the getdns library will likely develop an integrated DANE TLS
connection function that will do this.

-- 
Shumon Huque

---

From: "John R Levine" <[email-masked]>
Date: 4 Feb 2016 20:53:10 -0500

> at the current charter just now, it might already cover some of the work

If you have a clear, well focused list of things to do, you'll probably 
find that setting up a new WG is easier than rechartering.  It certainly 
comes with less baggage.

Regards,

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 5 Feb 2016 02:26:00 +0000

Hi again,
 really -- does re-chartering have a higher bar now?
I would have thought, if some items are already in/alluded to in the existing charter, then extending it for focussed extensions that are close-coupled to the current text could be a quicker approach. That's certainly been my experience in the past.

Either way, a new charter (or extension to the current one) requires enthusiasts to spell out exactly what the tasks will be, when they are needed/aim to be completed, and get people willing to do the work. That means charter text.

Your esteemed co-chair did ask for this, so over to you folks -- if you want it, make it happen.
(I'm sure there's an apposite Mel Brooks quote here).

all the best,
  Lawrence

On 5 Feb 2016, at 01:53, John R Levine <[email-masked]> wrote:
> If you have a clear, well focused list of things to do, you'll probably find that setting up a new WG is easier than rechartering.  It certainly comes with less baggage.
> 
> Regards,

---

From: John Gilmore <[email-masked]>
Date: Fri, 05 Feb 2016 02:02:52 -0800

> design a solution, 3) deploy the solution.  The IETF is (only) step #2.

Yeah, let's not have the designers talking with the deployers.  That can
lead to interoperability and harmony, which IETF is dead set against.

I suggest that any dane member who doesn't want to continue, should
quit the group and resign from the mailing list.  Then from your point
of view, the group will already be "shut down".  Yet those who wish to
continue will still be able to continue.

>From whence is the pressure coming to "shut down the group entirely"?
Perhaps NSA is concerned that DANE might actually provide a usable
public key infrastructure for mass authentication and encryption?
Better shut that puppy right down, then, before it's too late.

	John (irony trigger warning)

---

From: "Olafur Gudmundsson" <[email-masked]>
Date: Fri, 5 Feb 2016 05:50:00 -0500 (EST)

<chair-hat=on> 
For the record: 
IF there is identified work to do rechartering is an easy step.
Lets identify what remains from existing charter that is still relevant.
Add any new work proposed and there is interest in pursuing by more people than just the editors. 
 
Olafur
Ps: the best way to figure out if a WG is done is to threaten to shut it down 

On Thursday, 4 February, 2016 20:37, "Shumon Huque" <[email-masked]> said:

On Thu, Feb 4, 2016 at 7:43 PM, Lawrence Conroy <[ [email-masked] ]( mailto:[email-masked] )> wrote:
Hi folks,
  so ...
 ogud + friendly AD:
 There seems some serious reluctance to re-charter DANE to do more work (for reasons I'd love to see spelt out).
 The question's been asked, but I haven't seen a detailed answer.

---

From: Melinda Shore <[email-masked]>
Date: Fri, 5 Feb 2016 17:07:24 -0900

> lead to interoperability and harmony, which IETF is dead set against.

Well, no.  This is an artifact of how the IETF works.  I
think on balance the decision to terminate working groups
as soon as they complete their charter work has led to
exactly the problems you describe, but it's really
bureaucratic rather than malicious.

It may be time to start making wider use of maintenance
and extensions working groups, although that's a wider
discussion for the entire IETF.  In any event working groups
are typically not chartered on the basis of some of the
arguments being made here and the discussion really needs
to focus on things that need to be specified.

But, if someone wants to take the discussion of M&E working
groups to the broader list, I think I'd support that.

Melinda

---

From: John Gilmore <[email-masked]>
Date: Sat, 06 Feb 2016 14:55:49 -0800

> Well, no.  This is an artifact of how the IETF works.  

You mean, how the IETF fails.

> I think on balance the decision to terminate working groups

If it's a pervasive, bureaucratic issue, then it should be fixed even
more than if it was just based on one person's malice.

The bizarre part for me is that it's easier just to let it continue.
So why does the bureacracy do actual work to shut it down?

	John

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 6 Feb 2016 23:06:36 +0000

Folks,

I think the chairs already said that if there's work to be
done they're up for this wg continuing. I think that is
entirely the right position to take.

The chairs had earlier said that if the chartered work items
were completed then shutting down would be the plan. And that
is a good plan in general, though there's of course room for
what can be quite subtle differences in reasonable opinions.
And if more credible work turns up with more credible folks
willing to do that, then continuing is the clear thing to do,
with re-chartering as needed. (And re-chartering is not at all
a hard thing, whoever said it is hard... is plain wrong.)

What I don't myself see any room for, or have any time for,
is the kind of hyperbole below - a phrase like "pervasive
bureaucracy" is IMO an entirely undeserved and unjustified
slur presumably aimed at the WG chairs and is no form of
rational or informed criticism.

And with that, I hope participants here move their attention
back to improving how public keys get distributed.

Thanks,
S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 12 Feb 2016 07:51:21 -0500

> lead to interoperability and harmony, which IETF is dead set against.

If you want deployment, then you had better talk to the developers in
step 0, not after the finished product is published.

This working group made sure that the developer community was
alienated at an early stage. Their input was ignored and some of the
participants made sure that they insulted a couple of key people in
the browser world whose support was essential.

The industry now has or at least it thinks it has two answers to the
problems DANE addresses. They are using HTTP key pinning as their
security policy layer and are looking at Lets Encrypt for free certs.

If you want to achieve the original objectives of this working group
and get them deployed, then work within the framework that the parties
whose buy-in you need for deployment have already established.

HTTP key pinning does provide some security but it is in band to HTTP
which means it can only provide security after first use and there is
a big potential for 'shooting yourself in the foot'. The DNS based
answer to those problems that is deployable is to take the HTTP key
pinning record that they have already defined and support in the
browser code and publish that exact text string as a DNS Resource
Record.

---

From: Dan York <[email-masked]>
Date: Fri, 12 Feb 2016 13:26:07 +0000

Phillip,

On Feb 12, 2016, at 7:51 AM, Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>> wrote:

HTTP key pinning does provide some security but it is in band to HTTP
which means it can only provide security after first use and there is
a big potential for 'shooting yourself in the foot'.

A couple of weeks ago I was having this kind of discussion with someone about how cert pinning was Trust-On-First-Use and how DNSSEC/DANE could be used *with* cert pinning to get around the TOFU problem.  My suggestion was that the app in question could also do a lookup on the DANE TLSA record and compare that with what they were getting for the cert to pin, but...

The DNS based

... that is certainly another answer and perhaps much simpler and easier.   Put the exact RFC 7469 HPKP header ( https://tools.ietf.org/html/rfc7469 ) in DNS as a resource record and then sign that with DNSSEC.

Has anyone ever taken a look at whether that (putting the HPKP header into DNS) would be something reasonable to do?

Given that this would not be with the TLSA record, I realize this work might be outside of the scope of the *current* charter of the DANE WG ( https://datatracker.ietf.org/wg/dane/charter/ ), although it does say "The DANE WG will specify how to incorporate DANE and DANE-like functionality into protocols."   But if this is something worth pursuing it could be something done here (with a recharter) or something done in another WG (or a new short-term WG could be spun up).

Anyway... an interesting idea, Phillip!

Dan

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Feb 2016 06:45:59 -0800

> lead to interoperability and harmony, which IETF is dead set against.

It important that the IETF not be the only place such folk can interact. 
  Successful protocols have active involvement of developers and 
deployers from before the standards process, and long after.

There needs to be an /independent/ community establishing the needs and 
exploiting the new capabilities.  Again: the IETF is a way-station in 
the life-cycle.  It supplies some resources and process for a step along 
the way, but it is not the anchor holding the community together.

Keeping the IETF mailing list active is often helpful, but that's 
different from maintain a working group.  For that independent 
community, outside of the IETF it is common to have multiple, related 
mailing lists, such as foo-interest, for general discussion, and 
foo-dev, for discussion of the technical details and possible revisions, 
and foo-ops, for deployment discussion.

As for the concern expressed in the thread for garnering feedback about 
a new specification and then incorporating changes, that forms input to 
a fresh effort to form a new working group, to do the next version of 
the specification.

In fact there often is a a counter-productive effect of keeping a 
working group actively seeking input to revisions:  It communicates to 
the industry that the specification remains unstable.  Operators do not 
like deploying unstable specifications; so they defer adoption.

d/

---

From: Paul Wouters <[email-masked]>
Date: Fri, 12 Feb 2016 17:27:59 -0500 (EST)

> Has anyone ever taken a look at whether that (putting the HPKP header into DNS) would be something reasonable to do?

If you are using the http server to send the key info, why not just send
the TLSA RRset as an option? We already have a draft for that:

https://tools.ietf.org/html/draft-shore-tls-dnssec-chain-extension-02

> Given that this would not be with the TLSA record

I don't see why not to use the TLSA record. Its existence basically
means "MUST do TLS with this key, hard fail otherwise".

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 13 Feb 2016 01:42:26 +0000

> whose buy-in you need for deployment have already established.

It seems to me that the most significant obstacle to using
DNSSEC-assisted key pinning in browsers is not the RRdata format
(TLSA or HPKP text), but rather the DNSSEC last-mile problem, which
means browsers often can't get DNSSEC validated records of any
kind.

Hence revived efforts to transport DNS data inside the TLS handshake
between HTTP server and client.

Given that the DNSSEC approach has more solid mechanisms for ensuring
freshness, and that DANE also supports pinning of trust-anchors,
not just EE keys, there is little to recommend HPKP once DNSSEC is
available.

-- 
	Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 12 Feb 2016 23:13:34 -0500

> means browsers often can't get DNSSEC validated records of any

Yes, hence I submitted a proposal to address that issue before DANE chartered.

The other problem is that in DANE DNSSEC is a MUST. Which was a
problem when every single one of my browser contacts refused to
consider at present.

My goal was to upsell my DV customers to DNSSEC. That can't happen if
it is a MUST.

> between HTTP server and client.

But the folk pursuing that effort refuse to consider the fact that the
browser engineers are pushed to minimize latency as first priority. So
now deployment of DPRIV is effectively gated on TCP Fast start.

> not just EE keys, there is little to recommend HPKP once DNSSEC is

Except for the fact that it is already deployed and has a
comprehensive support base.

HPKP in a DNS RR offers exactly the same functionality without the
deployment hassles. Why do you expect the internet to bend to the will
of a dozen people who don't listen?

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 13 Feb 2016 04:35:16 +0000

> of a dozen people who don't listen?

Again this is quite orthogonal to the payload format, you're arguing
for using DNS key pinning without DNSSEC (similar to DKIM).  That
makes the lookup vulnerable to active attacks, so we're back to
TOFU and cache lifetimes longer than the DNS TTL, ...

There a lot less reason left to using DNS by the time that happens,
except for the hope of the upselling you mention, where perhaps
some folks start publishing the same records in signed zones, and
clients start checking the signatures.

Yes, I understand that DNSSEC is at present and may indefinitely
remain too high a bar.  In which case DANE fails.  However key
pinning via insecure DNS is not really DANE, it is just an alternate
transport for some application data via a typically untrusted cache.
It may be more efficient than a roundrip to the HTTP server, but
that's all.  

So I don't think there was is any need for a DANE working-group to
propose and standardize such things.  The DANE working-group is
trying something more ambitious, that may fail, but is likely worth
a try.

-- 
	Viktor.

---

From: "Patrik Fältström" <[email-masked]>
Date: Sat, 13 Feb 2016 11:42:48 +0100

On 13 Feb 2016, at 5:35, Viktor Dukhovni wrote:

> Yes, I understand that DNSSEC is at present and may indefinitely remain too high a bar.

It is too high a bar just because this is repeated over and over again. Not because it really is.

   Patrik

---

From: Dave Crocker <[email-masked]>
Date: Sat, 13 Feb 2016 10:40:44 -0800

> It is too high a bar just because this is repeated over and over again. Not because it really is.

Please explain.  The continuing lack of widespread adoption is only due 
to what?  The fact that people keep saying it's too hard?  It would be 
easy if only they would realize it?

When a market is glacially slow to adopt something, it does not help 
much to blame the market.

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 13 Feb 2016 19:15:16 +0000

On Sat, Feb 13, 2016 at 10:40:44AM -0800, Dave Crocker wrote:

> Please explain.  The continuing lack of widespread adoption is only due to
> what?  The fact that people keep saying it's too hard?  It would be easy if
> only they would realize it?
> 
> When a market is glacially slow to adopt something, it does not help much to
> blame the market.

Indeed, the incentives have not yet been sufficient, and might
never become sufficiently compelling.   There needs to be more
value and fewer disincentives.  

I'm working on the value part by adding DANE support to Postfix
and OpenSSL, and contributing to DANE support in Exim.  At some
point I'll look at additional open-source TLS toolkits beyond
OpenSSL.

I've also worked with a number of DNS providers to fix their stacks,
so that TLSA record lookups don't routinely fail.  The impedance
is much lower now than it was in 2014.  The only remaining significant
clusters of problems are at mail.mil and isphuset.no.

I have tickets open with both, but progress if any is glacial.

Adoption of DANE TLSA for email is still low, but growing.  At the
MAAWG conference in October I could report ~6k domains with 24
"large enough" to also be listed in Google's email transparency
report.  Today it is ~11k domains, with 32 listed in Google's email
transparency report.  

The DANE specs were released with no meaningful running code in
sight, and the browsers as the aspirational initial target market.
For various reasons the browsers did not turn out turn out to be
a good fit at the time.  So what we're seeing is a much slower
ramp-up in more niche technology segments, with the protocol not
yet widely supported in toolkits.  So it is too early to expect
broad adoption.

As for DNSSEC, I've surveyed around 4.6 million (zone-apex) domains,
of these, 110k have DNSSEC for both the domain and at least one
best preference MX host.  So it looks like:

    domains : dnsssec : dane ~ 400 : 10 : 1

Another data-point is that among the "large enough" domains (listed
in Google's email transparency report at some point in the last
couple of years) I have:

	domains : dnssec : dane ~ 70000 : 700 : 32

so here DNSSSEC adoption is ~1% rather than ~2.5%, and dane adoption
among DANE-capable domains is 1:20 rather than 1:10.

If this were steady-state, we should give up.  For now, there's
some room for optimism.  And yes, I agree with you about not blaming
the market.  If we want a different result, work is required to
change the incentives.

-- 
	Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 13 Feb 2016 19:40:11 -0500

My problem with DANE is that since it allows for Cert Validation,
DNSSEC must be a MUST.

Of course if you are doing HPKP in DNS, doing DNNSEC is a no brainer
for the site. But from a game theory point of view, there is a big
difference between 'strongly encouraged' and 'MUST'.

Making the requirement for DNSSEC a 'MUST' means that DNSSEC support
in the browser is a MUST. And so any attempt to use TLSA is dependent
on DNSSEC deployment having been achieved.

HPKP in DNS can be rolled out today. Rolling out HPKP highlights the
failure of the browser providers to fully lock the system down with
DNSSEC.

The objective here is to get the camel's nose inside the tent.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 14 Feb 2016 11:37:12 +0000

On 5 Feb 2016, at 01:53, John R Levine <[email-masked]> wrote:

> If you have a clear, well focused list of things to do, you'll probably find that setting up a new WG is easier than rechartering.

In my experince: It depends. Either they are about the same amount of work or rechartering is slightly easier, unless ADs have a desire to shutdown the WG.

> It certainly comes with less baggage.

True.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 15 Feb 2016 12:56:26 +1100

On 14 February 2016 at 11:40, Phillip Hallam-Baker
<[email-masked]> wrote:
> HPKP in DNS can be rolled out today.

Maybe I'm just dim today, but doesn't that suffer from the same
problem as TLSA?  HPKP in HTTPS relies on HTTPS providing integrity.
Don't you need DNSSEC to get the same result for DNS?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 15 Feb 2016 08:40:36 -0500

> Don't you need DNSSEC to get the same result for DNS?

You only need authentication if you are going to store the information
for longer than the DNS TTL or use it in place of an authenticated key
pin.

Otherwise, a false D-HPKP signal is just a Denial of Service vector
which is already trivial for someone who controls DNS.

Obviously there is an advantage to deployment of DNSSEC, as follows:

1) For browser providers as a means of improving D-HPKP security
policy once there is an established base for D-HPKP.

2) Once there is a deployment of DNSSEC in a browser, there is an
incentive for sites with D-HPKP to deploy DNSSEC.

DANE requires both sides to anticipate support by the other. It is a
deployment deadlock. There is no advantage to deployment by sites
without support in the browser. The browser providers have stated they
don't see the point of DNSSEC to secure A/AAAA records (and they are
right). TLSA deployment is negligible, less than 1000 domains and
7-13% of those are wrong.

https://www.isi.edu/~johnh/PAPERS/Zhu15a.pdf

The other deployment pathology that DANE suffers from is that the
companies that help most enterprises manage their DNS records are DNS
registrars. These companies typically have a business model of selling
the DNS record at or below cost and making the difference up with
value added services, chiefly SSL certificates.

Now without laboring the point, just how did you expect to deploy a
new protocol when you were openly boasting about how it was going to
eliminate the principal source of revenue for the party you need
support from?

This was an experiment. It has failed. Now if you really want to solve
the problem, how about people let me have a go at doing it the way I
suggested in the first place.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 15 Feb 2016 18:30:19 +0000

On Sun, Feb 14, 2016 at 6:32 AM Alexey Melnikov <[email-masked]>
wrote:

> find that setting up a new WG is easier than rechartering.
>
> In my experince: It depends. Either they are about the same amount of work
> or rechartering is slightly easier, unless ADs have a desire to shutdown
> the WG.
>

Yes,  it depends -- on many things. These include how large of a change to
the charter is proposed, how similar a new WG would be, what the WG wants
to do, how the WG has been performing until this point, how receptive the
ADs are, recent history and the phase of the moon.

Without seeing specific documents / proposed charter text it is really hard
to know if it is something that this WG should do.
We (Ondrej and I) specifically added:
"When work on currently chartered documents is complete the WG
may re-charter if sufficiently pressing new work is identified.

DANE is not intended to be a long-lived catch-all WG for all
public key distribution in DNS issues and so will generally not
adopt new work items without re-chartering." because we didn't want to just
limp along, staying alive just to stay alive.
Olafur and I proposed wrapping things up largely because we hadn't seen a
large amount of concrete proposed work, and reviews on existing work were
getting harder / it was the same set of voices[0]. Again, we are happy that
people want to get work done, and we are happy to adopt new work, recharter
if needed, whatever -- but this requires everyone (yes, including the
chairs!) doing their bit -- for example, there has been very little
discussion on draft-huque-dane-client-cert, and much of what discussion
there has been is on the prefix / label. Please, can folk review the
content of the document for other issues?
Also, we have heard that people would like to get new work going - it is
getting close to BA, so if you have work, we'd like to see some documents
so that we can discuss them, please request meeting time, etc.

> > It certainly comes with less baggage.
Indeed.

W

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 15 Feb 2016 15:15:13 -0500

> On Feb 15, 2016, at 8:40 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> TLSA deployment is negligible, less than 1000 domains and

Not surprising. For HTTPS, if nobody is checking, why should they be right!

With SMTP, out of 11k tested domains ~30 (0.3%) are wrong.  TLSA records are only
kept right if there's an operational impact when they're wrong.

The error rate for SMTP will drop as more sending systems enable outbound checks.

-- 
	Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 15 Feb 2016 16:41:44 -0500

> The error rate for SMTP will drop as more sending systems enable outbound checks.

That is a predictable consequence from combining the key publication
mechanism and the security policy mechanism.

People create keys in advance of actually using them.

This is why I proposed separating the two systems. To validate a cert
one would use

<base32-cert-fingerprint>.example.com TLSB <blah>

Perhaps if some people had been less willing to dismiss any
contribution from people in the PKI industry as antithetical to the
purposes of the WG, this situation might have been avoided.

That is all water under the bridge now of course. I will write a draft
proposing my way to do it. Perhaps people could do me the favor of
thinking twice before complaining that it treads on DANE scope.