On 18/01/17 00:32, Bill Frantz wrote:
On 1/17/17 at 9:16 AM, [email protected] (Rob Stradling) wrote:
On 17/01/17 17:07, Tom Ritter wrote:
<snip>
It also assumes the client has a clock that is correct to the order of
a few days...
True. Is it, or might it soon be, reasonable to make that assumption?
e.g., https://roughtime.googlesource.com/roughtime sounds promising, I
think.
Machines such as the Raspberry PI and the Beaglebone do not have clock
chips, although it is easy to add an external real time clock board.
They can set their clocks from NTP if they have internet access, which
is more-or-less needed to run a browser, unless running on private
network. I can see scenerios where they can have a very badly off clock
though.
Is it (or might it soon be) reasonable to expect a TLS client to know
whether or not it has a reliable time source? If so, then TLS clients
could just ignore "minimum SCT ages" when they're insufficiently
confident of when "now" is.
As a way of dealing with clocks that are far behind, perhaps TLS clients
that implement CT could treat any observed SCT timestamp (that
corresponds to any observed cert) and any observed STH timestamp as
trustworthy evidence that these timestamps are in the past rather than
in the future. (If multiple SCTs/STHs from multiple logs all agree that
time X is in the past, then the TLS client can have even greater
confidence that this is indeed so).
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
