[Ach] Secure E-Mail Transport based on DNSSec/TLSA/DANE

[Sebastian]

Hi,

On 11/01/2015 12:21 PM, Gunnar Haslinger wrote:
> Hi,
>
> Austrian "Communications Authority" (Rundfunk und Telekom
> Regulierungs-GmbH) invites to a Workshop "E-Mail-Security, What
> providers can contribute" this week (5th November, in Vienna).
> See Website: https://www.rtr.at/de/inf/E_Mail_Sicherheit05112015
I heard that some people, who are active at/in bettercrypto, will attend
:) Would be great to meet you there!
> As I spent the last weekends figuring out how DNSSec, BIND, Postfix ...
> work together and should be configured to build a Secure E-Mail
> Transport based on DANE, I'm looking forward to attend this workshop.
>
> I wrote a practically oriented paper about this topic.
> It's still in work - so status is "Draft"!
> And sorry - it't written in german, but as I know many of you come from
> the german speaking part of europe maybe there is somebody interested in.
>
> I uploaded the paper here:
> https://it-sec.ovh/secure-mail
>
> FYI: The Domain "it-sec.ovh" is just a DNSSec enabled Demo-Domain used
> for implementing a Secure E-Mail Transport based on DANE, if somebody
> likes to test his/her system against mine you are welcome to do so.
>
> Feedback regarding my paper is highly welcome.
It's quite long and I just had a look on some small parts of this great
documents.

configuration of Apache in 5.1.1.
> Performance: Die schnelleren Ephemeral-ECDH-Key-Agreement-Varianten
sollen denlangsameren Ephemeral-DH-Varianten gegenüber bevorzugt werden.
en: "the faster ECDHE variants should be preferred over the slower EDH
variants"

I would like to discuss this here for ach too. I think the current
recommendation is basically 2 years old and the crypto landscape has
changed.

> Entfernung von Camellia – alle relevanten Clients ziehen AES ohnehin
vor, es würde somit nicht zur Anwendung kommen.
en: "removal of camellia - all relevant clients prefer AES over camellia
so it would never be used"
The reasoning for camellia is AFAIR that it can be used as sane fallback
if a flaw in AES is found. AES would be the only symmetric cipher,
whereas we have RSA, DH and ECDH for key exchange. It AES is broken, and
all our setups require AES, as we forbade camellia, we have a problem.
If we enable camellia (do not forbid it), we can easily switch from aes
to camellia by disabling it on at least on side.
Also see https://en.wikipedia.org/wiki/Camellia_%28cipher%29#Adoption
> Performance: AES-128 soll gegenüber AES-256 vorgereiht werden. AES256
bringt keine praxisrelevante zusätzliche Sicherheit.
"performance: aes-128 should be preferred over aes-256. aes-256 has no
relevant security over the 128 variant"
I don't know about the security part. But AES is most times implemented
as cpu extensions and openssl uses it automatically if present. Here a
benchmark on my notebook:

$ openssl speed -evp aes-128-cbc aes-192-cbc aes-256-cbc
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
bytes
aes-128-cbc      37099.53k    38996.33k    39900.98k    40155.92k   
40233.95k
aes-192 cbc      30046.07k    31734.99k    32428.18k    83262.45k   
84807.11k
aes-256 cbc      25873.84k    27235.08k    27787.90k    72604.33k   
73917.68k

And here on a virtualized server:
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
bytes
aes-128-cbc      68294.84k    75900.15k    78432.15k   186528.96k  
188700.69k
aes-192 cbc      60960.82k    64182.95k    65496.30k   157816.60k  
158468.43k
aes-256 cbc      52705.83k    55418.73k    54468.30k   134780.59k  
136797.84k

The -evp uses hardware acceleration if present (must be switched on
explicitly for the tests). I'm unsure if this is time gap is significant
enough to throw out AES-156.

I also had a quick glance over the postfix and dovecot sections and they
look fine. But that's no detailed review.
Great document, even more useful if it was in English ;)

Sebastian
> -- 
> python programming - mail server - photo - video - https://sebix.at
> To verify my cryptographic signature or send me encrypted mails, get my
> key at https://sebix.at/DC9B463B.asc and on public keyservers.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20151102/ac6974ce/attachment.sig>