Re: [TLS] Un-deprecating everything TLS 1.2

[Ilari Liusvaara <[e-mail]>]

On Tue, Oct 06, 2020 at 10:13:19PM -0400, Michael D'Errico wrote:
> On 10/5/20 22:00, Christopher Patton wrote:
> > I agree that the HRR code path is hard to reason about, but I don't
> > really see an attack here. Is it your contention that the HRR code path
> > leads to an attack not accounted for by existing proofs?
> 
> I know that it may lead to denial-of-service
> for a legitimate client.  That's a big deal, but
> I was more worried that there might be a bigger
> problem with ECC, and I'm glad to hear that you
> and Nick Harper say it's just fine (or at least
> that we're no worse off than we are by trusting
> ECC in version 1.2).

If implemented properly, it will never lead to denying a legimate
client.
 
> I'm still very concerned that everything 1.2- and
> non-ECC is being thrown in the trash.

Because actually proving security of any practical cryptography is far
beyond current capabilities of open cryptography, the way security of
crypto is judged today is from attempts to break it.

ECC has been subject to this for ~35 years, and natural prime curves
(which include P-256, P-384, P-521, Curve25519 and Curve448) are second
to none in how well those have fared.

RSA and finite-field discete-logs have fared MUCH worse in ~45 years.

And there is no tradeoff between security and performance: Using ECC
instead of RSA/DH gives massive performance improvement.

This is not to say there will not be major challenges in future: If
large quantum computers can be built, ECC is toast (along with lots
of other stuff), and one needs new crypto, which is a necressarily a lot
less secure.


And regarding TLS 1.2, it is a mess:

- There is an extension to prevent attacks from having server confuse
  initial handshake and renegotiation.
- There is an extension to prevent attacks from failing to include
  exchange keys into master secret.
- Diffie-Hellman group negotiation is completely broken. To prevent
  attacks, clients must either disable DHE or tolerate handshakes with
  some servers failing.
- Signatures fail to include handshake type. The endpoints can disagree
  about handshake type, leading to attacks.
- Session ticket mechanism is pretty totally insecure.
- Static RSA uses insecure encryption (and is not forward-secure).
- Blockmodes use mac-then-pad, leading to timing attacks. There is
  extension to fix this, but pretty much nobody implements it.
- The MTI ciphersuite is insecure.
- You think EXPORT and single-DES have gone the way of dodo, >20
  years after being proven completely insecure? Unfortunately no.
- Limited extensibilty due to middlebox threat.
- Adding post-quantum cryptography is not feasible.

It is in practice impossible to implement TLS 1.2 securely. The best
one can do is some approximation with multiple unimplemented features
that is approximately secure.

Then there are non-security issues with TLS 1.2. Like ciphersuite
negotiation being petty much impossible to implement correctly due
to coupling between encryption and certificates.

> To see what I mean about denial of service, a
> "stateless" server implemented according to the
> way RFC 8446 describes is not going to have the
> actual HelloRetryRequest message it sent to the
> client.  I don't know what is done to solve this
> problem, but apparently a lot of people have
> implemented stateless-HRR so they must have done
> something to either guess this value, or maybe
> their code is not actually stateless.  If they
> are guessing the value of HRR based on the 2nd
> ClientHello received, and they guess wrong, and
> the client puts a different value of HRR in its
> own Transcript-Hash, then the handshake will
> fail and a legitimate client will be denied
> service.

Have function cookie_to_hrr(c,cs,grp) that turns a cookie c into
HRR message, and is pure function of the cookie.

Then:

Without cookie:

1) Receive ClientHello without cookie.

2) Figure out ciphersuite cs and group grp to use.

3) Compute invariant partial hash of Client Hello.

4) Serialize state, including full client hello hash, cs and grp in
   cookie (no need to include the invariant hash).

5) Use MAC to authenticate the cookie, including the invariant hash.
   
   OR

   Use MRAE to encrypt and authenticate cookie, including the invariant
   hash in associated data.

6) Use cookie_to_hrr(c,cs,grp), send result to client and abort.


With cookie:

1) Receive ClientHello with cookie.

2) Compute invariant partial hash of Client Hello.

3) Authenticate the cookie, and decrypt it if it is encrypted. If
   authentication fails, abort. Important: There is an attack if
   this is not done!

4) Read full client hello hash, cs and grp from cookie.

5) Inject client hello hash to transcript.

6) Use cookie_to_hrr(c,cs,grp), and inject result to transcript.

7) Add inject second client hello to transcript.

8) Figure out other connection parameters besides ciphersuite and
   group, and continue handshake.


This can be proven to always work.


-Ilari