Penso che mischiate la crittografia opportunistica come descritto da queste bozze e STARTTLS.
STARTTLS ha una semantica chiaramente definita su come devono essere verificati i certificati (vedere RFC6125) e la maggior parte degli agenti di posta (MUA) implementano queste convalide quando si connettono a un Agente di trasporto posta (MTA). Pertanto, è necessario accettare esplicitamente un'impronta digitale specifica di un server se il certificato è firmato da una CA sconosciuta. La maggior parte degli MTA offre invece dei modi per disabilitare questi controlli di convalida, con l'argomentazione che TLS non validato aiuta contro il monitoraggio passivo, quindi è almeno migliore di nessun TLS.
Ma il modello di sicurezza della posta (SMTP) è completamente diverso da HTTP. SMTP è un protocollo hop-by-hop con almeno MTA tra il MUA di origine e di destinazione. Non esiste una crittografia end-to-end (vale a dire MUA-to-MUA), ma solo hop-by-hop. Ciò significa che qualsiasi MTA in mezzo può vedere e modificare le mail in testo normale, anche se la connessione a questo MTA è protetta da TLS. Quindi, se hai bisogno di privacy con SMTP, devi crittografare il corpo della posta da solo - questo è quello che fanno PGP e S / MIME.
HTTP invece fornisce una connessione end-to-end tra le parti e HTTPS offre quindi la crittografia end-to-end. Non è stato definito alcun livello di sicurezza aggiuntivo (ad esempio simile a PGP o S / MIME), pertanto la tua privacy dipende esclusivamente dalla corretta implementazione di TLS.
Dai un'occhiata alla sezione sulle considerazioni sulla sicurezza nelle RFC a cui hai fatto riferimento. Entrambi affermano chiaramente che proteggono solo dal monitoraggio passivo, che sono vulnerabili agli attacchi man-in-the-middle e che i creatori di browser non dovrebbero fornire un'interfaccia utente che potrebbe suggerire una protezione paragonabile a HTTPS.
E a proposito dei tuoi reclami sul "cartello" associato a HTTPS: non c'è nulla di intrinseco con TLS / HTTPS che ha bisogno di un simile "cartello". Ma ciò di cui ha bisogno è un modo per convalidare l'identificazione (certificato) presentata dal peer, perché altrimenti sarebbe vulnerabile agli attacchi man-in-the-middle (attivi). Storicamente questa convalida è stata implementata con un set fisso di trust ancore nei browser e inizia da lì per convalidare il certificato. Se si dispone di un altro metodo affidabile per verificare il certificato dei server, è possibile utilizzarlo, ma alla fine non rimuove la necessità di alcun tipo di ancore di trust, ma lo sostituisce solo con altri ancore di trust. Come con DANE, dove hai bisogno di DNSSec che ha bisogno nuovamente di CA di fiducia per firmare le voci radice DNS e creare una catena di fiducia da lì per verificare le voci DNS che includono il certificato.
Non suggerirei che il modo attuale con 100s di CA radice affidabili nel browser sia il modo in cui dovremmo continuare. Ma almeno fornisce la sicurezza prevista nella maggior parte dei casi. Quindi non consiglierei di sostituirlo con qualcosa di molto peggio, ad esempio uno di questi progetti che fornisce la crittografia senza identificazione del peer. Non consiglierei nemmeno di implementarlo come opzione all'interno del browser, perché l'utente medio non sarà in grado di comprendere le differenze tra i vari livelli di sicurezza.