|SMTP TLS, but I am not obligated to provide a comprehensive
|justification in response to every trollish one liner, the above
Luckily there is the UDPish EDNS0 extension from RFC 2671 as in
The default is 1280 (RFC 2671, 4.5.1.).
The minimum is 1024 (RFC 3226, 3.; note: not 1220!).
The maximum is 65000.
Have a nice weekend
--steffen
--- Begin Message ---
On Sat, Dec 28, 2013 at 05:56:41PM +0100, Michael Str?der wrote:
> > http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-05.html#rfc.section.1.2
> >
> > This is why I am working to implement and standardize SMTP with DANE TLS.
>
> DANE itself does not help. It just shifts the trust anchor problem.
>
> DNSSEC secures the MX lookups.
For the record:
While indeed SMTP with DANE TLS relies on DNSSEC to secure the
MX lookup, it also critically relies on DANE for two additional
pieces of information:
- Downgrade resistant STARTTLS support signalling. Without
this MITM attackers simply suppress STARTTLS and the sender
proceeds in cleartext.
- TLS support signalling is combined with signalling that the
peer can be authenticated and all the key material needed to
perform authentication. Sending MTAs run unattended with no
user to "click OK". They must not routinely fail due to
Goedel's theorem for CA bundles (any set of trusted CAs is
either insecure or incomplete).
- Since it is already agreed that DNSSEC must be trusted to
protect the MX records, eliminating the CA bundle from the
picture reduces risk AND improves reliability to the point
where peer authentication with SMTP becomes usable. It is
NOT usable with CA bundles.
There are more good reasons why DANE is required as part secure
SMTP TLS, but I am not obligated to provide a comprehensive
justification in response to every trollish one liner, the above
will have to do.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
--- End Message ---