Morning!
TLDR' I think we might want FT Log to respond with an inclusion promise (https://github.com/google/trillian/blob/master/docs/TransparentLogging.md#inclusion-proofs-vs-promises) called signed firmware timestamp (SFT similar to SCT in https://www.certificate-transparency.org/how-ct-works) to submission of valid firmware. And then for Update Client, verification of the SFT should be good enough instead of verification of consistency. Verification of consistency leads to availability issues and potential attack surface with URL of FT Log alone.
The following are the details. Because we are discussing the design, so I will use the language in the Claimant models.
From the description of the overview figure of the design page, the Update Client in the Device block is acting as the Believer role of both FIRMWARE and FIRMWARE_Log. And it is also acting as the Verifier role of FIRMWARE_Log by asking for consistency proof from FT Log and verifies the received proof. This is a 'Verify before Use' mode of believer as mentioned in https://github.com/google/trillian/blob/master/docs/claimantmodel/CoreModel.md#trust-but-verify. And Verify before Use mode is subject to availability issue. While Transparency is mostly used with the 'Trust but Verify' mode AFAIK. And also, for Update Client to verify the identity of FT Log, a URL might not be good enough (DNS poisoning etc). A fake FT log can lead to a Split view attack. So most likely a hard-coded certificate of FT Personality is required. On the other hand, if we let FT Log to respond with a signed firmware timestamp (SFT) to submission of valid firmware to FT Log and let Update Client verifies the SFT. We can solve the availability issue, the potential attack surface and can still achieve eventual discoverability. (Note that, in the current demo implementation of FT Log, publisher.go would submit firmware image and wait for proof of inclusion. Only after the publisher validates the inclusion of proof, would it proceed. So in this case, the MMD field in SFT could be deprecated. And signed firmware timestamp (SFT) might be better names signed firmware promise (SFP)? Just random thoughts.)
Since Update Client is a Believer of FIRMWARE_Log, so it might want to just believe FT_log (by verifying SFT) instead of still acting as Verifier. And since FIRMWARE vendor's monitor and Observer's FT Monitor are already acting as Verifier, so we should be able to assume any inconsistency of FT Log would be reported to Arbiter once found.
To put it simple, the Update Client needs to validate the blessing from two entities, one is the Vendor and the other is FT Log. And it shall not be the Update Client's duty to make sure these two entities are still working fine. It's FT Log's job to keep an eye on Vendor. And its Log monitor's (could be held by Vendor or third parties) job to watch FT Log. Putting the validation of FT Log working fine burden on Update Client does not seem to add much value. Since if the Vendor is benign, it would notice the misbehavior of FT Log and switch to another benign FT log source before it publishes an image.
If we want to defend against compromised FIRMWARE Vendor and compromised FT Log colluding together, then we need to add inclusion proof validation in Update Client and add multiple FT Log sources. See https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-16#section-3.3.3. But this is out of scope for this issue.
Please let me know if I have any misunderstandings or incorrect assumptions!