On Wed, Jan 3, 2018 at 10:28 AM, Ranjana Mukhia <[email protected]>
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 protected]> wrote:
>
>> Send Uta mailing list submissions to
>>         [email protected]
>>
>> 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 protected]
>>
>> You can reach the person managing the list at
>>         [email protected]
>>
>> 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 protected]>
>> To: [email protected]
>> 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 protected]>
>> To: [email protected]
>> 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 protected]>
>> 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 protected]
>> 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
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta

Reply via email to