This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[atlas] Feature request for Validated Timestamps
- Next message (by thread): [atlas] Feature request for Validated Timestamps
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Will
willscott at gmail.com
Thu Apr 1 21:12:23 CEST 2021
I was starting to work on a mapping measurement project where I wanted to delegate measurements to remote machines. There are a number of schemes that have been used where a not fully trusted node can come away from a measurement with a record that can be used to verify that it actually made the measurement. Many of these make use of a time stamp signed by the "server" as a way to prevent replaying old measurements. Things that have been done with this feature also include tlsnotary[1], which works with web servers where the "server random" bytes of the tls handshake includes the server timestamp (the default for openssl). The implementation of ssl currently used by probes does not appear to include the timestamp in the server hello. Another approach would be to add a "roughtime" service on probes Interested to hear if there would be willingness to have probe software support something in this direction. [1] https://tlsnotary.org/ --Will -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/ripe-atlas/attachments/20210401/a068c681/attachment.html>
- Next message (by thread): [atlas] Feature request for Validated Timestamps
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]