Appendix A. Design Decision Notes (Note sulle Decisioni di Progettazione)
Questa appendice discute varie decisioni di progettazione, documenta alcune vie alternative che non sono state intraprese, e fornisce contesto aggiuntivo per le decisioni prese. L'appendice è organizzata approssimativamente nell'ordine in cui i problemi sorgono nella specifica.
A.1. Not Requiring HSTS on Redirect (Non Richiedere HSTS sui Reindirizzamenti)
Non è necessario che un host HSTS notifichi agli UA che è un host HSTS come risultato del UA che elabora una risposta HTTP che segnala un reindirizzamento. Ciò è dovuto al fatto che tali risposte di reindirizzamento possono essere emesse da attaccanti, e senza un robusto controllo sull'integrità della risposta, un attaccante potrebbe causare che il UA consideri host arbitrari come host HSTS.
A.2. No Rewrite Cookies Without "Secure" Flag (Nessuna Riscrittura dei Cookie Senza Flag "Secure")
I cookie impostati su trasporto non sicuro, o su trasporto sicuro senza il flag "Secure", sono comunemente usati per tracciare utenti per scopi legittimi (anche se alcuni considerano questo un uso meno che ideale dei cookie). Non riscrivere tali cookie per includere il flag "Secure" permette che tale tracciamento continui per quei cookie che sono stati impostati prima che il sito migrasse a HSTS.
I rischi sono che se un sito imposta cookie di sessione senza il flag "Secure" anche dopo il passaggio a HSTS, un attaccante attivo può raccogliere tali cookie di sessione (ad esempio, su un hotspot Wi-Fi non sicuro) e sottrarre la sessione dell'utente. Ma questo è un problema del sito, non un problema di HSTS. Per questa e altre ragioni (vedi ad esempio [ForceHTTPS]), i siti devono (SHOULD) usare il flag "Secure" sui loro cookie.
A.3. UA-Configured HSTS Policy (Politica HSTS Configurata dall'UA)
Non definiamo un modo per gli utenti di specificare che un particolare host dovrebbe essere considerato come un host HSTS, né un modo per gli utenti di specificare un tempo di scadenza della politica. Molti utenti non hanno la competenza tecnica per fare ciò correttamente, e l'atto di fare ciò potrebbe facilmente diventare un'azione "comune". Cioè, se le persone diventano abituate a semplicemente dichiarare host arbitrari come host HSTS, indipendentemente dal fatto che tali host abbiano mai emesso una politica HSTS, potrebbero avere un falso senso di sicurezza.
A.4. No Canonical Hostname/Domain (Nessun Hostname/Dominio Canonico)
Questa specifica originariamente includeva una direttiva "canonical" che gli host potevano usare per segnalare agli UA che il nome di dominio dell'host è un alias e gli UA dovrebbero "seguire" il alias sostituendo il nome di dominio dato con il nome di dominio canonico. Per diversi motivi, questa funzionalità non è stata inclusa in questa specifica; la ragione principale è che è troppo complicata e aumenta significativamente la superficie di attacco.
A.5. Always Setting State vs. Always Updating State (Impostare Sempre lo Stato vs. Aggiornare Sempre lo Stato)
Alcuni hanno sostenuto che è importante inviare sempre un campo di intestazione STS su connessioni sicure, in modo che gli host HSTS possano "rinnovare" la loro politica HSTS. Altri sostengono che è meglio che gli host inviino il campo di intestazione STS solo una volta (ad esempio, in una risposta a una richiesta POST che stabilisce una sessione autenticata), e che l'host dovrebbe richiedere all'UA di stabilire una nuova connessione sicura solo quando strettamente necessario (ad esempio, quando la vecchia politica è scaduta).
Il primo gruppo preferisce il "rinnovo automatico" per evitare gli host di dimenticare di rinnovare la loro politica. Il secondo gruppo preferisce il "rinnovo selettivo" perché credono che l'instaurazione di connessioni sicure sia costosa e dovrebbe essere fatta con parsimonia.
Questa specifica non favorisce uno approccio rispetto all'altro, ma richiede che se una connessione sicura viene stabilita, e se l'host HSTS invia un campo di intestazione STS, allora l'UA deve aggiornare la sua cache della politica HSTS di conseguenza.
A.6. Extent of includeSubDomains (Estensione di includeSubDomains)
La direttiva includeSubDomains applica la politica HSTS dal nome di dominio del dato host a tutti i sottodomini dei nomi di dominio del dato host. Potrebbe sembrare intuitivo che se un dominio padre asserisce includeSubDomains, allora i sottodomini dovrebbero ereditare non solo la proprietà di essere un host HSTS, ma anche la capacità di asserire includeSubDomains su ulteriori sotto-sottodomini. Tuttavia, questo non è il caso.
Un host HSTS dichiara politica solo per se stesso, e può estendere tale politica ai suoi sottodomini se desidera tramite includeSubDomains. I sottodomini non ereditano automaticamente la capacità di estendere la politica. Questo perché potrebbe essere confuso se un dato sottodominio può o non può asserire la politica a ulteriori sotto-sottodomini, dato che tale capacità è determinata dalla politica di un dominio padre potenzialmente arbitrariamente distante.