Re: HTTPS trust anchors in sysinst

The reverse DNS thing is something that happens sometimes for some 
people. I wish I could figure out the reason, because whenever I check 
it works fine for me. (Usually checking against 8.8.8.8)

   Johnny

On 2023-09-03 03:58, Mouse wrote:
>> 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

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: [email protected]             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol