Re: [dane] IETF-89 draft minutes

[Viktor Dukhovni <[e-mail]>]

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.

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

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
> expanded name (after following the CNAME chain) or not? And what if
> expansion is insecure (not signed with DNSSEC)?

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.

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

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
> seem to raise interest.

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.

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

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.

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

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.