Subject: [dane] RPK use-case high level problem statement

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Jun 2014 23:59:16 +0000

Perhaps we can at least agree on the high-level problem statement:

    1. Some clients will support both X.509 and RPK TLS handshakes,
       and will opportunistically negotiate RPK as an optimization.

    2. Some subset of those clients with use DANE authentication to
       authenticate whichever of X.509 or RPK is negotiated.

    3. Some subset of servers will have TLSA RRsets during transition
       states, not currently defined as "misconfigured", such that
       X.509 DANE TLSA authentication works, but RPK DANE TLSA
       authentication fails, because the RPK-compatible TLSA RRs
       match only past or future keys.

    4. Somebody (client, server or both) should do something to avoid
       unnecessary application failure under the above conditions.

    5. We should probably write-up the potential problem cases,
       and spell out client and server responsibilities and strategies
       to avoid the problem cases.  Either client is conservative
       and avoids opportunistic RPK, or server avoids publishing
       potentially problematic RRsets or both.  We should probably
       not recommend "retries" see [Footnote], but for some clients
       retries might be a viable strategy.

-- 
	Viktor.

Footnote:

    Client retries will typically be futile, because a DANE authentication
    failure with RPK for past/future keys cannot be distinguished from
    other reasons for the server keys not matching.  Clients that retry
    will often fail to authenticate even after negotiating the use of
    X.509 keys.

    Retries are also difficult to hide in client libraries, because
    often connection management is done by the application, while
    the TLS protocol engine is handled by a suitable library.  Thus
    applications will have to be willing to retry, and somehow know
    to tell the library to avoid RPK the second time around.
    Connection setup can be expensive, and reconnection difficult.

-- 
	Viktor.

---

From: John Gilmore <[email-masked]>
Date: Thu, 05 Jun 2014 19:13:24 -0700

>        and will opportunistically negotiate RPK as an optimization.

Agreed.

>        authenticate whichever of X.509 or RPK is negotiated.

Agreed (s/with/will/).

>        match only past or future keys.

I do not agree with this and am still awaiting a communication from
you about why you think this will occur.  Normally, key transitions
are done by moving from publishing "current" keys, to "current/future"
keys by adding the future keys.  Those then become "past/current" keys
when the server's key itself changes, and then are moved to "current"
keys by dropping the past keys.

At no point do the TLSA records in a key rollover include only
"past/future" keys.  TLS would fail if they did so.

>        unnecessary application failure under the above conditions.

Disagree, based on not seeing why 3 is anything but a mistake made
by naive or unskilled administrators.

>        retries might be a viable strategy.

I thought we had already done that by explaining in detail how to do
key rollovers.  See Appendix A.4 of RFC 6698.  If you try to change 
keys and you do it wrong, your service will become inaccessible.  The
cure is to do it right, not to contort the protocol.

PS- you do the same rollover process when changing the "A" record of
your server.  This is not specific to TLSA, DANE, DNSSEC, or RPK.
Would you argue that the protocol should somehow accommodate
administrators who, while trying to change their A record from 1.2.3.4
to 5.6.7.8, somehow foolishly publish 1.2.3.4 and 9.10.11.12?  Of
course when the server at 1.2.3.4 goes down, all attempts to connect
will be broken.  The server at 5.6.7.8 will be sitting there ready,
but nobody will connect to it.  There is no recovery until the "A"
records are corrected.  The TLSA situation is directly analogous.

	John

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Jun 2014 02:37:18 +0000

> keys by dropping the past keys.

Done under separate cover.  Some key rotation scenarios involve
changes from TA issued keys to self-issued keys or the converse.

Or sometimes even simply a change from "3 0 1" with old keys to
a deliberate "3 1 1" with new keys (to make them RPK compatible).

> "past/future" keys.  TLS would fail if they did so.

The total set of TLSA RRs indeed always contains present keys when
the server is not misconfigured.  But there is (today) no guarantee
that the "3 1 X" subset of the TLSA RRset contains any present
keys.  I am proposing to document this issue.  We've not yet agreed
on who's responsible for the work-around (client, server, both).

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Fri, 06 Jun 2014 02:54:01 -0400

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

VD>     3. Some subset of servers will have TLSA RRsets during transition
VD>        states, not currently defined as "misconfigured", such that
VD>        X.509 DANE TLSA authentication works, but RPK DANE TLSA
VD>        authentication fails, because the RPK-compatible TLSA RRs
VD>        match only past or future keys.

Now I see why/where we disagree.

In the case where the server's current key cannot be verified by a RPK-
compatible TLSA, and where the server publishes TLSA at all, it is a
mis-configuration to permit the server to negotiate RPK.

Just because a client sends the RPK extension does not mean that the
server must or will agree.

If the admin knows that no published RPK-compatible TLSA will verify the
key which the server currently would send to an RPK client, said admin
SHOULD configure the server to refuse the RPK extension.

Servers which expect their RPK clients to authenticate the SPKI via LDAP
or pre-shared knowledge SHOULD NOT publish TLSA which cannot verify the
current SPKI without also publishing TLSA which can do so.  (This is why
the last paragraph is only a SHOULD rather than a MUST.)

Servers which expect their RPK clients to authenticate the SPKI via TLSA
MUST publish at least one TLSA which can verify the current SPKI.

It seems extremely unlikely to me that, as RPK support is added to the
various TLS libraries, that it will be enabled by default.  It is vastly
more likely that explicit configuration will be required by any server
software to enable support for RPK.  Perhaps even requiring that the
SPKI to be sent to RPK clients be in a file outside of any 509 container,
rather than auto-extracted as needed.

The likelyhood, therefore, of servers suddenly negotiating RPK unbeknownst
to their admins is negligible.  Admins who want to enable RPK and want to
support DANE verification of the bare SPKIs should be expected always to
include a suitable record in their TLSA set.

-JimC
--
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: "Simon Arlott" <[email-masked]>
Date: Fri, 6 Jun 2014 12:56:07 +0100

> on who's responsible for the work-around (client, server, both).

If a server operator is moving from RPK-only to PKIX-only then they
MUST (with all the necessary TTL considerations for each step):
1. Add support for PKIX on the server and in the TLSA RRs
2. Remove support for RPK in the TLSA RRs
3. Remove support for RPK on the server

In my opinion the server operator is responsible. They also MUST NOT
provide support for RPK unless they have configured SPKI TLSA RRs,
otherwise a PKIX+RPK client will prefer RPK and fail.

-- 
Simon Arlott

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Jun 2014 14:52:07 +0000

> server must or will agree.

Indeed I was/am expecting some TLS implementations to automatically
negotiate RPK and use keys extracted from the leaf certificate (far
simpler in mixed environments than configuring separate bare SPKI
objects).  If RPK only gets enabled:

    * Toolkit implements RPK, off by default
    * Application enables RPK support, off by default
    * Administrator enables RPK (when not in conflict with TLSA, ...)

Then it will take quite some time before there's any noticeable
RPK deployment even in the presence of DANE TLSA records than can
authenticate RPK.  The alternative model is:

    * Toolkit implements RPK, on by default in servers.
    * Application may be updated to allow disabling of RPK support.
    * Server administrator publishes "3 1 X" TLSA RRs.
    * Client sees "pure" "3 1 X" TLSA RRset, enables RPK, and off we go.

The extension deploys itself "organically" as implementations are
adopted.  However, if that's the model, then TLSA RRset transitions
need to be managed with care, or clients should be cautious when
automaticaly enabling RPK or better yet both.

I am planning to *recommend* a server BCP of "make sure each and
every U/S/M matches a current keyset" strategy anyway, there are
non-RPK reasons to do that anyway.

So the question with respect to RPK is whether it is:

    * The server's responsibility to only enable it while publishing
    compatible TLSA records (assuming the server publishes TLSA
    records), leading to much slower RPK deployment, but closing
    the "mixed TLSA" exposure.

OR

    * The server's responsibility to carefully publish TLSA records
    in such a way that no U/S/M subset is purely past/future, also
    closing the exposure.

OR

    * The client's responsibility to be cautious in the face of
      "mixed" TLSA records.

If the consensus is that PRK enablement in server applications
needs to be explicit, and it needs to be off by default, then this
should I think be published in the new RPK RFC.  Toolkit implementors
adding server-sie code for the extension need to know that it is not
safe to enable by default.

> rather than auto-extracted as needed.

I don't want to rely on happy accidents, if it is not spelled out,
all bets are off.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Sat, 07 Jun 2014 05:01:58 -0400

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

VD> Indeed I was/am expecting some TLS implementations to automatically
VD> negotiate RPK and use keys extracted from the leaf certificate (far
VD> simpler in mixed environments than configuring separate bare SPKI
VD> objects).

I tend to expect crypto authors to be more conservative in enabling new
extensions by default.  Heartbleed, of course, demonstrates that such
conservatism isn't always there....

If it does get added to the libs enabled by default, w/o the need for
application buy in, things will be radically different than what I
expected.

VD> I am planning to *recommend* a server BCP of "make sure each and
VD> every U/S/M matches a current keyset" strategy anyway, there are
VD> non-RPK reasons to do that anyway.

Such a recomendation is most welcome.

VD> So the question with respect to RPK is whether it is:

VD>  * The server's responsibility to carefully publish TLSA records
VD>  in such a way that no U/S/M subset is purely past/future, also
VD>  closing the exposure.

That would be my preference.

VD> If the consensus is that PRK enablement in server applications
VD> needs to be explicit, and it needs to be off by default,

I wasn't advocating either way.  Just anticipating that lib and app
authors would be conservative about the new extension.

And I doubt any will care whether an rfc demands by default or only when
configured.

-JimC

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 7 Jun 2014 16:54:36 +0000

> application buy in, things will be radically different than what I

I was expecting at least some implementations to be on by default
on the server, and off by default on the client.  Then, when the
client asks, and the server is capable, RPK would be used.

If no specification requires any particular default mode of operation,
then likely neither you nor I have any rational basis for our
expectations.

> That would be my preference.

OK, when I get a chance, I'll write up the desired invariant and
strategies for ensuring it is met in the "ops" draft.

Is there anyone who now or still supports my original suggestion
that clients ought to be cautious in the face of "mixed" TLSA
records?  Should the above server TLSA record update strategy be
a BCP or a mandate (RECOMMENDED vs. SHOULD)?

> And I doubt any will care whether an rfc demands by default or only when

Whether or not toolkit implementors "care" (I am guessing they
would), I think stating the requirement (if it is to be a requirement)
is necessary.

So what is the view of the WG re: server RPK support?  On by default
OK? Required off by default, unless enabled by server administrator?

-- 
	Viktor.