>You write TLS, but really, I think you mean PKIX (certificates). >AFAIK, TLS with raw public key or PSK doesn't care about time. > >While this might be a pedantic point, I think it's important to be clear >about where the problem is because it reveals that there are TLS uses which >do not have problems, but also that the time problem is not just about TLS >and DNSSEC.
My reasoning was the following: Assume a device that has no idea about time when it boots. Assume that some security protocols (DNSSEC, TLS most of the time, etc) have as a requirement secure, somewhat accurate time. So we need a protocol that allows the device to fetch the current time in a way that doesn't allow an attacker to interfere. Now also let's assume todays internet. We can design fancy new time protocols, but if they take decades to deploy then it doesn't do much good. So a very simple protocol to obtain secure time is to have the device ask a preconfigured server. This protocol then needs to have two properties: - The time returned by the server has to be authenticated and integrity protected (and the device has to be able to verify this) - The timestamp has to be fresh (and the device has to verify this) So this can easily be implemented using standard protocols such as HTTPS: - The device needs to have a long lasting certificate for the server (lasting long enough that time irrelevant) - The device has to be configure to require forward secrecy, or any other TLS configuration that guarantees that replay is impossible. - The device issues a simple 'GET /' and gets the current time back in the response header. So if you want to bootstrap secure time today, this is an easy way to use existing protocols. _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
