SSHFP records / DNSSEC support

laduke commented 3 years ago

Hi, just wanted to write this down and see if anyone else had interest or comments.

SSHFP records just let you skip this thing:

The authenticity of host 'examplehost.example.org (192.0.2.123)' can't be established.
ECDSA key fingerprint is SHA256:MH85JK0yq+JNl1lPKUlxit+dGFqWMS/MmohcINp/e9Q.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

We're already on a secure transport (zerotier), so that's cool. I'm not sure how much dnssec would have to be rubbed on zeronsd.

2.4.  Authentication

   A public key verified using this method MUST NOT be trusted if the
   SSHFP resource record (RR) used for verification was not
   authenticated by a trusted SIG RR.

   Clients that do validate the DNSSEC signatures themselves SHOULD use
   standard DNSSEC validation procedures.

   Clients that do not validate the DNSSEC signatures themselves MUST
   use a secure transport (e.g., TSIG [9], SIG(0) [10], or IPsec [8])
   between themselves and the entity performing

someara commented 3 years ago

This would require DNSSEC validation -s

On Wed, Jun 16, 2021 at 9:35 PM Travis LaDuke @.***> wrote:

Hi, just wanted to write this down and see if anyone else had interest or comments.

SSHFP https://datatracker.ietf.org/doc/html/rfc4255 records just let you skip this thing:

The authenticity of host 'examplehost.example.org (192.0.2.123)' can't be established. ECDSA key fingerprint is SHA256:MH85JK0yq+JNl1lPKUlxit+dGFqWMS/MmohcINp/e9Q. Are you sure you want to continue connecting (yes/no/[fingerprint])?

We're already on a secure transport (zerotier), so that's cool. I'm not sure how much dnssec would have to be rubbed on zeronsd.

2.4. Authentication

A public key verified using this method MUST NOT be trusted if the SSHFP resource record (RR) used for verification was not authenticated by a trusted SIG RR.

Clients that do validate the DNSSEC signatures themselves SHOULD use standard DNSSEC validation procedures.

Clients that do not validate the DNSSEC signatures themselves MUST use a secure transport (e.g., TSIG [9], SIG(0) [10], or IPsec [8]) between themselves and the entity performing

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/zerotier/zeronsd/issues/76, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAQ3TBPGCWK2W4PLNOLXJTTTD4H3ANCNFSM462D4A5Q .

someara commented 3 years ago

and yes, I'm very interested =) -s

On Wed, Jun 16, 2021 at 10:03 PM Sean OMeara @.***> wrote:

This would require DNSSEC validation -s

On Wed, Jun 16, 2021 at 9:35 PM Travis LaDuke @.***> wrote:

Hi, just wanted to write this down and see if anyone else had interest or comments.

SSHFP https://datatracker.ietf.org/doc/html/rfc4255 records just let you skip this thing:

The authenticity of host 'examplehost.example.org (192.0.2.123)' can't be established. ECDSA key fingerprint is SHA256:MH85JK0yq+JNl1lPKUlxit+dGFqWMS/MmohcINp/e9Q. Are you sure you want to continue connecting (yes/no/[fingerprint])?

We're already on a secure transport (zerotier), so that's cool. I'm not sure how much dnssec would have to be rubbed on zeronsd.

2.4. Authentication

A public key verified using this method MUST NOT be trusted if the SSHFP resource record (RR) used for verification was not authenticated by a trusted SIG RR.

Clients that do validate the DNSSEC signatures themselves SHOULD use standard DNSSEC validation procedures.

Clients that do not validate the DNSSEC signatures themselves MUST use a secure transport (e.g., TSIG [9], SIG(0) [10], or IPsec [8]) between themselves and the entity performing

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/zerotier/zeronsd/issues/76, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAQ3TBPGCWK2W4PLNOLXJTTTD4H3ANCNFSM462D4A5Q .

zerotier / zeronsd

SSHFP records / DNSSEC support #76