Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

implement IETF draft #13

Open
oreparaz opened this issue Oct 30, 2022 · 4 comments
Open

implement IETF draft #13

oreparaz opened this issue Oct 30, 2022 · 4 comments
Labels
enhancement New feature or request

Comments

@oreparaz
Copy link
Owner

There are a growing number of servers that won't talk the pre-IETF version of roughtime. We should add some minimal support to talk to those servers.

@wingel has added support for this on their fork so let's use that for inspiration:

@oreparaz oreparaz added the enhancement New feature or request label Oct 30, 2022
@oreparaz
Copy link
Owner Author

Examples of servers that exhibit this behavior:

  • roughtime.se:2002 S3AzfZJ5CjSdkJ21ZJGbxqdYP/SoE8fXKY0+aicsehI=
  • sth1.roughtime.netnod.se:2002 9l1JN4HakGnG44yyqyNNCb0HN0XfsysBbnl/kbZoZDc=

Basically, those with newver(true) here https://groups.google.com/a/chromium.org/g/proto-roughtime/c/noix2AYXSXE

@wingel
Copy link

wingel commented Nov 1, 2022

I'm using vroughtime in this project:

https://github.com/netnod/vadarklockan

The variant there supports both draft 05/06 and 07 of the Roughtime protocol. If you want to I can try to merge it back to my vroughtime fork. Would that be helpful?

@oreparaz
Copy link
Owner Author

oreparaz commented Nov 3, 2022

Thank you @wingel, I'm glad you find vroughtime useful.

If you want to I can try to merge it back to my vroughtime fork. Would that be helpful?

Let me have a look in the next few days and will come back and see how we can proceed further. I'm thinking I may ask you to open a PR with your branch and I'll integrate / modify / clean up stuff. But before that I need to read the IETF draft in a bit more detail to see what's actually changing from the pre-IETF version.

Do you think we can ditch support for version 05/06? Are there servers running only that version?

I'm also a bit skeptical of implementing a moving target. It sucks when the draft standard gets breaking changes for no meaningful gain. The nice thing about the pre-IETF version is that several servers still talk that version today.

@wingel
Copy link

wingel commented Nov 3, 2022

I think the major changes are that the format of some fields have changed, instead of microseconds since 1970-01-01 timestamps are now Modified Julian Date (MJD) and that there is a "ROUGHTIM" header before the tag/index stable. The hashing algoritihm has changed from SHA-512 truncated to 32 bytes to SHA-512/256. Unfortunately tweetnacl does not have support for SHA-512/256 but the only real difference is the IV to the hash function and I have hacked support into tweetnacl for it. I just need to clean up those patches and publish them. I'll try to have that done before the IETF Hackathon starts on saturday.

Do you think we can ditch support for version 05/06? Are there servers running only that version?

I'd say that 05/06 support can be dropped. As far as I know the only implementations are Marcus Dansarie's roughtimed and pyroughtime and he has since updated them to draft 07.

I'm also a bit skeptical of implementing a moving target. It sucks when the draft standard gets breaking changes for no meaningful gain. The nice thing about the pre-IETF version is that several servers still talk that version today.

Yes, it is a bit of a pain. I've managed to update my C implementation and the Python implementation on Linux to draft 07. My Python client for ESP32 is still stuck on draft 05/06 and there are no longer any servers supporting that version.

I my hacked version of vroughtime I've added a "query builder" which tries to accomodate all the different variants, but if the protocol stabilises a bit it really won't be neccesary to use it since it should be possible for a client to use a hardcoded query where only the NONC field is updated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants