Subject: [dane] IETF-89 draft minutes

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 12 Mar 2014 16:58:54 -0400

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 14 Mar 2014 02:02:36 +0000

On Wed, Mar 12, 2014 at 04:58:54PM -0400, Olafur Gudmundsson wrote:

[ Comments clarifying the minutes, I'll open separate threads to
  discuss each issue. ]

> 2.1) DANE SMTP by Viktor Dukhovni (Postfix)

And Wes Hardaker, though I got to present this time, the drafts
(and slides) are joint work.

> or also check the other fields of the certificate?

The phrasing above is a bit misleading.  More accurate:

    * With DANE-TA(2) and DANE-EE(3), should the content of the
      matching trust anchor or end-entity certificate be used in
      validating the server chain, beyond the extent necessary to
      match it with the TLSA record (either exact comparison of
      DER encoding with matching type 0, or comparison of the digest
      of the certificate or SPKI.

	- Does this depend on whether the selector is Cert(0) or SPKI(1)?

    * With DANE-EE(3), whether we ignore the rest of the certificate
      or not, at the very least the client MUST NOT enforce name
      checks or expiration, which are handled via DNSSEC.

> Many combination of options in DANE are strange and may be useless
> and require explanations anyway.

I think what I actually said that is vaguely along these lines is:

    * What does "IN TLSA DANE-TA(2) SPKI(1) Full(0)" mean?  Are
      clients expected to be able to perform validation with "bare"
      keys (when the TLS server's chain does not contain a matching
      certificate, but rather contains only a certificate signed
      with said key).

    * Later I suggested that applications should typically support
      only one of the pairs of the usage pairs: {(DANE-TA, DANE-EE),
      (PKIX-TA, PKIX-EE)}.  Supporting both gives you the intersection
      of the security properties and the union of the interoperability
      issues (i.e. generally a bad idea).

> What if some keys are published with a different
> set of digests?

    * There has been little discussion of digest algorithm agility.
      Given the new BCP for protocol authors, it is clear a spec
      is needed.

    * The approach proposed requires server operators to publish
      TLSA records (when more than one digest algorithm is employed)
      in a compatible manner.  The question was "what to do if they
      don't"?  (Discussion in separate thread).

> Big CNAME issue: search the TLSA record in the

The CNAME issue is I think no longer particularly controversial,
but people need to read the SMTP and OPS drafts and make sure we're
not missing anything.  What happens (proposed) when the CNAME chain
is insecure is that the origin is the candidate TLSA base domain.
Ditto when the chain is secure, but no TLSA records are present there.

> be secure, for instance with DLV).

This needs to be done in all protocols where DANE is not mandatory.
Otherwise, DNS lookup failure with TLSA RRs will be observed with
bare-bones nameservers in dns load balancer and related kit that
cuts corners on DNS code.

> 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)

Right, this is "2 1 0" support, when the peer's chain has no matching
cert, just things signed under the key (see above).  The group has
to decide whether clients are expected to go the extra mile to
support this (like in Postfix).

> Philip Hallam-Baker mentioned Certificate Transparency but it did not

To be fair, I mentioned that CT is specified out of scope for
DANE-TA(2) and DANE-EE(3) in the ops draft.  Phillip believes that
it is possible (and therefore desirable) to support CT in these
cases.  I contend that it is not possible to apply CT to private
CAs and private leaf certs.

> Dukhovni disagreed, saying that DANE is complicated enough.

This would have to be done in band in either the application or
TLS protocols, even though DANE is an out-of-band DNS policy
mechanism.  So this would be a DANE-specific TLS extension, that
servers would have the option to log in some manner for later
analysis.  Now in TLSv1.2 clients already send digest names, but
they are TLS digests, and need not be the set of digests supported
for DANE matching types.  I don't see this working cleanly...

However such signalling can be specified later, we can hope SHA2-256
will last long enough for most clients to upgrade to the protocol
versions in which such signalling is supported.

> word to describe the algorithm proposed in the current draft.)

Right, this is not exactly fallback to lower security, rather this
is a search for applicable TLSA records in multiple (either one or
two) candidate locations.

-- 
	Viktor.