[dane] IETF-89 draft minutes

[Olafur Gudmundsson <[e-mail]>]

Unless we hear otherwise in the by March 24'th these will become the official minutes.
Thanks to Stephane, Olle and Dan for their notes. 

	Olafur & Warren 


IETF 89, DANE Working Group meeting
2014-03-06 
Chairs: Warren Kumari, Olafur Gudmundsson
Scribe: Stephane Bortzmeyer
Jabber Scribe: Olle Johansson 
Tweeter: Dan York 

Agenda in <https://datatracker.ietf.org/meeting/89/agenda/dane/>
With links to the slides at <https://tools.ietf.org/wg/dane/agenda>

0) Administrivia

The room is more than completely packed and many people are standing
(or waiting outside). Next time, a bigger room is needed.

1) DANE status, Managment changes, future direction

Co-chair Olafur Gudmundsson replaces Ondrej Sury.

The draft "registry acronyms" draft-ietf-dane-registry-acronyms is in
the RFC editor queue.

Four other drafts are active. The plans are:
1.1) SMTP draft-ietf-dane-smtp-with-dane in WGLC.  SRV draft-ietf-dane-srv
soon (15 april) in WGLC
1.2) SMIME draft-ietf-dane-smime + OpenPGP draft-wouters-dane-openpgp
(if adopted by the WG) : in WGLC on 15 may
1.3) DANE operations draft-ietf-dane-ops : decision in june?
1.4) IPsec draft-osterweil-dane-ipsec (if adopted) after

What after that? Shutdown? Many changes are expected before
june, so it is too early to decide. Paul Hoffman : lots of interest in
other WGs so, it would be unwise to shutdown. Discussion taken to the
mailing list (but nobody argued for a shutdown).

2) Working group Lookup documents

2.1) DANE SMTP by Viktor Dukhovni (Postfix)
http://www.ietf.org/proceedings/89/slides/slides-89-dane-1.pdf

Viktor reported a *lot* of open issues, discovered by the development
of DANE-for-SMTP but often not-SMTP specifics. Some examples: if DANE
publishes a full certificate, should we use only the public key in it
or also check the other fields of the certificate? Many combination of
options in DANE are strange and may be useless and require
explanations anyway. What if some keys are published with a different
set of digests?  Big CNAME issue: search the TLSA record in the
expanded name (after following the CNAME chain) or not? And what if
expansion is insecure (not signed with DNSSEC)?

Some details when implementing DANE on Postfix: don't do TLSA when the
base domain is insecure even if, in theory, the DANE domain name may
be secure, for instance with DLV). When Postfix receives a raw public
key, it builds a dummy certificate around it, to make its TLS library
happy. (See the draft on raw keys draft-ietf-tls-oob-pubkey, in RFC
editor queue)

Philip Hallam-Baker mentioned Certificate Transparency but it did not
seem to raise interest.

Crocker asked for a way for the client to signal the server which
algorithms it knows, so the server can know when to drop an algorithm.
Dukhovni disagreed, saying that DANE is complicated enough.

After a few certificate questions, the DNS ones : the main discussion
was (Peter Koch) about "fallback" to the first item in a CNAME chain
when it is insecure. Fallbacks are brittle and can be dangerous. (It
is the opinion of the minute taker that "fallback" is not the best
word to describe the algorithm proposed in the current draft.)

2.2) Using DNS-Based Authentication of Named Entities (DANE) TLSA
records with SRV and MX records.
Matt Miller 
http://www.ietf.org/proceedings/89/slides/slides-89-dane-0.pdf

Olle Johansson suggested that SIP has similar issues and that DANE
people should harmonize with SIP.

Someone suggested (jokingly, presumes the minute taker) to write a
NAPTR document for DANE...

A list of XMPP servers using DANE <https://xmpp.net/reports.php#dnssecdane>

2.3) Harmonizing how applications specify DANE-like usage
(DANE vocabulary)
Olafur Gudmunsson
https://tools.ietf.org/agenda/89/slides/slides-89-dane-4.pdf

Having a separate document, only with DNS vocabulary since it seems
under-specified, and varies wildly? This would introduce a delay. OK
for Paul Hoffman: I have issues such as changing DNSSEC vocabulary. We
should slow down the drafts, so we can fix the
vocabulary. Disagreement for Viktor Dukhovni : no delay is wished for,
the specification is ready.

Paul Hoffman suggested to public the current drafts, then write the vocabulary
document, then produce a -bis of the other documents. Taken to the
mailing list.

2.4) The DANE world model
DANE - key acquisition, service discovery or usage assurance?
Paul Hoffman
(No slides)

This was a more philosophical discussion (do note the W3C has an
explicit Philosophy Working Group
<http://www.w3.org/community/philoweb/>). Now that DANE is used for
other things than the Web, we have many questions. Biggest one in the
discussion, "DNS : delivery or discovery?" It seems there is no
consensus, one of the reasons being that there is no clear definition
of either.  Many people do not see the difference (Dave Crocker: no
difference. A lookup with A is the same as a lookup with SRV).  Some
people says there is one and that discovery is bad, is not "proper use
of the DNS". For instance, on XMPP, Andrew Sullivan said "there's an
ambiguity in 'discovery'.  Some of it is 'discover service at this
owner name' and some of it is 'find the right owner name for this
service'.  Most of the DNS anger is directed at (2) because it
requires tree-climbing."

It is not only philosophical, it may have security consequence if the
data in the DNS and in TLS disagree. Also, does it mean we can use
DANE to find out if we are supposed to connect to the peer with TLS?
Tony Finch: a TLSA record also means you expect people to use TLS (no
consensus on that).

Peter Koch said it is neither delivery or discovery, DNS is lookup,
you need a fixed identifier to starts with. He pointed out another
ambiguity: domain can mean a subtree or a domain name (a node).

Andrew Sullivan suggested also to start on a new work item: "Semiotics
of DNS names from an architechtonic lead user's, pan-applicationist,
IntraSuperSemioNet, post-modernist perspective" :-)

For this issue, there was one question by the chairs: do we need to
document this? The hmmmm clearly says yes and there was four-five
volunteers to work on it.

2.5) Using DANE to Associate OpenPGP public keys with email addresses
Paul Wouters
https://tools.ietf.org/agenda/89/slides/slides-89-dane-2.pdf

There is running code on
<http://people.redhat.com/pwouters/hash-slinger/> (and Github
<https://github.com/letoams/hash-slinger>) + a milter for Sendmail and
Postfix.

Biggest issue in the discussion: the TLSA record is found at a domain
name which is the user's email address (actually, a hash of it). Since
the left part of an email address is case-sensitive (in theory: Paul
Wouters asked if there really was SMTP servers which care about case
and got not reply), matching is less trivial thaan it seems ('echo -n
"jAkOb" | openssl sha -sha224' ?)

Mark Andrews claimed we should define canonicalization rules. Not
doing so is "lazyness". Paul Hoffman disagrees, canonicalization is
not easy (internationalized left parts) Taken to the mailing list.

The two OpenPGP documents are asking for adoption.
draft-wouters-dane-openpgp and draft-wouters-dane-openpgpkey-usage
both got a strong hmmmmmmmmmmm.

2.6) IPSECKEY / Auth_none
Paul Wouters
http://www.ietf.org/proceedings/89/slides/slides-89-dane-3.pdf

Just information, no decision

2.7) IPSECA
Eric Osterweill
(slides not available)

draft-osterweil-dane-ipsec

One of the goals is harmonize IPsec key learning with DANE. For
instance, IPsec keys are currently host-specific while DANE keys are
port-specific. Not many reactions