Re: HTTPS trust anchors in sysinst

> I do know that just using ssh against that machine takes somewhere
> around 20s to just get to the password prompt.  Compared to telnet,
> which is pretty instant.

That is more or less my basis for concern as well.  The PK crypto
involved in ssh kex typically takes a human-long time when one of my
SS20s is involved.  (I just did a test.  An SS20 sshing to a fast
machine took 32 seconds, based on "date; ssh fastmachine date; date".
Well, actually, "date; ssh -no-share fastmachine date; date", because
without the -no-share it would have used my existing shared connection,
which brings it down to about a second - still human-perceptible, but
far more usable.)

Now, as a cryptographer I'm strictly a dilettante.  I don't know the
details of SSL/TLS/whatever-it's-called-this-week, and I don't know how
its crypto compares to ssh's.  But I do know that "modern" software
tends to consider HTTPS connections free, as in, it doesn't seem to
even hesitate to do half a dozen of them if that is slightly more
convenient at the source-code level.  Perhaps the code being
contemplated for the installer is more parsimonious.  But I have little
faith that it will be, especially since the (in)famous decision to
focus on "industrially relevant" architectures at the expense of
smaller machines, compounded by NetBSD's use of external components,
such as OpenSSL, that tend to be written and maintained by people who
think two 1GHz 64-bit cores with 8G of RAM is a small machine.  (Come
to think of it, actually, the latter is unsurprising in view of the
former.)

This is compounded by the CA hierarchy design, which (as I understand
it - again, dilettante here) involves a PK crypto op for each level of
CA involved.  Per connection.

> And I just reply to all when I reply, but the copies to Mouse
> constantly fails because his mail server refuse to talk with me.

Well, that's convenient in that it means I don't get constant
duplicates of your list mail.  But...

> Received: from Mim.Stupi.NET (MIM.Stupi.NET [192.108.202.74])
> 	by mail.netbsd.org (Postfix) with ESMTP id D122984D24
> 	for <[email protected]>; Sun,  3 Sep 2023 01:10:55 +0000 (UTC)

Curious.  That doesn't _look_ problematic.

Checking, I find I got mail from you that (as far as I can tell from my
logs) worked fine on 2023-08-07, 2023-08-26, and 2023-08-27.  Yeah,
here's one of them in my mailbox:

Received: from Mim.Stupi.NET (<user:SYSTEM>@MIM.Stupi.NET [192.108.202.74]) by Stone.Rodents-Montreal.ORG via TCP with SMTP id "RgJtqg.MnWh.SmP"; 27 Aug 2023 18:28:06 -0400 (EDT, 22:28:06 GMT)

On 2023-08-30, my SMTP listener started getting NXDOMAIN when looking
up your rDNS.  I don't know why (whatever was wrong seems to have gone
away now) - but it lasted long enough for my defenses to get fed up and
ban that IP until 2023-09-06 sometime (the exact time should be given
in the SMTP rejection message).  I've manually destroyed the state for
that IP, so it should work once again now.

I really REALLY wish we still had a civilized net, one where that level
of defensive paranoia weren't necessary.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B