On Thu, Feb 4, 2016 at 8:28 PM, Viktor Dukhovni <[email protected]> wrote:
> On Thu, Feb 04, 2016 at 08:14:49PM -0500, John R Levine 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. > > > > 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. > > 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. > 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. > 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. > 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
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
