Re: [TLS] Enforcing Protocol Invariants

[Eric Rescorla <[e-mail]>]

Hi Ryan,

Thanks for your comments.

On Thu, Nov 8, 2018 at 12:44 AM Ryan Carboni <[e-mail]> 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