Hi Ryan
 
reading through your email and the subsequent exchanges I am surprised that you show up right after years of standardization of TLS 1.3.
Suggesting ideas at the right time is somewhat important.  
 
Later in your emails you explain what you consider complex in TLS and some of the ideas you are suggesting are alternative design approaches. What standardization helps you do is to work out the details of these different proposals and then to compare the different approaches against each other. 
 
> The state of cyber security is a horrible disappointment.
... and most (if not all) of that disappointment has nothing to do with TLS. 
 
Ciao
Hannes
 
Gesendet: Donnerstag, 08. November 2018 um 09:44 Uhr
Von: "Ryan Carboni" <rya...@gmail.com>
An: tls@ietf.org
Betreff: [TLS] Enforcing Protocol Invariants
Hmm. TLS has gotten too complex. How does one create a new protocol? Maybe we should ask Google.
 
The SSHFP DNS record exists. DNSSEC exists.
 
This might be a radical proposal, but maybe the certificate hash could be placed in a DNS TXT record. In another DNS TXT record, a list of supported protocols could be listed.
A DNS SRV record would define the port that one can use to connect to a service, because the URL scheme died after .onion was recognized as a domain and after chromium decided to that the presentation of sub domains was unimportant. So no browser has to show which port it is connected to.
Although, to be radical, all anyone needs is RSA-2048, ephemeral DH-3072, and SHAKE-128 as AEAD.
And maybe recommend that boot entropy could be obtained by using the timer entropy daemon for one second (and which would in theory provide enough entropy for perpetuity).
 
This isn’t rocket science. The state of cyber security is a horrible disappointment.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to