[TUHS] off-topic list

[Grant Taylor]

On 06/25/2018 09:51 AM, Steffen Nurpmeso wrote:
> I cannot really imagine how hard it is to write a modern web browser, 
> with the highly integrative DOM tree, CSS and Javascript and such, 
> however, and the devil is in the details anyway.

Apparently it's difficult.  Or people aren't sufficiently motivated.

I know that I personally can't do it.

> Good question.  Then again, young men (and women) need to have a chance 
> to do anything at all.  Practically speaking.  For example we see almost 
> thousands of new RFCs per year.  That is more than in the first about 
> two decades all in all.  And all is getting better.

Yep.  I used to have aspirations of reading RFCs.  But work and life 
happened, then the rate of RFC publishing exploded, and I gave up.

> Really?  Not that i know of.  Resolvers should be capable to provide 
> quality of service, if multiple name servers are known, i would say.

I typically see this from the authoritative server side.  I've 
experienced this (at least) once myself and have multiple colleagues 
that have also experienced this (at least) once themselves too.

If the primary name server is offline for some reason (maintenance, 
outage, hardware, what have you) clients start reporting a problem that 
manifests itself as a complete failure.  They seem to not fall back to 
the secondary name server.

I'm not talking about "slowdown" complaints.  I'm talking about 
"complete failure" and "inability to browse the web".

I have no idea why this is.  All the testing that I've done indicate 
that clients fall back to secondary name servers.  Yet multiple 
colleagues and myself have experienced this across multiple platforms.

It's because of these failure symptoms that I'm currently working with a 
friend & colleague to implement VRRP between his name servers so that 
either of them can serve traffic for both DNS service IPs / Virtual IPs 
(VIPs) in the event that the other server is unable to do so.

We all agree that a 5 ~ 90 second (depending on config) outage with 
automatic service continuation after VIP migration is a LOT better than 
end users experiencing what are effectively service outages of the 
primary DNS server.

Even in the outages, the number of queries to the secondary DNS 
server(s) don't increase like you would expect as clients migrate from 
the offline primary to the online secondary.

In short, this is a big unknown that I, and multiple colleagues, have 
seen and can't explain.  So, we have each independently decided to 
implement solutions to keep the primary DNS IP address online using what 
ever method we prefer.

> This is even RFC 1034 as i see, SLIST and SBELT, whereas the latter 
> i filled in from "nameserver" as of /etc/resolv.conf, it should have 
> multiple, then.  (Or point to localhost and have a true local resolver 
> or something like dnsmasq.)

I completely agree that per all documentation, things SHOULD work with 
just the secondary.  Yet my experience from recursive DNS server 
operator stand point, things don't work.

> I do see DNS failures via Wifi but that is not the fault of DNS, but of 
> the provider i use.

Sure.  That's the nature of a wireless network.  It's also unrelated to 
the symptoms I describe above.

> P.S.: actually the only three things i have ever hated about DNS, and 
> i came to that in 2004 with EDNS etc. all around yet, is that backward 
> compatibly has been chosen for domain names, and therefore we gained 
> IDNA, which is a terribly complicated brainfuck thing that actually 
> caused incompatibilities, but these where then waved through and ok. 
> That is absurd.

I try to avoid dealing with IDNs.  Fortunately I'm fairly lucky in doing so.

> And the third is DNSSEC, which i read the standard of and said "no". 
> Just last year or the year before that we finally got DNS via TCP/TLS 
> and DNS via DTLS, that is, normal transport security!

My understanding is that DNSSEC provides verifiable authenticity of the 
information transported by DNSSEC.  It's also my understanding that 
DTLS, DOH, DNScrypt, etc provide DNS /transport/ encryption 
(authentication & privacy).

As I understand it, there is nothing about DTLS, DOH, DNScrypt, etc that 
prevent servers on the far end of said transports from modifying queries 
/ responses that pass through them, or serving up spoofed content.

To me, DNSSEC serves a completely different need than DTLS, DOH, 
DNScrypt, etc.

Please correct me and enlighten me if I'm wrong or have oversimplified 
things.

> Twenty years too late, but i really had good days when i saw those 
> standards flying by!  Now all we need are zone administrators which 
> publish certificates via DNS and DTLS and TCP/TLS consumers which can 
> integrate those in their own local pool (for at least their runtime).

DANE has been waiting on that for a while.

I think DANE does require DNSSEC.  I think DKIM does too.

> I actually hate the concept very, very much ^_^, for me it has 
> similarities with brainfuck.  I could not use it.

Okay.  To each his / her own.

> Except that this will work only for all-english, as otherwise character 
> sets come into play, text may be in a different character set, mail 
> standards may impose a content-transfer encoding, and then what you are 
> looking at is actually a database, not the data as such.

Hum.  I've not considered non-English as I so rarely see it in raw email 
format.

> This is what i find so impressive about that Plan9 approach, where 
> the individual subparts of the message are available as files in the 
> filesystem, subjects etc. as such, decoded and available as normal files. 
> I think this really is .. impressive.

I've never had the pleasure of messing with Plan9.  It's on my 
proverbial To-Do-Someday list.  It does sound very interesting.

> Thanks, eh, thanks.  Time will bring.. or not.

;-)

> It is of course not the email that leaves you no more.  It is not just 
> headers are added to bring the traceroute path.  I do have a bad feeling 
> with these, but technically i do not seem to have an opinion.

I too have some unease with things while not having any technical 
objection to them.

> Well, this adds the burden onto TUHS.  Just like i have said.. but 
> you know, more and more SMTP servers connect directly via STARTSSL or 
> TCP/TLS right away.  TUHS postfix server does not seem to do so on the 
> sending side

The nature of email is (and has been) changing.

We're no longer trying to use 486s to manage mainstream email.  My 
opinion is that we have the CPU cycles to support current standards.

> -- you know, i am not an administor, no earlier but on the 15th of March 
> this year i realized that my Postfix did not reiterate all the smtpd_* 
> variables as smtp_* ones, resulting in my outgoing client connections 
> to have an entirely different configuration than what i provided for 
> what i thought is "the server", then i did, among others
> 
> smtpd_tls_security_level = may +smtp_tls_security_level = 
> $smtpd_tls_security_level

Oy vey.

> But if TUHS did, why should it create a DKIM signature?  Ongoing is the 
> effort to ensure SMTP uses TLS all along the route, i seem to recall i 
> have seen RFCs pass by which accomplish that.  Or only drafts??  Hmmm.

SMTP over TLS (STARTTLS) is just a transport.  I can send anything I 
want across said transport.

DKIM is about enabling downstream authentication in email.  Much like 
DNSSEC does for DNS.

There is nothing that prevents sending false information down a secure 
communications channel.

> Well S/MIME does indeed specify this mode of encapsulating the entire 
> message including the headers, and enforce MUAs to completely ignore the 
> outer envelope in this case.  (With a RFC discussing problems of this 
> approach.)

Hum.  That's contrary to my understanding.  Do you happen to have RFC 
and section numbers handy?  I've wanted to, needed to, go read more on 
S/MIME.  It now sounds like I'm missing something.

I wonder if the same can be said about PGP.

> The BSD Mail clone i maintain does not support this yet, along with other 
> important aspects of S/MIME, like the possibility to "self-encrypt" (so 
> that the message can be read again, a.k.a. that the encrypted version 
> lands on disk in a record, not the plaintext one).  I hope it will be 
> part of the OpenPGP, actually privacy rewrite this summer.

I thought that many MUAs handled that problem by adding the sender as an 
additional recipient in the S/MIME structure.  That way the sender could 
extract the ephemeral key using their private key and decrypt the 
encrypted message that they sent.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180625/e20d8d0e/attachment.bin>