Re: [TUHS] off-topic list

[Grant Taylor via TUHS <tuhs@minnie.tuhs.org>]

[-- Attachment #1: Type: text/plain, Size: 2820 bytes --]

On 06/25/2018 10:10 AM, Steffen Nurpmeso wrote:
> DKIM reuses the *SSL key infrastructure, which is good.

Are you saying that DKIM relies on the traditional PKI via CA 
infrastructure?  Or are you saying that it uses similar technology that 
is completely independent of the PKI / CA infrastructure?

> (Many eyes see the code in question.)  It places records in DNS, which 
> is also good, now that we have DNS over TCP/TLS and (likely) DTLS. 
> In practice however things may differ and to me DNS security is all in 
> all not given as long as we get to the transport layer security.

I believe that a secure DNS /transport/ is not sufficient.  Simply 
security the communications channel does not mean that the entity on the 
other end is not lying.  Particularly when not talking to the 
authoritative server, likely by relying on caching recursive resolvers.

> I personally do not like DKIM still, i have opendkim around and 
> thought about it, but i do not use it, i would rather wish that public 
> TLS certificates could also be used in the same way as public S/MIME 
> certificates or OpenPGP public keys work, then only by going to a TLS 
> endpoint securely once, there could be end-to-end security.

All S/MIME interactions that I've seen do use certificates from a well 
know CA via the PKI.

(My understanding of) what you're describing is encryption of data in 
flight.  That does nothing to encrypt / protect data at rest.

S/MIME /does/ provide encryption / authentication of data in flight 
/and/ data at rest.

S/MIME and PGP can also be used for things that never cross the wire.

> I am not a cryptographer, however.  (I also have not read the TLS v1.3 
> standard which is about to become reality.)  The thing however is that 
> for DKIM a lonesome user cannot do anything -- you either need to have 
> your own SMTP server, or you need to trust your provider.

I don't think that's completely accurate.  DKIM is a method of signing 
(via cryptographic hash) headers as you see (send) them.  I see no 
reason why a client can't add DKIM headers / signature to messages it 
sends to the MSA.

Granted, I've never seen this done.  But I don't see anything preventing 
it from being the case.

> But our own user interface is completely detached.  (I mean, at least 
> if no MTA is used one could do the DKIM stuff, too.)

I know that it is possible to do things on the receiving side.  I've got 
the DKIM Verifier add-on installed in Thunderbird, which gives me client 
side UI indication if the message that's being displayed still passes 
DKIM validation or not.  The plugin actually calculates the DKIM hash 
and compares it locally.  It's not just relying on a header added by 
receiving servers.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]