HKDF to derive multiple keys from a strong constant master secret and a weaker changing secret

Question

I am working with constrained nodes (type OpenMote CC2538) on a (constrained) 6TiSCH network and I am trying to design a good re-keying scheme designed to generate AES-128 keys dubbed Device Authentication Key DAK using HKDF.

Proposal:

• Each node of the network is initially pre-configured with a Device Master Secret DMS and an initial Re-Keyed Secret RKS. Note that both are secret, unique (one of each for each node), and the only entities having access to them are the Authentication Server AS and the node itself.
• The Device Master Secret is there for the lifetime of the device, would be 10-100 times longer than the AES-128 keys it will be used to derive (so 1-10 Kb), and very-high entropy (bits from a physical source of entropy compressed with something like FPAQ8 as described here although it’s not exactly for the same purpose).
• The RKS however, would be the same size as the AES-128 key, and probably with lesser entropy than the DMS (let’s say the 128 bits of the RKS only amount to 90 bits of entropy, if even that), but everytime a new key is to be generated, the RKS is changed.
• To do this, the AS provides the node with a new RKS some time before the actual change through an exchange encrypted with the current DAK. Then when the actual change is to be made, a flag in the exchanged messages is set by the AS and a new key is derived using the DMS and the new RKS using HKDF, thus giving the new DAK.

Questions:

1. Opinion on the robustness of this proposal ? Lengths of the various parameters sufficient/overkill …? (I do not really know the number of keys I would need to derive using this scheme, but let’s say at least 100-1000)
2. The salt and the IKM parameters in HKDF do not have symmetrical roles, however in my case the DMS and the RKS are both secret, and both have “pros&cons”. The DMS is at least 1Kb of pure entropy, but never changes, and is (the device is assumed never to be physically compromised, because it doesn’t interest me in this case, I just want to protect the key from the outside world, not from physical tampering) guaranteed to be secret forever. The RKS changes but is only 90bits of entropy, and since it is transmitted on an untrusted network, even if it encrypted, there is a higher chance it would be intercepted (even though honestly I really don’t see how). Which should I use as the salt and which as the IKM in your opinion ?
3. The HKDF RFC clearly states that the salt and the IKM should be of independent sources of entropy. However in my case, I think this won’t really be the case: the actual bits of the KMS and of the DMS would come from the same physical source of entropy, although the DMS would be the refined version after compression and the KMS the raw bits going out of the entropy source. I kind of hope this is enough to at least mitigate the inherent auto-correlation between the two parameters, but let’s face it, this is more homemade-crypto than anything else... So does this actually improve things compared to just using directly the same source for both, or not really ? And does this affect the answer to 2. ?

Thanks in advance !

PS:

4. Bonus question : I really don’t understand all the answers saying here things like :

HKDF is intended to turn an unguessable value into something that looks uniformly random. It has been analyzed for that use. It was not designed to derive multiple keys from the same Z

or:

It is not designed to produce "multiple keys" from the same Z, and one should definitely not call the KDF on the same Z twice (even with different salts) and expect to get two independent keys.

Either I completely misunderstood both the RFC and the paper, or they seem to reduce HKDF to its first “extract” stage, and seem to be forgetting that it is literally written here, third paragraph:

The second stage "expands" the key K into several additional pseudorandom keys (the output of the KDF).

I mean one can hardly state more clearly that it is designed to derive multiple keys from the same material if necessary and that everything has been studied to make it work (provided you don't expect to be able to generate 1 billion secure keys from the same material), no ?