From 4e2aad82d6c3ce2e9b5e0a3b6f3ef19431169729 Mon Sep 17 00:00:00 2001 From: Sridharan Rajagopalan Date: Tue, 26 Nov 2024 14:01:36 -0500 Subject: [PATCH 1/4] add text for raw public keys --- draft-thomson-https-local-domains.md | 27 ++++++++++++++++++++++----- 1 file changed, 22 insertions(+), 5 deletions(-) diff --git a/draft-thomson-https-local-domains.md b/draft-thomson-https-local-domains.md index b36cfc5..8144e9d 100644 --- a/draft-thomson-https-local-domains.md +++ b/draft-thomson-https-local-domains.md @@ -455,12 +455,29 @@ handshake after the Finished message by sending TLS close_notify. # Raw Public Keys {#rpk} -Todo: rewrite this section +Raw public keys are used in various security protocols to facilitate +authentication without the need for full certificate chains {{?RFC7250}}. +This approach simplifies the certificate exchange process by +transmitting only the necessary public key information. -Certificates are complicated for most people. They also have an -expiration date. This system uses a public key for the lifetime -of the device, which is hopefully years. A certificate is not -appropriate; a raw public key is more approporiate. +Certificates are complicated because they involve: + + * Managing multiple levels of certificate authorities (CAs). + * Regular renewal and lifecycle management. + * Establishing and verifying trust with CAs. + +Raw public keys offer a simpler alternative: + + * No need for complex certificate chains. + * Using raw public keys allows for direct authentication, + making it easier to implement and understand. + * Raw public keys use a public key for the lifetime of the device, + eliminating the need for renewal and longer lifetimes. + * Robust authentication through public key cryptography. + +Using raw public keys can streamline authentication processes while +maintaining high levels of security, making them an attractive +alternative to traditional certificates. # Validation {#validation} From c36400701bef77216a0f7ffdecf24fda15fc83d8 Mon Sep 17 00:00:00 2001 From: Sridharan Rajagopalan Date: Tue, 26 Nov 2024 15:42:11 -0500 Subject: [PATCH 2/4] add operational consideration text and move things around --- draft-thomson-https-local-domains.md | 47 +++++++++++++++++++--------- 1 file changed, 33 insertions(+), 14 deletions(-) diff --git a/draft-thomson-https-local-domains.md b/draft-thomson-https-local-domains.md index 8144e9d..760a282 100644 --- a/draft-thomson-https-local-domains.md +++ b/draft-thomson-https-local-domains.md @@ -549,29 +549,48 @@ connection is made to that address, those are also considered * fc00::/7 (from {{?RFC4193}}) * 127/8 and ::1/128 (from {{?RFC990}} and {{?RFC4291}}) -# Incremental Deployment +# Operational Considerations + +## Incremental Deployment Where a server's hostname can be configured, a motivated network administrator can configure server hostnames to comply with this specification to provide immediate value to supporting clients. -# Security Considerations - -TODO: write more on security considerations +## Server Identity Change -Because the server's public key is encoded into its domain name, -changing the public key would also change its domain name -- thus, its +The server's public key is encoded into its domain name. +Changing the public key would also change its domain name -- thus, its identity as known by client password managers and other configurations -in clients (e.g., printer, SMB share, etc.). As such an identity -change is extremely disruptive, it needs to be avoided. This means -the public/private key pair on a server needs to stay static. The -tradeoff is servers are vulnerable to their private keys being stolen -and an active attacker intercepting traffic to that server. The -alternatives are to continue using unencrypted communication to local -servers, which is vulnerable to passive attack, or to condition users -to validate self-signed certificates for local servers. +in clients (e.g., printer, SMB share, etc.). As such an identity +change is extremely disruptive, it needs to be avoided. + +## Simplify DNS + +To simplify access to devices within a household, administrator can configure +an in-house DNS server and create short, user-friendly DNS names that resolve +to longer, more complex names. Configure the in-house DNS server to map +these short names to their corresponding long names. This approach +ensures that users can easily connect to the desired device using +a simpler, more memorable DNS name. +Implementing DNSSEC {{?RFC4033}} and using DNS over HTTPS (DoH) RFC 8484 +or DNS over TLS (DoT) {{?RFC7858}} for DNS queries can enhance the +reliability of this system. +# Security Considerations + +TODO: write more on security considerations + +Due to challenges in key rotation, the public/private key pair on a +server needs to stay static. The tradeoff is servers are vulnerable +to their private keys being stolen and an active attacker intercepting +traffic to that server. The alternatives are to continue using +unencrypted communication to local servers, which is vulnerable to +passive attack, or to condition users to validate self-signed certificates +for local servers. In this case, the +advantages of making HTTPS available would seem to far outweigh the +risk of using a key over long periods. # IANA Considerations {#iana} From 9ca2a01800cc68c6cd2fb84d8361058cf2373913 Mon Sep 17 00:00:00 2001 From: Sridharan Rajagopalan Date: Tue, 26 Nov 2024 15:51:49 -0500 Subject: [PATCH 3/4] reword abstract --- draft-thomson-https-local-domains.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/draft-thomson-https-local-domains.md b/draft-thomson-https-local-domains.md index 760a282..f3fd070 100644 --- a/draft-thomson-https-local-domains.md +++ b/draft-thomson-https-local-domains.md @@ -57,8 +57,14 @@ informative: --- abstract -Proposal to make origins with non-unique names like Printer.local or -192.168.0.1 use an extended origin to allow them to use HTTPS. +This document explores a method for providing secure HTTPS access +to local domains without the need for traditional certificates. +By leveraging local domain names embedded with public keys, this +approach ensures secure communication within a local network. The +method simplifies the setup process and enhances security by avoiding +the complexities of certificate management by using raw public keys. +This solution is particularly beneficial for local services that +require HTTPS access without exposing them to the internet. --- middle From ac67cb9f45b36b70a962b0c6e00afefa63d691de Mon Sep 17 00:00:00 2001 From: Sridharan Rajagopalan Date: Fri, 6 Dec 2024 16:05:24 -0500 Subject: [PATCH 4/4] Update draft-thomson-https-local-domains.md Co-authored-by: Dan Wing --- draft-thomson-https-local-domains.md | 12 ------------ 1 file changed, 12 deletions(-) diff --git a/draft-thomson-https-local-domains.md b/draft-thomson-https-local-domains.md index f3fd070..db57ae1 100644 --- a/draft-thomson-https-local-domains.md +++ b/draft-thomson-https-local-domains.md @@ -571,18 +571,6 @@ identity as known by client password managers and other configurations in clients (e.g., printer, SMB share, etc.). As such an identity change is extremely disruptive, it needs to be avoided. -## Simplify DNS - -To simplify access to devices within a household, administrator can configure -an in-house DNS server and create short, user-friendly DNS names that resolve -to longer, more complex names. Configure the in-house DNS server to map -these short names to their corresponding long names. This approach -ensures that users can easily connect to the desired device using -a simpler, more memorable DNS name. - -Implementing DNSSEC {{?RFC4033}} and using DNS over HTTPS (DoH) RFC 8484 -or DNS over TLS (DoT) {{?RFC7858}} for DNS queries can enhance the -reliability of this system. # Security Considerations