[ Thanks to Russ Mundy for taking the minutes. ] * DANE WG Minutes 24 March 2015, 1730-1830 Afternoon Session III * Agenda: Administrivia Olafur / Warren 10 minutes Early discussion about the meetecho queue experiment. Olafur explained document status: largely delayed, some were rescheduled. Security model, advance DANE/IPSEC need document editor. * S/MIME library status update and DANE portal announcement. Glen Wiley, Eric Osterweil 10 minutes http://www.ietf.org/proceedings/92/slides/slides-92-dane-2.pptx Eric Osterweil talked about object security via S/MIME (libsmaug). It's released open source library (C/C++), on github now: https://github.com/verisign/smaug https://github.com/verisign/smaug-tbird-plugin Some screenshots were shown (thunderbird add-on). DANE provisioning portal is a proof of concept to give folks a way of creating a delegation. Eric asked for feedback: send a note to Glen/Eric * Using DANE for Payment Information 5 minutes Glen Wiley Does this work fit with the DANE WG charter? (not as currently chartered) - Does the group want to recharter for this? Discussions: Paul Hoffman says 'Yes' with appropriate constraints People think we should work on this? Olafur encouraged discussion on the ML. hum for 'interesting': many not interesting: (almost) none Dan York (?): (comment lost) The hum for interesting and useful was much stronger than the hum for not interesting and useful. * OPENPGP/SMIME lookup problem 30 minutes Chairs and Pete Resnick Addressing issues that were raised in WG Last Call on the OPENPGP/SMIME - Mapping the left-hand side of the email address is rather complicated - Pete asked for a discussion. - Paul Hoffman: suggestion was that we should not do it. this has been a problem that we should not try to solve this problem that is larger than this WG. Has any other application besides LDAP - John Levine: Tried very hard to not put specifics in the local (left-hand side) of the address. Either should solve "correctly" but doesn't think that we should 'encourage' guessing. - Keith Moore: This WG isn't the right place to work this out. DNS is not really the right way work this out, should use some sort of orcle for the answer. - Victor: (remote) (see jabber log) most people use address books - Pete did not agree with this position - Brian: Discovery vs publication problem, doesn't think that this is really a DANE problem - Dave Crocker: discussions and proposals seem to be conflating some problems. Seems that solution space should not be in the middle of this kind of lookup mechanism - Chris Newman: Does not want to have local part lookup solved in this WG - if it's done, it should be something like additional smtp serveer activities. for example, mail lists have unique knowledge in the MTA - Pete: if it's done by smtp server, is there still a need for DANE. Several heads nodded yes. - Andrew Sullivan: If he heard John right, we should use naptr which would be bad. - Paul W: external orcle is an awful idea because of zone walking & knowing that you're getting to the right orcle. Leaving it in DNSSEC is the right idea. Second comment, is using only what the user types in will not work well since the spec can't prevent them from doing various random mappings. - Eric Osterweil: perfect is the enemy of completion - if we use what we already know we have such as certs & keys from an existing email. - Jeff Hodges: stated the problem & got agreement. did a design & installation at Stanford & there was lots of stuff that was very site specific - Keith Moore: when I try to map lots of stuff into dns, it's problematic since the dns is usually out of sync with the mail servers - Ben Schwartz: why are we hashing? a: normalization & non-ascii characters - Brian: might be a good experiment using orcle that uses dns/dane is feasible - Daniel: listed multiple points but missed them - [fingers tired - ] does this open the door for more spam & phishing attacks - Eric: wants to re emphasise do something simple - put uri in structure so that could reach corp servers. Pete summary: If we go forward with this, please keep in mind that either or both dns & SMTP can be changed/entended. As an experiment, going forward with the OpenPGPKey ID as an experiment, the yes hum was stronger than the no hum. A couple of people expessed strong aversion to publishing anything without strong warnings.