[TUHS] off-topic list
gtaylor at tnetconsulting.net
Tue Jun 26 04:48:33 AEST 2018
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
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
More information about the TUHS