On Wed 2015-12-09 18:12:41 -0500, Christian Huitema <[email protected]> wrote:
> However, I am a bit skeptical of some of the requirement to provide
> "two or more pins" for each server. This assumes a specific model of
> out-of-band provisioning, and it also assumes that servers always have
> a second key to fallback to if the first one is compromised.
To clarify this: it requires server *operators* to prepare and have
available a second key for fallback. It does not require the server
itself to have access to both keys concurrently.
> That may be true in many deployments, but that will not always be
> true. For example, just after a fallback, it will take some time for a
> second key to become available.
I think the implication here is that as soon as a compromise happens,
the servers may no longer use the original key. This isn't how things
are likely to work in practice. In practice, a key compromise and
rollover will have a timeline like this:
Time Action Key used Keys Permitted
by server on updated client
0 Setup A A,B
1 Compromise A A,B
2 Compromise A A,B
Discovered
3 Backup key B A,B
Deployed
4 New Pins B B,C
Announced
(OOB)
The time i think you're talking about is the time between 1 and 3,
right? Key A, despite being known-compromised, does not become unusable
until step 4 has completed. This is slower than we might like, but it
also allows for smooth service upgrades and no failures in service while
the operator waits for the action in step 4 to take effect across all
connected clients.
> Another model would be for clients to proactively refresh the pins
> that are nearing end-of-life, or maybe perform periodic updates. I
> would suggest replacing the text in section 4.2 between "MUST deploy"
> and "future key rollover" by something less imperative, like "SHOULD
> deploy a backup pin along with the primary pin, for the reasons
> explained in [RFC7479]."
If a server operator deploys this scheme with a pinset containing only
one pin, and they have more than one client, then they cannot change
their service key without either (a) coordinating a simultaneous
rollover between all clients, or (b) causing service interruption for
some clients. This is effectively an unmaintainable system, and we
should not provide the wiggle-room to say that an unmaintainable service
is compliant with the specification.
> The mechanism is also somewhat under-specified, because RFC7469 pins
> can differ in many ways, besides pinning different keys. For example,
> they could be computed in the future using different hash algorithms,
HSTS has explicitly decided to not specify multiple algorithms now, and
will deal with subsequent algorithms with an update when SHA-256 is
nearing end-of-life. I see no reason for this authentication mechanism
for dprive should be more specific.
> they may have different life times, they may include subdomains, or
> they may have different purposes such as "report-only."
None of these features are relevant to this dprive authentication
mechanism, which explicitly states that the pinsets are per-endpoint
(not associated with a name at all), are fail-closed, and must be
updated in some out-of-band process. (yes, the "some out-of-band
process" is deliberately not specified -- that's the piece that an
implementer needs to handle on their own).
--dkg
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
