Hello, Since implementing automatic certificate generation in Agate and choosing Ed25519 as the default algorithm over ECDSA [1], I have received multiple complaints about server operators not being able to connect to their own servers because clients seemingly did not support this signing algorithm. Some that were mentioned by name were Ariane, Deedum and portal.mozz.us. I have to agree with Stéphane that this should not be the case, and other people raised concerns about which TLS libraries are used as well. Although I will most likely have to switch the default algorithm to ECDSA since support for Ed25519 seems so bad, please check if a browser that you maintain (or the library it uses respectively) does support Ed25519. If it does not, please reconsider the library choice. Regards, Johann [1] The reasoning being mainly derived from what followed in this thread: <gemini://gemi.dev/gemini-mailing-list/messages/006134.gmi> It would be interesting to see if this has made any impact towards quantitative usage of Ed25519 according to Lupa.
> Hello, > > Since implementing automatic certificate generation in Agate and choosing > Ed25519 as the default algorithm over ECDSA [1], I have received multiple > complaints about server operators not being able to connect to their own > servers because clients seemingly did not support this signing algorithm. > > Some that were mentioned by name were Ariane, Deedum and portal.mozz.us. > I have to agree with St?phane that this should not be the case, and other > people raised concerns about which TLS libraries are used as well. > > Although I will most likely have to switch the default algorithm to ECDSA > since support for Ed25519 seems so bad, please check if a browser that > you maintain (or the library it uses respectively) does support Ed25519. > If it does not, please reconsider the library choice. > > Regards, > Johann I am currently facing this issue too. It is also the case with Bombadillo. What is the best thing to do here? Use different certs? - Eoin
On Thu, Apr 08, 2021 at 12:33:39AM +0200, Johann Galle <johann@qwertqwefsday.eu> wrote a message of 170 lines which said: > choosing Ed25519 as the default algorithm over ECDSA [1], I have > received multiple complaints about server operators not being able > to connect to their own servers because clients seemingly did not > support this signing algorithm. Lupa <gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi> shows that indeed only a small minority of capsules use Ed25519. There is probably a chicken-and-egg probleme here, since client support, as you noticed, is poor, which does not motivate capsulemasters. This is a serious problem for Gemini. Ed25519 in TLS was standardized in RFC 8410 <gemini://gemini.bortzmeyer.org/rfc-mirror/rfc8410.txt>, more than two years ago. And of course, it is much older than that, so all TLS implementations should have it by now. The Web has no such problem. Ed25519 has two characteristics:
Stéphane Bortzmeyer writes:
> So I do not really see why someone would like to use exotic TLS
> libraries without Ed25519.
Do we have a list of which libraries do not include Ed25519?
--
Jason McBrayer | “Strange is the night where black stars rise,
jmcbray@carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.”
| ― Robert W. Chambers,The King in Yellow
> Do we have a list of which libraries do not include Ed25519? It looks like it was only recently added to plain Java in JDK 15: https://seanjmullan.org/blog/2020/10/13/jdk15 That may be why both of the Android clients I tried (Ariane and Deedum) were unable to connect when I used a default-generated cert from Agate. FWIW, it also looks like neither Chromium nor Firefox supports Ed25519 signatures https://security.stackexchange.com/questions/236931/whats-the-deal-with-x25 519-support-in-chrome-firefox
On Mon, Apr 12, 2021 at 11:59 AM Jason McBrayer <jmcbray@carcosa.net> wrote: > > Stéphane Bortzmeyer writes: > > > So I do not really see why someone would like to use exotic TLS > > libraries without Ed25519. > > Do we have a list of which libraries do not include Ed25519? portal.mozz.us is using openssl 1.0.2k from the Centos 7 repo [0], which is still supported, but old enough that it doesn't include ed25519. - Michael [0] https://centos.pkgs.org/7/centos-updates-x86_64/openssl-1.0.2k-21.el7_9 .x86_64.rpm.html
Michael Lazar writes:
> On Mon, Apr 12, 2021 at 11:59 AM Jason McBrayer <jmcbray@carcosa.net> wrote:
>>
>> Stéphane Bortzmeyer writes:
>>
>> > So I do not really see why someone would like to use exotic TLS
>> > libraries without Ed25519.
>>
>> Do we have a list of which libraries do not include Ed25519?
>
> portal.mozz.us is using openssl 1.0.2k from the Centos 7 repo [0],
> which is still supported, but old enough that it doesn't include
> ed25519.
Yeah, that doesn't surprise me too much. I am a little surprised that
it's newer (1.1.1d) in Debian stable, but it's probably just a release
cycle thing. It looks like ed25519 support appears in OpenSSL 1.1.1.
--
Jason McBrayer | “Strange is the night where black stars rise,
jmcbray@carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.”
| ― Robert W. Chambers,The King in Yellow
---