[tialaramex]

We should distinguish whether we want everybody to be able to authenticate the messages or only our intended recipient. This is separate from the question of whether the message should be encrypted. It may be reasonable for infrastructure to work only with messages everybody may authenticate since there is nothing to hide. For this purpose a Signature Scheme is ideal - simply sign your messages.

Whereas for example in Signal two people could have made an Alice->Bob message. Both Alice and Bob have the keys to make such a message. Alice might have made it, and sent it to Bob, or, Bob might have just made it seem as though Alice sent him a message. Bob presumably knows if he's lying, but he can't prove it either way.

The unauthenticated link is basically useless. You aren't "securely talking to an unknown entity" because if you were that would be an authenticated link. TLS 1.3 can do "securely talking to an unknown entity" - but it's an authenticated link, the unknown entity is the authenticated remote party. You don't know who they are, but you do know they're your remote party whoever that is.

[H8crilA]

Maybe I should have added what an encrypted, but not authenticated link looks like, because I meant it in both directions. An example would be doing unauthenticated Diffie-Hellman (without any signatures, or proving knowledge of a secret, or anything of this sort), then proceeding using the shared key with even the best of schemes. Another example would be a spy sending and receiving one-time-pad encrypted data via an untrusted, malleable channel - the only authenticity is in hoping that adversarial modifications will cause one of the endpoints to fail at "parsing" the message. It is indeed useless.

Also, this property of Signal is called repudiation (or non-non-repudiation :) ), meaning that you as a party in the communication can repudiate the origin of the message, i.e. say that you didn't write it. It is a nice extra feature, on top of authenticity and secrecy.

[tialaramex]

> then proceeding using the shared key with even the best of schemes

Unlike with your "spy" scenario, this situation is in fact what TLS 1.3 builds initially and it's not useless at all, nor is the resulting link unauthenticated.

1. First Alice sends her fresh parameters to Bob

2a. Then Bob sends his fresh parameters to Alice

2b. Alice and Bob now have all the DH parameters and they now have a shared secret X

2c. Bob calculates a Digest of a transcript of the entire conversation so far and sends this Digest, encrypted with X to Alice, he can send this alongside the parameters if he wants

3. Alice also likewise calculates a Digest and sends the encrypted digest to Bob

Both Alice and Bob now have a shared secret and have an authenticated (because they've seen the other party's view of the conversation in the digest and confirmed it matches their expectation) communication channel which they can use. They don't learn each others' identity but, of course, it is easy to additionally offer this as part of the same protocol and HTTPS does so in one direction in the typical case.

Edited: Renumbered to clarify that only three messages are sent, parts 2a, 2b and 2c are actually a single message from Bob to Alice

[H8crilA]

I meant that man in the middle attacks make this effectively unauthenticated.

[tialaramex]

Suppose that Eric is in the middle.

Eric could allow those initial three messages to pass unmolested. In this case Alice and Bob now have an authenticated connection and Eric is unable to read or modify their messages. So I suppose you don't mean that.

What if Eric just substitutes his own message for Alice's in step 1? He provides his own parameters. Since these were not Alice's parameters, Alice will not provide an acceptable Digest for the conversation, the parameters Eric sent to Bob are different and do not match the transcript, the connection is terminated.

What if Eric substitutes Bob's only message in step 2? He provides his own parameters, and he can respond with a transcript digest for this alternate conversation. Now in fact the TLS 1.3 connection exists as normal, but it is between Alice and Eric. We're actually fine! We have a properly authenticated connection, with unidentified participants (we know they're Alice and Eric but Alice and Eric don't know that). Bob's connection fails, or he is unaware that Alice tried to connect.

Finally if Eric waits until Alice's second message in step 3, no message Eric knows how to construct is satisfactory. Only Alice's original message will work, other messages cause the connection to fail because Bob will not accept them.

[H8crilA]

I'm sorry, are you trolling? You pretend to be Bob to Alice, and Alice to Bob, at the same time. Real Alice and Bob never compute the same transcript digests, but it doesn't matter. As post handshake data is flowing you decrypt it and reencrypt, modifying what you want.

Or, imagine that there isn't even one legitimate Bob in the world. But Alice is still talking to someone who follows the protocol, and is indistinguishable from a real Bob. Is that possible?

[tialaramex]

I'm not trolling, I just don't think you've really thought about what "authentic" could mean if you don't have identity, which is a distinct problem.

For Alice there's no difference between a Bob whose identity you don't know and an Eric whose identity you don't know, they're each just another anonymous party.

Eric can't fool Alice and Bob into believing they're talking to each other, because they're using separate channels and identity systems will bind to the channel. Suppose Bob provides his identity, that's bound to the Eric-Bob channel, when Eric copies it to the Eric-Alice channel it's just obviously fraudulent, he could have made his own fraudulent claim of Bob's identity just as easily.