Minutes for DANE at IETF-91
minutes-91-dane-1

IETF91 - DANE Notes

Minutes (Summary)

- The agenda was not bashed
- No hums were taken during the meeting

Play-by-Play

Warren Kumari and Ólafur Guðmundsson - Opening Remarks
--------------------------------------------------------
Plan: Start WGLC on SMTP, SRV right after the meeting, and then rawkeys.  Hope
to WGLC the other openpgpkeys drafts later in the year Editors are needed for
the Jan-Sep milestones (4 docs) - see charter.  Send email to the chairs with
your “resume,” that is, why you would do the work well. Ólafur:  This is a good
opportunity for newbies.  The Chairs will give people help in whatever ways
needed, get people process guidance.  New blood is sought. Warren:  Also the
Chairs will be happy to help new editors to sort out the tool stuff. Peter Koch
asked if the timeline for going to Internet Standard is too fast, since DNSSEC
hasn’t been advanced to IS yet.  He also asked if the Chairs are looking for
interop reports for these actions.  Olafur answered yes about the interop
reports questions and noted people are staring to do that for the smtp draft.

Paul Wouters says they are writing code on IPSEC and DANE, and will contribute
text too (though stopped short of owning doc).

Quick Look at a DANE SMIMEA Prototype - Eric Osterweil
--------------------------------------------------------
I’m Eric from Verisign Labs.  Quick talk, willing to answer questions, but will
defer to chairs on when.

Ólafur: questions that aren’t about immediate prototype should be saved for
after the SMIMEA draft talk Simple goals for the prototype:  play with SMIMEA
discussion in real life & eat some of our own dogfood.  Heads-up approach, deal
with problems we find. We embraced _sign and _encr, and used NAPTR as a “sort
of lookaside thing.” Based it on the getdns implementation.  We can do full
validation at stub if we want.  Manually provisioned the SMIMEA records - this
is not a provisioning demo. Built into thunderbird, and we will open source
this soon.  Sits as a shim between Thunderbird and getdns. I can’t do a live
demo, but will show what I would show you if I had the confidence for the live
demo. Encryption: We took some effort to not write down the decrypted info into
anywhere persistent.  Which also leaves ciphertext to forward on later.
Signing: click buttons.  We wanted to learn with the buttons, e.g. there is
telemetry when you push, and users can opt-in to share usage behavior for
research. Really quck, but not “beat that dead horse”

Daniel Kahn Gilmore (DKG) - thanks for doing this.  Seems like it’s about key
distribution (SMIMEA) and tbird has built in.  Why not use tbird’s built-in
stuff? Ans - the engineers found the SMIME support that was there was very
good, but easier to not crack it open to put DANE inside.  This was fast for us.

DKG - I contribute to enigmail, and yes, it is a complete pain, but still the
right thing is to crack it open.

Sean Turner - how many people are using yet?
Ans - mostly aspiration for users so far, but we will soon release.

Sean Turner - the way you made some stuff up and held your nose is great, just
right for a prototype. Ans - the dogfood was delicious.

Dave Crocker  (relayed from jabber) - DANE is domain based and SMIME is user
based - how does SMIMEA work given this? Ans - There’s a domain in the name,
but the entries are on a per-inbox basis.  We found it interesting to have more
granularity.

Rick Lamb: great work.  How far off till we see something like this from
Outlook?  Suggestion to show an Outlook one at RSA, e.g. Ans - we hope this can
be useful to others as a reference implementation.

Phillip Hallam-Baker - would like to meet to see how this works compared with
my own DANE SMIME proxy.  Strong email addresses, put hash of cert in the email
addresses.  Would like to map the hashes together. Some way of saying in the
fingerprint, what algo?  Could we come to some agreement, so we sync up on
this? Ans - Good idea to meet.

Dave Crocker  (relayed) - per user labeling not in the spec?

Ólafur - openpgp and SMIME doc use same hashing of email addresses
Russ  Housley - Sean has a draft about the hashing.  Thanks for this work and
for separating sign and key management: they are different and don’t have to be
together, so they should not have to. George Michaelson - Eric, you are looking
really hot!  What happens when people retire a key, is this taken care of? Ans
- It is taken care of in the prototype.

Update on SMIMEA Draft - Jakob Schlyter
-----------------------------------------
We thought with 07 we were done, but up came this stuff form Eric and others. 
Not much discussion.  Then some more.  Let’s discuss via an updated use case
document.  We need more attention on it.  We have some proposed text to change
07 with the new use cases. One other item should get on the table: 
coordination of the SMIMEA and openpgp drafts.

Paul Wouters - for openpgp, we have a code assignment and implementations. 
What coordination are you looking for?

Jakob Schlyter - some of the proposals to update 07 would touch the packet
format.  The revocation part could apply to PGP as well.

Paul Hoffman - and note that none of the uses cases in the current document
specify SMIME versus openpgp, that’s why there might be coordination.  We don’t
know until we get through the use case document. End of their talk.

Ólafur - we will talk about how to take this work forward.  Do we need to wait
for implementations?

Enterprises Viewpoint (one slide) - Scott Rose
---------------------------------------------------
Scott Rose - this is about large enterprises, slow-moving, with entrenched
interests.

Points:
1. The need to associate keying material with a function. This isn’t really
about revoke but about whether a cert is acceptable for some function (and then
maybe no longer acceptable for that function).  Example - a cert is OK for some
purposes, but not for encrypted email due to some institutional need. That
granularity of association with a function, it is not just the status of the
keying material. 2. The need to communicate across domains, not just within. 
DIRECT (a US Health and Human Services electronic medical record program) had
to de-scope because this was so hard, though they have ended up being able to
use the DNS CERT record for discovery. 3. The desire to leverage existing
identity management - for instance, the US might want to include the 6 million
US federal employee PIV(?) cards into the DNS. The current use of LDAP servers
works inside domains, but does not work beyond a domain - we think SMIMEA could
be a killer app. In summary, The Enterprise.

Ólafur - goal of this work is to make it easy to use encryption technologies
across the whole universe.  If I want to send Scott Hollenbeck a signed
message, I currently have no idea how to do this, even though I know his email
address.

Sean Turner - I want to have the encryption part magically figure out where my
email peer’s cert is.  I have a small enterprise, but talking to anyone else is
a pain.  We should get it working

Paul Wouters -  I would like to map the subject line into our planning on
this..  Don’t forget to encrypt the subject, most tools leave it in the clear
these days. Subject of the email leaks info.

Paul Hoffman - encrypting of the subject works if you work this as an encrypted
MIME message - external subject has nothing, the real subject is in the
encrypted part.  Poorly implemented in present tools, agreed.

Daniel Kahn Gilmore (DKG) - I’m concerned with this discussion of putting
individual’s keys into the zone.  Enumerablity of zones in DNSSEC.

Mark Andrews - we could use NSEC3 and not have them so.

DKG - NSEC3 makes enumeration harder, but it has been broken; look at the
nsec3walker tool.

Mark Andrews - put in fake labels and it is hard to walk the zone.

DKG - this is defeated too - you pre-list typical names and you can force
through to walking the zone.

Paul Hoffman -  remember that SMIMEA exists in a world where you can find out
if someone has email by probiing with an email to see if it exists, so there is
already a necessary exposure.  An enterprise may have to look at the tradeoffs
and perhaps limit to the smallest set the people whose keys are in the DNS.

Warren Kumari -  couldn’t an enterprise put in fake labels?

Paul Hoffman -  yes, that is what people do with NSEC3.  But even if
enterprises can prevent a dictionary attack, they can’t prevent the email
probe.  Concern for the enumeration of individuals is why we started with plain
old email left sides but instead went with hashed ones.  Just because some
enterprises have a walkthrough problem, that is not a reason for not doing the
keys in the DNS.

DKG -  the probes are an online attack, whereas the breaking of enumerability
is an offline attack.  Enterprises have a harder time to defend against the
offline attack.  Proposals exist with online signing, e.g. the NSEC5 research.

Victor Dukhovni (by jabber relay) - Early on, I proposed a salt to prevent
rainbow tables ,and peoeple objected, but it would address this concern.

Ólafur - the consensus is that this is important work.  People need to supply
info and text, state usage cases.  We must try to wrap up reasonably soon.  We
will do the right thing.

Eric Osterweil - we have sent some suggested text and running code.  What else
should we contribute at this point?

Ólafur - we will consider all submitted text.  There has been a sort of
educational gap.  People from DNS comm, email comm, R&E comm are all relevant
here.

Paul Hoffman - I’m confused about what next.  Eric and Doug and Scott have an
enterprise use case draft.  Why don’t we discuss the long and well-thought
draft that exists rather than start again on this.

Ólafur - yes, start with it.  But if Dan York or someone has other usage cases,
they should bring them.

Paul Hoffman  - comment on the existing draft and also do those individual
contributions.  Great place to start

Warren Kumari -  we worded this badly [not sure what followed here]

Paul Wouters -  I’m really concerned about the IPR.  I don’t want to take  a
document from someone who has an IPR problem.

Andrew Sullivan -  hard to see what possible encumbrance is relevant for a use
case.

Warren Kumari - wrt, what does an IPR statement mean to this, we have been
working to get clarification on this.  Is Brian Haberman in room?

Brian Haberman -  where do you want me to start?  What I can say?   Despite
everyone buying into the Note Well, it’s apparent that people haven’t read the
BCPs.  I find the behavior of refusal around this astounding. But people are
learning about new processes, so don’t attribute to malice.  The IPR tool
allows not declaring the license, and that is on purpose.  Do not bash people
over the head on any of this.

Warren Kumari -  if people are sufficiently concerned, another document is an
option.

Ólafur relayed from Stephen Farrell - he agrees with what Brian said.

Warren Kumari - we’ll entertain other docs, and we’ll get clarification on the
licensing.

Paul Hoffman - then you want us to wait for the mailing list?  I suspect people
didn’t read something yet, but there are interesting issues that will cause a
long line at the mic if you want a long interesting discussion.

Warren Kumari - let’s do it now even if uncomfortable.  Better in back and
forth.

Jakob Schylter - just to confirm, we will not proceed with SMIMEA until the use
cases are ready.

Ólafur - that’s right.

Phillip Hallam-Baker - I don’t  understand what IPR thing is being referenced. 
But during DKIM, I proposed every single possible use of DNS and keys you can
imagine, and there is prior art of pretty much everything.

Burt Kaliski - To the extent that these cryptic references to IPR decrypt to
Verisign, I want to say that Verisign is in full compliance with the IETF’s IPR
policy and if anyone has concerns, then please talk to me.

Andrew Sullivan - most people haven’t read the use cases draft, as it wasn’t on
the agenda.

Paul Hoffman -  the use cases draft regardless of the authors talks about stuff
that has been true for well over a decade.  There’s a topic in there that will
cause long lines at the mic, but the issues  are old, and there could be an IPR
issue.  If the chairs want to get the WG riled up,  this will do it.

Andrew Sullivan - I’m  way less concerned on this, and I still don’t know what
IPR on a use case is.

Allison Mankin - Given that the draft was not put onto the agenda, and IETF
really likes people to read the draft before discussions, I suggest using the
technique that so many other WGs do, a virtual interim meeting.  This will also
mean that email folks can participate who aren’t in the room today.

Danny McPherson -  I agree with Andrew.  We appreciate Paul Hoffman’s interest.
We are not alone.  There’s been a lot of dialog on the mailing list around
these use case things.  I’d like to remind the chairs and editors that they
work for the WG, so please do be responsive.

Ólafur - we will have a virtual interim; it will not be when Warren is in HK,
even though Warren asked for the excuse to miss.

SRV Update - Matt Miller
----------------------------
Changes are small.  We think this is ready for WGLC.
Ólafur - we’ll issue a WGLC for this and SMTP jointly, starting this week. 
Four week WGLC.  Any comments in the room now will count as WGLC comments.
There are NONE.  Five people must review and comment on both docs.  Please
address the issue of what cross-document consistency is needed as well as your
own comments. Review Volunteers:  Paul Hoffman, Sean Turner, a person whom I
couldn’t recognize. Viktor Dukhovni (relayed by jabber) - what about OPS, it’s
also ready, and SMTP references it. Ólafur: it  will go next, right after the
SRV and SMTP.

DANE Deployment Observations - Dan York
------------------------------------------
The rationale - DNSSEC is a broccoli tech but it’s not exciting to eat.  DANE
more like the spam misubi.  You need to eat broccoli if you want your tasty
cookies (or spam). Stuff happening - note there are now hosting providers
advertising DNSSEC and DANE - German ads. What can we learn from active
deployment, roadblocks, challenges, things we could do to improve things. Maybe
we’re done when the docs are finished.  Or is there more we could do, or in
other WGs? Dan’s draft has a list.   One of the biggest, being able to add TLSA
through managed DNS services. Developer libraries - we have the getdns API.
Crypto concerns - we’ve seen a well-known DNSSEC critic complaining about our
1024 bit keys (DJB). Stephane pointed out lack of TLSA monitoring. Ops issues
as pointed out by Viktor.  That fact that use of EC results in appearance of no
crypto in many cases still.  M Ströder said don’t underestimate how much the
lack of DNSSEC support matters. Reality around the hosting issues.  Discussion,
thoughts?

Eric Osterweil - some things we discovered when playing with SMIMEA, doing diff
types of crypto services gave us different lessons.  Please produce new
records, learn about them, get to “play”.  Let’s not be “super-circumspect” as
some lessons can only be learned by developing and trying.

Viktor Dukhovni (relayed) - in Germany, DANE is being promoted.  How to get
efforts like this in other jurisdictions.

Peter Koch -  the response to lack of deployment is not more stds.  Operators 
don’t like moving targets.  One part of the “success” in DE is that the SMTP
part can be done under the hood.  End-users need no exposure to DNSSEC.  And
even so registrars get exposure and experience.

Richard Barnes - candidly, the browser case for DNSSEC is not good.  Thinking
of TLSA, browser developers consider DANE mainly as an RR, and this means
concern about latency and  extra round-trips.  I propose that if we want the
browsers, we should revive Adam Langley dnssec-serialization draft, put some
RRs for DNSSEC proof into the TLS handshake.  Second point, even if we get
momentum, the crypto issue is big, the 1K RSA keys are very glaring.

Dan York - I’ve heard that too.

Jason Livingood -  wrt to documents, what about a DANE cookbook? 15-20 use
cases, and an example for each, showing how to.  To get to the next level, it
has to understandable by the average IT person.

Dan York - this has been a focus at ISOC, but more is needed.

Eric Rescorla - there’s a big problem when the TLSA certs are not domain-based
- you can’t just use DANE as pinning, so you might as well do the cert pinning
and not DANE.  [This was a very high-speed comment so it maybe Ekr said
something not quite like this…].

Sebastian Castro - in New Zealand we have a very big push involving registrar
solutions.  We had a registrar workshop and they said they are looking forward
to widely enabling signed zones for DANE.  We need to create progress and
demand by talking with people.  Check out activities.  NZ registrars DNSSEC and
DANE workshop 2014.

George Michaelson -  dnsviz is of enormous benefit, it should show TLSA.  SMIME
and well packaged crypto will be a major boost.  SMIMEA is fairly close to a
killer app (and I do not like to say things about killers apps). Also, while
not trying to bag any particular CA, we need to take blobs of trust material
out of the browsers.

Eric Rescorla -  There’s a trust relationship based on you getting the browser
from us.  A distributed trust hierarchy like DNSSEC is delegations.   In the
case of the browser CA, you can think of it that we (browser vendors) are the
single trust anchor.

Dan York - let’s not refight the trust anchors stuff here and now.

Wes Hardaker - I do a lot of monitoring.  It’s hard to figure out the tradeoff
of security and operational monitoring - what does good look like? Operators
are scared. They need to be able to watch traffic from afar, and that need may
be a preventer of deployment.  I also worry about Happy Eyeballs. 
Parallelization of lookups.  Get there.  Happy Eyeballs are heavily related to
operator fears. Wrt to trust anchor - every app must decide for itself.  MTA
[?] has decided not to trust the CA bundle.  Conflicting viewpoints exist, we
will have to acknowledge this.

Franck Martin - On the email side of things, one problem with DNSSEC is with
load-balancing, what big orgs need to do.  Push people to resolve correctly,
like in IPv6, fragmented packets.  Studies show people are worried about
fragmented pkts.

Dan York - a lot of us have said push on validation now. According to the Geoff
Huston trend charts, about 12% of queries now have dnssec validation.  Higher
in many countries.

Phillip Hallam-Baker - admin and strategic considerations.  We should have
close relationships to DPRIVE and TRANS.  Puts in a plugs for his DPRIVE
proposal.  Guarantee I can get stuff there even with middle boxes.  I want to
make sure this is a strong requirement.  TRANS - this is research built on
rsrch built on rsrch - putting DNS roots for a zone in a TRANS notary archive
could be incredibly powerful.  I can show you in math terms - have a look at a
paper of mine on my website.  Could solve a lot of DANE troubles.  I trust 50
root CAs, and don’t want to move to one, unless that one is me. That’s the
heart of my (PHB) projects.  However - yes, we have 3K organizations working as
CAs. Don’t think of them as competitors but as channels.  Their job is not
issue certs.  CAs are people who provide tech support to people who deploy
crypto.  A million, 10 million companies rare eached by that industry.

Dan York - the perception that DANE doesn’t apply to me as somone who buys
certs - more clarity or education around TLSA modes?

Viktor Dukhovni - where are we with the last mile problem with DNSSEC?

Dan York points to Warren to answer.

Warren Kumari - DPRIVE has multiple mechanisms that address the last mile. 
Also it is handled by getdnsapi.

Jim Gettys - Jason Livingood funded Simon Kelley to do DNSSEC in dnsmasq, but
you need to replace a lot of devices to get it deployed.  If local home is the
primary, he doesn’t have signing of the domain done yet.

Unidentified Speaker -  DNSSEC is out of research and in production now.  There
are vendors who can turnkey it, including the load balancing and CDN stuff. 
Deploy, stop fiddling, use.

Dan York -  some Akamai folks are here, and there is Ólafur’s beach BOF about
the CDN issues coming up.

Jim Gettys - as we get IPv6 deployed, and therefore return to e2e traffic,
naming begins in the home.  Make it home-easy.

Dan York - it sounds like we are mostly done, from a standards perspective.

Warren Kumari - we will finish the documents we have on our agenda.

Ólafur - our core document is done.

Paul Hoffman - I would flip around what Ólafur said - with the SMTP doc and its
deployment, there will be a bump in general TLSA deployment.

Dan York - returning to web browser comments earlier, and then underlining the
“under the hood” point made by Peter Koch:  will it be strange if the driver
for DNSSEC is DANE and the driver for DANE turns out to be SMTP?  Are there
other infrastructure things where DANE would be effective?  I know there is
work on DANE in SIP.

Eric Osterweil -  SMIMA is critical and  I have to echo George:  I can’t send
an email to someone I know well because I don’t know how to learn their key. 
The ops draft is for TLS in mail, not web TLSA (per core).  And SMIMEA is
different from TLSA.  If we want, we can identify SMIMEA as a high value
target, giving the world a service it doesn’t have yet.  And drag DNSSEC along
with it.

Viktor Dukhovni (relayed) - if you have suggestions for the ops draft, send
them asap to me and  Wes.

Matt Miller - for XMPP we are seeing a lot of (non-US) adoption.  Signing of
SRV, not so much DANE.  Stg going on.

Nico Williams (relayed) - the killer app for SMTP with DANE is MUA security
indicators and a button for “make this secure” (one button).  The killer app
for HTTP2 is harder to pin down and note especially that browsers trying to get
away from UI sec indicators.

Wes Hardarker - I encourages Eric Osterweil to respond about the ops document. 
It is meant to be generic.  There are now words for raw keys, but it should get
more, it’s supposed to be generic.

Eric Osterweil - I think that we have such a well-written draft is great.  Hard
to have an ops draft for things we don’t operate yet.  Could you say “this is a
TLSA perspective” instead of saying it’s the all DANE one, and then allow for
lessons not to be stated before we learn them.   Per Sean Turner’s comment,
whenthe  ops draft says don’t put keys in, just fingerprints, then we can’t get
the encryption key as needed.  Suggest to be specific to where we have learned
specific lessons.

Wes Hardaker - as we move to more TCP over time,  it will be possible to
downgrade the recommendation not to send certs but only fingerprints.  There’s
no other large-scale security solution

Viktor Dukhovni (relayed) - the ops document only says it updates 6698, so it
is* TLSA specific, not SMIMEA.  SMIMEA.

Sean Turner - close the draft and move on.

Paul Hoffman - what if we rename the ops draft “ops for servers.”  Wes and
Victor have done a good job, but it’s server-focused.  What Eric has found in
his early SMIMEA implementation and what Jakob and I have found in looking at
SMIMEA suggest a different ops draft for those.

Ólafur - we have been chatting with our AD and we’re approved interim meeting
Dec 2.  Stephen Farrell approved over jabber.

Open Mic Session

No takers.

Adjourn a few minutes early.