Hi Ryan, Thanks for your comments.
On Thu, Nov 8, 2018 at 12:44 AM Ryan Carboni <rya...@gmail.com> wrote: > 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. > There's actually an RFC for this: https://tools.ietf.org/rfcmarkup?doc=6968. Unfortunately, it is not really a viable option for replacing the WebPKI for TLS for two reasons: 1. A nontrivial number of network elements will not correctly pass DNSSEC, and so attempting to use it will cause failures. 2. Essentially all clients and servers only support WebPKI authentication, so at least for existing applications (such as the Web), endpoints will need to support WebPKI for a very long time. There are some specific applications that could potentially use this method, but that's not going to work for most applications. It's also worth noting that in practice, many sites are served on multiple CDNs which do not share keying material. This is a real unsolved problem for Encrypted SNI and would also likely be a problem if the keys in question were endpoint keys. 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. > This is an orthogonal question to TLS, I believe. However, in general at least the Web community has decided that it's not excited about SRV. However, at least on the Web, the reason for the ubiquity of 443 isn't the inability to indicate the right port in the URL (which has a slot for this), but rather that other ports than 443 have much lower middlebox penetration rates. Although, to be radical, all anyone needs is RSA-2048, ephemeral DH-3072, > and SHAKE-128 as AEAD. > This is a fairly surprising proposed set of ciphers, given that the Internet seems to be rapidly moving towards elliptic curve. This proposal would certainly have very significantly worse computationsl performance than the mandatory TLS 1.3 ciphers. 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 also seems out of scope for TLS. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
