Subject: [dane] Agenda items for Dallas

From: Olafur Gudmundsson <[email-masked]>
Date: Sat, 24 Jan 2015 16:24:20 -0500

The chairs have requested a one hour slot 
please send us any requests for agenda slots
	Olafur & Warren

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 25 Jan 2015 05:54:00 +0000

> please send us any requests for agenda slots

Though I won't be there, I hope there will be some discussion of
any outstanding issues on the ops/6698-update draft.  In particular
if the proposal to extend "3 1 X" to apply to raw public keys is
not clear or is miguided, let's get that settled, and let's *finally*
get a LC timeframe for the document.

Speaking of LC, we seem to have lost all momentum on the SMTP and
SRV drafts, lets get those moving again please, together or
separately.

I've not yet done anything on the DANE client authentication front,
because I wanted to see the ops and SMTP drafts come to some closure
first.  This does not mean that DANE client auth is forgotten, I
think it is still a reasonable thing to specify.

Finally, I've a lot more operational experience now, and have twice
asked for feedback on the notion of adding some of the observations
to the SMTP or ops drafts, but there's been no feedback on that.

Exim 4.85 includes DANE support for SMTP, so there are now two
implementations of the SMTP draft.

In the mean-time Transip have fixed their DNS servers, and the
number of DNSSEC domains that return bogus denial of existence for
TLSA queries has dropped by ~40%.  There is distant rumbling of
progress on the forpsi front.

The S/MIME discussion seems to have stalled, perhaps someone will
have fresh ideas on how to move that forward.

Finally, it would be nice to see (correct!) DANE TLSA support in
TLS toolkits:

	OpenSSL, GnuTLS, PolarSSL, ...

while I'll likely help out on the OpenSSL front, what can be done
to get DANE support in the rest?

To get around last-mile problems, perhaps a revived effort to define
a TLS extension with "stapled TLSA records" (including the full
chain of DS/DNSKEY and RRSIG records necessary to validate them).

With stapled TLSA RRs, clients in DNSSEC-hostile environments can
elicit the relevant DNSSEC in-band data from servers.

-- 
	Viktor.