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

[Viktor Dukhovni <[e-mail]>]

On Fri, Jun 06, 2014 at 02:54:01AM -0400, James Cloos wrote:

> >>>>> "VD" == Viktor Dukhovni <[e-mail]> 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.

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.

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

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

-- 
	Viktor.