2009/8/31 C. Scott Ananian <[email protected]>: > On Thu, Aug 27, 2009 at 7:30 AM, Daniel Drake<[email protected]> wrote: >> The server will respond with: "time01: <TIMESTAMP> sig0x: xxx" > > I don't understand why this is necessary; there is already a 'time' > field in the server response for this purpose: > http://wiki.laptop.org/go/Theft_deterrence_protocol#Theft-deterrent_server_response
This part was discussing and extending the port 191 protocol, not the theft deterrence protocol. The port 191 client is in the initramfs, and the theft deterrence protocol client is separated, on the rootfs as part of olpc-update-query. The port 191 protocol is currently as follows: 1. client opens connection, writes its own serial number to socket 2. server writes appropriate lease to socket 3. connections close Now Martin's work extends that so that the client can send a time01 request on that socket. >> Both sig01 and sig02 formats are accepted in the server response. One >> important point is that the expiry date of any sig02 keys used in the >> chain are *not* checked at all -- this is because we're assuming the >> XO clock might not be accurate. > > Server time is trusted, because it is validated with a signature; the > XO's local time should be updated if necessary, but validation should > be done with the server's time to avoid races with another process > updating the XO's clock. Good point. >> I would vote that time-publishing should be disabled by default on the >> XS. However, in the case of the OATS protocol it is not an optional >> field. Should we extend/amend the protocol? > > I'm not sure why you believe it should be disabled. Hijacking an XS 2 reasons, neither related to attacks : 1. I've seen a lot of bad clocks in regular PCs, which jump around in time. If you have one of these in your server, you're now likely to kill all the XOs, even if they have good clocks. 2. The OATS server is not necessarily the same machine as the port 191 server. The machine that generated the leases is not necessarily the XS, or the OATS server. We never used to rely on the XS having a time-keeping and accurate clock (or at least one synced with the contents of the leases), but this would change that. It might not be totally unreasonable to ask for a good clock, but this is still slightly tightening the requirements for deployments, which really benefit from flexibility in the systems... Sure, new features introduce new risk. And new features change the trust model, as you describe. The thing is, not all deployments will use these new features. And as the code is right now, they will still be inversely affected by these possible complications (which won't be overly common, but we're likely to see a few) that are introduced even if they are not using the new features. Daniel _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
