Wiadomość napisana przez Viktor Dukhovni <vik...@dukhovni.org> w dniu 
13.04.2017, o godz. 20:35:
> 
> 
>> On Apr 13, 2017, at 1:55 PM, Zbyszek Żółkiewski <t...@onefellow.com> wrote:
>> 
>> And as the note that it not make things secure: yes i understand that - but 
>> if there is technology that is new and can be used - why not prioritize it 
>> where it can be? What’s the point then introducing new stuff if nobody uses 
>> it? In my opinion we should push new things, not hide it.
> 
> If you want new, deploy a system that uses OpenSSL 1.1.0, and not OpenSSL
> 1.0.1, which reached end-of-life in Dec 2016 and gets no further security
> fixes.

I hope to get there with next stable release

> 
> In any case, in opportunistic security broad interoperability is far more
> useful than cutting-edge sophistication.  Let the browsers and other
> software push the envelope with new algorithms, and over time these will
> become the norm in the underlying crypto libraries.

I think SMTP get too old and it will get even older and more obsolete if we 
will not put newtech/cutting edge into it. Even with hard push to enable 
encryption by default - we all know it will take many years until sysadmins 
decide to go „encrypt only” with smtp servers - there always will be someone 
who use old software. At some point community will have to decide to drop those 
who left too far behind. 

> 
> It makes little sense to expend precious energy on optimizing (best-effort)
> TLS in SMTP.  If you want security, deploy DNSSEC and DANE for your domain:

yes, maybe my desire to prefer ECDSA was/is not worth of effort - at last, I 
just wanted to be used more - but it roll into nice discussion anyways 

> 
>   
> http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444
>   https://www.ietf.org/mail-archive/web/uta/current/msg01498.html
>   https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766
>   
> https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/
>   
> https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022
>   http://tools.ietf.org/html/rfc7671#section-8.1
>   http://tools.ietf.org/html/rfc7671#section-8.4
>   http://dane.sys4.de/common_mistakes
> 

thanks for the reference - i am tight to AWS R53 with some features

> That makes a real difference, while it is far from clear whether ECDSA is
> actually more or less secure than RSA.  Of course deploying DANE means
> getting the operational details right:
> 
>   * Monitoring of TLSA record validity (match the actual server cert chain)
>   * Monitoring of DNSSEC DS/DNSKEY records and signature non-expiration
>   * Reliable key rotation
>   * …

running good SMTP server is a serious job but also compelling 

> 
> This takes some skill to get right.
> 
> -- 
>       Viktor.
> 

_
Zbyszek Żółkiewski

Reply via email to