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

From: Stephen Farrell <[email-masked]>
Date: Wed, 03 Jun 2015 15:14:55 +0100

Hiya,

My review of this is below. I'm fine with starting the IETF LC
and you handling these as last call comments along with others
but since there are a bunch of 'em (and I bet Viktor will not
be silent anyway:-) please tell me (Warren, as shepherd) if you
prefer me to start the IETF LC now, or wait until we've chatted
about these a bit. (And I'm fine either way.)

Cheers and thanks for the work on this,
S.

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

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

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

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

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

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

- 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.  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.) In the absence of evidence I think we
should omit these (and they are not needed.)

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

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

- 5.2.1: 2nd para says "do honour constraints" but
earlier (for DANE-EE+Cert) you explicitly said to
ignore validity, subject etc. 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.
As-is, I suspect developers are likely to randomly
either ignore validity and naming here too, or
not;-) 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.)

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

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

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

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

- 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. 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. I'm not saying that's a better
transition but only that it could presumably be done
and arguably easier if it worked. But the only
change I'd suggest for now is to just point out that
a new key pair is generated for this example.

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

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

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

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

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

- 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?
If to, 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?

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

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 4 Jun 2015 14:22:51 +0000

> has a good idea about how to make it easier to read.

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

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

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

> this) but I don't care that much really.

This can probably be made shorter, ...

> I'm not sure what it means, but it's not quite

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.

> version is a SHOULD and is currently 1.2?

Or just "TLS 1.2 or later".

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

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

> logic" - wouldn't it be better to explain? If 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.

> 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

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.

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

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

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?

> so maybe drop the 2119 "SHOULD NOT"?

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

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

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

> are transitioning from DANE-EE to DANE-TA.

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

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

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

> whether that means 2119 or not. I don't care how you

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

> worth a bullet of its own

Sure.

> to be a useful summary - its a doozy of a sentence

Yeah, I can give that another go.

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

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

> 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

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

> WebPKI/ would be more accurate

Sure.

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Jun 2015 00:59:41 +0100

So I didn't see a response from the shepherd and since I'm
heading off now on holiday I've asked for the IETF LC to be
started. I'd like to continue this discussion when I'm back
after IETF LC. (And yes I saw Viktor's response but haven't
had a chance to get back on that sorry)

Cheers,
S.

On 03/06/15 15:14, Stephen Farrell wrote:
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
> 
>