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.
- [dane] AD review of draft-ietf-dane-ops-12 Stephen Farrell
- Re: [dane] AD review of draft-ietf-dane-ops-12 Viktor Dukhovni
- Re: [dane] AD review of draft-ietf-dane-ops-12 Stephen Farrell