About document signing

Hello,

I'm reading Gemini stuff for days now and I feel that the idea of a 
lighter and safer web is marvelous.

I must confess that TLS is a big issue for me.
I don't really trust TLS as company/states nowdays use TLS interception 
and we should consider TLS as broken.
Really secure application are now using end-to-end encryption at 
application level (protonmail, etc.).

Why not simply using GPG?

Signing all document at publication time (oneshoot computation) and 
serving gemini page with server/path/document.gmi + 
server/path/document.gpg could assure you that the original document is 
free of hacking and don't break minimalist gemini browser.

* This keep the phylosophy of serving data with only one connexion, the 
second for security purpose is optional.
* Keeping vital data (text) throughput requirement low is important to 
spread on network with low bandwidth and high latency.


Regards, K.I.S.S and Less is More :-)
freD.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - defdefred at protonmail.com - 0xF2B9981B.asc
Type: application/pgp-keys
Size: 1828 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200518/f8e8
5cc8/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 477 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200518/f8e8
5cc8/attachment.sig>

May 18, 2020 2:50 PM, "defdefred" <defdefred at protonmail.com> wrote:

> Hello,
> 
> I'm reading Gemini stuff for days now and I feel that the idea of a 
lighter and safer web is
> marvelous.
> 
> I must confess that TLS is a big issue for me.
> I don't really trust TLS as company/states nowdays use TLS interception 
and we should consider TLS
> as broken.

well... the spec recommends TOFU verification, which would mean you can 
safely self-sign your sites, which many do
the TOFU part, as is mentioned in the spec, works by trusting the first cert you see,
so all you'd need to do is get the site ONCE, through a trusted 
connection, and be done with it, you can just ignore all the CAs and 
chains or trust and whatnot,
so unless the company/state manages to re-encrypt with the exact SAME KEY, 
you will see it differ, and can warn user or refuse connection.

PGP isn't a bad idea, but I don't think there's anywhere CLOSE to as much 
support to PGP APIs than there is to TLS, in various programming 
languages, and calling an OS program, even when possible, is usually seen 
as a bad idea...

On Mon, May 18, 2020 at 11:50:30AM +0000, defdefred wrote:
> 
> Why not simply using GPG?
> 
> Signing all document at publication time (oneshoot computation) and 
serving gemini page with server/path/document.gmi + 
server/path/document.gpg could assure you that the original document is 
free of hacking and don't break minimalist gemini browser.

Unless I've badly misunderstood something, this solution:

1) Provides literally nothing in the way of confidentiality (the first
request happens totally as plaintext, right?).  That means your ISP
can monitor everything you read via Gemini and compile a behavioural
profile to sell to marketers and/or to have stolen by state security
serivices.  States with censorship regimes can requires ISPs to
terminate connections when forbidden keywords are detected in plaintext
content.  In this respect, Gemini would be no improvement over Gopher.

2) Provides authentication and integrity if and only if the client has
some totally unspecified way of securely acquiring the public key
required to validate the signature downloaded in the second request
- i.e. if we assume that the really hard part of public key cryptography
is already solved.

TLS certainly has problems, but it's better than this!

Of course, there is nothing wrong with signing files to be distributed
via Gemini and if this makes sense for people they can and should do
exactly this.  But it's not in any way a sensible blanket solution.

Cheers,
Solderpunk

Hi!

I love cryptography so this is kinda my area of interest. Just to add to
solderpunk's great reply: modern TLS with DH also adds forward secrecy,
which is a very desirable property that GPG lacks.

Inline on freD's message:

I must confess that TLS is a big issue for me.
I don't really trust TLS as company/states nowdays use TLS interception and
we should consider TLS as broken.


Can you elaborate? What is TLS interception and how does it make TLS broken?

Really secure application are now using end-to-end encryption at
application level (protonmail, etc.).


AFAIK Protonmail uses both: TLS for in-transit crypto (communication with
Protonmail servers) and GPG for at-rest crypto (the actual mail contents).

As a reminder: TLS is end-to-end encrypted!

In summary: TLS and GPG solve different problems and they can be used
alongside. (Also: GPG is a nightmare and there are better alternatives[0],
but that's another story).

Cheers,
kaoD

[0] https://www.cryptologie.net/article/502/alternatives-to-pgp/,
discussion in Reddit
https://www.reddit.com/r/crypto/comments/ggvl2h/alternatives_to_pgp/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200518/367b
bf25/attachment.htm>

On Mon, May 18, 2020 at 03:06:24PM +0200, kaoD wrote:
 
> I love cryptography so this is kinda my area of interest. Just to add to
> solderpunk's great reply: modern TLS with DH also adds forward secrecy,
> which is a very desirable property that GPG lacks.

I am planning for the next spec revision to state that Gemini
transactions using TLS 1.2 MUST use only a limited set of ciphersuites,
all of which will provide forward secrecy.  I will be relying on the
community to help curate a list of example code for different
languages/libraries to impose these constraints.

As I've said elsewhere, I would *love* to spec only TLS 1.3 or above,
where all options provide forward secrecy and old cruft like RC4 has
been removed.  But this would be equivalent to requiring OpenSSL, which
I'd rather not do.  As a compromise, 1.2 will be allowed but only if
used responsibly.

> Can you elaborate? What is TLS interception and how does it make TLS broken?

I imagine this is mostly in reference to companies loading their
employee's computers with browsers that have the company's own CA added
alongside the browser's defaults.  Which is not a cryptographic break of
TLS in any way.

Cheers,
Solderpunk

??????? Original Message ???????
On Monday 18 May 2020 14:45, solderpunk <solderpunk at SDF.ORG> wrote:
> 1.  Provides literally nothing in the way of confidentiality (the first
>     request happens totally as plaintext, right?). That means your ISP
>     can monitor everything you read via Gemini and compile a behavioural
>     profile to sell to marketers and/or to have stolen by state security
>     serivices. States with censorship regimes can requires ISPs to
>     terminate connections when forbidden keywords are detected in plaintext
>     content. In this respect, Gemini would be no improvement over Gopher.

GPG signing is only for data integrity and achieve simple secure public 
data diffusion with optional client driven computation.
If someone need to store private information in a gemini server I will 
tell him to store file already encryted with his public key.
Is TLS really useful in censorship regimes or are they closing access to 
all web site where they can't add TLS inspection?
Courageous people are rather using VPN and/or multiple ssh jump to hide...

With TLS, only the transport layer is "secure", but you don't know if 
someone hack the server and the files!
It is not End-to-End encrypted between the writer and the reader.

> 2.  Provides authentication and integrity if and only if the client has
>     some totally unspecified way of securely acquiring the public key
>     required to validate the signature downloaded in the second request

Initial TOFU is no more an option?

Maybe having gimini:// and TLS geminis:// is the way to go to keep gemini 
usable for small computer and low bandwith networks.

Imagine, the gemini browser:
1. download the first file.gmi and present it to the user.
2. download the second file.gpg while the user is reading.
3. after computation notice if file integrity is preserved.

Regards,
freD.

On Monday 18 May 2020 15:06, kaoD <elkaod at gmail.com> wrote:

> I love cryptography so this is kinda my area of interest. Just to add to 
solderpunk's great reply: modern TLS with DH also adds forward secrecy, 
which is a very desirable property that GPG lacks.
In cryptography, regular enhancement is mandatory :-)

> Can you elaborate? What is TLS interception and how does it make TLS broken?
https://en.wikipedia.org/wiki/Transport_Layer_Security_Security#TLS_interception

> AFAIK Protonmail uses both: TLS for in-transit crypto (communication 
with Protonmail servers) and GPG for at-rest crypto (the actual mail contents).
They use both because the old SMTP protocol is keeping metadata impossible to encrypt.

> As a reminder: TLS is end-to-end encrypted!
Not End-to-End (Writer-to-Reader)... Only Server-to-Browser, without 
protection for the hosted files.

> [0]?https://www.cryptologie.net/article/502/alternatives-to-pgp/, 
discussion in Reddit?https://www.reddit.com/r/crypto/comments/ggvl2h/alternatives_to_pgp/
Maybe the blog author is forgotting that GPG signing is not useful without 
verifying signature...

Regards,
freD.

May 18, 2020 5:20 PM, "defdefred" <defdefred at protonmail.com> wrote:
>> As a reminder: TLS is end-to-end encrypted!
> 
> Not End-to-End (Writer-to-Reader)... Only Server-to-Browser, without 
protection for the hosted
> files.

even for PGP, unless you encrypt in a way decryptable with a specific key, 
you still only can trust as far as your server...
otherwise you need either some out of band way to get the key

if you get the key over gemini or other unencrypted connection, how do you 
know the key AND the data haven't been modified?
if you send plain content and then key, how do you know the separate key 
or signature was not modified on the server, or in transmission?

you can not have writer-to-reader encryption *AND* have it accessible to 
lots of people, without trusting the server...

defdefred <defdefred at protonmail.com> writes:

> With TLS, only the transport layer is "secure", but you don't know if
> someone hack the server and the files! It is not End-to-End encrypted
> between the writer and the reader.

You're missing the point that Gemini is a client-server protocol. The
two ends are the client and the server; it's not like email or chat
where the two ends are clients with a server in between.

TLS is *not* broken ? arguably, the CA system is broken, and it's very
broken if your employer or government can force you to accept them as a
CA, which is where TLS interception comes in. But Gemini does not rely
on the CA system.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |