On Fri, Apr 13, 2018 at 12:16:43PM -0700, Jim Fenton wrote: > From reading the abstract and introduction to this draft, it appears to > be proposing mostly a performance improvement for retrieving web pages > using DANE authentication. There is some security improvement, but that > seems to be incidental to the performance improvement. That would argue > in favor of publishing the draft as-is. However:
It's not just a performance improvement. It's also a last-mile technology: for clients that cannot perform DNS lookups due to being in, e.g., hotel networks. And it adds security. Using DANE adds security, that's for sure, since one can then rely on both, PKIX *and* DNSSEC, which can only add security. Or, if one does not trust the WebPKI, then only DNSSEC. I have no opinion as to which of WebPKI alone, WebPKI + DNSSEC, or DNSSEC alone, is best, but I have an opinion as to who ought to decide that: the server operator. This document gives the server operator that power, but it does not give the server operator any power over client pinning behavior, which means that operators will not turn this on for apps where it's not mandatory. That is, without revision, this document really does not help security as much as with a rather minor revision. We should want that minor revision because the (at-this-time-intangible) gain is potentially large, while the (at-this-time-intangible) cost/risk of not making that revision is equally large. > From the discussion I have read, there seems to be disagreement about > what even the semantics of this pinning would be. And if it's unclear to Among proponents there are no disagreements over pinning semantics. Pinning would be only to the use of the _extension_, not to the use of DANE, nor to any particular DANE usage. That is, if the server does not have TLSA RRs, it could still use this extension [to satisfy a client pin] to send the denial of existence proof, and the client's pin would be satisfied. > the WG participants, it's going to be even less clear to others that are > implementing this. I am also of the opinion that pinning is somewhat How would that follow? Shouldn't we see proposed text before we can tell if it would be unclear to implementors? > subtle; it requires a detailed understanding of the mechanism to remove > (expire) the pin, and if done wrong can result in availability problems. Exactly! (A) gives us a modicum of pin-clearing capability: if you get a denial of existence then you could clear the pin on the client. However, (A) + (B) (i.e., (C)) would give us the ability to separate the pin set/clear from the DNSSEC payload of the extension. *This* would give server operators all the control they need to feel safe enabling pinning behavior. It is much simpler to change a TTL in a server configuration than to make changes in the relevant DNS zone(s). Thus (C) or some (C') (see below) would be much better than (A). > In addition, the pins here would be maintained in individual browsers. And other user-agents for other application protocols (e.g., MUAs). > There is less benefit from pinning because unlike some other pinning > mechanisms, there isn't any leverage of the TOFU experience had by others. TOFU works reasonably well. It's risky for an attacker to mount an active attack that will be detected if the client has a pin -- this risk acts as deterrent. > This requires further thought, and I do not support adding pinning to > this draft. Perhaps as a separate draft, but the WG needs to decide on that. I wouldn't mind a (C'): a variant of (C) where we get denial of existence and a one- or two-byte TTL (one by count of weeks or two-byte count of hours) with de minimis text about it, leaving pinning semantics to a separate document. In such a (C') we'd elide all pinning (or most*) in this document. * We might want to say that if the TTL is zero then the clients MUST NOT pin and must clear any pin. And we might do this in spite of not describing any pinning semantics -- explicitly leaving pinning semantics to a future document. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
