Subject: [Uta] Question Regarding DANE and MTA-STS

From: Ranjana Mukhia <[email-masked]>
Date: Wed, 3 Jan 2018 10:35:20 +0530

On Wed, Jan 3, 2018 at 10:28 AM, Ranjana Mukhia <[email-masked]>
wrote:

> >Neither DANE nor STS provide message origin authenticity,
> >these are hop-by-hop security mechanisms that authenticate
> >only the receiving system, not the sender.
>
> What will be the provision for the origin authenticity then ? How to
> authenticate the sender ?
>
> On Wed, Jan 3, 2018 at 1:30 AM, <[email-masked]> wrote:
>
>> Send Uta mailing list submissions to
>>         [email-masked]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://www.ietf.org/mailman/listinfo/uta
>> or, via email, send a message with subject or body 'help' to
>>         [email-masked]
>>
>> You can reach the person managing the list at
>>         [email-masked]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Uta digest..."
>>
>> Today's Topics:
>>
>>    1. Question Regarding DANE and MTA-STS (Ranjana Mukhia)
>>    2. Re: Question Regarding DANE and MTA-STS (Viktor Dukhovni)
>>
>>
>> ---------- Forwarded message ----------
>> From: Ranjana Mukhia <[email-masked]>
>> To: [email-masked]
>> Cc:
>> Bcc:
>> Date: Tue, 2 Jan 2018 17:33:25 +0530
>> Subject: [Uta] Question Regarding DANE and MTA-STS
>> Hello All,
>>
>> This related to the below part of the latest uta-mta-sts-13 draft
>>
>> >The primary motivation of MTA-STS is to provide a mechanism for domains
>> to ensure transport >security even when deploying DNSSEC is undesirable or
>> impractical. However, MTA-STS is >designed not to interfere with DANE
>> deployments when the two overlap; in particular, senders who >implement
>> MTA-STS validation MUST NOT allow a "valid" or "testing"-only MTA-STS
>> validation to >override a failing DANE validation.
>>
>> My questions are
>>
>> 1.If we are going to implement MTA-STS then, whether it should be
>> compulsorily used with DANE ?If Not why ? as we have faced many problems
>> related to CA's in past.
>>
>> 2.Whether MTA-STS is fully capable of securing email transmission without
>> the help of any other technologies like DKIM,SPF,DMARC or DANE ?
>>
>>
>> Thanks
>>
>> Regards
>>
>> Ranjana
>>
>>
>> ---------- Forwarded message ----------
>> From: Viktor Dukhovni <[email-masked]>
>> To: [email-masked]
>> Cc:
>> Bcc:
>> Date: Tue, 2 Jan 2018 11:35:43 -0500
>> Subject: Re: [Uta] Question Regarding DANE and MTA-STS
>>
>>
>> > On Jan 2, 2018, at 7:03 AM, Ranjana Mukhia <[email-masked]>
>> wrote:
>> >
>> > 1.If we are going to implement MTA-STS then, whether it should be
>> compulsorily
>> > used with DANE?
>>
>> Nothing is compulsory.  The standards will tell you how to use STS, but
>> cannot compel its use.  Implementations that strive to avoid downgrade
>> and MiTM attacks should generally not permit weaker policies to downgrade
>> concurrent stronger policies.  Therefore, if:
>>
>>          1.  The domain's MX records are DNSSEC validated, and
>>
>>         2.  The MX hostname to which a connection is established
>>             is also in a signed zone (its A/AAAA records are signed,
>>             or result from a CNAME alias and the initial CNAME
>>             from the MX hostname is secure), and
>>
>>         3.  Secure TLSA records are published at the domain obtained
>>             by prefixing _<port>._tcp. (port is typically "25") to
>>             either:
>>
>>                 a.  The secure full CNAME expansion of the MX hostname,
>>                     or else if not secure, or, if no TLSA records present
>>                     there (NXDomain or NODATA, abort use of MX host on
>>                     TLSA lookup failure), at
>>                 b.  The original MX hostname (abort use of MX host on
>>                     TLSA lookup failure).
>>
>>
>> then, a sender that supports and enables DANE should typically ignore STS.
>> Requiring both when both are published feels too fragile to me, and
>> requiring
>> either downgrades DANE security.
>>
>> On the other hand, some domains might have only a partial DANE
>> implementation, where some MX hosts have TLSA records and others
>> do not.  In that case, when a given MX host is not secured with
>> DANE, but the domain has STS policy, it makes sense to apply STS
>> when delivering via that MX host (assuming STS is supported and
>> enabled at the sender).
>>
>> > 2.Whether MTA-STS is fully capable of securing email transmission
>> > without the help of any other technologies like DKIM,SPF,DMARC or DANE?
>>
>> You have not defined "securing email transmission".  STS and DANE
>> are both designed to authenticate the nexthop SMTP destination to
>> the sending MTA, and to transmit the message envelope and body over
>> a TLS channel that provides integrity and confidentiality of the
>> transmitted data.
>>
>> STS does this subject to the integrity of WebPKI certificate
>> issuance and potential downgrade on first-contact (and possibly
>> after previous cached policy has expired if email flow to the
>> nexthop domain is infrequent).  Given that DV certificates are
>> issued based on "domain control", the WebPKI can be at most as
>> secure as the DNS.
>>
>> DANE does this subject to the integrity of DNSSEC for the
>> domain and its ancestor domains up to the trust-anchor used
>> (typically the DNS root zone keys).  DANE does not have a
>> first-contact security gap.
>>
>> Neither DANE nor STS provide message origin authenticity,
>> these are hop-by-hop security mechanisms that authenticate
>> only the receiving system, not the sender.
>>
>> --
>>         Viktor.
>>
>>
>>
>> _______________________________________________
>> Uta mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/uta
>>
>> >Neither DANE nor STS provide message origin authenticity,
> >these are hop-by-hop security mechanisms that authenticate
> > only the receiving system, not the sender.
>

1.What will be the provision for the message origin authenticity ?

2.How are we going to authenticate the Sender ?

Can we use DMARC for this ?

Thanks

Regards
Ranjana

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 Jan 2018 12:31:21 -0500

> On Jan 3, 2018, at 12:05 AM, Ranjana Mukhia <[email-masked]> wrote:
> 
> 1.What will be the provision for the message origin authenticity?

Out of scope for UTA. TLS for SMTP is a hop-by-hop mechanism, while
message (sender and content) authenticity is an end-to-end problem.

> 2.How are we going to authenticate the Sender?

This is a difficult question.

Do you mean the author of the content, or the entity responsible
for sending the message, or the entity that elected to forward
the message to the recipient?  They are not always the same.

If your goal to protect users from "phishing", then no amount
of technology will prevent gullible humans from falling victim
to manipulation.  A well-crafted piece of social engineering does
not need to forge a particular sending address to be effective.

> Can we use DMARC for this?

Use of DANE or STS neither requires nor precludes the use of SPF,
DKIM, DMARC, ...   I personally don't publish, check or recommend
any of these.  My view on DKIM is largely neutral to mildly positive
when used as part of a reputation-based whitelisting system.  My view
on SPF is somewhat negative on technical grounds.  My view on DMARC is
that it is a terrible idea foisted on the Internet at large as a
cost-shifting exercise by the large free email providers.  If I could
waive a magic wand, nobody else would honour the (p=reject) DMARC
policies published by said providers or publish similar DMARC policies.

-- 
	Viktor.