Designing a simpler alternative to TLS

[Philip Linde]

On Sat, 21 Nov 2020 03:30:22 -0500
Sean Conner <sean at conman.org> wrote:

>   I'm no crytographic expert, but I don't see how this protocol prevents
> MITM attacks; the details in the key share (section 2.2.1) don't go into
> enough detail for my liking.  How do I know I'm talking to the server in
> question, and not being invisibly proxied by Eve or Mal?  And how does each
> side determine an insecure key share?  What exactly goes over the wire?

It seems to prevent this only to the same extent that the Gemini TOFU
(mis-)use of TLS does. First, ephemeral keys are generated and the
public keys are exchanged. The rest of communication is encrypted
using these keys. The server then sends the client an Authentication
message which contains the certificate and a corresponding signature of
the ephemeral public keys. The client verifies that the signature of the
public keys is correct according to the public key of the certificate.

You could then just pin that certificate on first use if you trust that
there is not a man in the middle at that moment. From that point, you
can verify that it's the same certificate in all future exchanges. This
is a weakness, but in principle the same weakness exists in the use of
self-signed non-preshared certificates in Gemini.

I think it's an interesting exercise, however unlikely to replace the
use of TLS in Gemini. For Gemini, I'd much rather see conventions for
peer verification of certificates where servers can share lists of
certificates they use for different hosts, and self-revocation lists
that contained self-signed revocation messages whereby a certificate
can revoke itself.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201121/d69f00dc/attachment.sig>