[openssl-users] OpenSSL version 1.1.0 pre release 6 published

[Jakob Bohm]

On 05/08/2016 01:48, Viktor Dukhovni wrote:
> On Thu, Aug 04, 2016 at 04:30:39PM -0700, Carl Byington wrote:
>
>> Have you seen the mta-sts proposal:
> Of course.
>
>> But mta-sts starts with an unauthenticated dns TXT record.
> Yes, this is but one of its compromises.
>
>> If that proposal is worth anything, it indicates there is some use for a
>> mechanism to allow publishing unauthenticated data in dns to be used by
>> mail senders to constrain the acceptable tls keys.
> You misunderstand the role of the DNS record in STS.  It is a
> cache-priming signal, it is not the actual policy, which is always
> delivered via HTTPS.
>
> You're also forgetting that RFC7672-compliant MTAs MUST NOT attempt
> to retrieve TLSA records when the address records are insecure, so
> "DANE=always" will almost never happen.
>
>> I think it is better to publish an unauthenticated TLSA record, rather
>> than to publish an unauthenticated TXT record that then leads to an
>> https url which then delivers the tls key constraints.
> Except that nobody will use it, when it lies in the same unsigned
> zone as the host records.
>
>> None of these MX, A, and TLSA records are signed. But mail senders
>> *could* still enforce the constraints implied by that TLSA record.
> But they MUST NOT look up the TLSA record except when it is (rarely)
> a CNAME from a signed to an unsigned zone.
>
>> Compared to mta-sts, this is easier for mail senders (a single TLSA
>> record, rather than a TXT record and an entire https infrastructure with
>> its own tls keys and pki certificates). It is also easier for mail
>> receivers, since it is not much code to relax the "must be dnssec
>> signed" constraint in the existing DANE code.
> I am not an avid fan of STS, but I am helping the authors to avoid
> needless mistakes.
>
I haven't read that proposal, but if the HTTPS server has to use the
same host name as the SMTPS server, then the SMTPS server could just
use the certificate directly.

Alternatively, if the HTTPS server has to have a specific name
relationship to the name of the SMTPS server or the RCPT TO domain,
then a rule to allow the weaker name matching directly on the SMTPS
certificate could be a simplification.

An unauthenticated or weakly authenticated flag to indicate a
specific certificate caching or matching discipline might be doable
on the SMTP(S) connection e.g. as a capability keyword in the initial
EHLO exchange, next to the keywords that indicate other SMTP features,
I think there is an IANA registry for those.

Just some ideas for those working on this.

Note that putting a feature extending proxy in front of an SMTP server
is common already, for example many spam-filters operate like that.
This can be used to add any needed extensions to an existing SMTP
server that can't be modified.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded