Re: [dane] AD review of draft-ietf-dane-ops-12

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 04 June 2015 14:22 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEB11B3536 for <dane@ietfa.amsl.com>; Thu, 4 Jun 2015 07:22:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caH3vcp6-jFn for <dane@ietfa.amsl.com>; Thu, 4 Jun 2015 07:22:53 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F92E1B353F for <dane@ietf.org>; Thu, 4 Jun 2015 07:22:53 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AC465283031; Thu, 4 Jun 2015 14:22:51 +0000 (UTC)
Date: Thu, 04 Jun 2015 14:22:51 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20150604142251.GI5090@mournblade.imrryr.org>
References: <556F0BDF.6090603@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <556F0BDF.6090603@cs.tcd.ie>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/7rpWHMnxllmacunsQyjICB_WB1I>
Subject: Re: [dane] AD review of draft-ietf-dane-ops-12
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jun 2015 14:22:57 -0000

On Wed, Jun 03, 2015 at 03:14:55PM +0100, Stephen Farrell wrote:

> - general: this was a bit of a slog - the draft is
> both dense (loads of 2119 terms) and long, which
> makes it a hard read. I'm not saying it's possible
> to do better, but just noting that in case someone
> has a good idea about how to make it easier to read.

I'm open to suggestions and will give this some more thought.

> - intro, 3rd para: I don't think this is very clear
> and it'd be great if it were - isn't there a way to
> provide clarity about the name that goes with the
> TLS session in which cases?

While the intent is primarily to raise the issue, this could be
more specific.  I'll try to improve this.

> - 1.1, I think you need to define "TLSA base domain"
> here (or is it elsewhere? I didn't find it in 6698)

It is step 3, near the top of section 3, but is not really singled
out as a definition:

   3.  The base domain name is appended to the result of step 2 to
       complete the prepared domain name.  The base domain name is the
       fully qualified DNS domain name [RFC1035] of the TLS server, with
       the additional restriction that every label MUST meet the rules
       of [RFC0952].  The latter restriction means that, if the query is
       for an internationalized domain name, it MUST use the A-label
       form as defined in [RFC5890].

I'll add a definition to the terminology section.

> - section 2: Why duplicate so much of 7218?  I think
> it'd be better not to (or to obsolete that with
> this) but I don't care that much really.

This can probably be made shorter, ...

> - section 2: last sentence before 2.1 - is that
> saying that the MUST applies to section 9? If not,
> I'm not sure what it means, but it's not quite
> clear.

Quote:

   Server operators MUST publish TLSA RRsets that are compatible
   with digest algorithm agility.

While, Section 9 says:

   To make digest algorithm agility possible, all published DANE
   TLSA RRsets MUST conform to the requirements of Section 8.

so the quoted text in 2 ultimately refers to the requiremens of
section 8 as illustrated by the examples in the sub-sections.

Perhaps forward references to sections 8/9 would help.

> - section 3: saying TLS1.2 is a SHOULD is fine but
> what about when TLS1.3 is done (next year).
> Wouldn't it be better to say that the latest TLS
> version is a SHOULD and is currently 1.2?

Or just "TLS 1.2 or later".

> - section 4: I read this as you calling DNSSEC
> "illusory incremental security" which I don't think
> is really what you mean and which interpretation
> calls into question the strength of the
> RECOMMENDATION here.

Illusory additional security by comparison with DANE-TA/EE.  That
is, this text calls into question whether PKIX-TA/PKIX-EE have any
value when the client also supports the DANE-TA/EE usages.  Any
additional perceived security from a public CA signature is illusory
when it is optional.

>  4.1 similarly says "PKIX-TA(0) and PKIX-EE(1) TLSA records do not provide
> additional security" which is too definitive, where is the evidence? (Not
> opinion or argument, but evidence.)

My university training was in pure mathematics.  For me a compelling
logical argument (proof if you like) is better than mere empirical
evidence.

I stand by the claims in the draft.  When DANE-TA/DANE-EE are
acceptable (web-PKI CA signatures are optional), any successful
attack on DNSSEC can simply replace PKIX-TA/EE with DANE-TA/EE.

Insisting on additional Web-PKI CA checks is pointless when one
relies on DNS records to enable these checks.  If DNSSEC is not
compromised, then DANE-TA/DANE-EE are sufficient (and less prone
to failure due to mismatched trusted CA, problems with building
chains, ...).

> - 4.2: Did we check that CT is unlikely to make
> sense with DANE-TA records? In principle, public
> logs could add enterprise CAs without having real
> spam issues. I agree it's unlikely to happen in
> practice, and it's probably fine to revise this if
> that starts happening a lot, but since it could in
> principle, I wondered if we'd checked with the trans
> list (and I don't recall that we have)

This was based in part on feedback from Ben Laurie who at the time
agreed that CT was only for public CAs.  And it seems rather unlikely
that anything different will happen for some time.  If something
different happens in the future, we can publish a suitable update.

> - 5.1, last para: that's a bit coy about the "extra
> logic" - wouldn't it be better to explain? If not,
> why not?

I've seen little evidence of DANE implementors going the extra mile
to handle rare corner cases (on the contrary implemetors are rather
lazy and make many, sometimes critical, compromises).

So I expect that unless I end up contributing DANE support to all
of OpenSSL, LibreSSL, mTLS (formerly PolarSSL) and GnuTLS, ...  at
least some of these will not jump through hoops to support RPK with
"3 0 0" TLSA records.

> - 5.2.1: 2nd para says "do honour constraints" but
> earlier (for DANE-EE+Cert) you explicitly said to
> ignore validity, subject etc.

ONLY and EXCLUSIVELY when a certificate or public key is matched
via DANE-EE records.  It would be folly to suggest that DANE-TA(2)
trust-anchor issued chains should bypass leaf certificate validation.

> I think it'd be better
> to explicitly say here whether or not validity and
> naming need to match and if they do, then how.

With DANE-TA(2), a trust chain is constructed in the usual way,
from the certificates sent by the peer, which must include the
TA certificate, plus any required intermediates.

> As-is, I suspect developers are likely to randomly
> either ignore validity and naming here too, or
> not;-)

I don't think there's any suggestion to skip name
checks or expiration checks for usage 2.

As for implementations other than mine, they almost universally
totally mess up usage 2, and don't even build a chain!  They just
check that the peer sent some matching certificate along, whether
there's a chain from that to the server keys or not!

So any hope that a typical "developer" will get this right is
unfounded.  Instead we need to integrate robust DANE support into
TLS toolkits, so that "developers" aren't tempted to implement DANE
for themselves.

> And if enough of 'em do different things,
> then that'd be bad. (If there were a good list of
> subsections of 5280 to honor or ignore that might
> work, but would be a bit tedious to figure out and
> might not work - I've not checked.)

For DANE-TA(2), they need to apply everything from 5280 in the
usual way, except that the trust-anchor is part of the peer chain
and is trusted on the basis of a matching DNSSEC TLSA record.

In Postfix (and the related ssl_dane library on github) I specifically
disable all lookups against the local trust store when doing
DANE-TA(2).  This makes the behaviour more predictable, and
discourages blame-shifting by server system operators who might
say that thir setup "works for everyone else".  If you don't include
your TA in the wire certificate message, verification *will* always
fail.  This is better than failing some of the time.

> - 5.2.3, last para: What is "are encouraged to" in
> 2119 terms?

Good question.  I don't know the answer.  Postfix and ssl_dane
support this.  I've not seen it done by anyone else.  So I am not
comfortable promising server operators that this is likely to work,
but at the same time arguably clients SHOULD do this.  Is SHOULD
sufficiently weaselly to allow various implementations to punt on
this?  Or do I need to raise the bar for clients and make this a
requirement?

> - 5.4: "SHOULD NOT always stop" isn't clear, and the
> next sentence seems to have the MUST that clarified,
> so maybe drop the 2119 "SHOULD NOT"?

Fair enough, I'll take a stab at fixing this.

> - section 6: what is a "master" TLSA record?  Maybe
> better to not introduce a new term like that.

Yes, the word "master" is unnecessary and counter-productive.  I
think the idea here is that aliases to records at the provider are
not "master" records, but there are better ways to say that.

> - section 8, 2nd para: saying "are only compatible
> with" seems like an overstatement to me

The ONLY other potentially compatible TLSA parameter combination
is "3 0 0", from which a public key can be extracted.  The draft
suggests not to expecting this to work.

> - 8.2: I think in this example you generate a new
> key pair for the TLS server at the time that your
> are transitioning from DANE-EE to DANE-TA.

Yes, that's often unavoidable, when the DANE-EE(3) cert is
typically self-signed.

> Saying
> that would help, as there could be another
> transition case where the same TLS server key pair
> is maintained and an x.509 certificate (issued under
> the DANE-TA) for that same key is deployed on the
> TLS server.

Sure, there is a simpler transition in which the DANE-EE
chain is aleready signed by the desired TA, that'll be
rare, but can be mentioned.

>  But the only
> change I'd suggest for now is to just point out that
> a new key pair is generated for this example.

Tried to do that by using the phrase "new chain".  If that's not
clear enough, a longer phrase or sentence can be inserted.

> - 8.3: lowercase "should" often confuses as to
> whether that means 2119 or not. I don't care how you
> resolve.

SHOULD will work for -13 (before or after IETF LC as instructed).


> - 8.4, I think last sentence of 1st bullet could be
> worth a bullet of its own

Sure.

> - 8.4, I'm not sure the last bullet is clear enough
> to be a useful summary - its a doozy of a sentence
> in any case;-)

Yeah, I can give that another go.

> - section 9: your background is showing:-) "by the
> MTA administrator" should presumably be "on the TLS
> client (e.g. by an MTA administrator)" or similar.

Oops, thanks.  Originally there was only one draft covering SMTP,
OPS and more.  This slipped through the surgery that created two
separate drafts.  Will fix.

> - 10.1.1: I guess we don't consider that it'd be
> good to give a reference to the TC bit? I'm ok with
> that but someone else might like to have one.

No strong opinion on my part.  I just thought it is well known that
that one should avoid DNS UDP fragmentation whenever possible.

> - 10.2: "The server name used for this comparison
> SHOULD be the base domain of the TLSA RRset." I
> think that works ok, but isn't that a change in
> client behaviour compared to a non-DANE TLS client?

In some cases yes, but the server has published TLSA records at
the base domain, thereby designating that base domain as the
appropriate name for the service endpoint.

For HTTP, almost always the TLSA base domain will be the same as
the domain in the URL.  However, in the presence of "secure" CNAME
chains, and TLSA RRs at the expanded CNAME, the client will expect
the expanded name primarily and may also match the original name
secondarily (as in the SMTP and SRV drafts).

The specifics were left to individual protocol documents, if
none are expected to be forthcoming from working groups describing
how apply DANE in their particular application protocols, we could
state a default approach (allow either domain as with SRV and MX).

> If so, then don't you need to call that out much
> more clearly? Do we actually need a "differences
> between DANE TLS clients and non-DANE TLS clients"
> section?

I don't think we need a "differences" section, but we might
need a default when there is no application-specific standard.

> - section 11: I think s/public CA PKI/public CA
> WebPKI/ would be more accurate

Sure.

> - section 11: I don't get the logic for recommending
> weekly signing - once you automate signing (which
> you have to) then daily seems like it should work
> for everyone and weekly hasn't any benefit. So I
> don't get the reasoning here. (And a week seems bad
> when I read section 13 too.)

The problem is that signature validity needs to be larger than the
"expire time" in the SOA record to avoid secondary nameservers
routinely publishing records with expired signatures.  And that
time needs to reflect operational reality (how quickly is
synchronization between primary and secondary servers restored when
it fails).

For professionally operated domains, this time can be short.  For
smaller domains (such as mine) with arms-length secondary servers,
very short signature lifetimes are impractical.

-- 
	Viktor.