From nobody Wed Mar 1 03:44:03 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550D5129508 for ; Wed, 1 Mar 2017 03:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcvlmZSGNhyA for ; Wed, 1 Mar 2017 03:43:59 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B06F91294CA for ; Wed, 1 Mar 2017 03:43:59 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id d1so29181303ywd.2 for ; Wed, 01 Mar 2017 03:43:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VYRJ/XX4KRTcfBEILsGEhvdv6KA98T/qdhYx5nvWe2Y=; b=jLEr0Q4nzqpo0jgtydUd6udbBi4VOPRrKTHQ+RYhSAKGmalRefhckDzchEBYF8k5/P Lpkef+AsYQHZ+Kd9E/4dm/1WoDttKvc9uTclnKLxIUkNSzDVoIpWzyg1Az0L678q5NSm sNVrMC+ZG6dRJ1p8ji43XF8vfDwXULH9W8vGpuE8RcEgvGzf0wwUfBteP5qkw6Y1QLyg Oh7VaaORIKRCsnUtUUEYfiM7KA4JymoaB9bedc+SFA/r+wRrw4Tcytq73lFmPn3j7I2c ciyJUVSjD/tY9CDjnPy6cFku6G04HUN00eSGnjzdXbXC/deCjh8Bm3kctoBfTJ56Hi7p yQ8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VYRJ/XX4KRTcfBEILsGEhvdv6KA98T/qdhYx5nvWe2Y=; b=Z7CiFro7mxUiLfZ5oef7qHU62k3hpl5f77wARh1wBjXCqOYq8cSyhHErLY7huWDqYA s70Eo8c8hdAjftaE/5ZNYQcXPtEF4yWQdaiXe/fO3WrMhYUNOhhQmSW05L5tbVKtK6WT OQ3Bj85xfaKPCOnPkYkxlsZSOY2w5qWv50DuknG3pmvyyaamiQUohzvlTAHGocI/cuUr Ob6M0d/3h3oM5Mqj9ajGj/AkRpuJXwAoh5CzLDnwhsrjcHCjfUlglmFrRaMsSRQCQuCS 6lb2xFhfRMp18tBd2nxdU1mVD2g3Jn8ZAc+eMUuIe5xz1wRkKLolceUzfovA0jGcDcWp QUNw== X-Gm-Message-State: AMke39lWX30a/89OcT+vZzWGjFNNxrBEk8wGyJOBDOeLDNqJ4Fw1YDw4d3WbWbzCJuLRkZ5Q4zpsBaBdpTa1/bU9 X-Received: by 10.37.76.7 with SMTP id z7mr1598657yba.14.1488368638294; Wed, 01 Mar 2017 03:43:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.24.6 with HTTP; Wed, 1 Mar 2017 03:43:57 -0800 (PST) In-Reply-To: <20170228211322.GV28122@blitiri.com.ar> References: <20170228211322.GV28122@blitiri.com.ar> From: Daniel Margolis Date: Wed, 1 Mar 2017 12:43:57 +0100 Message-ID: To: Alberto Bertogli Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113e969c0671130549a9d4d1" Archived-At: Cc: "uta@ietf.org" , "Brotman, Alexander" Subject: Re: [Uta] Updated drafts for MTA-STS & TLSRPT X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 11:44:01 -0000 --001a113e969c0671130549a9d4d1 Content-Type: multipart/alternative; boundary=001a113e969cfb8a6a0549a9d344 --001a113e969cfb8a6a0549a9d344 Content-Type: text/plain; charset=UTF-8 Ugh, you're right. Seems like I screwed up the merge or something. I can't remember what I was doing. Anyway, since we have to submit another draft for the whole CNAME issue I guess no harm done. :-/ If only we had some sort of code review process to review code. What an idea. Thanks for the close look. ;) dan On Tue, Feb 28, 2017 at 10:13 PM, Alberto Bertogli wrote: > On Wed, Feb 15, 2017 at 07:57:48PM +0000, Brotman, Alexander wrote: > > Folks, > > > > We uploaded new revisions for MTA-STS and TLSRPT. There are minor > changes to each: > > > > 1) Remove the "_" from DNS records to be consistent with A/AAAA > > records used with the HTTPS retrieval, and make this a bit less > > confusing for deployments. We did this for both MTA-STS and > > TLSRPT. > > Thanks a lot for this! > > Even though unfortunately it will be reverted/changed due to the CNAME > incompatibility mentioned in the thread, FWIW I still appreciate it. > > > > 2) Clarify language around punycode > > I don't see any punicode related changes in the diffs. Are you sure they > went in? > > In both MTA-STS and TLSRPT all I can find are removals of the "_". I'm > looking at the links included in the emails: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-smtp-tlsrpt-03 > https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-mta-sts-03 > > What I assume is the/a corresponding issue in github is still open: > https://github.com/mrisher/smtp-sts/issues/127. There was a commit > adding some wording [1] which was removed the same day [2], maybe that > caused some confusion? > > Thanks! > Alberto > > > [1]: https://github.com/mrisher/smtp-sts/commit/ > 4b5bed7b9faf0b23c701367b9e147e559e16b373 > [2]: https://github.com/mrisher/smtp-sts/commit/ > dc8abacbb728863739bd24ffd44d5ce595f1e6b4 > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a113e969cfb8a6a0549a9d344 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ugh, you're right. Seems like I screwed up the merge o= r something. I can't remember what I was doing.=C2=A0

Anyway, since we have to submit another draft for the whole CNAME issue I= guess no harm done. :-/=C2=A0

If only we had some= sort of code review process to review code. What an idea.=C2=A0
=
Thanks for the close look. ;)

dan

On Tue,= Feb 28, 2017 at 10:13 PM, Alberto Bertogli <albertito@blitiri.co= m.ar> wrote:
On Wed, Feb 15, 2017 at 07:57:48PM +0000, Brotman, Alexander wrote:
> Folks,
>
> We uploaded new revisions for MTA-STS and TLSRPT.=C2=A0 There are mino= r changes to each:
>
> 1) Remove the "_" from DNS records to be consistent with A/A= AAA
>=C2=A0 =C2=A0 records used with the HTTPS retrieval, and make this a bi= t less
>=C2=A0 =C2=A0 confusing for deployments.=C2=A0 We did this for both MTA= -STS and
>=C2=A0 =C2=A0 TLSRPT.

Thanks a lot for this!

Even though unfortunately it will be reverted/changed due to the CNAME
incompatibility mentioned in the thread, FWIW I still appreciate it.


> 2) Clarify language around punycode

I don't see any punicode related changes in the diffs. Are you s= ure they
went in?

In both MTA-STS and TLSRPT all I can find are removals of the "_"= . I'm
looking at the links included in the emails:

https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-uta-smtp-tlsrpt-03
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-uta-mta-sts-03

What I assume is the/a corresponding issue in github is still open:
https://github.com/mrisher/smtp-sts/issues/127. There was a commit
adding some wording [1] which was removed the same day [2], maybe that
caused some confusion?

Thanks!
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alberto


[1]: https://gith= ub.com/mrisher/smtp-sts/commit/4b5bed7b9faf0b23c701367b9e147e559e16b373
[2]: https://gith= ub.com/mrisher/smtp-sts/commit/dc8abacbb728863739bd24ffd44d5ce595f1e6b4

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

--001a113e969cfb8a6a0549a9d344-- --001a113e969c0671130549a9d4d1 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+ q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0 TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg 5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27 8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDQ56r4ejTpd92h Ys9L5ebiYzLCLthvbSecExUbNwlHVzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAzMDExMTQzNTlaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAOqjUXT7l1atg2P1JB53D53hHQ8hsLrpl 6+m8aghayuVoPbBlFvjopKUo/tXJZaRlcUg963MhBtpsuY8jiWYXEv2D5GIgaCxKChlIE1jXsSUO Y9lxfV29m+OdABSXU8tYacKX3nUM/DVR3f1lQfGgQCS/uDOpuTVQDT/xL8RhROWB1G7y2BOtbMve dduF69LJS/BPEMyFpwIDIsMT8ebopjxIfyRjZ0DsUhZ1D1awDWfQs34FjwEMRfQTSL8MXQvLFX5d dnaurhmB652d2lv1m1Qy/pFc9+VmyLKZQfHnYkAgkoN7Pz1f+88oCQlj89ZYvN8RnXBogDErI+Lp z1IHug== --001a113e969c0671130549a9d4d1-- From nobody Wed Mar 1 03:47:47 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA08A129998 for ; Wed, 1 Mar 2017 03:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Og_1ueh7rPbD for ; Wed, 1 Mar 2017 03:47:45 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09C58129508 for ; Wed, 1 Mar 2017 03:47:45 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id s15so6492954ywg.0 for ; Wed, 01 Mar 2017 03:47:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FRa6fN9uc8baLf77zit4f43gfWdkbcA6PoRQKxLuhGo=; b=CpxK6ubYjYeRwHNLLEHjdZYp5HRWHQUNeUbXcK0bwgDDeVzz53anjctMXV0Tipr7ph V3gT3eisxO1jiGsIqoPgSC8mtcw1tWvThvaAx9vnZYAzsCoy1Wom6cHnDkmk114wepmS GfISy7m+USaQpJu7zi7CBybTuOlKH2ncq+/MAHzwBCZ70KPIeWozebdSa7ZZv3Io1OzI I6+ZiaUhYR1FZT/EVNLqNM2UT6sPTWwsQW/PThRb0xHcfV4Ce/+xwWZHOpOOUO2J1SmX 1kw5t4nyyqn9pGhrg/qf5LbXEWc21Adxd4iYxsPu+WhFp63sL8+Itsu8gf4ip6XlwXIk X13A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FRa6fN9uc8baLf77zit4f43gfWdkbcA6PoRQKxLuhGo=; b=JZkwPRVfOUOdeMP1k/sloGgESJnQtnoSBb17i/F1ael9+pnjcmrO+NEAQS6p99blp1 al3kgXPAes7KvuF1EdnHE09U0Dx/D9UvVAmytnPja7RCf5EIMg7nw9HTx7IvBa2XnQGa 15kBgYYoy10TqXBNOXvgav1m48+c8XQzLVCz3d7FhawHYcYaCLlao5cMbJWkTTphjkwB dshnEfTllCfATrq7djnH6DYZzUavFUvuBWjCd+e3CFSbpRW1Yv3j5QnW6NvrRduZ7Ebx 6GZjEaoARTmK1i7B3QgfPy8iM7ooaETgRKvGY51xT9tEk3rYHVDHwkzSD0VALNlqidA2 7F8A== X-Gm-Message-State: AMke39lpOZ64M1Wj35BqDc1Uz0hGHemHb8L6PHBKzYygWH+quIlem3BkFoOLfV1VvTTzBQaqtabNDbLkHmOrXXPt X-Received: by 10.129.135.69 with SMTP id x66mr3232747ywf.279.1488368863870; Wed, 01 Mar 2017 03:47:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.24.6 with HTTP; Wed, 1 Mar 2017 03:47:43 -0800 (PST) In-Reply-To: <20170301045522.1001.qmail@ary.lan> References: <813df83a-841e-4e6a-e3a1-f2852b20ddbc@bluepopcorn.net> <20170301045522.1001.qmail@ary.lan> From: Daniel Margolis Date: Wed, 1 Mar 2017 12:47:43 +0100 Message-ID: To: John Levine Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114f03127619760549a9e15c" Archived-At: Cc: uta@ietf.org, Jim Fenton Subject: Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 11:47:46 -0000 --001a114f03127619760549a9e15c Content-Type: multipart/alternative; boundary=001a114f03126d69780549a9e109 --001a114f03126d69780549a9e109 Content-Type: text/plain; charset=UTF-8 Sounds like we go back to underscore-prefixed. Thanks for the feedback John. On Wed, Mar 1, 2017 at 5:55 AM, John Levine wrote: > In article <813df83a-841e-4e6a-e3a1-f2852b20ddbc@bluepopcorn.net> you > write: > >3.1. MTA-STS TXT records > > > >There is no IANA registry for reserved hostnames, which is why protocols > >like SPF store their policies at the domain itself. > > Urrgh. SPF is as far as I know the only protocol published by the > IETF that stores policies at the unprefixed hostname, and that is > widely agreed to be a mistake. DKIM and DMARC use prefixes. > > There's the somewhat separate issue that if the prefixed name has to > be a hostname so it can be used in a URI, it can't contain an > underscore. > > R's, > John > > PS: Dave Crocker and I have been working on a prefix registry, but > it's a thankless task. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a114f03126d69780549a9e109 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sounds like we go back to underscore-prefixed. Thanks for = the feedback John.=C2=A0

On Wed, Mar 1, 2017 at 5:55 AM, John Levine = <johnl@taugh.com> wrote:
In a= rticle <813df83a-841e-4e6a-e3a1-f2852b20ddbc@bluepopcorn.net> y= ou write:
>3.1. MTA-STS TXT records
>
>There is no IANA registry for reserved hostnames, which is why protocol= s
>like SPF store their policies at the domain itself.

Urrgh.=C2=A0 SPF is as far as I know the only protocol published by = the
IETF that stores policies at the unprefixed hostname, and that is
widely agreed to be a mistake.=C2=A0 DKIM and DMARC use prefixes.

There's the somewhat separate issue that if the prefixed name has to be a hostname so it can be used in a URI, it can't contain an
underscore.

R's,
John

PS: Dave Crocker and I have been working on a prefix registry, but
it's a thankless task.

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

--001a114f03126d69780549a9e109-- --001a114f03127619760549a9e15c Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+ q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0 TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg 5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27 8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCQndS5M0oryebj Trp1KJiChryxSwuCrnzPpa6DNJoYZzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAzMDExMTQ3NDRaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAOV6xw0bknPOG8xbqCx55GdL/zyonl+99 d9xv73mVt+pbUQMDjB4FKkqzNHXyKEqZBt+QDJir6NChLJwU5l84jOyh+GNA/UOhKR8YkQt9r0od Yn9C6mf890FH+UqXSoR+IDclug2gFS0x0lHscYBoVciIf9aKT+zL6iU/QC9ZbL24ILA1D4kQoRAv zo2TGBIFoEU6wrF49eiBdIhjIrBoDV5AfZiaYhfN8XKfHwO6XJDK51L5BHxM5Tl/UFcwJXA4pNbs 1KiDDE4WL8pLYESYCA+5osirPPBwipNllPuu9eP32ayOOvj8jfS1U3hck7OyOMCldZaVxYH95AIl OdO69Q== --001a114f03127619760549a9e15c-- From nobody Wed Mar 1 12:03:34 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69E6129694 for ; Wed, 1 Mar 2017 12:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPCxpagn3uqT for ; Wed, 1 Mar 2017 12:03:31 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857E7129692 for ; Wed, 1 Mar 2017 12:03:31 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QBGIVX8DNK0058YY@mauve.mrochek.com> for uta@ietf.org; Wed, 1 Mar 2017 11:58:26 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QBGIU2IF6O0003XB@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for uta@ietf.org; Wed, 01 Mar 2017 11:58:23 -0800 (PST) From: ned+uta@mrochek.com Message-id: <01QBGIVV9BM80003XB@mauve.mrochek.com> Date: Wed, 01 Mar 2017 11:57:47 -0800 (PST) In-reply-to: "Your message dated Wed, 01 Mar 2017 12:47:43 +0100" References: <813df83a-841e-4e6a-e3a1-f2852b20ddbc@bluepopcorn.net> <20170301045522.1001.qmail@ary.lan> To: Daniel Margolis Archived-At: Cc: uta@ietf.org, Jim Fenton , John Levine Subject: Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 20:03:33 -0000 Please post a revised draft with these changes sooner rather than later. Thanks. Ned > Sounds like we go back to underscore-prefixed. Thanks for the feedback > John. > On Wed, Mar 1, 2017 at 5:55 AM, John Levine wrote: > > In article <813df83a-841e-4e6a-e3a1-f2852b20ddbc@bluepopcorn.net> you > > write: > > >3.1. MTA-STS TXT records > > > > > >There is no IANA registry for reserved hostnames, which is why protocols > > >like SPF store their policies at the domain itself. > > > > Urrgh. SPF is as far as I know the only protocol published by the > > IETF that stores policies at the unprefixed hostname, and that is > > widely agreed to be a mistake. DKIM and DMARC use prefixes. > > > > There's the somewhat separate issue that if the prefixed name has to > > be a hostname so it can be used in a URI, it can't contain an > > underscore. > > > > R's, > > John > > > > PS: Dave Crocker and I have been working on a prefix registry, but > > it's a thankless task. > > > > _______________________________________________ > > Uta mailing list > > Uta@ietf.org > > https://www.ietf.org/mailman/listinfo/uta > > From nobody Fri Mar 3 16:01:34 2017 Return-Path: X-Original-To: uta@ietf.org Delivered-To: uta@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 664A5129A43; Fri, 3 Mar 2017 15:55:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858533541.15846.4178538587610872413.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:35 -0800 Archived-At: Cc: uta@ietf.org, aamelnikov@fastmail.fm Subject: [Uta] uta - Requested session has been scheduled for IETF 98 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:35 -0000 Dear Leif Johansson, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. uta Session 1 (1:00:00) Tuesday, Afternoon Session II 1450-1620 Room Name: Zurich G size: 115 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Using TLS in Applications Area Name: Applications and Real-Time Area Session Requester: Leif Johansson Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: tokbind tls Second Priority: oauth secevent People who must be present: Keith Moore Chris Newman Orit Levin Alexey Melnikov Leif Johansson Jim Fenton Resources Requested: Meetecho support in room Special Requests: please avoid mail or security related BoFs if possible --------------------------------------------------------- From nobody Fri Mar 3 16:37:31 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770201294BA for ; Fri, 3 Mar 2017 16:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHKgMIhZsyf6 for ; Fri, 3 Mar 2017 16:37:28 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE6E127601 for ; Fri, 3 Mar 2017 16:37:28 -0800 (PST) Received: from [10.27.14.3] (mobile-166-171-184-226.mycingular.net [166.171.184.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 5C0A37A32D8 for ; Sat, 4 Mar 2017 00:37:20 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Viktor Dukhovni In-Reply-To: <3f9308ab-d01d-71e9-be14-b9894601a416@bluepopcorn.net> Date: Fri, 3 Mar 2017 19:36:58 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <148705066595.22281.9383659754042012758.idtracker@ietfa.amsl.com> <3f9308ab-d01d-71e9-be14-b9894601a416@bluepopcorn.net> To: uta@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Uta] New Version Notification for draft-fenton-smtp-require-tls-03.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: uta@ietf.org List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 00:37:30 -0000 > On Feb 14, 2017, at 12:51 AM, Jim Fenton wrote: > > A new version of I-D, draft-fenton-smtp-require-tls-03.txt > has been successfully submitted by Jim Fenton and posted to the > IETF repository. Review comments: === Abstract: The text starts: The SMTP STARTTLS option, used in negotiating transport-level encryption of SMTP connections, is not as useful from a security standpoint as it might be because of its opportunistic nature; message delivery is prioritized over security. ... I do not think it is appropriate to say "not as useful as it might be". Unauthenticated opportunistic STARTTLS is *very* useful and effective in reducing opportunities for passive attacks. Indeed with ~84% of email protected via TLS: https://www.google.com/transparencyreport/saferemail/ opportunistic STARTTLS is more successful than HTTPS, which recent reports indicate protects ~50% of web site visits. Now of course it is fair and accurate to say that unauthenticated opportunistic SMTP STARTTLS alone offers only passive attack protection and that mechanisms such as RFC7672 DANE or the proposed STS are hop-by-hop MTA-to-MTA security protocols, which seek to strengthen "the network", but give no control to the user. So I see this draft as filling that gap. Therefore, I think it would be best to start with something that goes right to the point. A start in that direction might be: No existing IETF protocol gives an email user the means to express SMTP transport security policy beyond the user's initial interaction with the message submission agent (MSA). Any further SMTP relaying of the message from the MSA, often via multiple relay hops, to its final destination is subject only to the policy of the intermediate email relays. This specification provides a mechanism for a user to express an SMTP transport security preference, either to prioritize security, or, conversely, to prioritize delivery even when transport security is not available or appears to be compromised. The above likely has its own flaws, so feel free to borrow from it or ignore it as you see fit, but perhaps it serves to clarify the approach I'm suggesting. === 1. Introduction By default, TLS is used only upon mutual agreement (successful negotiation) of STARTTLS between the client and server; if this is not possible, the message is sent without transport encryption. Furthermore, it is common practice for the client to negotiate TLS even if the SMTP server's certificate fails to authenticate it. Here, I think the point is not that the client "negotiates TLS" even when authentication fails, but rather that *delivery* continues despite lack of authentication (a reference to RFC7435 may be appropriate here). It would certainly not be better (as sadly done by some MTAs) to abort the TLS handshake and deliver in the clear! So the last sentence should be rewritten. The second paragraph: Policy mechanisms such as DANE [RFC7672] and SMTP STS [I-D.ietf-uta-mta-sts] may impose requirements for the use of TLS for email destined for some domains. However, such policies do not allow the sender to specify which messages are more sensitive and require transport-level encryption, and which ones are urgent and ought to be relayed even if TLS cannot be negotiated successfully. is much closer to the spirit of what I'm suggesting for the abstract, so it could be another basis for a new abstract, or text that connects the abstract to the introduction. The third paragraph reads: The default opportunistic nature of SMTP TLS enables several "on the wire" attacks on SMTP security between MTAs. These include passive eavesdropping on connections for which TLS is not used, interference in the SMTP protocol to prevent TLS from being negotiated (presumably followed by eavesdropping), and insertion of a man-in-the-middle attacker taking advantage of the lack of server authentication by the client. Attacks are more described in more detail in the Security Considerations section of this document. Here you're conflating opportunistic (RFC7435), with "unauthenticated" use-cases that are not downgrade-resistant. Keep in mind that DANE is still "opportunistic TLS", because authenticated delivery takes place only when the peer publishes TLSA records, and TLS is otherwise best effort. So DANE for SMTP is a downgrade-resistant, authenticated, but still opportunistic mechanism, and the same holds for the proposed STS. Downgrade attacks are considerably more difficult with DANE, and to a lesser degree with STS (which is weak on first contact, but provides similar defenses thereafter). === 2. The REQUIRETLS Service Extension What is optional per the paragraph: An optional parameter to the REQUIRETLS MAIL FROM option specifies the requirements for server authentication that MUST be used for any onward transmission of the following message. The parameter takes the form of either a single value or comma-separated list, separated from the REQUIRETLS option by a single "=" (equals-sign) character. If present, the parameter MUST take one or more of the following values: is optional to add "REQUIRETLS=..." to "MAIL FROM" or it optional to add "=..." with "REQUIRETLS"? The first sentence suggests the latter, but I don't think that makes sense. What follows immediately below that paragraph is IMNSHO an overly prescriptive disaster: o CHAIN - The certificate presented by the SMTP server MUST verify successfully in a trust chain leading to a certificate trusted by the SMTP client. The choice of trusted (root) certificates by the client is at their own discretion. The client MAY choose to use the certificate set maintained by the CA/B forum [citation needed] for this purpose. o DANE - The certificate presented by the SMTP server MUST verify succesfully using DANE as specified in RFC 7672 [RFC7672]. o DNSSEC - The server MUST confirm that any MX record or CNAME lookup used to locate the SMTP server must be DNSSEC [RFC4035] signed and valid. o NO - The SMTP client SHOULD attempt to send the message regardless of its ability to negotiate STARTTLS with the SMTP server, ignoring policy-based mechanisms, if any, asserted by the recipient domain. Nevertheless, the client MAY negotiate STARTTLS with the server if available. If the NO parameter is present, any other REQUIRETLS parameter MUST NOT be used. Setting aside the "NO" case, the remaining options are MUCH too precise. The client should at most be able to specify: * ENCRYPT: must negotiate STARTTLS, but perhaps not authenticated * SECURE: must negotiate STARTTLS *and* authenticate the peer via DANE, STS or local policy that provides active-attack resistance for the nexthop destination. I don't see anyone using "CHAIN", "DANE", "DNSSEC" or being able to explain these to users. I'll stop here for now, because the rest of the document is moot if this issue cannot be resolved. -- Viktor. From nobody Fri Mar 3 19:42:17 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E9B1293FD for ; Fri, 3 Mar 2017 19:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66rR-X2uwT68 for ; Fri, 3 Mar 2017 19:42:14 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217A8127076 for ; Fri, 3 Mar 2017 19:42:13 -0800 (PST) Received: from [10.27.14.3] (33.sub-70-214-112.myvzw.com [70.214.112.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 9EDCC7A32D8 for ; Sat, 4 Mar 2017 03:42:12 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) From: Viktor Dukhovni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Fri, 3 Mar 2017 22:42:10 -0500 To: uta@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [Uta] TLSRPT review X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: uta@ietf.org List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 03:42:16 -0000 First: Since this draft is about SMTP security, references to DANE should be to RFC7672 not RFC6698. === 1. Introduction In the paragraph: The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and hosts to establish secure SMTP sessions over TLS. The protocol design is based on "Opportunistic Security" (OS) [RFC7435], which provides interoperability for clients that do not support STARTTLS s/provides/maintains/ s/for/with/ but (absent downgrade-destination destination security policy, such as DANE or, after initial contact, STS) means that any attacker who can delete parts of the SMTP session (such as the "250 STARTTLS" response) or redirect the entire SMTP session (perhaps by overwriting the resolved MX record of the delivery domain) can perform a downgrade or interception attack. Would s/parts/stages/ be better in the below? Because such "downgrade attacks" are not necessarily apparent to the receiving MTA, this document defines a mechanism for sending domains to report on failures at multiple parts of the MTA-to-MTA conversation. === 1.1 Terminology: In: o DANE Policy: A mechanism for enabling the administrators of domain names to specify the keys used in that domain's TLS servers. DANE is defined in [RFC6698] I think 'administrators of domain names' is poor wording. DANE policy is specified by MTA operators, and published by the administrators of the DNS zones in which the MTA hosts are found. When the MX hosts of a domain are operated by a third party, the DANE policy is published by the MX host operator, all the domain owner has to do is use DNSSEC to publish their MX records. === 3. Reporting Policy In the below: * In the case of "mailto", reports should be submitted to the specified email address. When sending failure reports via SMTP, sending MTAs MUST NOT honor SMTP STS or DANE TLSA failures. perhaps instead of "must not honor ... failures" it should be "must deliver the report despite any ... failures". I think this means that even if there are multiple MX hosts, and a failure is encountered with the first one, delivery proceeds even though it may be possible to do more secure delivery via one of the remaining MX hosts. Also if the TLS handshake fails (TLS interop issue), I would say that delivery should then be retried in the clear (though perhaps as part of a retry, after the report is initially deferred). The idea is that reports should get through even when STARTTLS is fails to establish a handshake, not just completes with authentication errors. In: o "ruf": Future use. (There may also be a need for enabling more detailed "forensic" reporting during initial stages of a deployment. To address this, the authors consider the possibility of an optional additional "forensic reporting mode" in which more details--such as certificate chains and MTA banners--may be reported.) I don't see the point of talking about "ruf", given that no specification is proposed. This should be deleted. === Section 4: In: * One of the following policy types: (1) The SMTP MTA STS policy applied (as a string) (2) The DANE TLSA record applied (as a string) (3) The literal string "no-policy-found", if neither a TLSA nor MTA-STS policy could be found. "The DANE TLSA record" is in fact an RRset, and a single string encoding would be suboptimal, or at least needs a more precise specification. Do you want the presentation form of the RRs separated by CRLF? Do you want these with "owner ttl class type rrdata" or just the rrdata? ... Some of the DANE TLSA RRs might be "usable" and others "not usable", which is which depends on the client. Similarly, digest agility means that the client might be ignoring some of the RRs. What makes sense to me is to report either a non-empty set of usable unignored RRs, or if all are unusable, the full set of RRs and an indication that they are all unusable (in which case per RFC7672 the MTA would enforce the use of TLS, but without authentication). === 4.1. Report Time-frame Given the text: The report SHOULD cover a full day, from 0000-2400 UTC. This should allow for easier correlation of failure events. I'm inclined to conclude that TLSRPT is not an especially timely notification mechanism. Since on average problem reports will be 12 hours or so late. Is there some provision for more timely notification, or will that need to be done in-band (separate spec TBD)? === 4.3.1. Routing Failures Recent discussion of the STS draft suggests that the "mx" field in STS really should become a "san" field instead, with MX choice unaffected by the STS policy. Fraudulent MX hosts will not be able (we hope) to present certificates whose SANs match the STS policy. If so: o "mx-mismatch": This indicates that the MX resolved for the recipient domain did not match the MX constraint specified in the policy. This error condition goes away, and is subsumed by failure to match the certificate against any of the policy SAN values. This is much cleaner, but, full disclosure, this requires more sophistication in the TLS peer-verification code to support such matching (rather than just match the literal MX host). Postfix can already do this, but for other MTAs this would be new code. If they're using OpenSSL, then the library has the requisite hooks as of OpenSSL 1.0.2 to match either a literal name or a sub-domain of a parent domain from a set of such names or parent domains. https://www.openssl.org/docs/man1.0.2/crypto/X509_check_host.html other toolkits might not yet support an equivalent feature. === 4.3.2. Negotiation Failures o "certificate-host-mismatch": This indicates that the certificate presented did not adhere to the constraints specified in the STS or DANE policy, e.g. if the CN field did not match the hostname of the MX. The "CN field" is long obsolete. It would be great if STS required compliant certificates to have a DNS SAN (rather than support legacy CN per 6125). The STS spec is new, and really should raise the bar here. I don't know of any CAs that omit DNS subject altnames these days. In any case the above text should talk about SANs primarily and the CN only as an afterthought. In the below: o "certificate-not-trusted": This a label that covers multiple certificate related failures that include, but not limited to errors such as untrusted/unknown CAs, certificate name contraints, certificate chain errors etc. When using this declaration, the reporting MTA SHOULD utilize the "failure-reason" to provide more information to the receiving entity. "contraints" is a typo. === 4.3.3.1. DANE-specific Policy Failures Keep in that the TLSA records are plural (an RRset) and that invalid records are "unusable", and ignored so long as some usable records are found. So it is not clear what this is for, except perhaps to signal that all the records are unusable. o "tlsa-invalid": This indicates a validation error in the TLSA record associated with a DANE policy. As for dnssec-invalid, that's simply a DNS lookup error, which can lead to skipping the MX host or deferral of mail. So the condition is much too specific. The typical MTA will never see invalid DNSSEC replies, the resolver will just report SERVFAIL in response to "_25._tcp.smtp.example.com. IN TLSA ?" o "dnssec-invalid": This indicates a failure to authenticate DNS records for a Policy Domain with a published TLSA record. === 5.3 Email Transport Note that, when sending failure reports via SMTP, sending MTAs MUST NOT honor SMTP STS or DANE TLSA failures. See above re "not honor", ... -- Viktor. From nobody Tue Mar 7 13:55:24 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2FB1294E1 for ; Tue, 7 Mar 2017 13:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiNYHCBTrmJp for ; Tue, 7 Mar 2017 13:55:21 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1480C1204D9 for ; Tue, 7 Mar 2017 13:55:20 -0800 (PST) Received: from splunge.local (c-24-4-98-3.hsd1.ca.comcast.net [24.4.98.3]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v27LtHKu015708 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 7 Mar 2017 13:55:19 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1488923719; bh=qej4fseEuHNzc7v+RGCleu/Phk9/2lF+KpwKCf3ezZ4=; h=Subject:To:References:From:Date:In-Reply-To; b=CMTAylKy4IGshj9tYH8RcmT6wnKVUY7nr41Gk/6a0yjLcIjA4e4fPRfm9yHI+qGie JldLsehoBFY10pF5HeTdYseIR9fEkG700znLhFso5nAWHwVoMLgwv0tdvd1VhzKPg9 Nk1TB3lZhdw1hQBWdN6vot4FbxA102jGsV9WLO9Q= To: uta@ietf.org References: <148705066595.22281.9383659754042012758.idtracker@ietfa.amsl.com> <3f9308ab-d01d-71e9-be14-b9894601a416@bluepopcorn.net> From: Jim Fenton Message-ID: Date: Tue, 7 Mar 2017 13:55:11 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Uta] New Version Notification for draft-fenton-smtp-require-tls-03.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 21:55:23 -0000 Responses inline. On 3/3/17 4:36 PM, Viktor Dukhovni wrote: >> On Feb 14, 2017, at 12:51 AM, Jim Fenton wrot= e: >> >> A new version of I-D, draft-fenton-smtp-require-tls-03.txt >> has been successfully submitted by Jim Fenton and posted to the >> IETF repository. > Review comments: > > =3D=3D=3D Abstract: > > The text starts: > > The SMTP STARTTLS option, used in negotiating transport-level > encryption of SMTP connections, is not as useful from a security > standpoint as it might be because of its opportunistic nature; > message delivery is prioritized over security. ... > > I do not think it is appropriate to say "not as useful as it might > be". Unauthenticated opportunistic STARTTLS is *very* useful and > effective in reducing opportunities for passive attacks. Indeed > with ~84% of email protected via TLS: > > https://www.google.com/transparencyreport/saferemail/ > > opportunistic STARTTLS is more successful than HTTPS, which > recent reports indicate protects ~50% of web site visits. I did not say that opportunistic STARTTLS is not useful. I said that STARTTLS would be more useful if it wasn't only opportunistic. It's important to start the document with a clear statement of the problem it is solving, and this is the clear statement. > > Now of course it is fair and accurate to say that unauthenticated > opportunistic SMTP STARTTLS alone offers only passive attack > protection and that mechanisms such as RFC7672 DANE or the > proposed STS are hop-by-hop MTA-to-MTA security protocols, > which seek to strengthen "the network", but give no control > to the user. So I see this draft as filling that gap. > > Therefore, I think it would be best to start with something that > goes right to the point. A start in that direction might be: > > No existing IETF protocol gives an email user the means to > express SMTP transport security policy beyond the user's > initial interaction with the message submission agent (MSA). > Any further SMTP relaying of the message from the MSA, often > via multiple relay hops, to its final destination is > subject only to the policy of the intermediate email relays. > This specification provides a mechanism for a user to express > an SMTP transport security preference, either to prioritize > security, or, conversely, to prioritize delivery even > when transport security is not available or appears to > be compromised. > > The above likely has its own flaws, so feel free to borrow from > it or ignore it as you see fit, but perhaps it serves to clarify > the approach I'm suggesting. I'll look at this, but remember that this is just the abstract. It's intentionally short. I'd be considerably more open to providing more detail in the body of the document. > > =3D=3D=3D 1. Introduction > > By default, TLS is used only upon mutual agreement > (successful negotiation) of STARTTLS between the client and server; > if this is not possible, the message is sent without transport > encryption. Furthermore, it is common practice for the client to > negotiate TLS even if the SMTP server's certificate fails to > authenticate it. > > Here, I think the point is not that the client "negotiates TLS" even > when authentication fails, but rather that *delivery* continues despite= > lack of authentication (a reference to RFC7435 may be appropriate here)= =2E > It would certainly not be better (as sadly done by some MTAs) to abort > the TLS handshake and deliver in the clear! So the last sentence shoul= d > be rewritten. Good point. > > The second paragraph: > > Policy mechanisms such as DANE [RFC7672] and SMTP STS > [I-D.ietf-uta-mta-sts] may impose requirements for the use of TLS fo= r > email destined for some domains. However, such policies do not allo= w > the sender to specify which messages are more sensitive and require > transport-level encryption, and which ones are urgent and ought to b= e > relayed even if TLS cannot be negotiated successfully. > > is much closer to the spirit of what I'm suggesting for the abstract, s= o > it could be another basis for a new abstract, or text that connects the= > abstract to the introduction. OK; I'm not sure I re-looked at the abstract when adding "MAYTLS". > > The third paragraph reads: > > The default opportunistic nature of SMTP TLS enables several "on the= > wire" attacks on SMTP security between MTAs. These include passive > eavesdropping on connections for which TLS is not used, interference= > in the SMTP protocol to prevent TLS from being negotiated (presumabl= y > followed by eavesdropping), and insertion of a man-in-the-middle > attacker taking advantage of the lack of server authentication by th= e > client. Attacks are more described in more detail in the Security > Considerations section of this document. > > Here you're conflating opportunistic (RFC7435), with "unauthenticated" > use-cases that are not downgrade-resistant. Keep in mind that DANE > is still "opportunistic TLS", because authenticated delivery takes > place only when the peer publishes TLSA records, and TLS is otherwise > best effort. So DANE for SMTP is a downgrade-resistant, authenticated,= > but still opportunistic mechanism, and the same holds for the proposed > STS. Downgrade attacks are considerably more difficult with DANE, and > to a lesser degree with STS (which is weak on first contact, but provid= es > similar defenses thereafter). DANE, STS, and other policy mechanisms are opportunistic because there is no assurance that the client will pay any attention to them. I have tended to associate downgrade resistance with the use of weaker (perhaps "export grade") encryption, and opportunistic with whether things will be sent in the clear if encryption can't be negotiated at all, but perhaps those aren't quite the right distinctions. > > =3D=3D=3D 2. The REQUIRETLS Service Extension > > What is optional per the paragraph: > > An optional parameter to the REQUIRETLS MAIL FROM option specifies > the requirements for server authentication that MUST be used for any= > onward transmission of the following message. The parameter takes > the form of either a single value or comma-separated list, separated= > from the REQUIRETLS option by a single "=3D" (equals-sign) character= =2E > If present, the parameter MUST take one or more of the following > values: > > is optional to add "REQUIRETLS=3D..." to "MAIL FROM" or it optional > to add "=3D..." with "REQUIRETLS"? The first sentence suggests the > latter, but I don't think that makes sense. The intent here is that the "=3D..." is optional. If the REQUIRETLS optio= n is specified without the optional parameter, there are no requirements on how the server certificate is to be validated. > > What follows immediately below that paragraph is IMNSHO an overly > prescriptive disaster: > > o CHAIN - The certificate presented by the SMTP server MUST verify > successfully in a trust chain leading to a certificate trusted by= > the SMTP client. The choice of trusted (root) certificates by th= e > client is at their own discretion. The client MAY choose to use > the certificate set maintained by the CA/B forum [citation needed= ] > for this purpose. > > o DANE - The certificate presented by the SMTP server MUST verify > succesfully using DANE as specified in RFC 7672 [RFC7672]. > > o DNSSEC - The server MUST confirm that any MX record or CNAME > lookup used to locate the SMTP server must be DNSSEC [RFC4035] > signed and valid. > > o NO - The SMTP client SHOULD attempt to send the message regardles= s > of its ability to negotiate STARTTLS with the SMTP server, > ignoring policy-based mechanisms, if any, asserted by the > recipient domain. Nevertheless, the client MAY negotiate STARTTL= S > with the server if available. If the NO parameter is present, an= y > other REQUIRETLS parameter MUST NOT be used. > > Setting aside the "NO" case, the remaining options are MUCH too precise= =2E > The client should at most be able to specify: > > * ENCRYPT: must negotiate STARTTLS, but perhaps not authenticated > * SECURE: must negotiate STARTTLS *and* authenticate the peer via > DANE, STS or local policy that provides active-attack= > resistance for the nexthop destination. > > I don't see anyone using "CHAIN", "DANE", "DNSSEC" or being able to > explain these to users. Let me start with DNSSEC, because that has the strongest case. In the absence of an authenticated MX record for the target domain, an MITM attacker could just spoof the MX record, substituting their own mail server (and of course authentication will succeed because the attacker chose the MX record target). This does not require much in the way of attacker capabilities in addition to those required to interfere with STARTTLS negotiation. REQUIRETLS should not just address attacks that currently exist, but also those that might be reasonably anticipated in response to its deployment (or perhaps STS deployment). I have been wondering whether the DNSSEC option should require the recipient domain to be DNSSEC signed as is currently specified, or if it should be sufficient for the accepting SMTP server to use a DNSSEC-verifying resolver to detect problems for those domains that are DNSSEC-signed. The latter is weaker, but more likely to actually find use= =2E Your ENCRYPT option is the default, in the absence of the optional "=3D" parameter. I have trouble calling anything SECURE! SECURE shouldn't cover the DNSSEC case, because authentication isn't meaningful if the MX record is wrong (as described above). With respect to CHAIN and DANE, perhaps those are too fine-grained, but unfortunately it has been difficult to get rough consensus with only a couple of us commenting on this. The real question is whether attackers that control a root CA are part of the threat model. Or perhaps we should just let DANE "speak for itself": if there are DANE records for the MX server, require them (and don't have a separate option). > > I'll stop here for now, because the rest of the document is moot if thi= s > issue cannot be resolved. > From nobody Mon Mar 13 14:21:13 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BEA129A59 for ; Mon, 13 Mar 2017 14:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hkXuL3N0JdR for ; Mon, 13 Mar 2017 14:21:10 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0107.outbound.protection.outlook.com [104.47.34.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EEB21297F1 for ; Mon, 13 Mar 2017 14:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nxAr4IX2GRGC77bg2gWpeXzBfZgcc5NZLBegNcMolXo=; b=FwMzhd5HJrtzbtt0XP/C34IO52vk1GDhEXn/3v5LvO0MMY0GrDx6moNJVAjlAU2i0g/GxbGUlpcATLtT37+siGoG+oJV7VtfDpY2KD33uNh9uMMQkUAzs/G4A2o9AQm9vDl0dyl9Zxk8pJRI2Bwy3BLwI73S+WnCwNPj4r71/+o= Received: from CY1PR0301MB2122.namprd03.prod.outlook.com (10.164.2.156) by CY1PR0301MB2121.namprd03.prod.outlook.com (10.164.2.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Mon, 13 Mar 2017 21:21:09 +0000 Received: from CY1PR0301MB2122.namprd03.prod.outlook.com ([10.164.2.156]) by CY1PR0301MB2122.namprd03.prod.outlook.com ([10.164.2.156]) with mapi id 15.01.0961.021; Mon, 13 Mar 2017 21:21:09 +0000 From: Orit Levin To: "uta@ietf.org" Thread-Topic: Agenda requests Thread-Index: AdKcPx8bI3jbqBWgQtaPGmoDuGpODg== Date: Mon, 13 Mar 2017 21:21:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [131.107.147.93] x-microsoft-exchange-diagnostics: 1; CY1PR0301MB2121; 7:cbt2bz53lZn1koON6yYVBNhj98hfNYS6/fa+WlpZCUqZHwMgmlLLCGocXcASA409DHuYIiV1K58zdE84Qwm4qULbYnRFjHYGyKdiZhIc/wau1Q4qooaXr52fUBX7XjmFAVFXpsGiY3+ak+x3G1xgVGsHHNHEwWQ58TkrcNgUaC5fNHa12EBxsxm3eEtq1EabGHs7CPw5GhA2F3sKiwoEeFp4YM/rEwRDsz4sINwzYy8jKN+xb28Z+mmvyQzfK4Fe5W6w4PDfZP3ltuA9aR9Dwov9JPErcJT6i3ksmk0oHd+b3KK8IazKccWdgl+RsgmCp0mzIcDOSWVVaLoZUldC6tGqZ/qdk+9ryGxCJTIco5c= x-ms-office365-filtering-correlation-id: 89c5311b-3731-44b7-a554-08d46a56de31 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB2121; x-o365eop-header: O365_EOP: Allow for Unauthenticated Relay x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(20161123558025)(6072148); SRVR:CY1PR0301MB2121; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB2121; x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39850400002)(39450400003)(39410400002)(39860400002)(53754006)(53936002)(6116002)(38730400002)(102836003)(4326008)(3660700001)(189998001)(5660300001)(3846002)(99286003)(66066001)(86612001)(55016002)(86362001)(3480700004)(3280700002)(2501003)(2351001)(221733001)(10290500002)(5005710100001)(7736002)(1730700003)(7696004)(25786008)(2906002)(5640700003)(110136004)(7116003)(6506006)(8676002)(305945005)(6436002)(8936002)(33656002)(6916009)(54906002)(81166006)(50986999)(74316002)(10090500001)(122556002)(77096006)(54356999)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB2121; H:CY1PR0301MB2122.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2017 21:21:09.2516 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB2121 Archived-At: Cc: Alexey Melnikov , "leifj@sunet.se" Subject: [Uta] Agenda requests X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:21:12 -0000 Hello all, Please, send your agenda requests "officially" by the end of day tomorrow: = what draft(s), length of presentation/discussion, and presenter(s) name(s). Thank you! The chairs. From nobody Mon Mar 13 15:50:03 2017 Return-Path: X-Original-To: uta@ietf.org Delivered-To: uta@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E72129BCF; Mon, 13 Mar 2017 15:49:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944539677.20433.7775400419388289046@ietfa.amsl.com> Date: Mon, 13 Mar 2017 15:49:56 -0700 Archived-At: Cc: uta@ietf.org Subject: [Uta] I-D Action: draft-ietf-uta-email-deep-06.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 22:49:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Using TLS in Applications of the IETF. Title : Mail User Agent Strict Transport Security (MUA-STS) Authors : Keith Moore Chris Newman Filename : draft-ietf-uta-email-deep-06.txt Pages : 42 Date : 2017-03-13 Abstract: This specification defines a set of requirements and facilities designed to improve email confidentiality between a mail user agent (MUA) and a mail submission or mail access server. This provides mechanisms intended to increase use of already deployed Transport Layer Security (TLS) technology and provides a model for a mail user agent's confidentiality assurance. This enables mail service providers to advertise strict transport security (STS) policies that request MUAs increase confidentiality assurance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-uta-email-deep/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-uta-email-deep-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-email-deep-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 21 22:04:53 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87F6129459 for ; Tue, 21 Mar 2017 22:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UONQBC3h8bGx for ; Tue, 21 Mar 2017 22:04:48 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93D412944E for ; Tue, 21 Mar 2017 22:04:47 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 978BB7A32F1 for ; Wed, 22 Mar 2017 05:04:46 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) From: Viktor Dukhovni Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <4C0807DA-4852-4DAC-80ED-8A25371CFFAA@dukhovni.org> Date: Wed, 22 Mar 2017 01:04:45 -0400 To: uta@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [Uta] MTA-STS-03 review X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 05:04:52 -0000 [ I've pasted in the entire draft, and "quoted" it as though it were a post to trim an reply to. ] > SMTP MTA Strict Transport Security (MTA-STS) > draft-ietf-uta-mta-sts-03 >=20 > Abstract >=20 > SMTP Mail Transfer Agent Strict Transport Security (SMTP STS) is a > mechanism enabling mail service providers to declare their ability = to > receive TLS-secured connections and an expected validity of > certificates presented by their MX hosts, and to specify whether > sending SMTP servers should refuse to deliver to MX hosts that do = not > offer TLS with a trusted server certificate. In the abstract I think that "TLS-secured" already covers certificate validity (which makes for a clumsy insertion into the text anyway). Also instead of "TLS-secured connections" say "TLS-secure SMTP = connections". See https://www.rfc-editor.org/materials/abbrev.expansion.txt for the list of common IETF acronyms, and which are sufficiently widely used to not need to be expanded on first use. Thus SMTP and ESMTP are fine with expansion, but apparently we've not yet reached similar familiarity with TLS. :-) > 1. Introduction >=20 > The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and > hosts to negotiate the use of a TLS channel for secure mail > transmission. I would drop "secure" above, or replace it with "encrypted". > While such _opportunistic_ encryption protocols provide a high While "_" may work as italics in MarkDown, you'll need to change all these to RFC XML (where IIRC ... may be supported, but don't take my word for it, check). More importantly, you've made quite a leap here from talking about RFC 3207, which merely defines an SMTP extension mechanism, to assuming that the reader knows how the extension is typically used. It also important to recall that opportunistic security (as defined in RFC7435) subsumes both MTA best-effort unauthenticated encryption, and the new opportunistically authenticated DANE and STS use-cases. With DANE and STS transmission is protected only when and as receiving system = publishes the requisite policy records. DANE offers stronger downgrade = protection, at the cost of requiring DNSSEC to achieve that goal. > barrier against passive man-in-the-middle traffic interception, therefore the "passive-only" protection is a feature of unauthenticated opportunistic security, as practiced by most MTAs at present. > This document defines a mechanism for recipient domains to publish > policies specifying: >=20 > o whether MTAs sending mail to this domain can expect TLS support >=20 > o expected validity of server certificates presented by the = domain's > MX hosts It seems to me that STS does not provide any means to signal unauthenticated TLS support. And so, as in the abstract, the above two bullets are really just one, "WebPKI TLS security". > 1.1. Terminology >=20 > We also define the following terms for further use in this = document: >=20 > o STS Policy: A committment by the Policy Domain to support PKIX > authenticated TLS for the specified MX hosts. Which I think confirms my point about "authenticated TLS" as the only available commitment. > o Policy Domain: The domain for which an STS Policy is defined. > (For example, when sending mail to "alice@example.com", the = policy > domain is "example.com".) Perhaps this should mention that more generally this is the nexthop domain for SMTP delivery, and when mail routing is pre=C3=ABmpted by by explicit relays via local policy, the Policy domain is the domain name of the explicit relay (prior to any MX lookups if applicable). > o Policy Authentication: Authentication of the STS policy = retrieved > for a recipient domain by the sender. This definition seems all too circular. What does it actually mean? > 2. Related Technologies >=20 > The DANE TLSA record [RFC7672] is similar, in that DANE is also > designed to upgrade opportunistic, unauthenticated encryption into > required, authenticated encryption. Opportunistic DANE TLS upgrades unauthenticated encryption or even cleartext delivery to downgrade-resistant authenticated TLS. (Side note, not for the draft, for actually non-opportunistic TLS see Jim Fenton's REQUIRETLS proposal). STS aims to do the same, but without requiring TLS at the cost of losing some downgrade protection. > DANE requires DNSSEC [RFC4033] > for authentication; the mechanism described here instead relies on > certificate authorities (CAs) and does not require DNSSEC. For a > thorough discussion of this trade-off, see the section _Security_ > _Considerations_. The Security Considerations section (once again this is not MarkDown) will need to properly discuss the downgrade exposure of STS on first contact, and this trade-off probably should be mentioned here up-front. > In addition, SMTP STS provides an optional report-only mode, = enabling > soft deployments to detect policy failures. It is easy to define a couple of new "certificate usage" code-points for DANE that similarly signal "soft-fail" (with reporting). Would the group strongly support a draft along those lines? I am not sure that a merely "tamper-evident" operating mode is a good idea as a persistent operating state, and I think that the ability to have one or more (backup, i.e. worse preference) MX hosts without TLSA records adequately addresses the need for incremental deployment. > 3. Policy Discovery >=20 > To discover if a recipient domain implements MTA-STS, a sender need > only resolve a single TXT record. To see if an updated policy is > available for a domain for which the sender has a previously cached > policy, the sender need only check the TXT record's version "id" > against the cached value. Given earlier discussion on the list, while new "id" values can give expedited signals to refresh the policy, it may be appropriate here, (but perhaps later in the document as you see fit) to describe a recommended approach to proactively refresh policies prior to their pending expiration, this reduces the probability of "gaps" in policy coverage if the remote HTTPS service is unavailable just as a policy is expiring. In practice (say in Postfix, if/when STS is implemented) I wouldn't go looking through the cache for policies to refresh except when delivering mail to the destination in question. I don't want the cache to become a roach motel for policies to destinations I never again send mail to. If communication with a destination ceases completely, it is not unreasonable to let its STS policy simply age out. Google et. al. may of course choose indefinite data retension (data retentiveness is Google's business), but for SOHO and enterprise MTAs, the above may be more appropriate. > 3.2. MTA-STS Policies >=20 > This JSON object contains the following key/value pairs: >=20 > o "version": (plain-text, required). Currently only "STSv1" is > supported. >=20 > o "mode": (plain-text, required). Either "enforce" or "report", > indicating the expected behavior of a sending MTA in the case of = a > policy validation failure. >=20 > o "max_age": Max lifetime of the policy (plain-text non-negative > integer seconds, required). Well-behaved clients SHOULD cache a > policy for up to this value from last policy fetch time. To > mitigate the risks of attacks at policy refresh time, it is > expected that this value typically be in the range of weeks or > greater. A more comprehensive mitigation for attacks "at policy refresh time" would entail not just a long lifetime, but proactive refresh as = mentioned above. > o "mx": MX patterns (list of plain-text MX match strings, = required). > One or more patterns matching the expected MX for this domain. > For example, "["*.example.com", "*.example.net"]" indicates that > mail for this domain might be handled by any MX with a hostname = at > "example.com" or "example.net". Valid patterns can be either > hostname literals (e.g. "mx1.example.com") or wildcard matches, = so > long as the wildcard occupies the full left-most label in the > pattern. (Thus "*.example.com" is valid but "mx*.example.com" = is > not.) Here, as discussed on the list, serious consideration should be given to changing the semantics from validating the MX hostname to specifying the names allowed in the server's certificate. This simplifies MX = processing (which remains unmodified) and merely changes the conditions under which = an MX host is considered suitably authenticated per the policy. Which, for example, allows the MX hosts to share a single certificate with the destination domain (and not the MX hostname) as its DNS SAN. If the policy lists that (shared) name as what's expected in the = certificate, then authentication succeeds when the MX host's certificate matches one = of the allowed names. It should be made clear that the names here are always in A-label form and not U-label form (as they also are in DNS names in certificates). Furthermore, I think that using "*.example.com" in what are essentially (rfc6125) reference identifiers creates confusion with similar-looking, = but semantically distinct wildcard names in certificates. My suggestion was ".example.com" for sub-domain matching, with the policy optionally = specifying whether only single-label prefixes are accepted, or whether in fact = multi-label prefixes are also valid. > An example JSON policy is as below: >=20 > { > "version": "STSv1", > "mode": "enforce", > "mx": ["*.mail.example.com"], > "max_age": 123456 > } FWIW, I would have chosen something less fancy than JSON for what is clearly a simple array of attribute/value pairs. ESMTP already encodes such optional A/V pairs as space separated lists of attr=3Dvalue with xtext encoding as needed (it is not needed for any plausible value of the above attributes). We're not going to add a JSON decoder to the Postfix SMTP client, but if this specification retains JSON, then the code that does background policy retrieval will need to transform JSON into something more friendly to traditional C-based MTA implementations. > 4. Policy Validation Are we validating the policy or using the policy to authenticate the MX host? I think the name of this section is suboptimal. > When sending to an MX at a domain for which the sender has a valid > and non-expired SMTP MTA-STS policy, a sending MTA honoring SMTP = STS > MUST validate: s/validate/check/ or /ensure/. > 1. That the recipient MX matches the "mx" pattern from the = recipient > domain's policy. See above, perhaps "mx" becomes "san" and the check is deferred until it is time to verify the host's certificate. > 2. That the recipient MX supports STARTTLS and offers a valid PKIX > based TLS certificate. Here, it would be prudent to mention rfc6125, and be explicit about the acceptable wildcard patterns in that certificate. See, for example: https://tools.ietf.org/html/rfc7672#section-3.2.3 which limits certificate wildcards to the entire first label only. I would like to avoid supporting more general wildcards in new specifications. > This section does not dictate the behavior of sending MTAs when > policies fail to validate; in particular, validation failures of > policies which specify "report" mode MUST NOT be interpreted as > delivery failures, as described in the section _Policy_ > _Application_. The first sentence is unfortunate, you are in fact specifying behaviour, in the very next sentence. It might be better to add a = forward-reference to a section that provides a detailed explanation and not start with a disclaimer. > 4.1. MX Matching >=20 > When delivering mail for the Policy Domain to a recipient MX host, > the sender validates the MX match against the "mx" pattern from the > applied policy. The semantics for these patterns are those found = in > section 6.4 of [RFC6125]. Assuming this text survives, replace: validates the MX match against the "mx" pattern with something like ensures that the MX host name is consistent with the "mx" property of the STS policy (only matching MX hosts are used in delivery attempts). The reference to rfc6125 is rather unfortunate here, since it defines semantics for presented identifiers, not reference identifiers. > 4.2. MX Certificate Validation >=20 > The certificate presented by the receiving MX MUST be valid for the > MX hostname and chain to a root CA that is trusted by the sending > MTA. The certificate MUST have a CN or SAN matching the MX = hostname > (as described in [RFC6125]) and be non-expired. Here, if the proposal to switch from "mx" to "san" is taken up, the peer certificate is no longer restricted to authenticate the MX = hostname, rather, one its presented identifiers needs to match one of the = reference identifiers fro the "san" policy attribute. Either way some discussion is appropriate of how to perform matching when both the reference and the presented identifiers are "wildcards". > 5. Policy Application This is an appropriate target for the afore-mentioned forward-reference. > When sending to an MX at a domain for which the sender has a valid, > non-expired STS policy, a sending MTA honoring SMTP STS applies the > result of a policy validation one of two ways, depending on the = value > of the policy "mode" field: >=20 > 1. "report": In this mode, sending MTAs merely send a report (as > described in the TLSRPT specification (TODO: add ref)) = indicating > policy application failures. >=20 > 2. "enforce": In this mode, sending MTAs treat STS policy failures > as a mail delivery error, and MUST NOT deliver the message to > this host. We should not confuse "delivery error" with "authentication failure". When one MX host fails authentication, the next MX host should be tried. And, I think it should be mentioned that if all the MX hosts (that the sender is willing to try) fail authentication, the message should be deferred, not bounced. > When a message fails to deliver due to an "enforce" policy, a > compliant MTA MUST check for the presence of an updated policy at = the > Policy Domain before permanently failing to deliver the message. > This allows implementing domains to update long-lived policies on = the > fly. This seems to suggest the contrary, i.e. that it might be appropriate to bounce on policy failure when a more fresh policy still fails. However certificate problems (expiration most typically) are transient, and a receiving system operator should/may notice the problem before outstanding messages expire and bounce. So I would urge implementors to queue, rather than bounce, on authentication failure. > 5.1. MX Preference This section would go if a switch from "mx" to "san" takes place. > 5.2. Policy Application Control Flow >=20 > An example control flow for a compliant sender consists of the > following steps: Step 0: If the sending MTA is DANE-capable, the destination is DNSSEC signed, and one or more of the MX hosts have DANE TLSA records, then DANE TLSA preempts STS (more downgrade-resistant, works on first contact, ...). This is another reason to avoid STS-based MX filtering, with DNSSEC signed destinations the security of the MX records is sufficiently established, and we need to be able to proceed with DANE MX by MX, using STS policy only for MX hosts with no TLSA records. > 1. Check for a cached policy whose time-since-fetch has not = exceeded > its "max_age". If none exists, attempt to fetch a new policy. > (Optionally, sending MTAs may unconditionally check for a new > policy at this step.) Is "attempt to fetch" well understood at this point? The attempt only happens if the DNS TXT record is in place... > 2. Filter candidate MXs against the current policy. See "san" vs. "mx" issue above. Also proceed with non-STS delivery absent any policy. > 3. If no candidate MXs are valid and the policy mode is "enforce", > temporarily fail the message. (Otherwise, generate a failure > report but deliver as though MTA STS were not implemented.) Ditto. > 4. For each candidate MX, in order of MX priority, attempt to > deliver the message, enforcing STARTTLS and the MX host's PKIX > certificate validation. Well, no so much enforcing as performing, authentication may be allowed to fail in "report" mode. And of course only if there is an STS policy to use. > 5. Upon message retries, a message MAY be permanently failed > following first checking for the presence of a new policy (as > indicated by the "id" field in the "mta-sts" TXT record). I think this is a mistake. Please do not turn transient errors into permanent failures. > 6.1. Policy Updates >=20 > Updating the policy requires that the owner make changes in two > places: the "mta-sts" TXT record in the Policy Domain's DNS zone = and > at the corresponding HTTPS endpoint. In the case where the HTTPS > endpoint has been updated but the TXT record has not yet been, > senders will not know there is a new policy released and may thus > continue to use old, previously cached versions. Recipients should > thus expect a policy will continue to be used by senders until both > the HTTPS and TXT endpoints are updated and the TXT record's TTL = has > passed. The lifetime could be longer. Some MTAs may initiate *background* = refresh of unexpired policies after the DNS TXT record is found to have changed, which may not happen until the first message to the destination is sent after that change, and *that* message may well go out based on the = already cached policy while the refresh is in process. If the policy no longer matches reality, the message may be deferred, and would perhaps succeed on retry with a more current policy. So the TXT record will not guarantee refresh in any particular = timeframe. If no mail is sent to the destination, the policy may expire unused = despite the TXT record change. > 8. Security Considerations >=20 > Since we use DNS TXT records for policy discovery, an attacker who = is > able to block DNS responses can suppress the discovery of an STS > Policy, making the Policy Domain appear not to have an STS Policy. > The sender policy cache is designed to resist this attack. Well, not "resist" so much as reduce the effectiveness, since it will now only be effective on first contact, or perhaps when no mail is sent to the destination for a long time and the cached policy expired. > We additionally consider the Denial of Service risk posed by an > attacker who can modify the DNS records for a victim domain. = Absent > SMTP STS, such an attacker can cause a sending MTA to cache invalid > MX records for a long TTL. With SMTP STS, the attacker can > additionally advertise a new, long-"max_age" SMTP STS policy with > "mx" constraints that validate the malicious MX record, causing > senders to cache the policy and refuse to deliver messages once the > victim has resecured the MX records. Many DNS resolvers have sensible upper-bounds on record TTLs. It the attacker can obtain a certificate for the victim domain, they may indeed inject a long-lived policy, but the TXT record affords the victim the opportunity of recovery. This paragraph needs work. Finally, some discussion is appropriate of the fact that given weaker downgrade-resistance of STS viz. DANE, implementations that support both should apply DANE first and STS only in its absence. Indeed with the MX RRset validated via DNSSEC the "mx" policy element is not really needed to prevent MX record forgery, however that depends on the outcome of the "mx" vs. "san" discussion. There should probably be a recommendation that sending systems implement DANE in addition to STS. It is much easier to use a validating resolver than to sign one's own domain, and so the barrier to option of outbound DANE is significantly lower. I'll have some additional implementation news to report shortly... > 10.1. Example 1 >=20 > The owner of "example.com" wishes to begin using STS with a policy > that will solicit reports from receivers without affecting how the > messages are processed, in order to verify the identity of MXs that > handle mail for "example.com", confirm that TLS is correctly used, > and ensure that certificates presented by the recipient MX = validate. >=20 > STS policy indicator TXT RR: >=20 > mta-sts.example.com. IN TXT "v=3DSTSv1; id=3D20160831085700Z;" >=20 > STS Policy JSON served as the response body at [1] >=20 > { > "version": "STSv1", > "mode": "report", > "mx": ["mx1.example.com", "mx2.example.com"], > "max_age": 123456 > } Note, the "max_age" here is barely over a day, which is not consistent = with the recommended policy lifetimes. Even "report" policies should = probably have better downgrade protection through longer lifetimes (say a week or = more). > 11. Appendix 2: Message delivery pseudocode >=20 > Below is pseudocode demonstrating the logic of a complaint sending > MTA. This implements the "two-pass" approach, first attempting > delivery with a newly fetched policy (if present) before falling = back > to a cached policy (if present). Should that be "complaint" or "compliant"? :-) I would expect that sane implementations will use cached policies first, and only both refreshes based on TXT record changes or refresh timers, with updates in the background. Synchronous updates of policy at message delivery time are exceedingly unappealing at least to me. > func certMatches(connection, mx) { > // Return if the server certificate from "connection" matches the = "mx" host. This could use a detailed discussion of what "matches" means, or a back-reference to a section that does. Covering wildcard use in either or both of the reference and presented identifiers, and possible additional text if "mx" becomes "san". > func getMxsForPolicy(domain, policy) { > // Sort the MXs by priority, filtering out those which are invalid = according > // to "policy". > } [ "mx" vs. "san" ] > func tryGetNewPolicy(domain) { > // Check for an MTA STS TXT record for "domain" in DNS, and return = the > // indicated policy (or a local cache of the unvalidated policy). > } The DNS lookup may succeed, and the HTTPS lookup may tempfail, what happens in that case? What happens with an authenticated 404 HTTPS response? Let's avoid "unvalidated" here, or else avoid its use in the context of "peer authentication". > func cachePolicy(domain, policy) { > // Store "policy" as the cached policy for "domain". > } Along with the policy one should generally store the time at which it was last retrieved, and the time of any unsuccessful refresh attempts since then. This supports both eventual=20 expiration, and proactive refresh, with multiple retries, as the policy approaches expiration. > func tryMxAccordingTo(message, mx, policy) { > connection :=3D connect(mx) > if !connection { > return false // Can't connect to the MX so it's not an STS error. > } > status :=3D !(tryStartTls(mx, &connection) && = certMatches(connection, mx)) > status =3D true What's happening with "status" here? I think the first assignment = goes... > if !tryStartTls(mx, &connection) { > status =3D false > reportError(E_NO_VALID_TLS) > } else if certMatches(connection, mx) { Missing negation? > status =3D false > reportError(E_CERT_MISMATCH) > } > if status || !isEnforce(policy) { > return tryDeliverMail(connection, message) There are potential complications when an MX host accepts a proper subset of the envelope recipients and tempfails the rest, or fails for reasons unrelated to policy, ... So a simple boolean here is not enough. Delivery to backup MX hosts continues so long as recipients that are neither delivered nor permanently rejected remain. STS policy failure is just one way that (all the) recipients may remain unresolved. > } > return false > } >=20 > func tryWithPolicy(message, domain, policy) { > mxes :=3D getMxesForPolicy(domain, policy) > if mxs is empty { > reportError(E_NO_VALID_MXES) > } > for mx in mxes { > if tryMxAccordingTo(message, mx, policy) { > return true > } > } > return false > } >=20 > func handleMessage(message) { > domain :=3D ... // domain part after '@' from recipient > oldPolicy :=3D tryGetCachedPolicy(domain) > newPolicy :=3D tryGetNewPolicy(domain) In practice, the cached policie's DNS id will be compared with the current DNS value and if identical, no new policy will be fetched. If different, a new policy should be fetched, but perhaps in the backround, with delivery continuing per the cached policy. > if newPolicy { > cachePolicy(domain, newPolicy) > oldPolicy =3D newPolicy > } > if oldPolicy { > return tryWithPolicy(message, oldPolicy) > } > // There is no policy or there's a new policy that did not work. > // Try to deliver the message normally (i.e. without STS). > } --=20 Viktor.= From nobody Wed Mar 22 05:40:03 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E771294D1 for ; Wed, 22 Mar 2017 05:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmlZWnBMqfvj for ; Wed, 22 Mar 2017 05:39:57 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53BF9129739 for ; Wed, 22 Mar 2017 05:39:57 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id b140so64903779iof.1 for ; Wed, 22 Mar 2017 05:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=F2yvLgw2Ck5MRTDsU7xkiWH+bnCoScPER7fBuV6YYHQ=; b=WykYqfTUCIH+GRXp4QLTPzZnTNTF8VaVrG5rGGb+O+8x4GMc2DC/trBQrFns4K0RpA SfP1AowfPgtbYbCeXld+6Rg0F8oVOEk8whlOZ33Lax0cAwe9yn2PbFMiQLNiRHRB04SX aecq7mBu/i7xLdRQp+piAcO4IYhb7vTEJuqBuSwwGw2idnyq/ZeAv+S5NbjFwDpcAjoK YVDBMMVfjqMc2Nzjf6jJ48p4PbFlWW0wNGE87gfieqyldK/zm4YpPXVtbF7lAY5TdDyH G1q+mqb4uznQcKnTYUP4ioFJ9rDOmHuWYFsAFU+BoLms81TrITz23vNjjR3kH71T73rW 208A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=F2yvLgw2Ck5MRTDsU7xkiWH+bnCoScPER7fBuV6YYHQ=; b=ZvN0DZJdBGCHFsf7CXir8ZHvLlItHoaCivrnzRVSQ2/ibxtyLjINydtW4pBmXHlPn0 c1YIer4a+SHpn//w3eN1h6cVp1xBSHL/OB7D3yCp+0KvBKbVRuKuHWfkTTniRpmmWibw 9At1qiZ1Wdx2NMY2qAUdkSVagqygin0g69w/PQRj+GlQe4lmYxc9H++OiH9oFwLn4G1t BY7aUy/LjBADTbQYQZ7wGYBIl635Dk3vWNalrgqSQy98HLKCKjTbsGyCFuTwI3DXvkD+ q50qAl5UvC/SkiC+ECzQqXBH2KxGmkWpKb57xzyJHcZzKDpmB0yf+1RxIchXnMk6ZxBN BtKg== X-Gm-Message-State: AFeK/H34PGxNbo95uR5j5lg+n/T7pbkzbXmeCTpBebrERjY9W2PI8rUW/l5GMoScW/cDQjCT/tdmVcKQZBxZYvlz X-Received: by 10.107.33.68 with SMTP id h65mr4419804ioh.101.1490186395645; Wed, 22 Mar 2017 05:39:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.54.81 with HTTP; Wed, 22 Mar 2017 05:39:54 -0700 (PDT) In-Reply-To: <4C0807DA-4852-4DAC-80ED-8A25371CFFAA@dukhovni.org> References: <4C0807DA-4852-4DAC-80ED-8A25371CFFAA@dukhovni.org> From: Daniel Margolis Date: Wed, 22 Mar 2017 13:39:54 +0100 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1140f2c2cee2cc054b510e8f" Archived-At: Subject: Re: [Uta] MTA-STS-03 review X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 12:40:02 -0000 --001a1140f2c2cee2cc054b510e8f Content-Type: multipart/alternative; boundary=001a1140f2c2c3883c054b510efe --001a1140f2c2c3883c054b510efe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Viktor! Some comments inline, of course. ;) On Wed, Mar 22, 2017 at 6:04 AM, Viktor Dukhovni wrote: > > > While such _opportunistic_ encryption protocols provide a high > > While "_" may work as italics in MarkDown, you'll need to change all > these to RFC XML (where IIRC ... may be supported, but don't > take my word for it, check). > (This is just some mistake in our markdown->xml transformation. Beats me, but good catch.) > > > o Policy Domain: The domain for which an STS Policy is defined. > > (For example, when sending mail to "alice@example.com", the polic= y > > domain is "example.com".) > > Perhaps this should mention that more generally this is the nexthop > domain for SMTP delivery, and when mail routing is pre=C3=ABmpted by > by explicit relays via local policy, the Policy domain is the > domain name of the explicit relay (prior to any MX lookups if > applicable). > We mention this explicitly in section 3.4. > > > DANE requires DNSSEC [RFC4033] > > for authentication; the mechanism described here instead relies on > > certificate authorities (CAs) and does not require DNSSEC. For a > > thorough discussion of this trade-off, see the section _Security_ > > _Considerations_. > > The Security Considerations section (once again this is not MarkDown) > will need to properly discuss the downgrade exposure of STS on first > contact, and this trade-off probably should be mentioned here up-front. > We mention this (briefly) already, but maybe don't do it justice. In particular, while we say that "[t]he sender policy cache is designed to resist this attack," we don't call out explicitly the implied benefit of longer max_ages and longer caching. > > In addition, SMTP STS provides an optional report-only mode, enablin= g > > soft deployments to detect policy failures. > > It is easy to define a couple of new "certificate usage" code-points > for DANE that similarly signal "soft-fail" (with reporting). Would > the group strongly support a draft along those lines? I am not sure > that a merely "tamper-evident" operating mode is a good idea as a > persistent operating state, and I think that the ability to have > one or more (backup, i.e. worse preference) MX hosts without TLSA > records adequately addresses the need for incremental deployment. > Agreed. It's a difference from DANE (necessitated in part by the fact that DANE policies are per-MX rather than, as with STS, per-domain, so DANE has a different mechanism to allow incremental rollouts). I would not suggest it's better or worse, but supporting soft failures in this matter seems the easiest way to support testing a policy in the STS model, no? > Given earlier discussion on the list, while new "id" values can give > expedited signals to refresh the policy, it may be appropriate here, > (but perhaps later in the document as you see fit) to describe a > recommended approach to proactively refresh policies prior to their > pending expiration, this reduces the probability of "gaps" in policy > coverage if the remote HTTPS service is unavailable just as a policy > is expiring > Agreed. > Here, as discussed on the list, serious consideration should be given > to changing the semantics from validating the MX hostname to specifying > the names allowed in the server's certificate. This simplifies MX > processing > (which remains unmodified) and merely changes the conditions under which = an > MX host is considered suitably authenticated per the policy. > Which, for example, allows the MX hosts to share a single certificate > with the destination domain (and not the MX hostname) as its DNS SAN. > If the policy lists that (shared) name as what's expected in the > certificate, > then authentication succeeds when the MX host's certificate matches one o= f > the allowed names. > That's interesting. I think it's not actually that big a change--we just get rid of the MX host filtering and instead just apply the logic to validation. Downsides: 1. Misconfigurations _may_ be less obvious without connecting to the SMTP server. That is, today, you can spot some kinds of misconfigurations by merely looking at the DNS (so for example my test tool here http://sts.x.af0.net/ first looks at DNS, and only then tries SMTP connections). 2. As you say, it requires some changes to server certificate validation, but not much. I don't consider #1 compelling. So this seems fairly reasonable to me, but I will let others chime in. I've been quite hesitant to entertain any "business logic" changes at this point if we could avoid it, since we already have some code written, but like I said, I don't think this is actually a very large change. > > It should be made clear that the names here are always in A-label form > and not U-label form (as they also are in DNS names in certificates). > This is specified in 3.2. > Furthermore, I think that using "*.example.com" in what are essentially > (rfc6125) reference identifiers creates confusion with similar-looking, b= ut > semantically distinct wildcard names in certificates. My suggestion was > ".example.com" for sub-domain matching, with the policy optionally > specifying > whether only single-label prefixes are accepted, or whether in fact > multi-label > prefixes are also valid. > Well, I think our matching is a subset of the matching defined in RFC6125 section 6.4.3. We could specify that we support the full policy; it seemed worth a simplification (i.e. we don't support 'something*.domain.com', only '*.domain.com') to make implementation easier, but at cost of a semantic difference. If we get rid of the wildcard, I suppose it is indeed more obvious that we're just doing only suffix matching. Was that your point? > FWIW, I would have chosen something less fancy than JSON for > what is clearly a simple array of attribute/value pairs. ESMTP > already encodes such optional A/V pairs as space separated lists > of attr=3Dvalue with xtext encoding as needed (it is not needed for > any plausible value of the above attributes). > I seem to recall that we started with simple key-value pairs and moved to JSON because people variously seemed to think this was easier (since parsing libraries are common). I would also consider the vague possibility that in future iterations we wish to add fields. De novo, I myself have no real opinion here, because certainly either work, but of course I'm loath to make changes again. I'd appreciate more feedback from more readers, though, as these style discussions are always a bit subjective. I assume that for Postfix policy fetching is a background process anyway, though, so it isn't (I would hope) too big an implementation difference for you, right? > We're not going to add a JSON decoder to the Postfix SMTP client, > but if this specification retains JSON, then the code that does > background policy retrieval will need to transform JSON into > something more friendly to traditional C-based MTA implementations. > > > 4. Policy Validation > > Are we validating the policy or using the policy to authenticate > the MX host? I think the name of this section is suboptimal. > > > When sending to an MX at a domain for which the sender has a valid > > and non-expired SMTP MTA-STS policy, a sending MTA honoring SMTP STS > > MUST validate: > > s/validate/check/ or /ensure/. > > > 1. That the recipient MX matches the "mx" pattern from the recipien= t > > domain's policy. > > See above, perhaps "mx" becomes "san" and the check is deferred until > it is time to verify the host's certificate. > > > 2. That the recipient MX supports STARTTLS and offers a valid PKIX > > based TLS certificate. > > Here, it would be prudent to mention rfc6125, and be explicit about > the acceptable wildcard patterns in that certificate. See, for example: > > https://tools.ietf.org/html/rfc7672#section-3.2.3 > > which limits certificate wildcards to the entire first label only. I > would like to avoid supporting more general wildcards in new > specifications. > We specify this in 4.1 (as you discovered below), but maybe that's too late. > > > This section does not dictate the behavior of sending MTAs when > > policies fail to validate; in particular, validation failures of > > policies which specify "report" mode MUST NOT be interpreted as > > delivery failures, as described in the section _Policy_ > > _Application_. > > The first sentence is unfortunate, you are in fact specifying behaviour, > in the very next sentence. It might be better to add a forward-reference > to a section that provides a detailed explanation and not start with a > disclaimer. > Heh. Thanks. ;) > > 4.1. MX Matching > > > > When delivering mail for the Policy Domain to a recipient MX host, > > the sender validates the MX match against the "mx" pattern from the > > applied policy. The semantics for these patterns are those found in > > section 6.4 of [RFC6125]. > > Assuming this text survives, replace: > > validates the MX match against the "mx" pattern > > with something like > > ensures that the MX host name is consistent with the "mx" > property of the STS policy (only matching MX hosts are > used in delivery attempts). > > The reference to rfc6125 is rather unfortunate here, since it defines > semantics for presented identifiers, not reference identifiers. > If this field is used to validate the server certificate (and not the MX hostnames) as you suggested above, that would entail validating the presented identifier, which I think resolves your comment. > Here, if the proposal to switch from "mx" to "san" is taken up, the > peer certificate is no longer restricted to authenticate the MX hostname, > rather, one its presented identifiers needs to match one of the reference > identifiers fro the "san" policy attribute. Either way some discussion > is appropriate of how to perform matching when both the reference and > the presented identifiers are "wildcards". > Ah, good point--this is a bit of additional complexity implied by your suggested change. One option would be to merely disallow wildcards in the "mx" (or "san") field. Assuming people do not have full (non-wildcarded) hostnames in their server certificates, this should work fine. (IOW, for Google, we would change "*.aspmx.l.google.com" to "mail.google.com" or some other suitable name.) Upside: easy to use existing validation code to check (e.g. https://golang.org/src/crypto/tls/common.go?s=3D12153:20652#L426). Downside= : I guess this would be cumbersome if someone for some reason has a fully specified hostname as the CN/SAN in their server cert. Another: Specify our own matching rules for wildcards on both identifiers. It's not really that complicated, but I don't favor making people write this and possibly make mistakes. > When a message fails to deliver due to an "enforce" policy, a > > compliant MTA MUST check for the presence of an updated policy at th= e > > Policy Domain before permanently failing to deliver the message. > > This allows implementing domains to update long-lived policies on th= e > > fly. > > This seems to suggest the contrary, i.e. that it might be appropriate > to bounce on policy failure when a more fresh policy still fails. > However certificate problems (expiration most typically) are transient, > and a receiving system operator should/may notice the problem before > outstanding messages expire and bounce. So I would urge implementors > to queue, rather than bounce, on authentication failure. > Rather, the point of this was to encourage implemenors to _not_ bounce until at least updating the policy once, not to encourage them to bounce _after_ such an update. So I think we agree, but the wording may be suboptimal. > Step 0: If the sending MTA is DANE-capable, the destination is > DNSSEC signed, and one or more of the MX hosts have DANE TLSA > records, then DANE TLSA preempts STS (more downgrade-resistant, > works on first contact, ...). > > This is another reason to avoid STS-based MX filtering, with DNSSEC > signed destinations the security of the MX records is sufficiently > established, and we need to be able to proceed with DANE MX by MX, > using STS policy only for MX hosts with no TLSA records. > With the suggested change to use STS only to validate the server certificates and not to do MX filtering, this is obviated, no? I don't really favor specifying whether senders should do an AND or an OR in applying DANE and STS when both are present, and with that change it no longer implies any incompatibilities in MX selection. > > > 5. Upon message retries, a message MAY be permanently failed > > following first checking for the presence of a new policy (as > > indicated by the "id" field in the "mta-sts" TXT record). > > I think this is a mistake. Please do not turn transient errors into > permanent failures. > See above; the intent is not to specify that this should be a perm-fail, but rather that one should not perm-fail without first checking for a new policy. I agree on the wording, however. Finally, some discussion is appropriate of the fact that given weaker > downgrade-resistance of STS viz. DANE, implementations that support > both should apply DANE first and STS only in its absence. Indeed with > the MX RRset validated via DNSSEC the "mx" policy element is not really > needed to prevent MX record forgery, however that depends on the outcome > of the "mx" vs. "san" discussion. > > There should probably be a recommendation that sending systems implement > DANE in addition to STS. It is much easier to use a validating resolver > than to sign one's own domain, and so the barrier to option of outbound > DANE is significantly lower. I'll have some additional implementation > news to report shortly... > I'm good with putting that here (unlike my objection above); it seems appropriate to note the tradeoffs in Security Considerations in some form. > > > 10.1. Example 1 > > > > The owner of "example.com" wishes to begin using STS with a policy > > that will solicit reports from receivers without affecting how the > > messages are processed, in order to verify the identity of MXs that > > handle mail for "example.com", confirm that TLS is correctly used, > > and ensure that certificates presented by the recipient MX validate. > > > > STS policy indicator TXT RR: > > > > mta-sts.example.com. IN TXT "v=3DSTSv1; id=3D20160831085700Z;" > > > > STS Policy JSON served as the response body at [1] > > > > { > > "version": "STSv1", > > "mode": "report", > > "mx": ["mx1.example.com", "mx2.example.com"], > > "max_age": 123456 > > } > > Note, the "max_age" here is barely over a day, which is not consistent wi= th > the recommended policy lifetimes. Even "report" policies should probably > have better downgrade protection through longer lifetimes (say a week or > more). > I think that max_age was chosen because of the sequential nature of the numbers and not its value. ;) But point taken. > Should that be "complaint" or "compliant"? :-) I would expect that > sane implementations will use cached policies first, and only both > refreshes based on TXT record changes or refresh timers, with updates > in the background. Synchronous updates of policy at message delivery > time are exceedingly unappealing at least to me. > It's presented as such here only for ease of following the logic, not to suggest that one should prefer a synchronous fetch. > > func certMatches(connection, mx) { > > // Return if the server certificate from "connection" matches the "mx= " > host. > > This could use a detailed discussion of what "matches" means, or a > back-reference to a section that does. Covering wildcard use in > either or both of the reference and presented identifiers, and > possible additional text if "mx" becomes "san". > As discussed above, I'm not a huge fan of doing wildcards-on-both-sides...but let's conclude on that discussion first. > > What's happening with "status" here? I think the first assignment goes..= . > Man, who wrote this code? ;) > There are potential complications when an MX host > accepts a proper subset of the envelope recipients > and tempfails the rest, or fails for reasons unrelated > to policy, ... So a simple boolean here is not enough. > Delivery to backup MX hosts continues so long as > recipients that are neither delivered nor permanently > rejected remain. STS policy failure is just one way > that (all the) recipients may remain unresolved. > Well, the goal is not to implement a complete SMTP server here in pseudocode. ;) For clarity I'd probably keep that elided, unless you think it introduces confusion. --001a1140f2c2c3883c054b510efe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Viktor!=C2=A0

Some comments inl= ine, of course. ;)=C2=A0

On Wed, Mar 22, 2017 at 6:04 AM, Viktor Dukhovni <ietf-d= ane@dukhovni.org> wrote:

>=C2=A0 =C2=A0 While such _opportunistic_ encryption protocols provide a= high

While "_" may work as italics in MarkDown, you'll need to cha= nge all
these to RFC XML (where IIRC <i>...</i> may be supported, but d= on't
take my word for it, check).

(This is j= ust some mistake in our markdown->xml transformation. Beats me, but good= catch.)
=C2=A0

>=C2=A0 =C2=A0 o=C2=A0 Policy Domain: The domain for which an STS Policy= is defined.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(For example, when sending mail to "alice@example.com", the policy >=C2=A0 =C2=A0 =C2=A0 =C2=A0domain is "example.com".)

Perhaps this should mention that more generally this is the nexthop
domain for SMTP delivery, and when mail routing is pre=C3=ABmpted by
by explicit relays via local policy, the Policy domain is the
domain name of the explicit relay (prior to any MX lookups if
applicable).

We mention this explicitly= in section=C2=A03.4.=C2=A0
=C2=A0

>=C2=A0 DANE requires DNSSEC [RFC4033]
>=C2=A0 =C2=A0 for authentication; the mechanism described here instead = relies on
>=C2=A0 =C2=A0 certificate authorities (CAs) and does not require DNSSEC= .=C2=A0 For a
>=C2=A0 =C2=A0 thorough discussion of this trade-off, see the section _S= ecurity_
>=C2=A0 =C2=A0 _Considerations_.

The Security Considerations section (once again this is not MarkDown)
will need to properly discuss the downgrade exposure of STS on first
contact, and this trade-off probably should be mentioned here up-front.
=

We mention this (briefly) already, but may= be don't do it justice. In particular, while we say that "[t]he se= nder policy cache is designed to resist this attack," we don't cal= l out explicitly the implied benefit of longer max_ages and longer caching.=
=C2=A0
>=C2=A0 =C2=A0 In addition, SMTP STS provides an optional report-only mo= de, enabling
>=C2=A0 =C2=A0 soft deployments to detect policy failures.

It is easy to define a couple of new "certificate usage" code-poi= nts
for DANE that similarly signal "soft-fail" (with reporting).=C2= =A0 Would
the group strongly support a draft along those lines?=C2=A0 I am not sure that a merely "tamper-evident" operating mode is a good idea as a=
persistent operating state, and I think that the ability to have
one or more (backup, i.e. worse preference) MX hosts without TLSA
records adequately addresses the need for incremental deployment.

Agreed. It's a difference from DANE (necessi= tated in part by the fact that DANE policies are per-MX rather than, as wit= h STS, per-domain, so DANE has a different mechanism to allow incremental r= ollouts). I would not suggest it's better or worse, but supporting soft= failures in this matter seems the easiest way to support testing a policy = in the STS model, no?=C2=A0
=C2=A0
Given earlier discussion on the list, while new "id" values can g= ive
expedited signals to refresh the policy, it may be appropriate here,
(but perhaps later in the document as you see fit) to describe a
recommended approach to proactively refresh policies prior to their
pending expiration, this reduces the probability of "gaps" in pol= icy
coverage if the remote HTTPS service is unavailable just as a policy
is expiring

Agreed. =C2=A0
= =C2=A0
Here, as discussed on the list, serious consideration should be given
to changing the semantics from validating the MX hostname to specifying
the names allowed in the server's certificate.=C2=A0 This simplifies MX= processing
(which remains unmodified) and merely changes the conditions under which an=
MX host is considered suitably authenticated per the policy.

Which, for example, allows the MX hosts to share a single certificate
with the destination domain (and not the MX hostname) as its DNS SAN.
If the policy lists that (shared) name as what's expected in the certif= icate,
then authentication succeeds when the MX host's certificate matches one= of
the allowed names.

That's interesti= ng. I think it's not actually that big a change--we just get rid of the= MX host filtering and instead just apply the logic to validation.=C2=A0

Downsides:

1. Misconfigurat= ions _may_ be less obvious without connecting to the SMTP server. That is, = today, you can spot some kinds of misconfigurations by merely looking at th= e DNS (so for example my test tool here=C2=A0http://sts.x.af0.net/ first looks at =C2=A0DNS, and only then tries= SMTP connections).
2. As you say, it requires some changes to se= rver certificate validation, but not much.=C2=A0

I= don't consider #1 compelling. So this seems fairly reasonable to me, b= ut I will let others chime in.

I've been quite= hesitant to entertain any "business logic" changes at this point= if we could avoid it, since we already have some code written, but like I = said, I don't think this is actually a very large change.=C2=A0
=C2=A0

It should be made clear that the names here are always in A-label form
and not U-label form (as they also are in DNS names in certificates).

This is specified in 3.2.=C2=A0
= =C2=A0
Furthermore, I think that using "*.example.com" in what are essenti= ally
(rfc6125) reference identifiers creates confusion with similar-looking, but=
semantically distinct wildcard names in certificates.=C2=A0 My suggestion w= as
".= example.com" for sub-domain matching, with the policy optionally s= pecifying
whether only single-label prefixes are accepted, or whether in fact multi-l= abel
prefixes are also valid.

Well, I think = our matching is a subset of the matching defined in RFC6125 section=C2=A06.= 4.3. We could specify that we support the full policy; it seemed worth a si= mplification (i.e. we don't support 'something*.domain.com', only '*.d= omain.com') to make implementation easier, but at cost of a semanti= c difference. If we get rid of the wildcard, I suppose it is indeed more ob= vious that we're just doing only suffix matching. Was that your point?<= /div>
=C2=A0
FWIW, I would have chosen something less fancy than JSON for
what is clearly a simple array of attribute/value pairs. ESMTP
already encodes such optional A/V pairs as space separated lists
of attr=3Dvalue with xtext encoding as needed (it is not needed for
any plausible value of the above attributes).

I seem to recall that we started with simple key-value pairs and mov= ed to JSON because people variously seemed to think this was easier (since = parsing libraries are common). I would also consider the vague possibility = that in future iterations we wish to add fields.=C2=A0

=
De novo, I myself have no real opinion here, because certainly either = work, but of course I'm loath to make changes again. I'd appreciate= more feedback from more readers, though, as these style discussions are al= ways a bit subjective. I assume that for Postfix policy fetching is a backg= round process anyway, though, so it isn't (I would hope) too big an imp= lementation difference for you, right?
=C2=A0
We're not going to add a JSON decoder to the Postfix SMTP client,
but if this specification retains JSON, then the code that does
background policy retrieval will need to transform JSON into
something more friendly to traditional C-based MTA implementations.

> 4.=C2=A0 Policy Validation

Are we validating the policy or using the policy to authenticate
the MX host?=C2=A0 I think the name of this section is suboptimal.

>=C2=A0 =C2=A0 When sending to an MX at a domain for which the sender ha= s a valid
>=C2=A0 =C2=A0 and non-expired SMTP MTA-STS policy, a sending MTA honori= ng SMTP STS
>=C2=A0 =C2=A0 MUST validate:

s/validate/check/ or /ensure/.

>=C2=A0 =C2=A0 1.=C2=A0 That the recipient MX matches the "mx"= pattern from the recipient
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 domain's policy.

See above, perhaps "mx" becomes "san" and the check is = deferred until
it is time to verify the host's certificate.

>=C2=A0 =C2=A0 2.=C2=A0 That the recipient MX supports STARTTLS and offe= rs a valid PKIX
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 based TLS certificate.

Here, it would be prudent to mention rfc6125, and be explicit about
the acceptable wildcard patterns in that certificate.=C2=A0 See, for exampl= e:

=C2=A0 =C2=A0https://tools.ietf.org/html/rfc76= 72#section-3.2.3

which limits certificate wildcards to the entire first label only.=C2=A0 I<= br> would like to avoid supporting more general wildcards in new
specifications.

We specify this in 4.1 = (as you discovered below), but maybe that's too late.=C2=A0
= =C2=A0

>=C2=A0 =C2=A0 This section does not dictate the behavior of sending MTA= s when
>=C2=A0 =C2=A0 policies fail to validate; in particular, validation fail= ures of
>=C2=A0 =C2=A0 policies which specify "report" mode MUST NOT b= e interpreted as
>=C2=A0 =C2=A0 delivery failures, as described in the section _Policy_ >=C2=A0 =C2=A0 _Application_.

The first sentence is unfortunate, you are in fact specifying behaviour, in the very next sentence.=C2=A0 It might be better to add a forward-refere= nce
to a section that provides a detailed explanation and not start with a
disclaimer.

Heh. Thanks. ;)
= =C2=A0
> 4.1.=C2=A0 MX Matching
>
>=C2=A0 =C2=A0 When delivering mail for the Policy Domain to a recipient= MX host,
>=C2=A0 =C2=A0 the sender validates the MX match against the "mx&qu= ot; pattern from the
>=C2=A0 =C2=A0 applied policy.=C2=A0 The semantics for these patterns ar= e those found in
>=C2=A0 =C2=A0 section 6.4 of [RFC6125].

Assuming this text survives, replace:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 validates the MX match against the "mx&quo= t; pattern

with something like

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ensures that the MX host name is consistent wit= h the "mx"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 property of the STS policy (only matching MX ho= sts are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 used in delivery attempts).

The reference to rfc6125 is rather unfortunate here, since it defines
semantics for presented identifiers, not reference identifiers.

If this field is used to validate the server certi= ficate (and not the MX hostnames) as you suggested above, that would entail= validating the presented identifier, which I think resolves your comment.= =C2=A0
=C2=A0
Here, if the proposal to switch from "mx" to "san" is t= aken up, the
peer certificate is no longer restricted to authenticate the MX hostname, rather, one its presented identifiers needs to match one of the reference identifiers fro the "san" policy attribute.=C2=A0 Either way some= discussion
is appropriate of how to perform matching when both the reference and
the presented identifiers are "wildcards".
<= br>
Ah, good point--this is a bit of additional complexity implie= d by your suggested change.=C2=A0

One option would= be to merely disallow wildcards in the "mx" (or "san")= field. Assuming people do not have full (non-wildcarded) hostnames in thei= r server certificates, this should work fine. (IOW, for Google, we would ch= ange "*.aspmx.l.google.com&q= uot; to "mail.google.com" = or some other suitable name.) Upside: easy to use existing validation code = to check (e.g.=C2=A0https://golang.org/src/crypto/tls/common.go?s=3D12153= :20652#L426). Downside: I guess this would be cumbersome if someone for= some reason has a fully specified hostname as the CN/SAN in their server c= ert.=C2=A0

Another: Specify our own matching rules= for wildcards on both identifiers. It's not really that complicated, b= ut I don't favor making people write this and possibly make mistakes.= =C2=A0

Step 0:=C2=A0 If the sending MTA is DANE-capable, the destination is
DNSSEC signed, and one or more of the MX hosts have DANE TLSA
records, then DANE TLSA preempts STS (more downgrade-resistant,
works on first contact, ...).

This is another reason to avoid STS-based MX filtering, with DNSSEC
signed destinations the security of the MX records is sufficiently
established, and we need to be able to proceed with DANE MX by MX,
using STS policy only for MX hosts with no TLSA records.

With the suggested change to use STS only to validate the= server certificates and not to do MX filtering, this is obviated, no? I do= n't really favor specifying whether senders should do an AND or an OR i= n applying DANE and STS when both are present, and with that change it no l= onger implies any incompatibilities in MX selection.=C2=A0
=C2=A0=

>=C2=A0 =C2=A0 5.=C2=A0 Upon message retries, a message MAY be permanent= ly failed
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 following first checking for the presence o= f a new policy (as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 indicated by the "id" field in th= e "mta-sts" TXT record).

I think this is a mistake.=C2=A0 Please do not turn transient errors into permanent failures.

See above; the inte= nt is not to specify that this should be a perm-fail, but rather that one s= hould not perm-fail without first checking for a new policy. I agree on the= wording, however.=C2=A0

Finally, some discussion is appropriate of the fact that given weaker
downgrade-resistance of STS viz. DANE, implementations that support
both should apply DANE first and STS only in its absence.=C2=A0 Indeed with=
the MX RRset validated via DNSSEC the "mx" policy element is not = really
needed to prevent MX record forgery, however that depends on the outcome of the "mx" vs. "san" discussion.

There should probably be a recommendation that sending systems implement DANE in addition to STS.=C2=A0 It is much easier to use a validating resolv= er
than to sign one's own domain, and so the barrier to option of outbound=
DANE is significantly lower.=C2=A0 I'll have some additional implementa= tion
news to report shortly...

I'm good = with putting that here (unlike my objection above); it seems appropriate to= note the tradeoffs in Security Considerations in some form.=C2=A0
=C2=A0

> 10.1.=C2=A0 Example 1
>
>=C2=A0 =C2=A0 The owner of "example.com" wishes to begin using S= TS with a policy
>=C2=A0 =C2=A0 that will solicit reports from receivers without affectin= g how the
>=C2=A0 =C2=A0 messages are processed, in order to verify the identity o= f MXs that
>=C2=A0 =C2=A0 handle mail for "example.com", confirm that TLS i= s correctly used,
>=C2=A0 =C2=A0 and ensure that certificates presented by the recipient M= X validate.
>
>=C2=A0 =C2=A0 STS policy indicator TXT RR:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mta-sts.example.com.=C2=A0 IN TX= T "v=3DSTSv1; id=3D20160831085700Z;"
>
>=C2=A0 =C2=A0 STS Policy JSON served as the response body at [1]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ver= sion": "STSv1",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"mod= e": "report",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"mx&= quot;: ["mx1.example.com", "mx2.example.com"],
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"max= _age": 123456
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

Note, the "max_age" here is barely over a day, which is not consi= stent with
the recommended policy lifetimes.=C2=A0 Even "report" policies sh= ould probably
have better downgrade protection through longer lifetimes (say a week or mo= re).

I think that max_age was chosen be= cause of the sequential nature of the numbers and not its value. ;) But poi= nt taken.=C2=A0
=C2=A0
Should that be "complaint" or "compliant"? :-)=C2=A0 I = would expect that
sane implementations will use cached policies first, and only both
refreshes based on TXT record changes or refresh timers, with updates
in the background.=C2=A0 Synchronous updates of policy at message delivery<= br> time are exceedingly unappealing at least to me.

<= /div>
It's presented as such here only for ease of following the lo= gic, not to suggest that one should prefer a synchronous fetch.=C2=A0
=
=C2=A0
> func certMatches(connection, mx) {
>=C2=A0 =C2=A0// Return if the server certificate from "connection&= quot; matches the "mx" host.

This could use a detailed discussion of what "matches" means, or = a
back-reference to a section that does.=C2=A0 Covering wildcard use in
either or both of the reference and presented identifiers, and
possible additional text if "mx" becomes "san".

As discussed above, I'm not a huge fan of = doing wildcards-on-both-sides...but let's conclude on that discussion f= irst.=C2=A0

What's happening with "status" here?=C2=A0 I think the first = assignment goes...

Man, who wrote this = code? ;)=C2=A0
=C2=A0
There are potential complications when an MX host
accepts a proper subset of the envelope recipients
and tempfails the rest, or fails for reasons unrelated
to policy, ... So a simple boolean here is not enough.
Delivery to backup MX hosts continues so long as
recipients that are neither delivered nor permanently
rejected remain.=C2=A0 STS policy failure is just one way
that (all the) recipients may remain unresolved.

<= /div>
Well, the goal is not to implement a complete SMTP server here in= pseudocode. ;)=C2=A0

For clarity I'd probably= keep that elided, unless you think it introduces confusion.=C2=A0
=C2=A0

--001a1140f2c2c3883c054b510efe-- --001a1140f2c2cee2cc054b510e8f Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+ q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0 TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg 5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27 8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDl50rnHpjG7HBn GDFXyx54Qs/69s1ujEDbTu51aXvJdjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAzMjIxMjM5NTZaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAEG5rrpxwzF0j2MrVdZseezIcJcH2FkPY sznA0OieyZYXw1qydy3PPkYgkqkbj0ZF2nLaoxpX5bv8+NwM1k4MZM6ck9c1leFKea6wr46Nq6EZ O/0/q9RQNYIlMG6ysQ4c6zx/u4U4wjAZA5iBIr8PGI/FxOY1oU5iYgyQxBK2zLYjLwL2IH73mac3 prq9VVfad5qRJGhAC3YgzDttwOytP1fEmccjlaOWzAeB/VOk7x6DRsZDCsLY9TYhmeNY00vYXVUj 5xHD9RgQ/8yws815hluASmYzUzEsPyq/DW6g5lnq+plHczYyrulx5dVhPjzRKre+XY5tpZOgs/0d xnSS3A== --001a1140f2c2cee2cc054b510e8f-- From nobody Wed Mar 22 12:18:38 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE898129BE6 for ; Wed, 22 Mar 2017 12:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmMl8-MfbgdT for ; Wed, 22 Mar 2017 12:18:33 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936F1129B7E for ; Wed, 22 Mar 2017 12:18:33 -0700 (PDT) Received: from [172.31.30.83] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 79CA67A32F1 for ; Wed, 22 Mar 2017 19:18:32 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 22 Mar 2017 15:18:30 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: <46C421CB-1189-4493-B322-5A214D6A6EE9@dukhovni.org> References: <4C0807DA-4852-4DAC-80ED-8A25371CFFAA@dukhovni.org> To: uta@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Uta] MTA-STS-03 review X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 19:18:37 -0000 > On Mar 22, 2017, at 8:39 AM, Daniel Margolis = wrote: >=20 >>> o Policy Domain: The domain for which an STS Policy is defined. >>> (For example, when sending mail to "alice@example.com", the = policy >>> domain is "example.com".) >>=20 >> Perhaps this should mention that more generally this is the nexthop >> domain for SMTP delivery, and when mail routing is pre=C3=ABmpted by >> by explicit relays via local policy, the Policy domain is the >> domain name of the explicit relay (prior to any MX lookups if >> applicable). >=20 > We mention this explicitly in section 3.4.=20 I think that the *terminology* section needs a reasonably complete defintion, or at least a forward-reference. >>> DANE requires DNSSEC [RFC4033] >>> for authentication; the mechanism described here instead relies = on >>> certificate authorities (CAs) and does not require DNSSEC. For = a >>> thorough discussion of this trade-off, see the section = _Security_ >>> _Considerations_. >>=20 >> The Security Considerations section (once again this is not MarkDown) >> will need to properly discuss the downgrade exposure of STS on first >> contact, and this trade-off probably should be mentioned here = up-front. >=20 > We mention this (briefly) already, but maybe don't do it justice. In > particular, while we say that "[t]he sender policy cache is designed > to resist this attack," we don't call out explicitly the implied = benefit > of longer max_ages and longer caching. And I think don't give sufficient coverage to MiTM exposure on first-contact. >>> In addition, SMTP STS provides an optional report-only mode, = enabling >>> soft deployments to detect policy failures. >>=20 >> It is easy to define a couple of new "certificate usage" code-points >> for DANE that similarly signal "soft-fail" (with reporting). Would >> the group strongly support a draft along those lines? I am not sure >> that a merely "tamper-evident" operating mode is a good idea as a >> persistent operating state, and I think that the ability to have >> one or more (backup, i.e. worse preference) MX hosts without TLSA >> records adequately addresses the need for incremental deployment. >=20 > Agreed. It's a difference from DANE (necessitated in part by the fact > that DANE policies are per-MX rather than, as with STS, per-domain, > so DANE has a different mechanism to allow incremental rollouts). I > would not suggest it's better or worse, but supporting soft failures > in this matter seems the easiest way to support testing a policy in > the STS model, no? Well, my question is whether the group wants to see additional "certificate usage" code-points in DANE to support "report" mode, not a suggestion to change the STS specification... The STS "report" mode is roughly all one can do, though of course a more complex policy could express per-MX "enforce" bits, but I think that would be a mistake for STS. So if anyone has definite views on adding "soft fail" for DANE TLSA, please speak up! =20 >> Here, as discussed on the list, serious consideration should be given >> to changing the semantics from validating the MX hostname to = specifying >> the names allowed in the server's certificate. This simplifies MX = processing >> (which remains unmodified) and merely changes the conditions under = which an >> MX host is considered suitably authenticated per the policy. >>=20 >> Which, for example, allows the MX hosts to share a single certificate >> with the destination domain (and not the MX hostname) as its DNS SAN. >> If the policy lists that (shared) name as what's expected in the = certificate, >> then authentication succeeds when the MX host's certificate matches = one of >> the allowed names. >=20 > That's interesting. I think it's not actually that big a change--we = just > get rid of the MX host filtering and instead just apply the logic to > validation. Correct. =20 >> Furthermore, I think that using "*.example.com" in what are = essentially >> (rfc6125) reference identifiers creates confusion with = similar-looking, but >> semantically distinct wildcard names in certificates. My suggestion = was >> ".example.com" for sub-domain matching, with the policy optionally = specifying >> whether only single-label prefixes are accepted, or whether in fact = multi-label >> prefixes are also valid. >=20 > Well, I think our matching is a subset of the matching defined in = RFC6125 > section 6.4.3. We could specify that we support the full policy; it = seemed > worth a simplification (i.e. we don't support 'something*.domain.com', = only > '*.domain.com') to make implementation easier, but at cost of a = semantic > difference. If we get rid of the wildcard, I suppose it is indeed more = obvious > that we're just doing only suffix matching. Was that your point? Observe that with the current "mx" constraints these are compared only with the literal MX host names, which are in turn (as literals) compared with the certificate. So the literal MX hostname is on the one-hand compared against the STS policy (with potential wildcards) and on the = other hand the server certificate (with potential wildcards). If there's a switch to "san", the comparison of "san" is directly = against the certificate, which introduces the possibility of wildcard-to-wildcard comparison. Thus, my point is that there are two type of names with potential wildcards in this context. There are DNS SAN entries in certificates (presented identifiers) whose semantics are (partly) defined in RFC6125. RFC6125 leaves room for application-specific behaviour with respect to = CN-ID and exactly which kinds of wild-cards, if any, are supported. Then there are also "reference identifiers" which RFC6125 does not envision as anything other than plain literals. This draft casually treats "mx" constraints as though they were = presented identifiers from the certificate certificate, and I think this could = lead to user confusion, but this could be explained by noting that both kinds of patterns are compared against the MX hostname, and are then subject to similar interpretation. If however, the design is switched to "san" constraints, then there should be more care to distinguish "reference identifiers" from "presented identifiers". We tried to a=11void confusion in Postfix by using ".example.com" as the wildcard form for reference identifiers. So in the "san" design there would need to be some discussion of how to match reference identifiers against presented identifiers when the reference identifier is a = wildcard form and the presented identifier may also be a wildcard form. >> FWIW, I would have chosen something less fancy than JSON for >> what is clearly a simple array of attribute/value pairs. >=20 > I seem to recall that we started with simple key-value pairs and > moved to JSON because people variously seemed to think this was > easier (since parsing libraries are common). I would also consider > the vague possibility that in future iterations we wish to add > fields. Which a good reason to have name/value pairs rather than a simple ordered list of values with per-index semantics, but perhaps the instinct to choose JSON is over-engineering, and forces MTAs to include novel (to the MTA SMTP stack) technologies. A much simpler (and already common in MTAs) encoding would certainly suffice. I realize it is late in the evolution of the spec, but perhaps there is still time to reconsider. This is not critical, I'd likely have the transformation from JSON to something more natural happen in the software that imports data into the policy cache, so that the cache is more MTA friendly. Even if policy processing is out of the main MTA executable (Postfix is not monolithic like Sendmail or Exim) there is still a new JSON library dependency on the MTA package as a whole, and MTAs are part of base-system images for various operating system distributions (Postfix is part of "base" in NetBSD for example). So I really do think that JSON should be reconsidered. >> Here, it would be prudent to mention rfc6125, and be explicit about >> the acceptable wildcard patterns in that certificate. See, for = example: >>=20 >> https://tools.ietf.org/html/rfc7672#section-3.2.3 >>=20 >> which limits certificate wildcards to the entire first label only. I >> would like to avoid supporting more general wildcards in new >> specifications. >=20 > We specify this in 4.1 (as you discovered below), but maybe that's too = late. Repetition is good, not everyone reads each RFC from cover to cover. Try to make each section as self-contained as reasonably possible, or provide references to other relevant content where applicable. =20 >> The reference to rfc6125 is rather unfortunate here, since it defines >> semantics for presented identifiers, not reference identifiers. >=20 > If this field is used to validate the server certificate (and not > the MX hostnames) as you suggested above, that would entail validating > the presented identifier, which I think resolves your comment. So this draft should probably align with RFC7672 in permitting only full-label wildcards (*.example.com) and not partial-label wildcards (such as mail*.example.com) in presented identifiers of servers that publish STS policy. Separately, you should define the allowed wildcard forms for ("mx" or "san") and perhaps even consider allowing multi-label matches for those (another policy field?). Some domains have MX hosts like: mx01..example.com mx02..example.com mx01..example.com ... and might not want to "freeze" all the sites in the policy. They may be content with ".example.com" covering more than one label. >> Here, if the proposal to switch from "mx" to "san" is taken up, the >> peer certificate is no longer restricted to authenticate the MX = hostname, >> rather, one its presented identifiers needs to match one of the = reference >> identifiers fro the "san" policy attribute. Either way some = discussion >> is appropriate of how to perform matching when both the reference and >> the presented identifiers are "wildcards". >=20 > Ah, good point--this is a bit of additional complexity implied by your > suggested change. As explained above, if there's a switch to "san", the comparison of = "san" values is directly against the certificate, which introduces the = possibility of wildcard-to-wildcard comparison. > One option would be to merely disallow wildcards in the "mx" (or = "san") > field. That's probably too restrictive. If anything, I'd be more supportive in disallowing wildcards in the certificate! Certificate wildcards encourage poor practices (all eggs in one basket when the shared certificate fails, all the MX hosts fail, and wildcard certs enable redirection attacks between services that share the same certificate and application protocol, say HTTP). > Another: Specify our own matching rules for wildcards on both > identifiers. It's not really that complicated, but I don't favor > making people write this and possibly make mistakes. [ FWIW, already implemented in Postfix, http://www.postfix.org/postconf.5.html#smtp_tls_secure_cert_match ] >>> When a message fails to deliver due to an "enforce" policy, a >>> compliant MTA MUST check for the presence of an updated policy = at the >>> Policy Domain before permanently failing to deliver the message. >>> This allows implementing domains to update long-lived policies = on the >>> fly. >>=20 >> This seems to suggest the contrary, i.e. that it might be appropriate >> to bounce on policy failure when a more fresh policy still fails. >> However certificate problems (expiration most typically) are = transient, >> and a receiving system operator should/may notice the problem before >> outstanding messages expire and bounce. So I would urge implementors >> to queue, rather than bounce, on authentication failure. >=20 > Rather, the point of this was to encourage implemenors to _not_ bounce > until at least updating the policy once, not to encourage them to = bounce > _after_ such an update. So I think we agree, but the wording may be > suboptimal. Yes, please clarify. >>> Step 0: If the sending MTA is DANE-capable, the destination is >>> DNSSEC signed, and one or more of the MX hosts have DANE TLSA >>> records, then DANE TLSA preempts STS (more downgrade-resistant, >>> works on first contact, ...). >>=20 >> This is another reason to avoid STS-based MX filtering, with DNSSEC >> signed destinations the security of the MX records is sufficiently >> established, and we need to be able to proceed with DANE MX by MX, >> using STS policy only for MX hosts with no TLSA records. >=20 > With the suggested change to use STS only to validate the server > certificates and not to do MX filtering, this is obviated, no? I > don't really favor specifying whether senders should do an AND or > an OR in applying DANE and STS when both are present, and with > that change it no longer implies any incompatibilities in MX = selection. Well, this text goes away, and the decision moves down to the TLS handshake step, when deciding whether the host is adequately authenticated. I would argue that an STS policy of "report" should not preempt a non-soft-fail DANE policy. Note that DANE has one, perhaps non-obvious, "feature" in this space. When TLSA records are present, but are all "unusable", authentication is not enforced, but STARTTLS is still required. Thus, while the STS "report" mode also tolerates cleartext transmission, DANE TLSA with "unusable" TLSA records does not. Here too, I would not like to see STS "report" downgrade DANE to cleartext when both are published. Perhaps this draft need not be fully prescriptive about how the two mechanisms interact, but raising the issue is warranted, so that implementors make sensible decisions, and/or provide users with appropriate controls. >>> "max_age": 123456 >>=20 >> Note, the "max_age" here is barely over a day, which is not = consistent with >> the recommended policy lifetimes. Even "report" policies should = probably >> have better downgrade protection through longer lifetimes (say a week = or more). >=20 > I think that max_age was chosen because of the sequential nature of > the numbers and not its value. ;) But point taken. Add another digit or two, and you're set. An appealing looking number would be 90 days or 7776000 seconds. >> Should that be "complaint" or "compliant"? :-) I hope you'll fix the typo. --=20 Viktor. From nobody Wed Mar 22 12:50:33 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64257129C07 for ; Wed, 22 Mar 2017 12:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfQOhkrciFqF for ; Wed, 22 Mar 2017 12:50:29 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38B6C128BA2 for ; Wed, 22 Mar 2017 12:50:29 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id b140so71085739iof.1 for ; Wed, 22 Mar 2017 12:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=qysE1w/c04WcZDuyBpy+G0FVkIJ5yk+imGENVutE+00=; b=AuM+6SrDaR8z2y1qNXxfiv2zmLGsZSITPf7HOg9W/RI1G2wOj9MEqKCRwcd2cDZ9jh MoABEhltS6j0/m9ePFMgEV/3816s+gJqQ2C7T4dQqwqsBXcnLEZE7rq0DQaI2MZkx/Pu 49as4BPPV32cAkgOog9UgltdKVH0N1bV6VD9+RrEjm1OMCMQ27COveGhcp7vGSHvsP7a xfro35K79EGdB5zWDp17a1Ij3emgY265FutAPXskcDOpPM4qZovkUUG93AlSccE4F07X PuMu0R3PjP6EG757Osl3DTL8Cd40auvHn2RHoG1Rek4+zsrMpNCas7zW5JHFIakGacDL Ylkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=qysE1w/c04WcZDuyBpy+G0FVkIJ5yk+imGENVutE+00=; b=PHREKbC3Za42wcHvMVq/i5/ur0+eBJGekOU1idmqO+WMFKm01DLdkRaLETvG1sRGOx /nP7iOE+aNboSVXf1P/n/VEyG4ljd4Fq1HAcYe6LacmdgXOEUkoZ9dpcCpKPfBBUgiqG +p96AO3ui9950Fzl1R+OguG4MtDIcU++xzIoFIpZMJD6V8CRhlKYZ+WWDZ+maftWgtw9 hehcEomq5gbsfbgdg2FwcxMdjd4SerdFXhk7Or9cTU+Uz/dKdt2DJ+6YChQTosN6rdUm F9LoidEPbUErEywW+tgTzKrf63PyK9ytr6gCSZz/60RLjMkC/PxzVQlAYcrkk4N5TDTO 03YQ== X-Gm-Message-State: AFeK/H0oLpA61hcLDNgDSyiG/cL7asSLYgdJo0hO6AqzPRJFDURP86An8bVekUw6qb7zDiBaB7SC2xEnM7kqytpQ X-Received: by 10.107.33.68 with SMTP id h65mr6672111ioh.101.1490212227565; Wed, 22 Mar 2017 12:50:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.54.81 with HTTP; Wed, 22 Mar 2017 12:50:26 -0700 (PDT) In-Reply-To: <46C421CB-1189-4493-B322-5A214D6A6EE9@dukhovni.org> References: <4C0807DA-4852-4DAC-80ED-8A25371CFFAA@dukhovni.org> <46C421CB-1189-4493-B322-5A214D6A6EE9@dukhovni.org> From: Daniel Margolis Date: Wed, 22 Mar 2017 20:50:26 +0100 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1140f2c28245cc054b571256" Archived-At: Subject: Re: [Uta] MTA-STS-03 review X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 19:50:32 -0000 --001a1140f2c28245cc054b571256 Content-Type: multipart/alternative; boundary=001a1140f2c2773eec054b57127c --001a1140f2c2773eec054b57127c Content-Type: text/plain; charset=UTF-8 To be clear, I didn't reply to comments I thought were minor or needed no response. So I do agree on fixing the typo. ;) On Wed, Mar 22, 2017 at 8:18 PM, Viktor Dukhovni wrote: > > Thus, my point is that there are two type of names with potential > wildcards in this context. There are DNS SAN entries in certificates > (presented identifiers) whose semantics are (partly) defined in RFC6125. > RFC6125 leaves room for application-specific behaviour with respect to > CN-ID > and exactly which kinds of wild-cards, if any, are supported. Then > there are also "reference identifiers" which RFC6125 does not envision > as anything other than plain literals. > > This draft casually treats "mx" constraints as though they were presented > identifiers from the certificate certificate, and I think this could lead > to user confusion, but this could be explained by noting that both kinds > of patterns are compared against the MX hostname, and are then subject > to similar interpretation. > Right. I think it's _fairly_ simple as-is, since you're only ever matching against a hostname. More on this below. This is not critical, I'd likely have the transformation from > JSON to something more natural happen in the software that imports > data into the policy cache, so that the cache is more MTA friendly. > Even if policy processing is out of the main MTA executable (Postfix > is not monolithic like Sendmail or Exim) there is still a new JSON > library dependency on the MTA package as a whole, and MTAs are part > of base-system images for various operating system distributions > (Postfix is part of "base" in NetBSD for example). So I really > do think that JSON should be reconsidered. > Point taken. In our implementation it's all rapidly converted to protobuffers, anyway. But I'd appreciate feedback from the wider peanut gallery here, too. Parsing key/value pairs isn't hard, but do people prefer that (is there a standard parser?) versus taking a dependency on an existing JSON lib? Beats me--happy to hear from n>1 on it, though of course your voice is heavily weighted, Viktor. ;) > > If this field is used to validate the server certificate (and not > > the MX hostnames) as you suggested above, that would entail validating > > the presented identifier, which I think resolves your comment. > > So this draft should probably align with RFC7672 in permitting only > full-label wildcards (*.example.com) and not partial-label wildcards > (such as mail*.example.com) in presented identifiers of servers that > publish STS policy. Separately, you should define the allowed wildcard > forms for ("mx" or "san") and perhaps even consider allowing multi-label > matches for those (another policy field?). Some domains have MX hosts > like: > > mx01..example.com > mx02..example.com > mx01..example.com > ... > > and might not want to "freeze" all the sites in the policy. They > may be content with ".example.com" covering more than one label. > Right, as-is we did in fact specify only full-label and only left-most. I am unconvinced there are many cases where someone has "mx$n.$ siten.example.com" and cannot be content with "*.example.com"--if that's insufficient for them (because the example.com zone contains untrusted hosts), perhaps the MXs should be at "mail.example.com"; at risk of inducing necessary DNS changes, it seems worth it to preserve simplicity in the tricky matching rules. > >> Here, if the proposal to switch from "mx" to "san" is taken up, the > >> peer certificate is no longer restricted to authenticate the MX > hostname, > >> rather, one its presented identifiers needs to match one of the > reference > >> identifiers fro the "san" policy attribute. Either way some discussion > >> is appropriate of how to perform matching when both the reference and > >> the presented identifiers are "wildcards". > > > > Ah, good point--this is a bit of additional complexity implied by your > > suggested change. > > As explained above, if there's a switch to "san", the comparison of "san" > values is directly against the certificate, which introduces the > possibility > of wildcard-to-wildcard comparison. > > > One option would be to merely disallow wildcards in the "mx" (or "san") > > field. > > That's probably too restrictive. If anything, I'd be more supportive > in disallowing wildcards in the certificate! Certificate wildcards > encourage poor practices (all eggs in one basket when the shared > certificate fails, all the MX hosts fail, and wildcard certs > enable redirection attacks between services that share the same > certificate and application protocol, say HTTP). > > Another: Specify our own matching rules for wildcards on both > > identifiers. It's not really that complicated, but I don't favor > > making people write this and possibly make mistakes. > > [ FWIW, already implemented in Postfix, > http://www.postfix.org/postconf.5.html#smtp_tls_secure_cert_match ] > Yes, so you effectively limit it to wildcards in the leftmost label (if any). Which seems likely to work for anyone, and the matching is fairly easy. Yet it still means that instead of being able to merely validate against a hostname as in the Go API I linked to, implementors have to write _some_ heretofore nonexistent matching logic. If we restrict it to RFC 7672's section 3.2.3 logic, it's equivalent to the per-MX logic we already specified (I think), so no harder for implementors (as long as their TLS library exposes that, which it ought to). Anything more complex seems like it could lead to bugs. > >>> When a message fails to deliver due to an "enforce" policy, a > >>> compliant MTA MUST check for the presence of an updated policy at > the > >>> Policy Domain before permanently failing to deliver the message. > >>> This allows implementing domains to update long-lived policies on > the > >>> fly. > >> > >> This seems to suggest the contrary, i.e. that it might be appropriate > >> to bounce on policy failure when a more fresh policy still fails. > >> However certificate problems (expiration most typically) are transient, > >> and a receiving system operator should/may notice the problem before > >> outstanding messages expire and bounce. So I would urge implementors > >> to queue, rather than bounce, on authentication failure. > > > > Rather, the point of this was to encourage implemenors to _not_ bounce > > until at least updating the policy once, not to encourage them to bounce > > _after_ such an update. So I think we agree, but the wording may be > > suboptimal. > > Yes, please clarify. > > Note that DANE has one, perhaps non-obvious, "feature" in this space. > When TLSA records are present, but are all "unusable", authentication > is not enforced, but STARTTLS is still required. Thus, while the STS > "report" mode also tolerates cleartext transmission, DANE TLSA with > "unusable" TLSA records does not. Here too, I would not like to see > STS "report" downgrade DANE to cleartext when both are published. > I think that would be a buggy implementation! It doesn't make sense to me that someone who implements both would treat it as an OR, especially if STS is in "report" mode. So it's fair to call this out, certainly, but I think the concern is (hopefully) unwarranted--the point of STS is most decidedly not to override any existing TLSA records, nor would that make any sense. > Perhaps this draft need not be fully prescriptive about how the > two mechanisms interact, but raising the issue is warranted, so > that implementors make sensible decisions, and/or provide users > with appropriate controls. > I'm happy to suggest people not allow STS to override DANE. --001a1140f2c2773eec054b57127c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To be clear, I didn't reply to comments I thought were= minor or needed no response. So I do agree on fixing the typo. ;)=C2=A0

On Wed, Mar 22, = 2017 at 8:18 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:

Thus, my point is that there are two type of names with potential
wildcards in this context.=C2=A0 There are DNS SAN entries in certificates<= br> (presented identifiers) whose semantics are (partly) defined in RFC6125. RFC6125 leaves room for application-specific behaviour with respect to CN-I= D
and exactly which kinds of wild-cards, if any, are supported.=C2=A0 Then there are also "reference identifiers" which RFC6125 does not env= ision
as anything other than plain literals.

This draft casually treats "mx" constraints as though they were p= resented
identifiers from the certificate certificate, and I think this could lead to user confusion, but this could be explained by noting that both kinds of patterns are compared against the MX hostname, and are then subject
to similar interpretation.

Right. I thi= nk it's _fairly_ simple as-is, since you're only ever matching agai= nst a hostname. More on this below.=C2=A0

This is not critical, I'd likely have the transformation from
JSON to something more natural happen in the software that imports
data into the policy cache, so that the cache is more MTA friendly.
Even if policy processing is out of the main MTA executable (Postfix
is not monolithic like Sendmail or Exim) there is still a new JSON
library dependency on the MTA package as a whole, and MTAs are part
of base-system images for various operating system distributions
(Postfix is part of "base" in NetBSD for example).=C2=A0 So I rea= lly
do think that JSON should be reconsidered.

<= div>Point taken. In our implementation it's all rapidly converted to pr= otobuffers, anyway.=C2=A0

But I'd appreciate f= eedback from the wider peanut gallery here, too. Parsing key/value pairs is= n't hard, but do people prefer that (is there a standard parser?) versu= s taking a dependency on an existing JSON lib? Beats me--happy to hear from= n>1 on it, though of course your voice is heavily weighted, Viktor. ;)= =C2=A0
=C2=A0
> If this field is used to validate the server certificate (and not
> the MX hostnames) as you suggested above, that would entail validating=
> the presented identifier, which I think resolves your comment.

So this draft should probably align with RFC7672 in permitting only<= br> full-label wildcards (*.example.com) and not partial-label wildcards
(such as mail*.example.com) in presented identifiers of servers that
publish STS policy.=C2=A0 Separately, you should define the allowed wildcar= d
forms for ("mx" or "san") and perhaps even consider all= owing multi-label
matches for those (another policy field?).=C2=A0 Some domains have MX hosts=
like:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 mx01.<site1>.example.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mx02.<site1>.example.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mx01.<site2>.example.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...

and might not want to "freeze" all the sites in the policy.=C2=A0= They
may be content with ".example.com" covering more than one label.
=

Right, as-is we did in fact specify only f= ull-label and only left-most. I am unconvinced there are many cases where s= omeone has "mx$n.$siten.example.c= om" and cannot be content with "*.example.com"--if that's insufficient for them (because the= example.com zone contains untrusted hos= ts), perhaps the MXs should be at =C2=A0"mail.example.com"; at risk of inducing necessary DNS change= s, it seems worth it to preserve simplicity in the tricky matching rules.= =C2=A0
=C2=A0
>> Here, if the proposal to switch from "mx" to "san&q= uot; is taken up, the
>> peer certificate is no longer restricted to authenticate the MX ho= stname,
>> rather, one its presented identifiers needs to match one of the re= ference
>> identifiers fro the "san" policy attribute.=C2=A0 Either= way some discussion
>> is appropriate of how to perform matching when both the reference = and
>> the presented identifiers are "wildcards".
>
> Ah, good point--this is a bit of additional complexity implied by your=
> suggested change.

As explained above, if there's a switch to "san", the = comparison of "san"
values is directly against the certificate, which introduces the possibilit= y
of wildcard-to-wildcard comparison.

> One option would be to merely disallow wildcards in the "mx"= (or "san")
> field.

That's probably too restrictive.=C2=A0 If anything, I'd be m= ore supportive
in disallowing wildcards in the certificate!=C2=A0 Certificate wildcards encourage poor practices (all eggs in one basket when the shared
certificate fails, all the MX hosts fail, and wildcard certs
enable redirection attacks between services that share the same
certificate and application protocol, say HTTP).=C2=A0

> Another: Specify our own matching rules for wildcards on both
> identifiers. It's not really that complicated, but I don't fav= or
> making people write this and possibly make mistakes.

[ FWIW, already implemented in Postfix,
=C2=A0 http://www.postfix.org/= postconf.5.html#smtp_tls_secure_cert_match ]
=
Yes, so you effectively limit it to wildcards in the leftmos= t label (if any). Which seems likely to work for anyone, and the matching i= s fairly easy.=C2=A0

Yet it still means that inste= ad of being able to merely validate against a hostname as in the Go API I l= inked to, implementors have to write _some_ heretofore nonexistent matching= logic. If we restrict it to RFC 7672's section=C2=A03.2.3 logic, it= 9;s equivalent to the per-MX logic we already specified (I think), so no ha= rder for implementors (as long as their TLS library exposes that, which it = ought to). Anything more complex seems like it could lead to bugs.=C2=A0
=C2=A0
>>>=C2=A0 =C2=A0 =C2=A0When a message fails to deliver due to an &= quot;enforce" policy, a
>>>=C2=A0 =C2=A0 =C2=A0compliant MTA MUST check for the presence o= f an updated policy at the
>>>=C2=A0 =C2=A0 =C2=A0Policy Domain before permanently failing to= deliver the message.
>>>=C2=A0 =C2=A0 =C2=A0This allows implementing domains to update = long-lived policies on the
>>>=C2=A0 =C2=A0 =C2=A0fly.
>>
>> This seems to suggest the contrary, i.e. that it might be appropri= ate
>> to bounce on policy failure when a more fresh policy still fails.<= br> >> However certificate problems (expiration most typically) are trans= ient,
>> and a receiving system operator should/may notice the problem befo= re
>> outstanding messages expire and bounce.=C2=A0 So I would urge impl= ementors
>> to queue, rather than bounce, on authentication failure.
>
> Rather, the point of this was to encourage implemenors to _not_ bounce=
> until at least updating the policy once, not to encourage them to boun= ce
> _after_ such an update. So I think we agree, but the wording may be > suboptimal.

Yes, please clarify.

Note that DANE has one, perhaps non-obvious, "feature" in this sp= ace.
When TLSA records are present, but are all "unusable", authentica= tion
is not enforced, but STARTTLS is still required.=C2=A0 Thus, while the STS<= br> "report" mode also tolerates cleartext transmission, DANE TLSA wi= th
"unusable" TLSA records does not.=C2=A0 Here too, I would not lik= e to see
STS "report" downgrade DANE to cleartext when both are published.=

I think that would be a buggy implemen= tation! It doesn't make sense to me that someone who implements both wo= uld treat it as an OR, especially if STS is in "report" mode. So = it's fair to call this out, certainly, but I think the concern is (hope= fully) unwarranted--the point of STS is most decidedly not to override any = existing TLSA records, nor would that make any sense.=C2=A0
=C2= =A0
Perhaps this draft need not be fully prescriptive about how the
two mechanisms interact, but raising the issue is warranted, so
that implementors make sensible decisions, and/or provide users
with appropriate controls.

I'm happ= y to suggest people not allow STS to override DANE.=C2=A0

--001a1140f2c2773eec054b57127c-- --001a1140f2c28245cc054b571256 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+ q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0 TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg 5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27 8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCB8KVuNpBWGcwtY bcQmcoK+siFoozkYpYXEPhh1kQBuAzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAzMjIxOTUwMjhaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAFW31xUuUb9m75fUGYLRlqkJtnvq/pAXa M7o/vCDPKFwVdArMpEApFviHezgDsCAOrvnHgCtKjm1V85AMvXExwSRsDDh7UtvEJvriMQ2KUiee snoGYUr6D+rjXu+TUj1KL/qo1c24/vxckJElZqwdk0AWRqaBcfYj2MSfaxzkhwtqiSuNDlUmAaR+ y5ScqT3gBKwdIdQZhv/FGx5pZWM4X5I86r0HOIYybzKbXDlYVGjq7mQj0FUfDfpivvukioy3FtdB gx7mVeSBjpo/gC4ZhCKi3nzgPu5N+R/IC9VoYQVQBfzP/sbvPKE2YckhzMyZ5o9GYA6bLLi7GVZM X1qyvg== --001a1140f2c28245cc054b571256-- From nobody Wed Mar 22 13:28:42 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4754128BB6 for ; Wed, 22 Mar 2017 13:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1E_mjeifdXC for ; Wed, 22 Mar 2017 13:28:39 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3A7F12894A for ; Wed, 22 Mar 2017 13:28:38 -0700 (PDT) Received: from [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_RC100) id 1cqmrz-0000j8-JX for uta@ietf.org (return-path ); Wed, 22 Mar 2017 20:28:35 +0000 To: uta@ietf.org References: <4C0807DA-4852-4DAC-80ED-8A25371CFFAA@dukhovni.org> <46C421CB-1189-4493-B322-5A214D6A6EE9@dukhovni.org> From: Jeremy Harris Message-ID: <709db615-1750-bd31-f7e8-af1372673260@wizmail.org> Date: Wed, 22 Mar 2017 20:28:34 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Uta] MTA-STS-03 review X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 20:28:41 -0000 On 22/03/17 19:50, Daniel Margolis wrote: > But I'd appreciate feedback from the wider peanut gallery here, too. > Parsing key/value pairs isn't hard, but do people prefer that (is there a > standard parser?) versus taking a dependency on an existing JSON lib? >From the Exim developer's point of view, I much prefer name/value pairs since we have existing code doing that. We don't have any JSON and having to add some would be one more barrier against implementing STS. -- Cheers, Jeremy From nobody Fri Mar 24 10:00:33 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0286A127337 for ; Fri, 24 Mar 2017 10:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzRUsXbWRYoi for ; Fri, 24 Mar 2017 10:00:26 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC96127078 for ; Fri, 24 Mar 2017 10:00:26 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id y18so14637856itc.0 for ; Fri, 24 Mar 2017 10:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=URZM5vXKdFt0jLhAilwZ46Pe5D5wLlMxIryu4iEgAEY=; b=fLwAqsUMFmXvSvJI6jN5BFv6xygjQnaRExbt1Jh0wTvDAwdT2JBMj7Da3mOK7oZMLW /RPe0RGTJo8+A9MmXlbY3qkwpXvVfbsUX9/wrvvwVcrmbxtuT/LTeij8lnIMGeWdSYMt PCCAAjOwj/N4m0fYQ859J2ewLvFMiixXwyzJcCwSF5t1t9g1G3bxseo03tdbuhW+A7O1 4b0meYNgO2fajI+SIhL+o0OmY+RqYR+JfHls8NqXxvp59F6OSlcqxGdhEHCTJ9aZnpOc 7v0ViMYSdmIjxxRYMeIo3Nvb2DsWfxoiifR4axUx4EuoaNcIGEDb/4hnSCr69YoEA8MI CwbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=URZM5vXKdFt0jLhAilwZ46Pe5D5wLlMxIryu4iEgAEY=; b=cR8H58INlif3W7Dk501ynWCwlGmaHyfZOqdF3+WTfeNtGa0v6x+vf6I3AJCy21gGM8 INNEqzBswUea4zDXyY2gLstZldynPRS2QX13lR88TdKUGEYNStef1vCZs98wbBmn+rgs jwNymti4qZM46FzYfDygo6/l0jjbwbL/BPi+NPHTC0CQ6D31N26oMeRrGsSpdgtq/WEc fet+Stvk+XVd5V5YMx+qhBXUrHVHx0L63A9h4dBz1g3W2klOlWLJ3l99yffJ4cNGvon7 YZW0e10dhdHgjpRASQvaHjDhfR3E3u2y7qAZruWmGYgRp1qD8WzDlLzte/ji13S48PEO +zOg== X-Gm-Message-State: AFeK/H15lrAKHXH4STn0DjCYKUSUqp7ae5BADAHl1vkn4J7mIKpsfEegQHY5iZNDts5qf+hQ9WK/E/+3o3grApPJ X-Received: by 10.36.80.213 with SMTP id m204mr3840840itb.105.1490374825018; Fri, 24 Mar 2017 10:00:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.39.215 with HTTP; Fri, 24 Mar 2017 10:00:23 -0700 (PDT) In-Reply-To: <4C0807DA-4852-4DAC-80ED-8A25371CFFAA@dukhovni.org> References: <4C0807DA-4852-4DAC-80ED-8A25371CFFAA@dukhovni.org> From: Daniel Margolis Date: Fri, 24 Mar 2017 18:00:23 +0100 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1145f2fa139ec2054b7ceefa" Archived-At: Subject: Re: [Uta] MTA-STS-03 review X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 17:00:32 -0000 --001a1145f2fa139ec2054b7ceefa Content-Type: multipart/alternative; boundary=001a1145f2fa07ae04054b7cee5b --001a1145f2fa07ae04054b7cee5b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > > 6.1. Policy Updates > > > > Updating the policy requires that the owner make changes in two > > places: the "mta-sts" TXT record in the Policy Domain's DNS zone and > > at the corresponding HTTPS endpoint. In the case where the HTTPS > > endpoint has been updated but the TXT record has not yet been, > > senders will not know there is a new policy released and may thus > > continue to use old, previously cached versions. Recipients should > > thus expect a policy will continue to be used by senders until both > > the HTTPS and TXT endpoints are updated and the TXT record's TTL has > > passed. > The lifetime could be longer. Some MTAs may initiate *background* refres= h > of unexpired policies after the DNS TXT record is found to have changed, > which may not happen until the first message to the destination is sent > after that change, and *that* message may well go out based on the alread= y > cached policy while the refresh is in process. If the policy no longer > matches reality, the message may be deferred, and would perhaps succeed > on retry with a more current policy. > So the TXT record will not guarantee refresh in any particular timeframe. > If no mail is sent to the destination, the policy may expire unused despi= te > the TXT record change. I'm no longer sure what this section was meant to convey. If I switch my policy from policy A to policy B at time t1, anyone may nonetheless continue to use policy A up until t1 + max_age_A, but no longer, regardless of when they fetched it. Policies *must not* be used longer than max_age past the last time they were actually being served. The DNS TTL doesn't really come into it. I think we added this section to try to clarify a different case (not relating to max_age): when publishing a new policy (B), people may continue to use A *and not try to get B even on failure* for the duration of the TTL (because checking the TXT record will not indicate that there is in fact a new policy). So I will clarify that part. On Wed, Mar 22, 2017 at 6:04 AM, Viktor Dukhovni wrote: > > [ I've pasted in the entire draft, and "quoted" it as though it > were a post to trim an reply to. ] > > > SMTP MTA Strict Transport Security (MTA-STS) > > draft-ietf-uta-mta-sts-03 > > > > Abstract > > > > SMTP Mail Transfer Agent Strict Transport Security (SMTP STS) is a > > mechanism enabling mail service providers to declare their ability t= o > > receive TLS-secured connections and an expected validity of > > certificates presented by their MX hosts, and to specify whether > > sending SMTP servers should refuse to deliver to MX hosts that do no= t > > offer TLS with a trusted server certificate. > > In the abstract I think that "TLS-secured" already covers certificate > validity (which makes for a clumsy insertion into the text anyway). > Also instead of "TLS-secured connections" say "TLS-secure SMTP > connections". > > See https://www.rfc-editor.org/materials/abbrev.expansion.txt for the > list of common IETF acronyms, and which are sufficiently widely used > to not need to be expanded on first use. Thus SMTP and ESMTP are fine > with expansion, but apparently we've not yet reached similar familiarity > with TLS. :-) > > > 1. Introduction > > > > The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and > > hosts to negotiate the use of a TLS channel for secure mail > > transmission. > > I would drop "secure" above, or replace it with "encrypted". > > > > While such _opportunistic_ encryption protocols provide a high > > While "_" may work as italics in MarkDown, you'll need to change all > these to RFC XML (where IIRC ... may be supported, but don't > take my word for it, check). > > More importantly, you've made quite a leap here from talking about > RFC 3207, which merely defines an SMTP extension mechanism, to assuming > that the reader knows how the extension is typically used. It also > important to recall that opportunistic security (as defined in RFC7435) > subsumes both MTA best-effort unauthenticated encryption, and the new > opportunistically authenticated DANE and STS use-cases. With DANE and > STS transmission is protected only when and as receiving system publishes > the requisite policy records. DANE offers stronger downgrade protection, > at the cost of requiring DNSSEC to achieve that goal. > > > barrier against passive man-in-the-middle traffic interception, > > therefore the "passive-only" protection is a feature of unauthenticated > opportunistic security, as practiced by most MTAs at present. > > > This document defines a mechanism for recipient domains to publish > > policies specifying: > > > > o whether MTAs sending mail to this domain can expect TLS support > > > > o expected validity of server certificates presented by the domain'= s > > MX hosts > > It seems to me that STS does not provide any means to signal > unauthenticated TLS support. And so, as in the abstract, the > above two bullets are really just one, "WebPKI TLS security". > > > 1.1. Terminology > > > > We also define the following terms for further use in this document: > > > > o STS Policy: A committment by the Policy Domain to support PKIX > > authenticated TLS for the specified MX hosts. > > Which I think confirms my point about "authenticated TLS" as the > only available commitment. > > > o Policy Domain: The domain for which an STS Policy is defined. > > (For example, when sending mail to "alice@example.com", the polic= y > > domain is "example.com".) > > Perhaps this should mention that more generally this is the nexthop > domain for SMTP delivery, and when mail routing is pre=C3=ABmpted by > by explicit relays via local policy, the Policy domain is the > domain name of the explicit relay (prior to any MX lookups if > applicable). > > > o Policy Authentication: Authentication of the STS policy retrieved > > for a recipient domain by the sender. > > This definition seems all too circular. What does it actually mean? > > > 2. Related Technologies > > > > The DANE TLSA record [RFC7672] is similar, in that DANE is also > > designed to upgrade opportunistic, unauthenticated encryption into > > required, authenticated encryption. > > Opportunistic DANE TLS upgrades unauthenticated encryption or even > cleartext delivery to downgrade-resistant authenticated TLS. (Side > note, not for the draft, for actually non-opportunistic TLS see > Jim Fenton's REQUIRETLS proposal). STS aims to do the same, but > without requiring TLS at the cost of losing some downgrade protection. > > > DANE requires DNSSEC [RFC4033] > > for authentication; the mechanism described here instead relies on > > certificate authorities (CAs) and does not require DNSSEC. For a > > thorough discussion of this trade-off, see the section _Security_ > > _Considerations_. > > The Security Considerations section (once again this is not MarkDown) > will need to properly discuss the downgrade exposure of STS on first > contact, and this trade-off probably should be mentioned here up-front. > > > In addition, SMTP STS provides an optional report-only mode, enablin= g > > soft deployments to detect policy failures. > > It is easy to define a couple of new "certificate usage" code-points > for DANE that similarly signal "soft-fail" (with reporting). Would > the group strongly support a draft along those lines? I am not sure > that a merely "tamper-evident" operating mode is a good idea as a > persistent operating state, and I think that the ability to have > one or more (backup, i.e. worse preference) MX hosts without TLSA > records adequately addresses the need for incremental deployment. > > > 3. Policy Discovery > > > > To discover if a recipient domain implements MTA-STS, a sender need > > only resolve a single TXT record. To see if an updated policy is > > available for a domain for which the sender has a previously cached > > policy, the sender need only check the TXT record's version "id" > > against the cached value. > > Given earlier discussion on the list, while new "id" values can give > expedited signals to refresh the policy, it may be appropriate here, > (but perhaps later in the document as you see fit) to describe a > recommended approach to proactively refresh policies prior to their > pending expiration, this reduces the probability of "gaps" in policy > coverage if the remote HTTPS service is unavailable just as a policy > is expiring. > > In practice (say in Postfix, if/when STS is implemented) I wouldn't > go looking through the cache for policies to refresh except when > delivering mail to the destination in question. I don't want the > cache to become a roach motel for policies to destinations I never > again send mail to. If communication with a destination ceases > completely, it is not unreasonable to let its STS policy simply > age out. Google et. al. may of course choose indefinite data > retension (data retentiveness is Google's business), but for > SOHO and enterprise MTAs, the above may be more appropriate. > > > 3.2. MTA-STS Policies > > > > This JSON object contains the following key/value pairs: > > > > o "version": (plain-text, required). Currently only "STSv1" is > > supported. > > > > o "mode": (plain-text, required). Either "enforce" or "report", > > indicating the expected behavior of a sending MTA in the case of = a > > policy validation failure. > > > > o "max_age": Max lifetime of the policy (plain-text non-negative > > integer seconds, required). Well-behaved clients SHOULD cache a > > policy for up to this value from last policy fetch time. To > > mitigate the risks of attacks at policy refresh time, it is > > expected that this value typically be in the range of weeks or > > greater. > > A more comprehensive mitigation for attacks "at policy refresh time" > would entail not just a long lifetime, but proactive refresh as mentioned > above. > > > o "mx": MX patterns (list of plain-text MX match strings, required)= . > > One or more patterns matching the expected MX for this domain. > > For example, "["*.example.com", "*.example.net"]" indicates that > > mail for this domain might be handled by any MX with a hostname a= t > > "example.com" or "example.net". Valid patterns can be either > > hostname literals (e.g. "mx1.example.com") or wildcard matches, s= o > > long as the wildcard occupies the full left-most label in the > > pattern. (Thus "*.example.com" is valid but "mx*.example.com" is > > not.) > > Here, as discussed on the list, serious consideration should be given > to changing the semantics from validating the MX hostname to specifying > the names allowed in the server's certificate. This simplifies MX > processing > (which remains unmodified) and merely changes the conditions under which = an > MX host is considered suitably authenticated per the policy. > > Which, for example, allows the MX hosts to share a single certificate > with the destination domain (and not the MX hostname) as its DNS SAN. > If the policy lists that (shared) name as what's expected in the > certificate, > then authentication succeeds when the MX host's certificate matches one o= f > the allowed names. > > It should be made clear that the names here are always in A-label form > and not U-label form (as they also are in DNS names in certificates). > > Furthermore, I think that using "*.example.com" in what are essentially > (rfc6125) reference identifiers creates confusion with similar-looking, b= ut > semantically distinct wildcard names in certificates. My suggestion was > ".example.com" for sub-domain matching, with the policy optionally > specifying > whether only single-label prefixes are accepted, or whether in fact > multi-label > prefixes are also valid. > > > An example JSON policy is as below: > > > > { > > "version": "STSv1", > > "mode": "enforce", > > "mx": ["*.mail.example.com"], > > "max_age": 123456 > > } > > FWIW, I would have chosen something less fancy than JSON for > what is clearly a simple array of attribute/value pairs. ESMTP > already encodes such optional A/V pairs as space separated lists > of attr=3Dvalue with xtext encoding as needed (it is not needed for > any plausible value of the above attributes). > > We're not going to add a JSON decoder to the Postfix SMTP client, > but if this specification retains JSON, then the code that does > background policy retrieval will need to transform JSON into > something more friendly to traditional C-based MTA implementations. > > > 4. Policy Validation > > Are we validating the policy or using the policy to authenticate > the MX host? I think the name of this section is suboptimal. > > > When sending to an MX at a domain for which the sender has a valid > > and non-expired SMTP MTA-STS policy, a sending MTA honoring SMTP STS > > MUST validate: > > s/validate/check/ or /ensure/. > > > 1. That the recipient MX matches the "mx" pattern from the recipien= t > > domain's policy. > > See above, perhaps "mx" becomes "san" and the check is deferred until > it is time to verify the host's certificate. > > > 2. That the recipient MX supports STARTTLS and offers a valid PKIX > > based TLS certificate. > > Here, it would be prudent to mention rfc6125, and be explicit about > the acceptable wildcard patterns in that certificate. See, for example: > > https://tools.ietf.org/html/rfc7672#section-3.2.3 > > which limits certificate wildcards to the entire first label only. I > would like to avoid supporting more general wildcards in new > specifications. > > > This section does not dictate the behavior of sending MTAs when > > policies fail to validate; in particular, validation failures of > > policies which specify "report" mode MUST NOT be interpreted as > > delivery failures, as described in the section _Policy_ > > _Application_. > > The first sentence is unfortunate, you are in fact specifying behaviour, > in the very next sentence. It might be better to add a forward-reference > to a section that provides a detailed explanation and not start with a > disclaimer. > > > 4.1. MX Matching > > > > When delivering mail for the Policy Domain to a recipient MX host, > > the sender validates the MX match against the "mx" pattern from the > > applied policy. The semantics for these patterns are those found in > > section 6.4 of [RFC6125]. > > Assuming this text survives, replace: > > validates the MX match against the "mx" pattern > > with something like > > ensures that the MX host name is consistent with the "mx" > property of the STS policy (only matching MX hosts are > used in delivery attempts). > > The reference to rfc6125 is rather unfortunate here, since it defines > semantics for presented identifiers, not reference identifiers. > > > 4.2. MX Certificate Validation > > > > The certificate presented by the receiving MX MUST be valid for the > > MX hostname and chain to a root CA that is trusted by the sending > > MTA. The certificate MUST have a CN or SAN matching the MX hostname > > (as described in [RFC6125]) and be non-expired. > > Here, if the proposal to switch from "mx" to "san" is taken up, the > peer certificate is no longer restricted to authenticate the MX hostname, > rather, one its presented identifiers needs to match one of the reference > identifiers fro the "san" policy attribute. Either way some discussion > is appropriate of how to perform matching when both the reference and > the presented identifiers are "wildcards". > > > 5. Policy Application > > This is an appropriate target for the afore-mentioned forward-reference. > > > When sending to an MX at a domain for which the sender has a valid, > > non-expired STS policy, a sending MTA honoring SMTP STS applies the > > result of a policy validation one of two ways, depending on the valu= e > > of the policy "mode" field: > > > > 1. "report": In this mode, sending MTAs merely send a report (as > > described in the TLSRPT specification (TODO: add ref)) indicatin= g > > policy application failures. > > > > 2. "enforce": In this mode, sending MTAs treat STS policy failures > > as a mail delivery error, and MUST NOT deliver the message to > > this host. > > We should not confuse "delivery error" with "authentication failure". > When one MX host fails authentication, the next MX host should be > tried. And, I think it should be mentioned that if all the MX > hosts (that the sender is willing to try) fail authentication, the > message should be deferred, not bounced. > > > When a message fails to deliver due to an "enforce" policy, a > > compliant MTA MUST check for the presence of an updated policy at th= e > > Policy Domain before permanently failing to deliver the message. > > This allows implementing domains to update long-lived policies on th= e > > fly. > > This seems to suggest the contrary, i.e. that it might be appropriate > to bounce on policy failure when a more fresh policy still fails. > However certificate problems (expiration most typically) are transient, > and a receiving system operator should/may notice the problem before > outstanding messages expire and bounce. So I would urge implementors > to queue, rather than bounce, on authentication failure. > > > 5.1. MX Preference > > This section would go if a switch from "mx" to "san" takes place. > > > 5.2. Policy Application Control Flow > > > > An example control flow for a compliant sender consists of the > > following steps: > > Step 0: If the sending MTA is DANE-capable, the destination is > DNSSEC signed, and one or more of the MX hosts have DANE TLSA > records, then DANE TLSA preempts STS (more downgrade-resistant, > works on first contact, ...). > > This is another reason to avoid STS-based MX filtering, with DNSSEC > signed destinations the security of the MX records is sufficiently > established, and we need to be able to proceed with DANE MX by MX, > using STS policy only for MX hosts with no TLSA records. > > > 1. Check for a cached policy whose time-since-fetch has not exceede= d > > its "max_age". If none exists, attempt to fetch a new policy. > > (Optionally, sending MTAs may unconditionally check for a new > > policy at this step.) > > Is "attempt to fetch" well understood at this point? The attempt only > happens if the DNS TXT record is in place... > > > 2. Filter candidate MXs against the current policy. > > See "san" vs. "mx" issue above. Also proceed with non-STS delivery > absent any policy. > > > 3. If no candidate MXs are valid and the policy mode is "enforce", > > temporarily fail the message. (Otherwise, generate a failure > > report but deliver as though MTA STS were not implemented.) > > Ditto. > > > 4. For each candidate MX, in order of MX priority, attempt to > > deliver the message, enforcing STARTTLS and the MX host's PKIX > > certificate validation. > > Well, no so much enforcing as performing, authentication may be allowed > to fail in "report" mode. And of course only if there is an STS policy > to use. > > > 5. Upon message retries, a message MAY be permanently failed > > following first checking for the presence of a new policy (as > > indicated by the "id" field in the "mta-sts" TXT record). > > I think this is a mistake. Please do not turn transient errors into > permanent failures. > > > 6.1. Policy Updates > > > > Updating the policy requires that the owner make changes in two > > places: the "mta-sts" TXT record in the Policy Domain's DNS zone and > > at the corresponding HTTPS endpoint. In the case where the HTTPS > > endpoint has been updated but the TXT record has not yet been, > > senders will not know there is a new policy released and may thus > > continue to use old, previously cached versions. Recipients should > > thus expect a policy will continue to be used by senders until both > > the HTTPS and TXT endpoints are updated and the TXT record's TTL has > > passed. > > The lifetime could be longer. Some MTAs may initiate *background* refres= h > of unexpired policies after the DNS TXT record is found to have changed, > which may not happen until the first message to the destination is sent > after that change, and *that* message may well go out based on the alread= y > cached policy while the refresh is in process. If the policy no longer > matches reality, the message may be deferred, and would perhaps succeed > on retry with a more current policy. > > So the TXT record will not guarantee refresh in any particular timeframe. > If no mail is sent to the destination, the policy may expire unused despi= te > the TXT record change. > > > 8. Security Considerations > > > > Since we use DNS TXT records for policy discovery, an attacker who i= s > > able to block DNS responses can suppress the discovery of an STS > > Policy, making the Policy Domain appear not to have an STS Policy. > > The sender policy cache is designed to resist this attack. > > Well, not "resist" so much as reduce the effectiveness, since it will > now only be effective on first contact, or perhaps when no mail is sent > to the destination for a long time and the cached policy expired. > > > We additionally consider the Denial of Service risk posed by an > > attacker who can modify the DNS records for a victim domain. Absent > > SMTP STS, such an attacker can cause a sending MTA to cache invalid > > MX records for a long TTL. With SMTP STS, the attacker can > > additionally advertise a new, long-"max_age" SMTP STS policy with > > "mx" constraints that validate the malicious MX record, causing > > senders to cache the policy and refuse to deliver messages once the > > victim has resecured the MX records. > > Many DNS resolvers have sensible upper-bounds on record TTLs. It the > attacker can obtain a certificate for the victim domain, they may > indeed inject a long-lived policy, but the TXT record affords the > victim the opportunity of recovery. This paragraph needs work. > > Finally, some discussion is appropriate of the fact that given weaker > downgrade-resistance of STS viz. DANE, implementations that support > both should apply DANE first and STS only in its absence. Indeed with > the MX RRset validated via DNSSEC the "mx" policy element is not really > needed to prevent MX record forgery, however that depends on the outcome > of the "mx" vs. "san" discussion. > > There should probably be a recommendation that sending systems implement > DANE in addition to STS. It is much easier to use a validating resolver > than to sign one's own domain, and so the barrier to option of outbound > DANE is significantly lower. I'll have some additional implementation > news to report shortly... > > > 10.1. Example 1 > > > > The owner of "example.com" wishes to begin using STS with a policy > > that will solicit reports from receivers without affecting how the > > messages are processed, in order to verify the identity of MXs that > > handle mail for "example.com", confirm that TLS is correctly used, > > and ensure that certificates presented by the recipient MX validate. > > > > STS policy indicator TXT RR: > > > > mta-sts.example.com. IN TXT "v=3DSTSv1; id=3D20160831085700Z;" > > > > STS Policy JSON served as the response body at [1] > > > > { > > "version": "STSv1", > > "mode": "report", > > "mx": ["mx1.example.com", "mx2.example.com"], > > "max_age": 123456 > > } > > Note, the "max_age" here is barely over a day, which is not consistent wi= th > the recommended policy lifetimes. Even "report" policies should probably > have better downgrade protection through longer lifetimes (say a week or > more). > > > 11. Appendix 2: Message delivery pseudocode > > > > Below is pseudocode demonstrating the logic of a complaint sending > > MTA. This implements the "two-pass" approach, first attempting > > delivery with a newly fetched policy (if present) before falling bac= k > > to a cached policy (if present). > > Should that be "complaint" or "compliant"? :-) I would expect that > sane implementations will use cached policies first, and only both > refreshes based on TXT record changes or refresh timers, with updates > in the background. Synchronous updates of policy at message delivery > time are exceedingly unappealing at least to me. > > > func certMatches(connection, mx) { > > // Return if the server certificate from "connection" matches the "mx= " > host. > > This could use a detailed discussion of what "matches" means, or a > back-reference to a section that does. Covering wildcard use in > either or both of the reference and presented identifiers, and > possible additional text if "mx" becomes "san". > > > func getMxsForPolicy(domain, policy) { > > // Sort the MXs by priority, filtering out those which are invalid > according > > // to "policy". > > } > > [ "mx" vs. "san" ] > > > func tryGetNewPolicy(domain) { > > // Check for an MTA STS TXT record for "domain" in DNS, and return th= e > > // indicated policy (or a local cache of the unvalidated policy). > > } > > The DNS lookup may succeed, and the HTTPS lookup may tempfail, what > happens in that case? What happens with an authenticated 404 HTTPS > response? Let's avoid "unvalidated" here, or else avoid its use > in the context of "peer authentication". > > > func cachePolicy(domain, policy) { > > // Store "policy" as the cached policy for "domain". > > } > > Along with the policy one should generally store the time > at which it was last retrieved, and the time of any unsuccessful > refresh attempts since then. This supports both eventual > expiration, and proactive refresh, with multiple retries, as > the policy approaches expiration. > > > func tryMxAccordingTo(message, mx, policy) { > > connection :=3D connect(mx) > > if !connection { > > return false // Can't connect to the MX so it's not an STS error. > > } > > status :=3D !(tryStartTls(mx, &connection) && certMatches(connection, > mx)) > > status =3D true > > What's happening with "status" here? I think the first assignment goes..= . > > > if !tryStartTls(mx, &connection) { > > status =3D false > > reportError(E_NO_VALID_TLS) > > } else if certMatches(connection, mx) { > > Missing negation? > > > status =3D false > > reportError(E_CERT_MISMATCH) > > } > > if status || !isEnforce(policy) { > > return tryDeliverMail(connection, message) > > There are potential complications when an MX host > accepts a proper subset of the envelope recipients > and tempfails the rest, or fails for reasons unrelated > to policy, ... So a simple boolean here is not enough. > Delivery to backup MX hosts continues so long as > recipients that are neither delivered nor permanently > rejected remain. STS policy failure is just one way > that (all the) recipients may remain unresolved. > > > } > > return false > > } > > > > func tryWithPolicy(message, domain, policy) { > > mxes :=3D getMxesForPolicy(domain, policy) > > if mxs is empty { > > reportError(E_NO_VALID_MXES) > > } > > for mx in mxes { > > if tryMxAccordingTo(message, mx, policy) { > > return true > > } > > } > > return false > > } > > > > func handleMessage(message) { > > domain :=3D ... // domain part after '@' from recipient > > oldPolicy :=3D tryGetCachedPolicy(domain) > > newPolicy :=3D tryGetNewPolicy(domain) > > In practice, the cached policie's DNS id will be compared with > the current DNS value and if identical, no new policy will be > fetched. If different, a new policy should be fetched, but > perhaps in the backround, with delivery continuing per the > cached policy. > > > if newPolicy { > > cachePolicy(domain, newPolicy) > > oldPolicy =3D newPolicy > > } > > if oldPolicy { > > return tryWithPolicy(message, oldPolicy) > > } > > // There is no policy or there's a new policy that did not work. > > // Try to deliver the message normally (i.e. without STS). > > } > > -- > Viktor. > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a1145f2fa07ae04054b7cee5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> 6.1.=C2=A0 Policy Updates
>
>= ;=C2=A0 =C2=A0 Updating the policy requires that the owner make changes in = two
>=C2=A0 =C2=A0 places: th= e "mta-sts" TXT record in the Policy Domain's DNS zone and>=C2=A0 =C2=A0 at the correspon= ding HTTPS endpoint.=C2=A0 In the case where the HTTPS
>=C2=A0 =C2=A0 endpoint has been updated but the = TXT record has not yet been,
>= ;=C2=A0 =C2=A0 senders will not know there is a new policy released and may= thus
>=C2=A0 =C2=A0 continue= to use old, previously cached versions.=C2=A0 Recipients should
= >=C2=A0 =C2=A0 thus expect a policy wil= l continue to be used by senders until both
>=C2=A0 =C2=A0 the HTTPS and TXT endpoints are updated and t= he TXT record's TTL has
>= =C2=A0 =C2=A0 passed.
The lifetime could be longer.=C2=A0 Some MTAs may initiate= *background* refresh
of unexpir= ed policies after the DNS TXT record is found to have changed,
which may not happen until the first message= to the destination is sent
afte= r that change, and *that* message may well go out based on the already
<= /span>cached policy while the refresh is i= n process.=C2=A0 If the policy no longer
matches reality, the message may be deferred, and would perhaps su= cceed
on retry with a more curre= nt policy.
So the TXT record will not guarantee refresh in any particular timefr= ame.
If no mail is sent to the d= estination, the policy may expire unused despite
the TXT record change.

<= div>I'm no longer sure what this section was meant to convey.=C2=A0

If I switch my policy from policy A to policy B at ti= me t1, anyone may nonetheless continue to use policy A up until t1 + max_ag= e_A, but no longer, regardless of when they fetched it. Policies must no= t=C2=A0be used longer than max_age past the last time they were actuall= y being served.=C2=A0

The DNS TTL doesn't real= ly come into it. I think we added this section to try to clarify a differen= t case (not relating to max_age): when publishing a new policy (B), people = may continue to use A and not try to get B even on failure=C2=A0for = the duration of the TTL (because checking the TXT record will not indicate = that there is in fact a new policy).=C2=A0

So I wi= ll clarify that part. =C2=A0

On Wed, Mar 22, 2017 at 6:04 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:

[ I've pasted in the entire draft, and "quoted" it as though = it
=C2=A0 were a post to trim an reply to. ]

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SMTP MTA Strict = Transport Security (MTA-STS)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 draft-ietf-uta-mta-sts-03
>
> Abstract
>
>=C2=A0 =C2=A0 SMTP Mail Transfer Agent Strict Transport Security (SMTP = STS) is a
>=C2=A0 =C2=A0 mechanism enabling mail service providers to declare thei= r ability to
>=C2=A0 =C2=A0 receive TLS-secured connections and an expected validity = of
>=C2=A0 =C2=A0 certificates presented by their MX hosts, and to specify = whether
>=C2=A0 =C2=A0 sending SMTP servers should refuse to deliver to MX hosts= that do not
>=C2=A0 =C2=A0 offer TLS with a trusted server certificate.

In the abstract I think that "TLS-secured" already covers certifi= cate
validity (which makes for a clumsy insertion into the text anyway).
Also instead of "TLS-secured connections" say "TLS-secure SM= TP connections".

See https://www.rfc-editor.org/materia= ls/abbrev.expansion.txt for the
list of common IETF acronyms, and which are sufficiently widely used
to not need to be expanded on first use.=C2=A0 Thus SMTP and ESMTP are fine=
with expansion, but apparently we've not yet reached similar familiarit= y
with TLS. :-)

> 1.=C2=A0 Introduction
>
>=C2=A0 =C2=A0 The STARTTLS extension to SMTP [RFC3207] allows SMTP clie= nts and
>=C2=A0 =C2=A0 hosts to negotiate the use of a TLS channel for secure ma= il
>=C2=A0 =C2=A0 transmission.

I would drop "secure" above, or replace it with "encrypted&q= uot;.


>=C2=A0 =C2=A0 While such _opportunistic_ encryption protocols provide a= high

While "_" may work as italics in MarkDown, you'll need to cha= nge all
these to RFC XML (where IIRC <i>...</i> may be supported, but d= on't
take my word for it, check).

More importantly, you've made quite a leap here from talking about
RFC 3207, which merely defines an SMTP extension mechanism, to assuming
that the reader knows how the extension is typically used.=C2=A0 It also important to recall that opportunistic security (as defined in RFC7435)
subsumes both MTA best-effort unauthenticated encryption, and the new
opportunistically authenticated DANE and STS use-cases.=C2=A0 With DANE and=
STS transmission is protected only when and as receiving system publishes the requisite policy records.=C2=A0 DANE offers stronger downgrade protecti= on,
at the cost of requiring DNSSEC to achieve that goal.

>=C2=A0 =C2=A0 barrier against passive man-in-the-middle traffic interce= ption,

therefore the "passive-only" protection is a feature of unauthent= icated
opportunistic security, as practiced by most MTAs at present.

>=C2=A0 =C2=A0 This document defines a mechanism for recipient domains t= o publish
>=C2=A0 =C2=A0 policies specifying:
>
>=C2=A0 =C2=A0 o=C2=A0 whether MTAs sending mail to this domain can expe= ct TLS support
>
>=C2=A0 =C2=A0 o=C2=A0 expected validity of server certificates presente= d by the domain's
>=C2=A0 =C2=A0 =C2=A0 =C2=A0MX hosts

It seems to me that STS does not provide any means to signal
unauthenticated TLS support.=C2=A0 And so, as in the abstract, the
above two bullets are really just one, "WebPKI TLS security".

> 1.1.=C2=A0 Terminology
>
>=C2=A0 =C2=A0 We also define the following terms for further use in thi= s document:
>
>=C2=A0 =C2=A0 o=C2=A0 STS Policy: A committment by the Policy Domain to= support PKIX
>=C2=A0 =C2=A0 =C2=A0 =C2=A0authenticated TLS for the specified MX hosts= .

Which I think confirms my point about "authenticated TLS" as the<= br> only available commitment.

>=C2=A0 =C2=A0 o=C2=A0 Policy Domain: The domain for which an STS Policy= is defined.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(For example, when sending mail to "alice@example.com", the policy >=C2=A0 =C2=A0 =C2=A0 =C2=A0domain is "example.com".)

Perhaps this should mention that more generally this is the nexthop
domain for SMTP delivery, and when mail routing is pre=C3=ABmpted by
by explicit relays via local policy, the Policy domain is the
domain name of the explicit relay (prior to any MX lookups if
applicable).

>=C2=A0 =C2=A0 o=C2=A0 Policy Authentication: Authentication of the STS = policy retrieved
>=C2=A0 =C2=A0 =C2=A0 =C2=A0for a recipient domain by the sender.

This definition seems all too circular.=C2=A0 What does it actually mean?
> 2.=C2=A0 Related Technologies
>
>=C2=A0 =C2=A0 The DANE TLSA record [RFC7672] is similar, in that DANE i= s also
>=C2=A0 =C2=A0 designed to upgrade opportunistic, unauthenticated encryp= tion into
>=C2=A0 =C2=A0 required, authenticated encryption.

Opportunistic DANE TLS upgrades unauthenticated encryption or even
cleartext delivery to downgrade-resistant authenticated TLS.=C2=A0 (Side note, not for the draft, for actually non-opportunistic TLS see
Jim Fenton's REQUIRETLS proposal).=C2=A0 STS aims to do the same, but without requiring TLS at the cost of losing some downgrade protection.

>=C2=A0 DANE requires DNSSEC [RFC4033]
>=C2=A0 =C2=A0 for authentication; the mechanism described here instead = relies on
>=C2=A0 =C2=A0 certificate authorities (CAs) and does not require DNSSEC= .=C2=A0 For a
>=C2=A0 =C2=A0 thorough discussion of this trade-off, see the section _S= ecurity_
>=C2=A0 =C2=A0 _Considerations_.

The Security Considerations section (once again this is not MarkDown)
will need to properly discuss the downgrade exposure of STS on first
contact, and this trade-off probably should be mentioned here up-front.

>=C2=A0 =C2=A0 In addition, SMTP STS provides an optional report-only mo= de, enabling
>=C2=A0 =C2=A0 soft deployments to detect policy failures.

It is easy to define a couple of new "certificate usage" code-poi= nts
for DANE that similarly signal "soft-fail" (with reporting).=C2= =A0 Would
the group strongly support a draft along those lines?=C2=A0 I am not sure that a merely "tamper-evident" operating mode is a good idea as a=
persistent operating state, and I think that the ability to have
one or more (backup, i.e. worse preference) MX hosts without TLSA
records adequately addresses the need for incremental deployment.

> 3.=C2=A0 Policy Discovery
>
>=C2=A0 =C2=A0 To discover if a recipient domain implements MTA-STS, a s= ender need
>=C2=A0 =C2=A0 only resolve a single TXT record.=C2=A0 To see if an upda= ted policy is
>=C2=A0 =C2=A0 available for a domain for which the sender has a previou= sly cached
>=C2=A0 =C2=A0 policy, the sender need only check the TXT record's v= ersion "id"
>=C2=A0 =C2=A0 against the cached value.

Given earlier discussion on the list, while new "id" values can g= ive
expedited signals to refresh the policy, it may be appropriate here,
(but perhaps later in the document as you see fit) to describe a
recommended approach to proactively refresh policies prior to their
pending expiration, this reduces the probability of "gaps" in pol= icy
coverage if the remote HTTPS service is unavailable just as a policy
is expiring.

In practice (say in Postfix, if/when STS is implemented) I wouldn't
go looking through the cache for policies to refresh except when
delivering mail to the destination in question.=C2=A0 I don't want the<= br> cache to become a roach motel for policies to destinations I never
again send mail to.=C2=A0 If communication with a destination ceases
completely, it is not unreasonable to let its STS policy simply
age out.=C2=A0 Google et. al. may of course choose indefinite data
retension (data retentiveness is Google's business), but for
SOHO and enterprise MTAs, the above may be more appropriate.

> 3.2.=C2=A0 MTA-STS Policies
>
>=C2=A0 =C2=A0 This JSON object contains the following key/value pairs:<= br> >
>=C2=A0 =C2=A0 o=C2=A0 "version": (plain-text, required).=C2= =A0 Currently only "STSv1" is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0supported.
>
>=C2=A0 =C2=A0 o=C2=A0 "mode": (plain-text, required).=C2=A0 E= ither "enforce" or "report",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0indicating the expected behavior of a sendin= g MTA in the case of a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0policy validation failure.
>
>=C2=A0 =C2=A0 o=C2=A0 "max_age": Max lifetime of the policy (= plain-text non-negative
>=C2=A0 =C2=A0 =C2=A0 =C2=A0integer seconds, required).=C2=A0 Well-behav= ed clients SHOULD cache a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0policy for up to this value from last policy= fetch time.=C2=A0 To
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mitigate the risks of attacks at policy refr= esh time, it is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0expected that this value typically be in the= range of weeks or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0greater.

A more comprehensive mitigation for attacks "at policy refresh time&qu= ot;
would entail not just a long lifetime, but proactive refresh as mentioned above.

>=C2=A0 =C2=A0 o=C2=A0 "mx": MX patterns (list of plain-text M= X match strings, required).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0One or more patterns matching the expected M= X for this domain.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0For example, "["*.example.com", = "*.example.net"]" indicates that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mail for this domain might be handled by any= MX with a hostname at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"example.com" or "example.net"= .=C2=A0 Valid patterns can be either
>=C2=A0 =C2=A0 =C2=A0 =C2=A0hostname literals (e.g. "mx1.example.com") or wildcard matches, so
>=C2=A0 =C2=A0 =C2=A0 =C2=A0long as the wildcard occupies the full left-= most label in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0pattern.=C2=A0 (Thus "*.example.com" = is valid but "mx*.example.com" is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0not.)

Here, as discussed on the list, serious consideration should be given
to changing the semantics from validating the MX hostname to specifying
the names allowed in the server's certificate.=C2=A0 This simplifies MX= processing
(which remains unmodified) and merely changes the conditions under which an=
MX host is considered suitably authenticated per the policy.

Which, for example, allows the MX hosts to share a single certificate
with the destination domain (and not the MX hostname) as its DNS SAN.
If the policy lists that (shared) name as what's expected in the certif= icate,
then authentication succeeds when the MX host's certificate matches one= of
the allowed names.

It should be made clear that the names here are always in A-label form
and not U-label form (as they also are in DNS names in certificates).

Furthermore, I think that using "*.example.com" in what are essenti= ally
(rfc6125) reference identifiers creates confusion with similar-looking, but=
semantically distinct wildcard names in certificates.=C2=A0 My suggestion w= as
".= example.com" for sub-domain matching, with the policy optionally s= pecifying
whether only single-label prefixes are accepted, or whether in fact multi-l= abel
prefixes are also valid.

>=C2=A0 =C2=A0 An example JSON policy is as below:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0"version": "STSv1",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0"mode": "enforce",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0"mx": ["*.mail.example.com"],
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0"max_age": 123456
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0}

FWIW, I would have chosen something less fancy than JSON for
what is clearly a simple array of attribute/value pairs. ESMTP
already encodes such optional A/V pairs as space separated lists
of attr=3Dvalue with xtext encoding as needed (it is not needed for
any plausible value of the above attributes).

We're not going to add a JSON decoder to the Postfix SMTP client,
but if this specification retains JSON, then the code that does
background policy retrieval will need to transform JSON into
something more friendly to traditional C-based MTA implementations.

> 4.=C2=A0 Policy Validation

Are we validating the policy or using the policy to authenticate
the MX host?=C2=A0 I think the name of this section is suboptimal.

>=C2=A0 =C2=A0 When sending to an MX at a domain for which the sender ha= s a valid
>=C2=A0 =C2=A0 and non-expired SMTP MTA-STS policy, a sending MTA honori= ng SMTP STS
>=C2=A0 =C2=A0 MUST validate:

s/validate/check/ or /ensure/.

>=C2=A0 =C2=A0 1.=C2=A0 That the recipient MX matches the "mx"= pattern from the recipient
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 domain's policy.

See above, perhaps "mx" becomes "san" and the check is = deferred until
it is time to verify the host's certificate.

>=C2=A0 =C2=A0 2.=C2=A0 That the recipient MX supports STARTTLS and offe= rs a valid PKIX
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 based TLS certificate.

Here, it would be prudent to mention rfc6125, and be explicit about
the acceptable wildcard patterns in that certificate.=C2=A0 See, for exampl= e:

=C2=A0 =C2=A0https://tools.ietf.org/html/rfc76= 72#section-3.2.3

which limits certificate wildcards to the entire first label only.=C2=A0 I<= br> would like to avoid supporting more general wildcards in new
specifications.

>=C2=A0 =C2=A0 This section does not dictate the behavior of sending MTA= s when
>=C2=A0 =C2=A0 policies fail to validate; in particular, validation fail= ures of
>=C2=A0 =C2=A0 policies which specify "report" mode MUST NOT b= e interpreted as
>=C2=A0 =C2=A0 delivery failures, as described in the section _Policy_ >=C2=A0 =C2=A0 _Application_.

The first sentence is unfortunate, you are in fact specifying behaviour, in the very next sentence.=C2=A0 It might be better to add a forward-refere= nce
to a section that provides a detailed explanation and not start with a
disclaimer.

> 4.1.=C2=A0 MX Matching
>
>=C2=A0 =C2=A0 When delivering mail for the Policy Domain to a recipient= MX host,
>=C2=A0 =C2=A0 the sender validates the MX match against the "mx&qu= ot; pattern from the
>=C2=A0 =C2=A0 applied policy.=C2=A0 The semantics for these patterns ar= e those found in
>=C2=A0 =C2=A0 section 6.4 of [RFC6125].

Assuming this text survives, replace:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 validates the MX match against the "mx&quo= t; pattern

with something like

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ensures that the MX host name is consistent wit= h the "mx"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 property of the STS policy (only matching MX ho= sts are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 used in delivery attempts).

The reference to rfc6125 is rather unfortunate here, since it defines
semantics for presented identifiers, not reference identifiers.

> 4.2.=C2=A0 MX Certificate Validation
>
>=C2=A0 =C2=A0 The certificate presented by the receiving MX MUST be val= id for the
>=C2=A0 =C2=A0 MX hostname and chain to a root CA that is trusted by the= sending
>=C2=A0 =C2=A0 MTA.=C2=A0 The certificate MUST have a CN or SAN matching= the MX hostname
>=C2=A0 =C2=A0 (as described in [RFC6125]) and be non-expired.

Here, if the proposal to switch from "mx" to "san" is t= aken up, the
peer certificate is no longer restricted to authenticate the MX hostname, rather, one its presented identifiers needs to match one of the reference identifiers fro the "san" policy attribute.=C2=A0 Either way some= discussion
is appropriate of how to perform matching when both the reference and
the presented identifiers are "wildcards".

> 5.=C2=A0 Policy Application

This is an appropriate target for the afore-mentioned forward-reference.
>=C2=A0 =C2=A0 When sending to an MX at a domain for which the sender ha= s a valid,
>=C2=A0 =C2=A0 non-expired STS policy, a sending MTA honoring SMTP STS a= pplies the
>=C2=A0 =C2=A0 result of a policy validation one of two ways, depending = on the value
>=C2=A0 =C2=A0 of the policy "mode" field:
>
>=C2=A0 =C2=A0 1.=C2=A0 "report": In this mode, sending MTAs m= erely send a report (as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 described in the TLSRPT specification (TODO= : add ref)) indicating
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 policy application failures.
>
>=C2=A0 =C2=A0 2.=C2=A0 "enforce": In this mode, sending MTAs = treat STS policy failures
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 as a mail delivery error, and MUST NOT deli= ver the message to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 this host.

We should not confuse "delivery error" with "authentication = failure".
When one MX host fails authentication, the next MX host should be
tried.=C2=A0 And, I think it should be mentioned that if all the MX
hosts (that the sender is willing to try) fail authentication, the
message should be deferred, not bounced.

>=C2=A0 =C2=A0 When a message fails to deliver due to an "enforce&q= uot; policy, a
>=C2=A0 =C2=A0 compliant MTA MUST check for the presence of an updated p= olicy at the
>=C2=A0 =C2=A0 Policy Domain before permanently failing to deliver the m= essage.
>=C2=A0 =C2=A0 This allows implementing domains to update long-lived pol= icies on the
>=C2=A0 =C2=A0 fly.

This seems to suggest the contrary, i.e. that it might be appropriate
to bounce on policy failure when a more fresh policy still fails.
However certificate problems (expiration most typically) are transient,
and a receiving system operator should/may notice the problem before
outstanding messages expire and bounce.=C2=A0 So I would urge implementors<= br> to queue, rather than bounce, on authentication failure.

> 5.1.=C2=A0 MX Preference

This section would go if a switch from "mx" to "san" ta= kes place.

> 5.2.=C2=A0 Policy Application Control Flow
>
>=C2=A0 =C2=A0 An example control flow for a compliant sender consists o= f the
>=C2=A0 =C2=A0 following steps:

Step 0:=C2=A0 If the sending MTA is DANE-capable, the destination is
DNSSEC signed, and one or more of the MX hosts have DANE TLSA
records, then DANE TLSA preempts STS (more downgrade-resistant,
works on first contact, ...).

This is another reason to avoid STS-based MX filtering, with DNSSEC
signed destinations the security of the MX records is sufficiently
established, and we need to be able to proceed with DANE MX by MX,
using STS policy only for MX hosts with no TLSA records.

>=C2=A0 =C2=A0 1.=C2=A0 Check for a cached policy whose time-since-fetch= has not exceeded
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 its "max_age".=C2=A0 If none exis= ts, attempt to fetch a new policy.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (Optionally, sending MTAs may unconditional= ly check for a new
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 policy at this step.)

Is "attempt to fetch" well understood at this point?=C2=A0 The at= tempt only
happens if the DNS TXT record is in place...

>=C2=A0 =C2=A0 2.=C2=A0 Filter candidate MXs against the current policy.=

See "san" vs. "mx" issue above.=C2=A0 Also proceed with= non-STS delivery
absent any policy.

>=C2=A0 =C2=A0 3.=C2=A0 If no candidate MXs are valid and the policy mod= e is "enforce",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 temporarily fail the message.=C2=A0 (Otherw= ise, generate a failure
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 report but deliver as though MTA STS were n= ot implemented.)

Ditto.

>=C2=A0 =C2=A0 4.=C2=A0 For each candidate MX, in order of MX priority, = attempt to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 deliver the message, enforcing STARTTLS and= the MX host's PKIX
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 certificate validation.

Well, no so much enforcing as performing, authentication may be allowed
to fail in "report" mode.=C2=A0 And of course only if there is an= STS policy
to use.

>=C2=A0 =C2=A0 5.=C2=A0 Upon message retries, a message MAY be permanent= ly failed
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 following first checking for the presence o= f a new policy (as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 indicated by the "id" field in th= e "mta-sts" TXT record).

I think this is a mistake.=C2=A0 Please do not turn transient errors into permanent failures.

> 6.1.=C2=A0 Policy Updates
>
>=C2=A0 =C2=A0 Updating the policy requires that the owner make changes = in two
>=C2=A0 =C2=A0 places: the "mta-sts" TXT record in the Policy = Domain's DNS zone and
>=C2=A0 =C2=A0 at the corresponding HTTPS endpoint.=C2=A0 In the case wh= ere the HTTPS
>=C2=A0 =C2=A0 endpoint has been updated but the TXT record has not yet = been,
>=C2=A0 =C2=A0 senders will not know there is a new policy released and = may thus
>=C2=A0 =C2=A0 continue to use old, previously cached versions.=C2=A0 Re= cipients should
>=C2=A0 =C2=A0 thus expect a policy will continue to be used by senders = until both
>=C2=A0 =C2=A0 the HTTPS and TXT endpoints are updated and the TXT recor= d's TTL has
>=C2=A0 =C2=A0 passed.

The lifetime could be longer.=C2=A0 Some MTAs may initiate *background* ref= resh
of unexpired policies after the DNS TXT record is found to have changed, which may not happen until the first message to the destination is sent
after that change, and *that* message may well go out based on the already<= br> cached policy while the refresh is in process.=C2=A0 If the policy no longe= r
matches reality, the message may be deferred, and would perhaps succeed
on retry with a more current policy.

So the TXT record will not guarantee refresh in any particular timeframe. If no mail is sent to the destination, the policy may expire unused despite=
the TXT record change.

> 8.=C2=A0 Security Considerations
>
>=C2=A0 =C2=A0 Since we use DNS TXT records for policy discovery, an att= acker who is
>=C2=A0 =C2=A0 able to block DNS responses can suppress the discovery of= an STS
>=C2=A0 =C2=A0 Policy, making the Policy Domain appear not to have an ST= S Policy.
>=C2=A0 =C2=A0 The sender policy cache is designed to resist this attack= .

Well, not "resist" so much as reduce the effectiveness, since it = will
now only be effective on first contact, or perhaps when no mail is sent
to the destination for a long time and the cached policy expired.

>=C2=A0 =C2=A0 We additionally consider the Denial of Service risk posed= by an
>=C2=A0 =C2=A0 attacker who can modify the DNS records for a victim doma= in.=C2=A0 Absent
>=C2=A0 =C2=A0 SMTP STS, such an attacker can cause a sending MTA to cac= he invalid
>=C2=A0 =C2=A0 MX records for a long TTL.=C2=A0 With SMTP STS, the attac= ker can
>=C2=A0 =C2=A0 additionally advertise a new, long-"max_age" SM= TP STS policy with
>=C2=A0 =C2=A0 "mx" constraints that validate the malicious MX= record, causing
>=C2=A0 =C2=A0 senders to cache the policy and refuse to deliver message= s once the
>=C2=A0 =C2=A0 victim has resecured the MX records.

Many DNS resolvers have sensible upper-bounds on record TTLs.=C2=A0 It the<= br> attacker can obtain a certificate for the victim domain, they may
indeed inject a long-lived policy, but the TXT record affords the
victim the opportunity of recovery.=C2=A0 This paragraph needs work.

Finally, some discussion is appropriate of the fact that given weaker
downgrade-resistance of STS viz. DANE, implementations that support
both should apply DANE first and STS only in its absence.=C2=A0 Indeed with=
the MX RRset validated via DNSSEC the "mx" policy element is not = really
needed to prevent MX record forgery, however that depends on the outcome of the "mx" vs. "san" discussion.

There should probably be a recommendation that sending systems implement DANE in addition to STS.=C2=A0 It is much easier to use a validating resolv= er
than to sign one's own domain, and so the barrier to option of outbound=
DANE is significantly lower.=C2=A0 I'll have some additional implementa= tion
news to report shortly...

> 10.1.=C2=A0 Example 1
>
>=C2=A0 =C2=A0 The owner of "example.com" wishes to begin using S= TS with a policy
>=C2=A0 =C2=A0 that will solicit reports from receivers without affectin= g how the
>=C2=A0 =C2=A0 messages are processed, in order to verify the identity o= f MXs that
>=C2=A0 =C2=A0 handle mail for "example.com", confirm that TLS i= s correctly used,
>=C2=A0 =C2=A0 and ensure that certificates presented by the recipient M= X validate.
>
>=C2=A0 =C2=A0 STS policy indicator TXT RR:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mta-sts.example.com.=C2=A0 IN TX= T "v=3DSTSv1; id=3D20160831085700Z;"
>
>=C2=A0 =C2=A0 STS Policy JSON served as the response body at [1]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ver= sion": "STSv1",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"mod= e": "report",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"mx&= quot;: ["mx1.example.com", "mx2.example.com"],
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"max= _age": 123456
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

Note, the "max_age" here is barely over a day, which is not consi= stent with
the recommended policy lifetimes.=C2=A0 Even "report" policies sh= ould probably
have better downgrade protection through longer lifetimes (say a week or mo= re).

> 11.=C2=A0 Appendix 2: Message delivery pseudocode
>
>=C2=A0 =C2=A0 Below is pseudocode demonstrating the logic of a complain= t sending
>=C2=A0 =C2=A0 MTA.=C2=A0 This implements the "two-pass" appro= ach, first attempting
>=C2=A0 =C2=A0 delivery with a newly fetched policy (if present) before = falling back
>=C2=A0 =C2=A0 to a cached policy (if present).

Should that be "complaint" or "compliant"? :-)=C2=A0 I = would expect that
sane implementations will use cached policies first, and only both
refreshes based on TXT record changes or refresh timers, with updates
in the background.=C2=A0 Synchronous updates of policy at message delivery<= br> time are exceedingly unappealing at least to me.

> func certMatches(connection, mx) {
>=C2=A0 =C2=A0// Return if the server certificate from "connection&= quot; matches the "mx" host.

This could use a detailed discussion of what "matches" means, or = a
back-reference to a section that does.=C2=A0 Covering wildcard use in
either or both of the reference and presented identifiers, and
possible additional text if "mx" becomes "san".

> func getMxsForPolicy(domain, policy) {
>=C2=A0 =C2=A0// Sort the MXs by priority, filtering out those which are= invalid according
>=C2=A0 =C2=A0// to "policy".
> }

[ "mx" vs. "san" ]

> func tryGetNewPolicy(domain) {
>=C2=A0 =C2=A0// Check for an MTA STS TXT record for "domain" = in DNS, and return the
>=C2=A0 =C2=A0// indicated policy (or a local cache of the unvalidated p= olicy).
> }

The DNS lookup may succeed, and the HTTPS lookup may tempfail, what
happens in that case?=C2=A0 What happens with an authenticated 404 HTTPS response?=C2=A0 Let's avoid "unvalidated" here, or else avoid= its use
in the context of "peer authentication".

> func cachePolicy(domain, policy) {
>=C2=A0 =C2=A0// Store "policy" as the cached policy for "= ;domain".
> }

Along with the policy one should generally store the time
at which it was last retrieved, and the time of any unsuccessful
refresh attempts since then.=C2=A0 This supports both eventual
expiration, and proactive refresh, with multiple retries, as
the policy approaches expiration.

> func tryMxAccordingTo(message, mx, policy) {
>=C2=A0 =C2=A0connection :=3D connect(mx)
>=C2=A0 =C2=A0if !connection {
>=C2=A0 =C2=A0 =C2=A0return false=C2=A0 // Can't connect to the MX s= o it's not an STS error.
>=C2=A0 =C2=A0}
>=C2=A0 =C2=A0status :=3D !(tryStartTls(mx, &connection) && = certMatches(connection, mx))
>=C2=A0 =C2=A0status =3D true

What's happening with "status" here?=C2=A0 I think the first = assignment goes...

>=C2=A0 =C2=A0if !tryStartTls(mx, &connection) {
>=C2=A0 =C2=A0 =C2=A0status =3D false
>=C2=A0 =C2=A0 =C2=A0reportError(E_NO_VALID_TLS)
>=C2=A0 =C2=A0} else if certMatches(connection, mx) {

Missing negation?

>=C2=A0 =C2=A0 =C2=A0status =3D false
>=C2=A0 =C2=A0 =C2=A0reportError(E_CERT_MISMATCH)
>=C2=A0 =C2=A0}
>=C2=A0 =C2=A0if status || !isEnforce(policy) {
>=C2=A0 =C2=A0 =C2=A0return tryDeliverMail(connection, message)

There are potential complications when an MX host
accepts a proper subset of the envelope recipients
and tempfails the rest, or fails for reasons unrelated
to policy, ... So a simple boolean here is not enough.
Delivery to backup MX hosts continues so long as
recipients that are neither delivered nor permanently
rejected remain.=C2=A0 STS policy failure is just one way
that (all the) recipients may remain unresolved.

>=C2=A0 =C2=A0}
>=C2=A0 =C2=A0return false
> }
>
> func tryWithPolicy(message, domain, policy) {
>=C2=A0 =C2=A0mxes :=3D getMxesForPolicy(domain, policy)
>=C2=A0 =C2=A0if mxs is empty {
>=C2=A0 =C2=A0 =C2=A0reportError(E_NO_VALID_MXES)
>=C2=A0 =C2=A0}
>=C2=A0 =C2=A0for mx in mxes {
>=C2=A0 =C2=A0 =C2=A0if tryMxAccordingTo(message, mx, policy) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0return true
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
>=C2=A0 =C2=A0return false
> }
>
> func handleMessage(message) {
>=C2=A0 =C2=A0domain :=3D ... // domain part after '@' from reci= pient
>=C2=A0 =C2=A0oldPolicy :=3D tryGetCachedPolicy(domain)
>=C2=A0 =C2=A0newPolicy :=3D tryGetNewPolicy(domain)

In practice, the cached policie's DNS id will be compared with
the current DNS value and if identical, no new policy will be
fetched.=C2=A0 If different, a new policy should be fetched, but
perhaps in the backround, with delivery continuing per the
cached policy.

>=C2=A0 =C2=A0if newPolicy {
>=C2=A0 =C2=A0 =C2=A0cachePolicy(domain, newPolicy)
>=C2=A0 =C2=A0 =C2=A0oldPolicy =3D newPolicy
>=C2=A0 =C2=A0}
>=C2=A0 =C2=A0if oldPolicy {
>=C2=A0 =C2=A0 =C2=A0return tryWithPolicy(message, oldPolicy)
>=C2=A0 =C2=A0}
>=C2=A0 =C2=A0// There is no policy or there's a new policy that did= not work.
>=C2=A0 =C2=A0// Try to deliver the message normally (i.e. without STS).=
> }

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

--001a1145f2fa07ae04054b7cee5b-- --001a1145f2fa139ec2054b7ceefa Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+ q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0 TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg 5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27 8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCfIhOVaojo3kKk HQ6/pMWPVQkmDw33kCvS7l3sGS/ezjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAzMjQxNzAwMjVaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAL7iaEkFm7fRh1UbA5KFGKzqOQIRd/iud HvlUZ7vuQpONH+fa7iCRW1Yy3qatpl80+hlxuC3KeI63pOH5sb8g2SIyN9MoLipDBK3dGnk2CQor UXif5ACo+tvrib0xmNL4bb39YNDT63hjxxDcvdcENIMjwECLmZhSOEh/tkR8hhvnfvlZOLiC6qiD BzOkioo+1VopOK+RAv11y2GqB1x9M6U5epE485CfGMUIKQ4mEZ7unD+tzHxC9fbQkMi7HmWDE/KE SlkHiLxg6a1Nq1Ts3jpSFIM/33tkTm6Prh+qDeI4KZCyyu3Bn7aZQcSMVyhHGwuKuLsgQU6aP1DA RH6UiA== --001a1145f2fa139ec2054b7ceefa-- From nobody Sun Mar 26 12:56:44 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21841296AD for ; Sun, 26 Mar 2017 12:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swWditq7cN5S for ; Sun, 26 Mar 2017 12:56:37 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895151296A6 for ; Sun, 26 Mar 2017 12:56:37 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id a5so19085975oth.1 for ; Sun, 26 Mar 2017 12:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=mzESdAUOjkSWM+KqdYgwADEsstc2dsKaKowbkIED+ZQ=; b=DotJdbEa1nFxA2ud0LUocVHKC5glpHhXd4olDWyKYjI+0jvfAz5bHkxKiAcNjDx03N XHIqIabG+trpC01Gui8VObfpL8j99p2e67ygZp8148BfwLru0KWMSNMuQ8ZzhUE1ViPm u+y+pRA/Be27/Lix4/UN1JENyFdjEL02nMu5zvFc/zkjVJ8mph993BiqhPO4Fls1KKXP KuM3htNVnh7r3b5v80Am+5OzaUu+TsQn+OII35UvEQjsa5q0iURf0WxsiLBowqgazgRs ADJqIswEOohqHBLJ7rWvuyyWOUNwi+lIBJmeZCJGsLwLkcpDl+Vi3LEpGRjom7Hijxwn Vpeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=mzESdAUOjkSWM+KqdYgwADEsstc2dsKaKowbkIED+ZQ=; b=WO+CFP9700ZYxZGBxB43rE3n7Z+mVKrRdd8rqdbRNy1TuQ+HuRAR4RUrWyzBT2m6v4 UKduaLgJxGDZTiZYDI3HZGNnhsQpQoChiqZr7K8WTaK8KO+b6z+yQf7cU1ZvJd5iT5gU sTkefWzZo1r2QF/JEI8OTS8p9Fn1UJ1etlEA1hfn0sysLANGd1g6vsNlNBpMwwBMvOlQ Ab56K2sVNnXqlca+Zbgav3pHmDA+PqhyYNsbGJsMqvW4RXs/IZOoDiFPZ1u1KpjEMExP lCyqztQL95iaw1yUgWsj4/6D7cjsQLg4AeK4xZyOtG/tunG75g21DRCLqqEAYmOtU0Gi ojjA== X-Gm-Message-State: AFeK/H3RZY5BxKrvW7LUnW5WtI2zHYW2AdFarHqgh+EP7r5ROKRfqwnNeOPVjFnIvg4JJN8gACIuRUZPn3EK7w== X-Received: by 10.157.63.252 with SMTP id i57mr7836611ote.39.1490558196629; Sun, 26 Mar 2017 12:56:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.14.248 with HTTP; Sun, 26 Mar 2017 12:56:36 -0700 (PDT) In-Reply-To: References: <4C0807DA-4852-4DAC-80ED-8A25371CFFAA@dukhovni.org> From: David Illsley Date: Sun, 26 Mar 2017 20:56:36 +0100 Message-ID: To: uta@ietf.org Content-Type: multipart/alternative; boundary=001a1145be46d3c89c054ba79fdc Archived-At: Subject: Re: [Uta] MTA-STS-03 review X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 19:56:42 -0000 --001a1145be46d3c89c054ba79fdc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 22, 2017 at 12:39 PM, Daniel Margolis wrote: > > >> Here, as discussed on the list, serious consideration should be given >> to changing the semantics from validating the MX hostname to specifying >> the names allowed in the server's certificate. This simplifies MX >> processing >> (which remains unmodified) and merely changes the conditions under which >> an >> MX host is considered suitably authenticated per the policy. > > >> Which, for example, allows the MX hosts to share a single certificate >> with the destination domain (and not the MX hostname) as its DNS SAN. >> If the policy lists that (shared) name as what's expected in the >> certificate, >> then authentication succeeds when the MX host's certificate matches one = of >> the allowed names. >> > > That's interesting. I think it's not actually that big a change--we just > get rid of the MX host filtering and instead just apply the logic to > validation. > > Downsides: > > 1. Misconfigurations _may_ be less obvious without connecting to the SMTP > server. That is, today, you can spot some kinds of misconfigurations by > merely looking at the DNS (so for example my test tool here > http://sts.x.af0.net/ first looks at DNS, and only then tries SMTP > connections). > 2. As you say, it requires some changes to server certificate validation, > but not much. > > I don't consider #1 compelling. So this seems fairly reasonable to me, bu= t > I will let others chime in. > > FWIW, I'm nervous about the idea of introducing non-standard server cert validation. It's not that complex, but certainly unexpected to people with experience deploying HTTPS. It also looks like some of the rationale is to enable reuse of website keys/certs, which while valid probably isn't desirable because of the risks of reusing the same keys for multiple purposes/with multiple software configurations (as was demonstrated in the DROWN paper https://drownattack.com/) On Wed, Mar 22, 2017 at 12:39 PM, Daniel Margolis wrote: > Thanks, Viktor! > > Some comments inline, of course. ;) > > On Wed, Mar 22, 2017 at 6:04 AM, Viktor Dukhovni > wrote: > >> >> > While such _opportunistic_ encryption protocols provide a high >> >> While "_" may work as italics in MarkDown, you'll need to change all >> these to RFC XML (where IIRC ... may be supported, but don't >> take my word for it, check). >> > > (This is just some mistake in our markdown->xml transformation. Beats me, > but good catch.) > > >> >> > o Policy Domain: The domain for which an STS Policy is defined. >> > (For example, when sending mail to "alice@example.com", the >> policy >> > domain is "example.com".) >> >> Perhaps this should mention that more generally this is the nexthop >> domain for SMTP delivery, and when mail routing is pre=C3=ABmpted by >> by explicit relays via local policy, the Policy domain is the >> domain name of the explicit relay (prior to any MX lookups if >> applicable). >> > > We mention this explicitly in section 3.4. > > >> >> > DANE requires DNSSEC [RFC4033] >> > for authentication; the mechanism described here instead relies on >> > certificate authorities (CAs) and does not require DNSSEC. For a >> > thorough discussion of this trade-off, see the section _Security_ >> > _Considerations_. >> >> The Security Considerations section (once again this is not MarkDown) >> will need to properly discuss the downgrade exposure of STS on first >> contact, and this trade-off probably should be mentioned here up-front. >> > > We mention this (briefly) already, but maybe don't do it justice. In > particular, while we say that "[t]he sender policy cache is designed to > resist this attack," we don't call out explicitly the implied benefit of > longer max_ages and longer caching. > > >> > In addition, SMTP STS provides an optional report-only mode, enabli= ng >> > soft deployments to detect policy failures. >> >> It is easy to define a couple of new "certificate usage" code-points >> for DANE that similarly signal "soft-fail" (with reporting). Would >> the group strongly support a draft along those lines? I am not sure >> that a merely "tamper-evident" operating mode is a good idea as a >> persistent operating state, and I think that the ability to have >> one or more (backup, i.e. worse preference) MX hosts without TLSA >> records adequately addresses the need for incremental deployment. >> > > Agreed. It's a difference from DANE (necessitated in part by the fact tha= t > DANE policies are per-MX rather than, as with STS, per-domain, so DANE ha= s > a different mechanism to allow incremental rollouts). I would not suggest > it's better or worse, but supporting soft failures in this matter seems t= he > easiest way to support testing a policy in the STS model, no? > > >> Given earlier discussion on the list, while new "id" values can give >> expedited signals to refresh the policy, it may be appropriate here, >> (but perhaps later in the document as you see fit) to describe a >> recommended approach to proactively refresh policies prior to their >> pending expiration, this reduces the probability of "gaps" in policy >> coverage if the remote HTTPS service is unavailable just as a policy >> is expiring >> > > Agreed. > > >> Here, as discussed on the list, serious consideration should be given >> to changing the semantics from validating the MX hostname to specifying >> the names allowed in the server's certificate. This simplifies MX >> processing >> (which remains unmodified) and merely changes the conditions under which >> an >> MX host is considered suitably authenticated per the policy. > > >> Which, for example, allows the MX hosts to share a single certificate >> with the destination domain (and not the MX hostname) as its DNS SAN. >> If the policy lists that (shared) name as what's expected in the >> certificate, >> then authentication succeeds when the MX host's certificate matches one = of >> the allowed names. >> > > That's interesting. I think it's not actually that big a change--we just > get rid of the MX host filtering and instead just apply the logic to > validation. > > Downsides: > > 1. Misconfigurations _may_ be less obvious without connecting to the SMTP > server. That is, today, you can spot some kinds of misconfigurations by > merely looking at the DNS (so for example my test tool here > http://sts.x.af0.net/ first looks at DNS, and only then tries SMTP > connections). > 2. As you say, it requires some changes to server certificate validation, > but not much. > > I don't consider #1 compelling. So this seems fairly reasonable to me, bu= t > I will let others chime in. > > I've been quite hesitant to entertain any "business logic" changes at thi= s > point if we could avoid it, since we already have some code written, but > like I said, I don't think this is actually a very large change. > > >> >> It should be made clear that the names here are always in A-label form >> and not U-label form (as they also are in DNS names in certificates). >> > > This is specified in 3.2. > > >> Furthermore, I think that using "*.example.com" in what are essentially >> (rfc6125) reference identifiers creates confusion with similar-looking, >> but >> semantically distinct wildcard names in certificates. My suggestion was >> ".example.com" for sub-domain matching, with the policy optionally >> specifying >> whether only single-label prefixes are accepted, or whether in fact >> multi-label >> prefixes are also valid. >> > > Well, I think our matching is a subset of the matching defined in RFC6125 > section 6.4.3. We could specify that we support the full policy; it seeme= d > worth a simplification (i.e. we don't support 'something*.domain.com', > only '*.domain.com') to make implementation easier, but at cost of a > semantic difference. If we get rid of the wildcard, I suppose it is indee= d > more obvious that we're just doing only suffix matching. Was that your > point? > > >> FWIW, I would have chosen something less fancy than JSON for >> what is clearly a simple array of attribute/value pairs. ESMTP >> already encodes such optional A/V pairs as space separated lists >> of attr=3Dvalue with xtext encoding as needed (it is not needed for >> any plausible value of the above attributes). >> > > I seem to recall that we started with simple key-value pairs and moved to > JSON because people variously seemed to think this was easier (since > parsing libraries are common). I would also consider the vague possibilit= y > that in future iterations we wish to add fields. > > De novo, I myself have no real opinion here, because certainly either > work, but of course I'm loath to make changes again. I'd appreciate more > feedback from more readers, though, as these style discussions are always= a > bit subjective. I assume that for Postfix policy fetching is a background > process anyway, though, so it isn't (I would hope) too big an > implementation difference for you, right? > > >> We're not going to add a JSON decoder to the Postfix SMTP client, >> but if this specification retains JSON, then the code that does >> background policy retrieval will need to transform JSON into >> something more friendly to traditional C-based MTA implementations. >> >> > 4. Policy Validation >> >> Are we validating the policy or using the policy to authenticate >> the MX host? I think the name of this section is suboptimal. >> >> > When sending to an MX at a domain for which the sender has a valid >> > and non-expired SMTP MTA-STS policy, a sending MTA honoring SMTP ST= S >> > MUST validate: >> >> s/validate/check/ or /ensure/. >> >> > 1. That the recipient MX matches the "mx" pattern from the recipie= nt >> > domain's policy. >> >> See above, perhaps "mx" becomes "san" and the check is deferred until >> it is time to verify the host's certificate. >> >> > 2. That the recipient MX supports STARTTLS and offers a valid PKIX >> > based TLS certificate. >> >> Here, it would be prudent to mention rfc6125, and be explicit about >> the acceptable wildcard patterns in that certificate. See, for example: >> >> https://tools.ietf.org/html/rfc7672#section-3.2.3 >> >> which limits certificate wildcards to the entire first label only. I >> would like to avoid supporting more general wildcards in new >> specifications. >> > > We specify this in 4.1 (as you discovered below), but maybe that's too > late. > > >> >> > This section does not dictate the behavior of sending MTAs when >> > policies fail to validate; in particular, validation failures of >> > policies which specify "report" mode MUST NOT be interpreted as >> > delivery failures, as described in the section _Policy_ >> > _Application_. >> >> The first sentence is unfortunate, you are in fact specifying behaviour, >> in the very next sentence. It might be better to add a forward-referenc= e >> to a section that provides a detailed explanation and not start with a >> disclaimer. >> > > Heh. Thanks. ;) > > >> > 4.1. MX Matching >> > >> > When delivering mail for the Policy Domain to a recipient MX host, >> > the sender validates the MX match against the "mx" pattern from the >> > applied policy. The semantics for these patterns are those found i= n >> > section 6.4 of [RFC6125]. >> >> Assuming this text survives, replace: >> >> validates the MX match against the "mx" pattern >> >> with something like >> >> ensures that the MX host name is consistent with the "mx" >> property of the STS policy (only matching MX hosts are >> used in delivery attempts). >> >> The reference to rfc6125 is rather unfortunate here, since it defines >> semantics for presented identifiers, not reference identifiers. >> > > If this field is used to validate the server certificate (and not the MX > hostnames) as you suggested above, that would entail validating the > presented identifier, which I think resolves your comment. > > >> Here, if the proposal to switch from "mx" to "san" is taken up, the >> peer certificate is no longer restricted to authenticate the MX hostname= , >> rather, one its presented identifiers needs to match one of the referenc= e >> identifiers fro the "san" policy attribute. Either way some discussion >> is appropriate of how to perform matching when both the reference and >> the presented identifiers are "wildcards". >> > > Ah, good point--this is a bit of additional complexity implied by your > suggested change. > > One option would be to merely disallow wildcards in the "mx" (or "san") > field. Assuming people do not have full (non-wildcarded) hostnames in the= ir > server certificates, this should work fine. (IOW, for Google, we would > change "*.aspmx.l.google.com" to "mail.google.com" or some other suitable > name.) Upside: easy to use existing validation code to check (e.g. > https://golang.org/src/crypto/tls/common.go?s=3D12153:20652#L426). > Downside: I guess this would be cumbersome if someone for some reason has= a > fully specified hostname as the CN/SAN in their server cert. > > Another: Specify our own matching rules for wildcards on both identifiers= . > It's not really that complicated, but I don't favor making people write > this and possibly make mistakes. > > > When a message fails to deliver due to an "enforce" policy, a >> > compliant MTA MUST check for the presence of an updated policy at t= he >> > Policy Domain before permanently failing to deliver the message. >> > This allows implementing domains to update long-lived policies on t= he >> > fly. >> >> This seems to suggest the contrary, i.e. that it might be appropriate >> to bounce on policy failure when a more fresh policy still fails. >> However certificate problems (expiration most typically) are transient, >> and a receiving system operator should/may notice the problem before >> outstanding messages expire and bounce. So I would urge implementors >> to queue, rather than bounce, on authentication failure. >> > > Rather, the point of this was to encourage implemenors to _not_ bounce > until at least updating the policy once, not to encourage them to bounce > _after_ such an update. So I think we agree, but the wording may be > suboptimal. > > >> Step 0: If the sending MTA is DANE-capable, the destination is >> DNSSEC signed, and one or more of the MX hosts have DANE TLSA >> records, then DANE TLSA preempts STS (more downgrade-resistant, >> works on first contact, ...). >> >> This is another reason to avoid STS-based MX filtering, with DNSSEC >> signed destinations the security of the MX records is sufficiently >> established, and we need to be able to proceed with DANE MX by MX, >> using STS policy only for MX hosts with no TLSA records. >> > > With the suggested change to use STS only to validate the server > certificates and not to do MX filtering, this is obviated, no? I don't > really favor specifying whether senders should do an AND or an OR in > applying DANE and STS when both are present, and with that change it no > longer implies any incompatibilities in MX selection. > > >> >> > 5. Upon message retries, a message MAY be permanently failed >> > following first checking for the presence of a new policy (as >> > indicated by the "id" field in the "mta-sts" TXT record). >> >> I think this is a mistake. Please do not turn transient errors into >> permanent failures. >> > > See above; the intent is not to specify that this should be a perm-fail, > but rather that one should not perm-fail without first checking for a new > policy. I agree on the wording, however. > > Finally, some discussion is appropriate of the fact that given weaker >> downgrade-resistance of STS viz. DANE, implementations that support >> both should apply DANE first and STS only in its absence. Indeed with >> the MX RRset validated via DNSSEC the "mx" policy element is not really >> needed to prevent MX record forgery, however that depends on the outcome >> of the "mx" vs. "san" discussion. >> >> There should probably be a recommendation that sending systems implement >> DANE in addition to STS. It is much easier to use a validating resolver >> than to sign one's own domain, and so the barrier to option of outbound >> DANE is significantly lower. I'll have some additional implementation >> news to report shortly... >> > > I'm good with putting that here (unlike my objection above); it seems > appropriate to note the tradeoffs in Security Considerations in some form= . > > >> >> > 10.1. Example 1 >> > >> > The owner of "example.com" wishes to begin using STS with a policy >> > that will solicit reports from receivers without affecting how the >> > messages are processed, in order to verify the identity of MXs that >> > handle mail for "example.com", confirm that TLS is correctly used, >> > and ensure that certificates presented by the recipient MX validate= . >> > >> > STS policy indicator TXT RR: >> > >> > mta-sts.example.com. IN TXT "v=3DSTSv1; id=3D20160831085700Z;= " >> > >> > STS Policy JSON served as the response body at [1] >> > >> > { >> > "version": "STSv1", >> > "mode": "report", >> > "mx": ["mx1.example.com", "mx2.example.com"], >> > "max_age": 123456 >> > } >> >> Note, the "max_age" here is barely over a day, which is not consistent >> with >> the recommended policy lifetimes. Even "report" policies should probabl= y >> have better downgrade protection through longer lifetimes (say a week or >> more). >> > > I think that max_age was chosen because of the sequential nature of the > numbers and not its value. ;) But point taken. > > >> Should that be "complaint" or "compliant"? :-) I would expect that >> sane implementations will use cached policies first, and only both >> refreshes based on TXT record changes or refresh timers, with updates >> in the background. Synchronous updates of policy at message delivery >> time are exceedingly unappealing at least to me. >> > > It's presented as such here only for ease of following the logic, not to > suggest that one should prefer a synchronous fetch. > > >> > func certMatches(connection, mx) { >> > // Return if the server certificate from "connection" matches the >> "mx" host. >> >> This could use a detailed discussion of what "matches" means, or a >> back-reference to a section that does. Covering wildcard use in >> either or both of the reference and presented identifiers, and >> possible additional text if "mx" becomes "san". >> > > As discussed above, I'm not a huge fan of doing > wildcards-on-both-sides...but let's conclude on that discussion first. > >> >> What's happening with "status" here? I think the first assignment goes.= .. >> > > Man, who wrote this code? ;) > > >> There are potential complications when an MX host >> accepts a proper subset of the envelope recipients >> and tempfails the rest, or fails for reasons unrelated >> to policy, ... So a simple boolean here is not enough. >> Delivery to backup MX hosts continues so long as >> recipients that are neither delivered nor permanently >> rejected remain. STS policy failure is just one way >> that (all the) recipients may remain unresolved. >> > > Well, the goal is not to implement a complete SMTP server here in > pseudocode. ;) > > For clarity I'd probably keep that elided, unless you think it introduces > confusion. > > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > > --001a1145be46d3c89c054ba79fdc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 22, 2017 at 12:39 PM, Daniel Margolis <dma= rgolis@google.com> wrote:
<snip>
=C2=A0
Here, as discussed on the list, serious consideration should be given
to changing the semantics from validating the MX hostname to specifying
the names allowed in the server's certificate.=C2=A0 This simplifies MX= processing
(which remains unmodified) and merely changes the conditions under which an=
MX host is considered suitably authenticated per the policy.

Which, for example, allows the MX hosts to share a single certificate
with the destination domain (and not the MX hostname) as its DNS SAN.
If the policy lists that (shared) name as what's expected in the certif= icate,
then authentication succeeds when the MX host's certificate matches one= of
the allowed names.

That's=20 interesting. I think it's not actually that big a change--we just get= =20 rid of the MX host filtering and instead just apply the logic to=20 validation.=C2=A0

Downsides:

<= div>1. Misconfigurations _may_ be less obvious without connecting to the SMTP=20 server. That is, today, you can spot some kinds of misconfigurations by=20 merely looking at the DNS (so for example my test tool here=C2=A0http://sts.x.af0.net/ first l= ooks at =C2=A0DNS, and only then tries SMTP connections).
2. As y= ou say, it requires some changes to server certificate validation, but not = much.=C2=A0

I don't consider #1 compelling. So= this seems fairly reasonable to me, but I will let others chime in.
<= div>

FWIW, I'm nervous about the idea of introducing non-standard server cert=20 validation. It's not that complex, but certainly unexpected to people= =20 with experience deploying HTTPS. It also looks like some of the rationale i= s to enable reuse of website keys/certs, which while valid probably=20 isn't desirable because of the risks of reusing the same keys for multi= ple purposes/with multiple software configurations (as was demonstrated in = the DROWN paper https://drownattack.co= m/)


On Wed, Mar 22, 2017 at 12:39 PM, Daniel Margolis <= ;dmargolis@google= .com> wrote:
Thanks, Viktor!=C2=A0

Some comments inline, of course= . ;)=C2=A0

<= span class=3D"">On Wed, Mar 22, 2017 at 6:04 AM, Viktor Dukhovni <ie= tf-dane@dukhovni.org> wrote:

>=C2=A0 =C2=A0 While such _opportunistic_ encryption protocols provide a= high

While "_" may work as italics in MarkDown, you'll need to cha= nge all
these to RFC XML (where IIRC <i>...</i> may be supported, but d= on't
take my word for it, check).

(Th= is is just some mistake in our markdown->xml transformation. Beats me, b= ut good catch.)
=C2=A0

>=C2=A0 =C2=A0 o=C2=A0 Policy Domain: The domain for which an STS Policy= is defined.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(For example, when sending mail to "alice@example.com&q= uot;, the policy
>=C2=A0 =C2=A0 =C2=A0 =C2=A0domain is "example.com".)

Perhaps this should mention that more generally this is the nexthop
domain for SMTP delivery, and when mail routing is pre=C3=ABmpted by
by explicit relays via local policy, the Policy domain is the
domain name of the explicit relay (prior to any MX lookups if
applicable).

We mention this exp= licitly in section=C2=A03.4.=C2=A0
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
>=C2=A0 DANE requires DNSSEC [RFC4033]
>=C2=A0 =C2=A0 for authentication; the mechanism described here instead = relies on
>=C2=A0 =C2=A0 certificate authorities (CAs) and does not require DNSSEC= .=C2=A0 For a
>=C2=A0 =C2=A0 thorough discussion of this trade-off, see the section _S= ecurity_
>=C2=A0 =C2=A0 _Considerations_.

The Security Considerations section (once again this is not MarkDown)
will need to properly discuss the downgrade exposure of STS on first
contact, and this trade-off probably should be mentioned here up-front.
=

We mention this (briefly) already, = but maybe don't do it justice. In particular, while we say that "[= t]he sender policy cache is designed to resist this attack," we don= 9;t call out explicitly the implied benefit of longer max_ages and longer c= aching.
=C2=A0
>=C2=A0 =C2=A0 In addition, SMTP STS provides an optional report-only mo= de, enabling
>=C2=A0 =C2=A0 soft deployments to detect policy failures.

It is easy to define a couple of new "certificate usage" code-poi= nts
for DANE that similarly signal "soft-fail" (with reporting).=C2= =A0 Would
the group strongly support a draft along those lines?=C2=A0 I am not sure that a merely "tamper-evident" operating mode is a good idea as a=
persistent operating state, and I think that the ability to have
one or more (backup, i.e. worse preference) MX hosts without TLSA
records adequately addresses the need for incremental deployment.

Agreed. It's a difference from DANE (= necessitated in part by the fact that DANE policies are per-MX rather than,= as with STS, per-domain, so DANE has a different mechanism to allow increm= ental rollouts). I would not suggest it's better or worse, but supporti= ng soft failures in this matter seems the easiest way to support testing a = policy in the STS model, no?=C2=A0
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> Given earlier discussion on the list, while new "id" values can g= ive
expedited signals to refresh the policy, it may be appropriate here,
(but perhaps later in the document as you see fit) to describe a
recommended approach to proactively refresh policies prior to their
pending expiration, this reduces the probability of "gaps" in pol= icy
coverage if the remote HTTPS service is unavailable just as a policy
is expiring

Agreed. =C2=A0
=
=C2=A0
Here, as discussed on the list, serious consideration should be given
to changing the semantics from validating the MX hostname to specifying
the names allowed in the server's certificate.=C2=A0 This simplifies MX= processing
(which remains unmodified) and merely changes the conditions under which an=
MX host is considered suitably authenticated per the policy.

Which, for example, allows the MX hosts to share a single certificate
with the destination domain (and not the MX hostname) as its DNS SAN.
If the policy lists that (shared) name as what's expected in the certif= icate,
then authentication succeeds when the MX host's certificate matches one= of
the allowed names.

That's in= teresting. I think it's not actually that big a change--we just get rid= of the MX host filtering and instead just apply the logic to validation.= =C2=A0

Downsides:

1. Misc= onfigurations _may_ be less obvious without connecting to the SMTP server. = That is, today, you can spot some kinds of misconfigurations by merely look= ing at the DNS (so for example my test tool here=C2=A0http://sts.x.af0.net/ first looks at =C2= =A0DNS, and only then tries SMTP connections).
2. As you say, it = requires some changes to server certificate validation, but not much.=C2=A0=

I don't consider #1 compelling. So this seems= fairly reasonable to me, but I will let others chime in.

I've been quite hesitant to entertain any "business logic&= quot; changes at this point if we could avoid it, since we already have som= e code written, but like I said, I don't think this is actually a very = large change.=C2=A0
=C2=A0

It should be made clear that the names here are always in A-label form
and not U-label form (as they also are in DNS names in certificates).

This is specified in 3.2.=C2=A0
=
=C2=A0
Furthermore, I think that using "*.example.com" in what are essenti= ally
(rfc6125) reference identifiers creates confusion with similar-looking, but=
semantically distinct wildcard names in certificates.=C2=A0 My suggestion w= as
".= example.com" for sub-domain matching, with the policy optionally s= pecifying
whether only single-label prefixes are accepted, or whether in fact multi-l= abel
prefixes are also valid.

Well, I= think our matching is a subset of the matching defined in RFC6125 section= =C2=A06.4.3. We could specify that we support the full policy; it seemed wo= rth a simplification (i.e. we don't support 'something*.domain.com', only '*.domain.com') to make imp= lementation easier, but at cost of a semantic difference. If we get rid of = the wildcard, I suppose it is indeed more obvious that we're just doing= only suffix matching. Was that your point?
=C2= =A0
FWIW, I would have chosen something less fancy than JSON for
what is clearly a simple array of attribute/value pairs. ESMTP
already encodes such optional A/V pairs as space separated lists
of attr=3Dvalue with xtext encoding as needed (it is not needed for
any plausible value of the above attributes).

I seem to recall that we started with simple key-value pairs = and moved to JSON because people variously seemed to think this was easier = (since parsing libraries are common). I would also consider the vague possi= bility that in future iterations we wish to add fields.=C2=A0
De novo, I myself have no real opinion here, because certainly = either work, but of course I'm loath to make changes again. I'd app= reciate more feedback from more readers, though, as these style discussions= are always a bit subjective. I assume that for Postfix policy fetching is = a background process anyway, though, so it isn't (I would hope) too big= an implementation difference for you, right?
= =C2=A0
We're not going to add a JSON decoder to the Postfix SMTP client,
but if this specification retains JSON, then the code that does
background policy retrieval will need to transform JSON into
something more friendly to traditional C-based MTA implementations.

> 4.=C2=A0 Policy Validation

Are we validating the policy or using the policy to authenticate
the MX host?=C2=A0 I think the name of this section is suboptimal.

>=C2=A0 =C2=A0 When sending to an MX at a domain for which the sender ha= s a valid
>=C2=A0 =C2=A0 and non-expired SMTP MTA-STS policy, a sending MTA honori= ng SMTP STS
>=C2=A0 =C2=A0 MUST validate:

s/validate/check/ or /ensure/.

>=C2=A0 =C2=A0 1.=C2=A0 That the recipient MX matches the "mx"= pattern from the recipient
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 domain's policy.

See above, perhaps "mx" becomes "san" and the check is = deferred until
it is time to verify the host's certificate.

>=C2=A0 =C2=A0 2.=C2=A0 That the recipient MX supports STARTTLS and offe= rs a valid PKIX
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 based TLS certificate.

Here, it would be prudent to mention rfc6125, and be explicit about
the acceptable wildcard patterns in that certificate.=C2=A0 See, for exampl= e:

=C2=A0 =C2=A0https://tools.ietf.org/html/rfc76= 72#section-3.2.3

which limits certificate wildcards to the entire first label only.=C2=A0 I<= br> would like to avoid supporting more general wildcards in new
specifications.

We specify this = in 4.1 (as you discovered below), but maybe that's too late.=C2=A0
=C2=A0

>=C2=A0 =C2=A0 This section does not dictate the behavior of sending MTA= s when
>=C2=A0 =C2=A0 policies fail to validate; in particular, validation fail= ures of
>=C2=A0 =C2=A0 policies which specify "report" mode MUST NOT b= e interpreted as
>=C2=A0 =C2=A0 delivery failures, as described in the section _Policy_ >=C2=A0 =C2=A0 _Application_.

The first sentence is unfortunate, you are in fact specifying behaviour, in the very next sentence.=C2=A0 It might be better to add a forward-refere= nce
to a section that provides a detailed explanation and not start with a
disclaimer.

Heh. Thanks. ;)
=C2=A0
> 4.1.=C2=A0 MX Matching
>
>=C2=A0 =C2=A0 When delivering mail for the Policy Domain to a recipient= MX host,
>=C2=A0 =C2=A0 the sender validates the MX match against the "mx&qu= ot; pattern from the
>=C2=A0 =C2=A0 applied policy.=C2=A0 The semantics for these patterns ar= e those found in
>=C2=A0 =C2=A0 section 6.4 of [RFC6125].

Assuming this text survives, replace:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 validates the MX match against the "mx&quo= t; pattern

with something like

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ensures that the MX host name is consistent wit= h the "mx"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 property of the STS policy (only matching MX ho= sts are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 used in delivery attempts).

The reference to rfc6125 is rather unfortunate here, since it defines
semantics for presented identifiers, not reference identifiers.

If this field is used to validate the serve= r certificate (and not the MX hostnames) as you suggested above, that would= entail validating the presented identifier, which I think resolves your co= mment.=C2=A0
=C2=A0
Here, if the proposal to switch from "mx" to "san" is t= aken up, the
peer certificate is no longer restricted to authenticate the MX hostname, rather, one its presented identifiers needs to match one of the reference identifiers fro the "san" policy attribute.=C2=A0 Either way some= discussion
is appropriate of how to perform matching when both the reference and
the presented identifiers are "wildcards".
<= br>
Ah, good point--this is a bit of additional complexity= implied by your suggested change.=C2=A0

One optio= n would be to merely disallow wildcards in the "mx" (or "san= ") field. Assuming people do not have full (non-wildcarded) hostnames = in their server certificates, this should work fine. (IOW, for Google, we w= ould change "*.aspmx.l.google.com" to "mail.google.com" or some other suitable name.) Up= side: easy to use existing validation code to check (e.g.=C2=A0https://golang.org/src/crypto/tls/common.go?s=3D12153:206= 52#L426). Downside: I guess this would be cumbersome if someone for som= e reason has a fully specified hostname as the CN/SAN in their server cert.= =C2=A0

Another: Specify our own matching rules for= wildcards on both identifiers. It's not really that complicated, but I= don't favor making people write this and possibly make mistakes.=C2=A0=

>=C2=A0 =C2=A0 When a message fails to deliver due to an &q= uot;enforce" policy, a
>=C2=A0 =C2=A0 compliant MTA MUST check for the presence of an updated p= olicy at the
>=C2=A0 =C2=A0 Policy Domain before permanently failing to deliver the m= essage.
>=C2=A0 =C2=A0 This allows implementing domains to update long-lived pol= icies on the
>=C2=A0 =C2=A0 fly.

This seems to suggest the contrary, i.e. that it might be appropriate
to bounce on policy failure when a more fresh policy still fails.
However certificate problems (expiration most typically) are transient,
and a receiving system operator should/may notice the problem before
outstanding messages expire and bounce.=C2=A0 So I would urge implementors<= br> to queue, rather than bounce, on authentication failure.

Rather, the point of this was to encourage impleme= nors to _not_ bounce until at least updating the policy once, not to encour= age them to bounce _after_ such an update. So I think we agree, but the wor= ding may be suboptimal.=C2=A0
=C2=A0
Step 0:=C2=A0 If the sending MTA is DANE-capable, the destination is
DNSSEC signed, and one or more of the MX hosts have DANE TLSA
records, then DANE TLSA preempts STS (more downgrade-resistant,
works on first contact, ...).

This is another reason to avoid STS-based MX filtering, with DNSSEC
signed destinations the security of the MX records is sufficiently
established, and we need to be able to proceed with DANE MX by MX,
using STS policy only for MX hosts with no TLSA records.

With the suggested change to use STS only to valid= ate the server certificates and not to do MX filtering, this is obviated, n= o? I don't really favor specifying whether senders should do an AND or = an OR in applying DANE and STS when both are present, and with that change = it no longer implies any incompatibilities in MX selection.=C2=A0
=C2=A0

>=C2=A0 =C2=A0 5.=C2=A0 Upon message retries, a message MAY be permanent= ly failed
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 following first checking for the presence o= f a new policy (as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 indicated by the "id" field in th= e "mta-sts" TXT record).

I think this is a mistake.=C2=A0 Please do not turn transient errors into permanent failures.

See above; t= he intent is not to specify that this should be a perm-fail, but rather tha= t one should not perm-fail without first checking for a new policy. I agree= on the wording, however.=C2=A0

Finally, some discussion is appropriate of the fact that given weaker
downgrade-resistance of STS viz. DANE, implementations that support
both should apply DANE first and STS only in its absence.=C2=A0 Indeed with=
the MX RRset validated via DNSSEC the "mx" policy element is not = really
needed to prevent MX record forgery, however that depends on the outcome of the "mx" vs. "san" discussion.

There should probably be a recommendation that sending systems implement DANE in addition to STS.=C2=A0 It is much easier to use a validating resolv= er
than to sign one's own domain, and so the barrier to option of outbound=
DANE is significantly lower.=C2=A0 I'll have some additional implementa= tion
news to report shortly...

I'= m good with putting that here (unlike my objection above); it seems appropr= iate to note the tradeoffs in Security Considerations in some form.=C2=A0
=C2=A0

> 10.1.=C2=A0 Example 1
>
>=C2=A0 =C2=A0 The owner of "example.com" wishes to begin using S= TS with a policy
>=C2=A0 =C2=A0 that will solicit reports from receivers without affectin= g how the
>=C2=A0 =C2=A0 messages are processed, in order to verify the identity o= f MXs that
>=C2=A0 =C2=A0 handle mail for "example.com", confirm that TLS i= s correctly used,
>=C2=A0 =C2=A0 and ensure that certificates presented by the recipient M= X validate.
>
>=C2=A0 =C2=A0 STS policy indicator TXT RR:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mta-sts.example.com.=C2=A0 IN TX= T "v=3DSTSv1; id=3D20160831085700Z;"
>
>=C2=A0 =C2=A0 STS Policy JSON served as the response body at [1]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ver= sion": "STSv1",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"mod= e": "report",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"mx&= quot;: ["mx1.example.com", "mx2.example.com"],
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"max= _age": 123456
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

Note, the "max_age" here is barely over a day, which is not consi= stent with
the recommended policy lifetimes.=C2=A0 Even "report" policies sh= ould probably
have better downgrade protection through longer lifetimes (say a week or mo= re).

I think that max_age was ch= osen because of the sequential nature of the numbers and not its value. ;) = But point taken.=C2=A0
=C2=A0
Should that be "complaint" or "compliant"? :-)=C2=A0 I = would expect that
sane implementations will use cached policies first, and only both
refreshes based on TXT record changes or refresh timers, with updates
in the background.=C2=A0 Synchronous updates of policy at message delivery<= br> time are exceedingly unappealing at least to me.

<= /div>
It's presented as such here only for ease of following= the logic, not to suggest that one should prefer a synchronous fetch.=C2= =A0
=C2=A0
> func certMatches(connection, mx) {
>=C2=A0 =C2=A0// Return if the server certificate from "connection&= quot; matches the "mx" host.

This could use a detailed discussion of what "matches" means, or = a
back-reference to a section that does.=C2=A0 Covering wildcard use in
either or both of the reference and presented identifiers, and
possible additional text if "mx" becomes "san".

As discussed above, I'm not a huge = fan of doing wildcards-on-both-sides...but let's conclude on that discu= ssion first.=C2=A0

What's happening with "status" here?=C2=A0 I think the first = assignment goes...

Man, who wrot= e this code? ;)=C2=A0
=C2=A0
There are potential complications when = an MX host
accepts a proper subset of the envelope recipients
and tempfails the rest, or fails for reasons unrelated
to policy, ... So a simple boolean here is not enough.
Delivery to backup MX hosts continues so long as
recipients that are neither delivered nor permanently
rejected remain.=C2=A0 STS policy failure is just one way
that (all the) recipients may remain unresolved.

<= /div>
Well, the goal is not to implement a complete SMTP server = here in pseudocode. ;)=C2=A0

For clarity I'd p= robably keep that elided, unless you think it introduces confusion.=C2=A0
=C2=A0


_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta


--001a1145be46d3c89c054ba79fdc-- From nobody Sun Mar 26 13:38:11 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644C3128616 for ; Sun, 26 Mar 2017 13:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIXkEQ0ARuDm for ; Sun, 26 Mar 2017 13:38:08 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2731912773A for ; Sun, 26 Mar 2017 13:38:08 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 158AD7A32F1 for ; Sun, 26 Mar 2017 20:38:07 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Viktor Dukhovni In-Reply-To: Date: Sun, 26 Mar 2017 16:38:05 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: <264C672A-6AAA-42F2-A73D-2F6AE7A1AB29@dukhovni.org> References: <4C0807DA-4852-4DAC-80ED-8A25371CFFAA@dukhovni.org> To: uta@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Uta] MTA-STS-03 review X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 20:38:10 -0000 > On Mar 26, 2017, at 3:56 PM, David Illsley = wrote: >=20 >>> Here, as discussed on the list, serious consideration should be = given >>> to changing the semantics from validating the MX hostname to = specifying >>> the names allowed in the server's certificate. This simplifies MX = processing >>> (which remains unmodified) and merely changes the conditions under = which an >>> MX host is considered suitably authenticated per the policy. >>>=20 >>> Which, for example, allows the MX hosts to share a single = certificate >>> with the destination domain (and not the MX hostname) as its DNS = SAN. >>> If the policy lists that (shared) name as what's expected in the = certificate, >>> then authentication succeeds when the MX host's certificate matches = one of >>> the allowed names. >>=20 >> That's interesting. I think it's not actually that big a change--we = just get rid of the MX host filtering and instead just apply the logic = to validation.=20 >>=20 >> Downsides: >>=20 >> 1. Misconfigurations _may_ be less obvious without connecting to >> the SMTP server. That is, today, you can spot some kinds of >> misconfigurations by merely looking at the DNS (so for example >> my test tool here http://sts.x.af0.net/ first looks at DNS, and >> only then tries SMTP connections). >>=20 >> 2. As you say, it requires some changes to server certificate >> validation, but not much.=20 >>=20 >> I don't consider #1 compelling. So this seems fairly reasonable >> to me, but I will let others chime in. >=20 > FWIW, I'm nervous about the idea of introducing non-standard > server cert validation. It's not that complex, but certainly > unexpected to people with experience deploying HTTPS. Well, TLS for MTA-to-MTA SMTP *is* very different from TLS for HTTPS. Reasoning by analogy with HTTPS often leads to incorrect conclusions. So, from my perspective, looking more obviously different from HTTPS is a feature. :-) > It also looks like some of the rationale is to enable reuse of > website keys/certs, No, not *reuse*, rather compatibility with pre-STS practice. Because MX records are untrusted absent DNSSEC, there is an existing practice to employ the recipient domain, rather than the MX hostname, as the DNS name in the certificate. This is one with "UCC" certificates. I'm one of the early instigators of this practice. I introduced it with Postfix "secure" TLS policy, and later recommended it to Microsoft for implementation in Exchange 2007. http://www.postfix.org/postconf.5.html#smtp_tls_security_level http://www.postfix.org/TLS_README.html#client_tls_limits https://technet.microsoft.com/en-us/library/bb266978(v=3Dexchg.80).aspx= So the idea is not "sharing", but compatibility with existing practice, as some domains may employ both STS and explicit TLS peering with business partners. The main motivation for the proposal is to get out of the way of MX host selection and constrain just certificate matching. > which while valid probably isn't desirable because of the risks of > reusing the same keys for multiple purposes/with multiple software > configurations (as was demonstrated in the DROWN paper > https://drownattack.com/ Ironic you mention DROWN: DROWN: Breaking TLS using SSLv2 Nimrod Aviram, Sebastian Schinzel, Juraj Somorovsky, Nadia Heninger, Maik Dankel, Jens Steube5, Luke Valenta, David Adrian, J. Alex Halderman, Viktor Dukhovni[7], Emilia Ka=CC=88sper, Shaanan Cohney, Susanne Engels, Christof Paar and Yuval Shavitt [7] Two Sigma/OpenSSL For the record, I do not recommend sharing a single certificate among multiple MX hosts, or between email and other services. In addition to DROWN, (which really helped drive SSLv2 support out of the ecosystem). The primary reason to avoid sharing certificates among MX hosts is to avoid a single point of failure. Operational errors in shared certificate/key rotation tend to break all the MX hosts at once. The operational issue dwarfs DROWN in its significance. --=20 Viktor. From nobody Sun Mar 26 13:52:25 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E941296C6 for ; Sun, 26 Mar 2017 13:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vagJXjF9mzAQ for ; Sun, 26 Mar 2017 13:52:22 -0700 (PDT) Received: from blitiri.com.ar (cdt.blitiri.com.ar [IPv6:2001:41d0:401:3100::2c1a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0EA81296B7 for ; Sun, 26 Mar 2017 13:52:21 -0700 (PDT) Received: from blitiri.com.ar (authenticated as alb@blitiri.com.ar) by cdt.blitiri.com.ar (chasquid) (over submission TLS-1.2-TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) (envelope from "albertito@blitiri.com.ar") ; Sun, 26 Mar 2017 22:52:19 +0200 Date: Sun, 26 Mar 2017 21:52:18 +0100 From: Alberto Bertogli To: Daniel Margolis Cc: uta@ietf.org Message-ID: <20170326205218.GN11426@blitiri.com.ar> References: <4C0807DA-4852-4DAC-80ED-8A25371CFFAA@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Uta] MTA-STS-03 review X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 20:52:24 -0000 Hi! Not sure if it's worth much, but my 0.7 cents inline :) On Wed, Mar 22, 2017 at 01:39:54PM +0100, Daniel Margolis wrote: > > Here, as discussed on the list, serious consideration should be given > > to changing the semantics from validating the MX hostname to specifying > > the names allowed in the server's certificate. This simplifies MX > > processing > > (which remains unmodified) and merely changes the conditions under which an > > MX host is considered suitably authenticated per the policy. > > > Which, for example, allows the MX hosts to share a single certificate > > with the destination domain (and not the MX hostname) as its DNS SAN. > > If the policy lists that (shared) name as what's expected in the > > certificate, > > then authentication succeeds when the MX host's certificate matches one of > > the allowed names. > > > > That's interesting. I think it's not actually that big a change--we just > get rid of the MX host filtering and instead just apply the logic to > validation. This would make certificate validation differ from the way it's commonly done, where the check is against the name used to connect to the server. I think that would be a mistake. Certificates are already non trivial to deploy and check, and making validation work in an unusual way introduces complexity in coding in some cases, (maybe not for postfix, of course, but most high level libraries such as Python's or Go's make this more difficult) in a very sensitive and delicate area. It also makes deployment and checks more complex, as wildcard certificates and mentions in the policy don't work in a somewhat unexpected way (I don't think most folks expect wildcards to be matched via string comparison). If it's the filtering that is too much additional complexity, an alternative would be to consider the "mx" field in the policy as an alternative source for the mail servers list (no wildcards allowed in that case, obviously). This has, I think, the same security benefits of the list for filtering, and may be easy to use in some cases. Deployment wise, it's probably not as simple as the filtering, but not terribly more complex, and is easy to understand and automate. I'm not terribly convinced about it, but it could be an alternative to filtering if it's an issue. > > FWIW, I would have chosen something less fancy than JSON for > > what is clearly a simple array of attribute/value pairs. ESMTP > > already encodes such optional A/V pairs as space separated lists > > of attr=value with xtext encoding as needed (it is not needed for > > any plausible value of the above attributes). > > > > I seem to recall that we started with simple key-value pairs and moved to > JSON because people variously seemed to think this was easier (since > parsing libraries are common). I would also consider the vague possibility > that in future iterations we wish to add fields. > > De novo, I myself have no real opinion here, because certainly either work, > but of course I'm loath to make changes again. I'd appreciate more feedback > from more readers, though, as these style discussions are always a bit > subjective. There are lots of advantages of using JSON for this. It is well defined, standard and there are lots of well tested and widely used implementations. It is used widely, it's familiar to many people, and its shortcomings (which are not few, admittedly) are well understood and documented. It support rich types (such as lists), and common libraries already handle difficult situations like non-ascii content, long integers, multi-line strings, malformed/malicious input, etc. Defining an ad-hoc key-value pair format may seem simpler in the short term, but I think it's not worth it, as many things will have to be decided an carefully designed (e.g. multi-line lists). Then parsers have to be implemented with support for a variety of things, and care for malicious input which is usually not trivial. Thanks! Alberto From nobody Sun Mar 26 18:01:40 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFDD128896 for ; Sun, 26 Mar 2017 18:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Orp18NSYtdzl for ; Sun, 26 Mar 2017 18:01:38 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2138E12878D for ; Sun, 26 Mar 2017 18:01:38 -0700 (PDT) Received: from vpro.lan (cpe-98-14-133-144.nyc.res.rr.com [98.14.133.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 5594C7A32F1 for ; Mon, 27 Mar 2017 01:01:37 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Viktor Dukhovni In-Reply-To: <20170326205218.GN11426@blitiri.com.ar> Date: Sun, 26 Mar 2017 21:01:36 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: <92500952-2A50-4508-8686-03CDBF72485D@dukhovni.org> References: <4C0807DA-4852-4DAC-80ED-8A25371CFFAA@dukhovni.org> <20170326205218.GN11426@blitiri.com.ar> To: uta@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Uta] MTA-STS-03 review X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 01:01:40 -0000 > On Mar 26, 2017, at 4:52 PM, Alberto Bertogli = wrote: >=20 > There are lots of advantages of using JSON for this. It is well = defined, > standard and there are lots of well tested and widely used > implementations. >=20 > It is used widely, it's familiar to many people, and its shortcomings > (which are not few, admittedly) are well understood and documented. Sure JSON is used widely in all kinds of software, but NOT in MTAs, and STS is for MTAs. > It support rich types (such as lists), and common libraries already > handle difficult situations like non-ascii content, long integers, > multi-line strings, malformed/malicious input, etc. Sure in Perl, Python, Go, ... but Sendmail, Qmail, Postfix and Exim are in C, and already have code to handle ESMTP attr=3Dvalue lists, and don't currently use JSON. The extra features of JSON you mention are not needed for this specification, and over-engineering to use JSON is IMHO not useful. --=20 Viktor. From nobody Mon Mar 27 01:08:29 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9325129474 for ; Mon, 27 Mar 2017 01:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVoWnqB-2S3f for ; Mon, 27 Mar 2017 01:08:26 -0700 (PDT) Received: from mx-r1.mag-news.it (mx-r1.mag-news.it [46.29.201.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E01531293DA for ; Mon, 27 Mar 2017 01:08:25 -0700 (PDT) Received: from mail1.mag-news.it by diennea.com (mx-r1.mag-news.it) (SecurityGateway 4.0.1) with ESMTP id SG003449555.MSG for ; Mon, 27 Mar 2017 10:08:23 +0200S Received: from EXC01-Arezzo.diennea.lan (10.80.108.190) by EXC01-Arezzo.diennea.lan (10.80.108.190) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 27 Mar 2017 10:08:21 +0200 Received: from EXC01-Arezzo.diennea.lan ([fe80::5104:cf16:9c4c:7fda]) by EXC01-Arezzo.diennea.lan ([fe80::5104:cf16:9c4c:7fda%19]) with mapi id 15.00.1178.000; Mon, 27 Mar 2017 10:08:21 +0200 From: Federico Santandrea - Diennea To: "uta@ietf.org" Thread-Topic: Comments on draft-ietf-uta-mta-sts-03 Thread-Index: AdKm0IX3L57s0I0dQZiX286rNOg8GA== Date: Mon, 27 Mar 2017 08:08:21 +0000 Message-ID: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.168.1.170] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SGSPF-Result: none (mx-r1.mag-news.it) Archived-At: Subject: [Uta] Comments on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 08:08:29 -0000 Here's something that came to my mind while reading draft-ietf-uta-mta-sts-= 03. Let's suppose the sending MTA finds the MTA-STS TXT record, which states the receiving domain has an MTA-STS policy. The draft says "To discover if a recipient domain implements MTA-STS, a sender need only resolve a single TXT record". But what happens when the sending MTA can't fetch the actual policy via HTTPS? Now the sending MTA knows MTA-STS should be in place, but can't know what the list of expected MX is. It has to decide what to do. - If it refuses to send the message, and the (unreachable) policy states that it is in "report" mode, this can be considered a denial of service. - If instead it falls back to deliver the message to any available MX, either encrypted or in plain text, or even acts as if the domain had not stated it had an MTA-STS policy at all; and the (unreachable) policy states that it is in "enforce" mode, then effectively this was degraded to opportunistic. Making the HTTPS endpoint unreachable is just a DDoS attack away. This would expose all first-contact sending MTAs to this conundrum. I think there is a need to clearly state what must be done in such a situation. For example we could add to Section 3.3: "If a MTA-STS TXT record is found but no policy can be fetched from the HTTPS endpoint, and there is no previous cached policy, then senders MUST assume the recipient domain does not implement MTA-STS." While this does not really improve the situation, it makes clear for the implementor of the receiving side that this is effectively equivalent to opportunistic encryption and allows for countermeasures to be considered. The reason for the "no previous cached policy" part is to provide for the first-contact scenario, but there is another one: what if instead the sender has previously seen a policy for the domain, but now it's expired (because of max_age or new id in the TXT record) and it can't fetch a new one? I propose that we let the domain owner decide, by stating it in the at a time when it was reachable. We could add a "fallback_mode" property to the policy object, with possible values: "block", "keep_expired", "opportunistic" (names are provisional and for illustration only). This property would define what the sending MTA is to do when it must fetch a new policy but can't: - "block" would state confidentiality is still favored over availability, therefore since the new expected MX list is not known (and might be missing compromised servers), messages must be discarded or retried at a later time when the endpoint might be available again; - "keep_expired" would keep applying the cached policy, which would not be discarded until it's possible to fetch a new one. I see this as useful because to me it's often the case that an expired policy would be more useful than no policy at all. - "opportunistic" would say that, in this non-normal scenario, availability is to be favored over availability, so the sender should discard the expired policy and act like in the previously explained first-contact scenario. The last one of course would mean that it's possible to force a fall back to plaintext by making the HTTPS endpoint unavailable until a policy expires, but the domain owner would have chosen this explicitly and has to understand that. -- Federico ________________________________ Iscriviti alla nostra newsletter per rimanere aggiornato su digital ed emai= l marketing! http://www.magnews.it/newsletter/ The information in this email is confidential and may be legally privileged= . If you are not the intended recipient please notify the sender immediatel= y and destroy this email. Any unauthorized, direct or indirect, disclosure,= copying, storage, distribution or other use is strictly forbidden. From nobody Mon Mar 27 01:21:16 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3891294B1 for ; Mon, 27 Mar 2017 01:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gusgDjW_TJqa for ; Mon, 27 Mar 2017 01:21:13 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7274A1294A3 for ; Mon, 27 Mar 2017 01:21:12 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 682AD7A32F1 for ; Mon, 27 Mar 2017 08:21:11 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Viktor Dukhovni In-Reply-To: Date: Mon, 27 Mar 2017 04:21:10 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: References: To: uta@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 08:21:15 -0000 > On Mar 27, 2017, at 4:08 AM, Federico Santandrea - Diennea = wrote: >=20 >=20 > Let's suppose the sending MTA finds the MTA-STS TXT record, which = states > the receiving domain has an MTA-STS policy. The draft says "To = discover > if a recipient domain implements MTA-STS, a sender need only resolve a > single TXT record". But what happens when the sending MTA can't fetch > the actual policy via HTTPS? Keep it simple. It is just as easy to block access to the TXT record as to block access to the HTTPS site. The TXT record is just an efficiency aid, so that MTAs don't have to attempt costly HTTPS connections (that typically time out) to domains with no STS records. Therefore, when the TXT record exists, but STS policy access fails, the right action is to assume no policy (regardless of whether this is a true first contact, or whether a previously cached policy had expired). STS is vulnerable to attack when no cached policy exists. Once the cache is primed, email to destinations that receive ongoing traffic will continue to have unexpired policy data, because the sender should do proactive refresh of the policy before it expires. For first contact, or domains that don't receive sufficiently regular mail, STS is vulnerable to downgrade attacks. So the right behaviour with TXT records that don't lead to a policy, is to continue as though there is no policy. Indeed with Postfix (if/when STS is implemented) I'm likely to always do STS policy lookup in the background, in which case the first (more than one if concurrent) message(s) to a domain will always go out with opportunistic TLS, and secure delivery will only begin once the background policy retrieval succeeds. Delaying delivery while waiting for remote HTTPS lookups to complete is not especially appealing. --=20 Viktor.= From nobody Mon Mar 27 04:41:12 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92BD124BE8 for ; Mon, 27 Mar 2017 04:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1CzdBb3ZuKb for ; Mon, 27 Mar 2017 04:41:08 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51FC2129504 for ; Mon, 27 Mar 2017 04:41:08 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id 190so49036248itm.0 for ; Mon, 27 Mar 2017 04:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=3rEg74fx/lBK0y0CGinOHtbCzwM8aXRK27xahxonLaw=; b=AmL66wR3B2S3I6lLMWBVj+iRXz2zBRQmJcxsVCm6SizCZXpnwouIjg6/U+mP9g969M 7YjphtCvsgT8Aym+y00rBc5qLJlWITMjTS+iJ3CEXW/19+UdFQ9KhtHl4GTF1qTcdUhf rIVpwFJ4m6uNGQ2jklT0dczKn0gJRF2UwZRN5MjRkTXDLownKMiJQjUJzyvAZ7R1ggIu VGEpGlsedxi2xXLwUNcJkvwXdmSF81xys0ejsCkYsLnEeULqpnal07BvsbgbRxqqe1aw oL+rx2W70bbRxpJc2+UWVrZmMFsZVFuN3EfjNwE6gT1Z4vnQ/NarjiqqTmurPZY0HItF 5ABA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=3rEg74fx/lBK0y0CGinOHtbCzwM8aXRK27xahxonLaw=; b=B2Cbwr7MzaYu9/aenr/JFOGSuav6XHnIj3KhhXomZ2dnk/czLiKJcKiVkF+k8KoAsG J93wC0iA5o49yww4FF5qbP+5/m0V9QeZ2tGrElj+7ipdRNwx0Txo4atLNGX7X5aJhJbL NtrHHaZNy99xWoFrz2rVRjcdvq88JlbL8mORbl7JVOWMYQoDPGA5qUpV4kS4xFanh8QI OCGW2ed2uMPyU3uudo1bqHhmGkzgXrqggfkYwV8ISl6Ga9/2faibbz5v1m0l8PWVI16m P7bEOSR6Y6Ns7Wzuva/wtNX7IxMEwzjrHzZnnN/hVsABI269oN/a1vgGBeEItrAHrLws 5E1w== X-Gm-Message-State: AFeK/H0/RuVPT5nxZTjTl90dnz4g9/ywGV1VfTIEr78AA3XKBz0iVeKQ8Y3bQvcPFWAjj/gKUXUoPuXQLDpJw0I3 X-Received: by 10.107.172.134 with SMTP id v128mr23037734ioe.49.1490614866932; Mon, 27 Mar 2017 04:41:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.39.215 with HTTP; Mon, 27 Mar 2017 04:41:05 -0700 (PDT) In-Reply-To: References: From: Daniel Margolis Date: Mon, 27 Mar 2017 13:41:05 +0200 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1148d5d4ae07a4054bb4d146" Archived-At: Subject: Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 11:41:11 -0000 --001a1148d5d4ae07a4054bb4d146 Content-Type: multipart/alternative; boundary=001a1148d5d4a48e10054bb4d141 --001a1148d5d4a48e10054bb4d141 Content-Type: text/plain; charset=UTF-8 I like your text, Federico: "If a MTA-STS TXT record is found but no policy can be fetched from the HTTPS endpoint, and there is no previous cached policy, then senders MUST assume the recipient domain does not implement MTA-STS." I will get this into the latest draft. :) (This was previously implied anyway by the fact that a failure to find a policy means there's no policy, but it's not so clear as you make it with this edit.) Regarding the threat of DoS'ing policy lookup until expiration has passed, as Viktor notes, this is party mitigated by opportunistically fetching new policies every so often (e.g. when delivering to the domain); Viktor has previously suggested we call this out more explicitly in the draft (i.e. that we suggest implementors seek some strategy to keep caches fresh). In this scenario, I do still feel that there's some gap in a mechanism (say, via TLSRPT) to allow senders who have non-expired policies from a recipient domain to tell the recipient domain that they're having trouble fetching that domain's policy, but the solution is not obvious to me and, I think, of a lower priority--if you can DoS policy lookup for order of months, you can potentially foil first discovery, too. And ultimately long-lived DoSes are the kinds of things to best be discovered through other transparency and reporting tools--https://gmail.com/postmaster/, discussions on the IETF list, etc. ;) Anyway, I'm very open to suggestions on how to make this more transparent within the scope of TLSRPT, but I don't love the idea of adding policy complexity by letting recipients specify what to do in this scenario. On Mon, Mar 27, 2017 at 10:21 AM, Viktor Dukhovni wrote: > > > On Mar 27, 2017, at 4:08 AM, Federico Santandrea - Diennea < > federico.santandrea@diennea.com> wrote: > > > > > > Let's suppose the sending MTA finds the MTA-STS TXT record, which states > > the receiving domain has an MTA-STS policy. The draft says "To discover > > if a recipient domain implements MTA-STS, a sender need only resolve a > > single TXT record". But what happens when the sending MTA can't fetch > > the actual policy via HTTPS? > > Keep it simple. It is just as easy to block access to the TXT record as > to block access to the HTTPS site. The TXT record is just an efficiency > aid, so that MTAs don't have to attempt costly HTTPS connections (that > typically time out) to domains with no STS records. > > Therefore, when the TXT record exists, but STS policy access fails, the > right action is to assume no policy (regardless of whether this is a > true first contact, or whether a previously cached policy had expired). > > STS is vulnerable to attack when no cached policy exists. Once the > cache is primed, email to destinations that receive ongoing traffic > will continue to have unexpired policy data, because the sender > should do proactive refresh of the policy before it expires. > > For first contact, or domains that don't receive sufficiently regular > mail, STS is vulnerable to downgrade attacks. > > So the right behaviour with TXT records that don't lead to a policy, > is to continue as though there is no policy. > > Indeed with Postfix (if/when STS is implemented) I'm likely to > always do STS policy lookup in the background, in which case > the first (more than one if concurrent) message(s) to a domain > will always go out with opportunistic TLS, and secure delivery > will only begin once the background policy retrieval succeeds. > > Delaying delivery while waiting for remote HTTPS lookups to > complete is not especially appealing. > > -- > Viktor. > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a1148d5d4a48e10054bb4d141 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I like your text, Federico:=C2=A0
=
"If a MTA-STS TXT record is found but no policy can be = fetched from the
HTTPS endpoint, and there is no previous cached = policy, then senders
MUST assume the recipient domain does not im= plement MTA-STS."

I will get this into = the latest draft. :) (This was previously implied anyway by the fact that a= failure to find a policy means there's no policy, but it's not so = clear as you make it with this edit.)

Regarding th= e threat of DoS'ing policy lookup until expiration has passed, as Vikto= r notes, this is party mitigated by opportunistically fetching new policies= every so often (e.g. when delivering to the domain); Viktor has previously= suggested we call this out more explicitly in the draft (i.e. that we sugg= est implementors seek some strategy to keep caches fresh).=C2=A0
=
In this scenario, I do still feel that there's some gap = in a mechanism (say, via TLSRPT) to allow senders who have non-expired poli= cies from a recipient domain to tell the recipient domain that they're = having trouble fetching that domain's policy, but the solution is not o= bvious to me and, I think, of a lower priority--if you can DoS policy looku= p for order of months, you can potentially foil first discovery, too. And u= ltimately long-lived DoSes are the kinds of things to best be discovered th= rough other transparency and reporting tools--https://gmail.com/postmaster/, discussions on the IETF lis= t, etc. ;)=C2=A0

Anyway, I'm very open to sugg= estions on how to make this more transparent within the scope of TLSRPT, bu= t I don't love the idea of adding policy complexity by letting recipien= ts specify what to do in this scenario.=C2=A0


On Mon, Mar 27, 2017= at 10:21 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> = wrote:

> On Mar 27, 2017, at 4:08 AM, Federico Santandrea - Diennea <federico.santandrea@diennea.com> wrote:
>
>
> Let's suppose the sending MTA finds the MTA-STS TXT record, which = states
> the receiving domain has an MTA-STS policy. The draft says "To di= scover
> if a recipient domain implements MTA-STS, a sender need only resolve a=
> single TXT record". But what happens when the sending MTA can'= ;t fetch
> the actual policy via HTTPS?

Keep it simple.=C2=A0 It is just as easy to block access to the TXT = record as
to block access to the HTTPS site.=C2=A0 The TXT record is just an efficien= cy
aid, so that MTAs don't have to attempt costly HTTPS connections (that<= br> typically time out) to domains with no STS records.

Therefore, when the TXT record exists, but STS policy access fails, the
right action is to assume no policy (regardless of whether this is a
true first contact, or whether a previously cached policy had expired).

STS is vulnerable to attack when no cached policy exists.=C2=A0 Once the cache is primed, email to destinations that receive ongoing traffic
will continue to have unexpired policy data, because the sender
should do proactive refresh of the policy before it expires.

For first contact, or domains that don't receive sufficiently regular mail, STS is vulnerable to downgrade attacks.

So the right behaviour with TXT records that don't lead to a policy, is to continue as though there is no policy.

Indeed with Postfix (if/when STS is implemented) I'm likely to
always do STS policy lookup in the background, in which case
the first (more than one if concurrent) message(s) to a domain
will always go out with opportunistic TLS, and secure delivery
will only begin once the background policy retrieval succeeds.

Delaying delivery while waiting for remote HTTPS lookups to
complete is not especially appealing.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.
_____________________= __________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

--001a1148d5d4a48e10054bb4d141-- --001a1148d5d4ae07a4054bb4d146 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+ q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0 TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg 5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27 8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCD/XDEg0Vcd/761 OfQBpcSTobOjRr3U1p+d1OOi3yUTdjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAzMjcxMTQxMDdaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAbN8UYBMydbLlepCV2KrzYRYAKB1IxpxU lNa0PDaM52+c9XRIT67NqxSXuwJxttwRGwGchgefgke21JVWx2sCcVU5F0uISpzetVEesJrOmw+w HMe5dVT/x3XyPQQgp5KXlqptYrLAfmhBu6z42fRbqAZli2AQqTiRF1BOdJgmFZdiGxdAUCYnUZsJ ROSpShigOF5WnxV7mZAVWQETUMVWKZKgC+3rEvgQ+ZlnEtZEVCG3mwChYkYPQ81BgAS+E+hTrmMl lwITnDtYbzATPjFh+kSof2eu3r9LEQimh5C1ghTPUqIasQ1IIN5kmXlAZAj52Q4kKrKdIB2nMbI7 4xt2gw== --001a1148d5d4ae07a4054bb4d146-- From nobody Mon Mar 27 08:06:02 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E023127286 for ; Mon, 27 Mar 2017 08:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVtsqFCxUmNe for ; Mon, 27 Mar 2017 08:05:59 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86221128854 for ; Mon, 27 Mar 2017 08:05:59 -0700 (PDT) Received: from dhcp-8607.meeting.ietf.org (dhcp-8607.meeting.ietf.org [31.133.134.7]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v2RF5uau002433 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 27 Mar 2017 08:05:58 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1490627159; bh=CpTuYaKKc538i6RtWku4QePl7au2408AtGTHM7eNrAM=; h=Subject:To:References:From:Date:In-Reply-To; b=b8xDmjSpm/fggbiPwvUHE92aIzoh1eOJmwxIQhVnmMUkDx6mFl+ggUs9j4uxAPRiW PPchel7DLZlT3K60s80yZzfiANcesIqhwhZdph0HOmMbITQa9H4cjTCFc3c+SFrH4d cRxeHhZzSqzGVHurJM+bgvpMubT5v1b2+fw4loKM= To: uta@ietf.org References: From: Jim Fenton Message-ID: <909c4e01-3701-ae7a-2406-f3aa4dfeefe8@bluepopcorn.net> Date: Mon, 27 Mar 2017 08:05:55 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 15:06:01 -0000 On 3/27/17 1:21 AM, Viktor Dukhovni wrote: >> On Mar 27, 2017, at 4:08 AM, Federico Santandrea - Diennea wrote: >> >> >> Let's suppose the sending MTA finds the MTA-STS TXT record, which stat= es >> the receiving domain has an MTA-STS policy. The draft says "To discove= r >> if a recipient domain implements MTA-STS, a sender need only resolve a= >> single TXT record". But what happens when the sending MTA can't fetch >> the actual policy via HTTPS? > Keep it simple. It is just as easy to block access to the TXT record a= s > to block access to the HTTPS site. The TXT record is just an efficienc= y > aid, so that MTAs don't have to attempt costly HTTPS connections (that > typically time out) to domains with no STS records. > Actually, it's easier to block access to the TXT record, because it's obvious in the clear that it's an MTA-STS TXT record, and an MITM that is actively interfering with STARTTLS would likely be able to block retrieval of the TXT record. In contrast, it's probably harder to block the HTTPS site without potentially causing collateral damage. The TXT record is more than an efficiency aid if clocking it causes the policy not to be discovered at all. OTOH, if it is used just to discover policy updates, we wouldn't have that problem. But that would increase the traffic load on the HTTPS server considerably. -Jim From nobody Mon Mar 27 08:17:56 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A73D1297BE for ; Mon, 27 Mar 2017 08:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yB7up2MBjfL4 for ; Mon, 27 Mar 2017 08:17:38 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AFC21297AB for ; Mon, 27 Mar 2017 08:17:34 -0700 (PDT) Received: from [172.31.30.48] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 9CE607A32F1 for ; Mon, 27 Mar 2017 15:17:33 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Viktor Dukhovni In-Reply-To: <909c4e01-3701-ae7a-2406-f3aa4dfeefe8@bluepopcorn.net> Date: Mon, 27 Mar 2017 11:17:32 -0400 Content-Transfer-Encoding: 7bit Reply-To: uta@ietf.org Message-Id: References: <909c4e01-3701-ae7a-2406-f3aa4dfeefe8@bluepopcorn.net> To: uta@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 15:17:45 -0000 > On Mar 27, 2017, at 11:05 AM, Jim Fenton wrote: > > The TXT record is more than an efficiency aid if cloaking it causes the > policy not to be discovered at all. OTOH, if it is used just to discover > policy updates, we wouldn't have that problem. But that would increase > the traffic load on the HTTPS server considerably. The phrase "the HTTPS server" hides an important assumption, namely that there is an HTTPS server in the first place. For the majority of domains there will (for some time) be no STS policies, and no secure way to discover whether there should be a server or not. Publishing an STS policy is not a requirement for SMTP, so STS discovery is opportunistic, and for lack of DNSSEC vulnerable to downgrades. The cacheable TXT record is an efficient mechanism for signalling when to try to load a (new?) policy. If we did not want to signal expedited updates by changing the id, the signal could be just the existence of an A record for some "reserved" hostname in the domain, but that also runs into the issue that reserved hostnames are not a good idea or popular at the IETF. -- -- Viktor. From nobody Mon Mar 27 13:42:26 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5F2129669 for ; Mon, 27 Mar 2017 13:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rgx_wQio6Of2 for ; Mon, 27 Mar 2017 13:42:18 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F3CC12966C for ; Mon, 27 Mar 2017 13:42:15 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id y18so69273884itc.1 for ; Mon, 27 Mar 2017 13:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=/n6sXkMBxvx2TQIGJU5pwV4nc9tWJqbEk41jctFva6w=; b=faGq5dInx3Qj3MySNDQmu+H1SbcKtJ7KsggGMXP0X6XC0V/rJjmuyNP9qMRyKnuGrD meersUMQVGfW4SLDLtU3YnaRwpHzu2OBGA5eauO9oIe8RgTUIKR6gagFWXT/qwOfRkwM WruH0Wn6RWGvfEq4U1c7B12zKbronXTyA+i1C9aslq3BY/pU2RVNC9pCtJlhPNt9G1jS WILpzBpa9aWR58izehGJZOVifZpjPTSs1xSGOBNJfw1YE486PpVOSAZThZhSOxu+BbVz ZawhgSTmjBqsfFqm2wUAlEQU3l7RzHzYCpnKtjs+mBVuCQIBOFlwUYMjGkIdw0In+OGu WQig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=/n6sXkMBxvx2TQIGJU5pwV4nc9tWJqbEk41jctFva6w=; b=l5mNMJmCxRboHX+TjdqSgvwbkJ/PUS1lb0Wr/fnGmiuuEN3OkJnw2CeXfh9dYQ2qZM FjEoDD+efzjUWE2HOCAno1WZtXLXsdgEQ5sAXwdaZpKZR3gXY1LA9Sav2l36+pLu5Cmb N7mixkZhSHoaE0+a1dsm3EI5NJTnzhE9O01K2zv4tYP/ktP/t8NrrdiUdHDeV8GAFOEt DMy/rdcKiV/IiNqlNPT125iv6Emb2nNBtXSVmcDbHjqSpoxhF4SW4jrCSBlJqy6qo133 gtF88IVXsg+JWuGdZ25/G5chmaJgxAKPbuj/fV53JyIKr0igIb58jAIx7qIpoRof/91+ iIrA== X-Gm-Message-State: AFeK/H0BEAqFgCQ8IgjmpB6twplo2Mk/5J4xSpiFwVHCPNCUZ2FO0Dza/wVym747A+srr5FcUwiMVXUeFqbmO4jo X-Received: by 10.36.80.213 with SMTP id m204mr11277047itb.105.1490647334065; Mon, 27 Mar 2017 13:42:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.39.215 with HTTP; Mon, 27 Mar 2017 13:42:13 -0700 (PDT) In-Reply-To: References: <909c4e01-3701-ae7a-2406-f3aa4dfeefe8@bluepopcorn.net> From: Daniel Margolis Date: Mon, 27 Mar 2017 22:42:13 +0200 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1145f2fadf1f53054bbc606b" Archived-At: Subject: Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 20:42:20 -0000 --001a1145f2fadf1f53054bbc606b Content-Type: multipart/alternative; boundary=001a1145f2fad5a135054bbc60e2 --001a1145f2fad5a135054bbc60e2 Content-Type: text/plain; charset=UTF-8 I'm also not convinced that it is harder to block the HTTPS request, since the hostname there is not the nexthop domain but is itself a special hostname ("mta-sts"). Given that, an attacker who can block the TXT can just block the CNAME/A/AAAA record for "mta-sts". You'd have to get rid of that and host the .well-known path at the naked domain (or something innocuous, like www) for that to not work (without the risk of noticeable side effects), and that has serious downsides in other ways. That said, while I'm not sure this focus is incorrect, it is worth restating that for many cases--notably, for large hosts who cannot easily deploy DNSSEC because of unrelated constrains--the primary defense against persistent refresh blocking will be transparency, in the form of reports (like Postmaster Tools), person-to-person contact, etc. (To analogize very slightly to a mostly different context, the same argument applies to provide some justification for "unsafe" defaults on, say, WhatsApp end-to-end encryption: while key-exchange MITMs are possible--a sort of spiritually similar attack to the policy discovery attack here--as long as some people are turning on key validation some of the time, any *widespread* MITM is likely to be discovered, posing a substantial risk to bulk interception.) On Mon, Mar 27, 2017 at 5:17 PM, Viktor Dukhovni wrote: > > > On Mar 27, 2017, at 11:05 AM, Jim Fenton wrote: > > > > The TXT record is more than an efficiency aid if cloaking it causes the > > policy not to be discovered at all. OTOH, if it is used just to discover > > policy updates, we wouldn't have that problem. But that would increase > > the traffic load on the HTTPS server considerably. > > The phrase "the HTTPS server" hides an important assumption, namely > that there is an HTTPS server in the first place. For the majority > of domains there will (for some time) be no STS policies, and no > secure way to discover whether there should be a server or not. > > Publishing an STS policy is not a requirement for SMTP, so STS > discovery is opportunistic, and for lack of DNSSEC vulnerable > to downgrades. > > The cacheable TXT record is an efficient mechanism for signalling > when to try to load a (new?) policy. > > If we did not want to signal expedited updates by changing the id, > the signal could be just the existence of an A record for some > "reserved" hostname in the domain, but that also runs into the issue > that reserved hostnames are not a good idea or popular at the IETF. > > -- > -- > Viktor. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a1145f2fad5a135054bbc60e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm also not convinced that it is harder to block the = HTTPS request, since the hostname there is not the nexthop domain but is it= self a special hostname ("mta-sts"). Given that, an attacker who = can block the TXT can just block the CNAME/A/AAAA record for "mta-sts&= quot;.=C2=A0

You'd have to get rid of that and host = the .well-known path at the naked domain (or something innocuous, like www)= for that to not work (without the risk of noticeable side effects), and th= at has serious downsides in other ways.

That said,= while I'm not sure this focus is incorrect, it is worth restating that= for many cases--notably, for large hosts who cannot easily deploy DNSSEC b= ecause of unrelated constrains--the primary defense against persistent refr= esh blocking will be transparency, in the form of reports (like Postmaster = Tools), person-to-person contact, etc.

(To analogi= ze very slightly to a mostly different context, the same argument applies t= o provide some justification for "unsafe" defaults on, say, Whats= App end-to-end encryption: while key-exchange MITMs are possible--a sort of= spiritually similar attack to the policy discovery attack here--as long as= some people are turning on key validation some of the time, any widespr= ead=C2=A0MITM is likely to be discovered, posing a substantial risk to = bulk interception.)=C2=A0

On Mon, Mar 27, 2017 at 5:17 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:

> On Mar 27, 2017, at 11:05 AM, Jim Fenton <fenton@bluepopcorn.net> wrote:
>
> The TXT record is more than an efficiency aid if cloaking it causes th= e
> policy not to be discovered at all. OTOH, if it is us= ed just to discover
> policy updates, we wouldn't have that problem. But that would incr= ease
> the traffic load on the HTTPS server considerably.

The phrase "the HTTPS server" hides an important assumptio= n, namely
that there is an HTTPS server in the first place.=C2=A0 For the majority of domains there will (for some time) be no STS policies, and no
secure way to discover whether there should be a server or not.

Publishing an STS policy is not a requirement for SMTP, so STS
discovery is opportunistic, and for lack of DNSSEC vulnerable
to downgrades.

The cacheable TXT record is an efficient mechanism for signalling
when to try to load a (new?) policy.

If we did not want to signal expedited updates by changing the id,
the signal could be just the existence of an A record for some
"reserved" hostname in the domain, but that also runs into the is= sue
that reserved hostnames are not a good idea or popular at the IETF.

--
--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

--001a1145f2fad5a135054bbc60e2-- --001a1145f2fadf1f53054bbc606b Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+ q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0 TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg 5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27 8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBxFbgWMAWq//MO WjpJCi16TnETFo5QJfxEBUQyiQ3OEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAzMjcyMDQyMTRaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAeFRO7iCSWNiHGf6YOP6DhiLIKf/8AVla z9mDjNZBe1M4/i9J0u+MaTK4i6FbHjnoSN3JSMJ+R6MuAeMynYsPFXAcACSXsX+TydqzpmdvSpCu 1xy8KPgqEl+Zot398wbuyiVM+4hTr0mLx+vGmVrrVKmG+qtl6/AsQxn5JaH7rsfU2JZtMnGkl41V UhpJbzhdKH0UheRS4d7dFAie/vKN9umV/nj33a5Uo9JCM0Z4ZWHkylSXtraq2IioXQgIzVZVuBBP HCPO7OMkZqG+Ieb3jxO9fo3o05W8eq9xqowj/bUOb0Kq6qi2oqB0bOmnrBUmWWal9y+fyxbafd9U /jl9PA== --001a1145f2fadf1f53054bbc606b-- From nobody Mon Mar 27 13:55:15 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431C9124234 for ; Mon, 27 Mar 2017 13:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEgr35RW5zVH for ; Mon, 27 Mar 2017 13:55:10 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 460C4129636 for ; Mon, 27 Mar 2017 13:55:09 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id e75so34707226itd.1 for ; Mon, 27 Mar 2017 13:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Dw/NP9yRmwp6xcmigQ+1uUgOsccaTU8boP/A7FrR5W4=; b=qnN4e139kuUAoChYl0244zWvMTbukLSJGDS8YqqooBsyusU2ympBljGW9xES+78S05 s57ijjJz6TewmYqV7qZTybBIlU689ttM6mqSOLctMckvMJhzWgG1xSyj40j6RnxrIbnq LnL9is3UxZBxlnm+aOpEm1fOadGGm73xw/L9Sl1AYH7JLBvyp4NdQwjiwqcTr1zRlJL0 0RfWoUdDn9KSkcWkzsuWSK35ow5z1LHHeq9h2nvp8wQeA2zCrfq/Yi/78BxOQ98CfmuZ 7nkxDT5wD/LWgXo4s1xU/xeQF/3ojmb+8eXKMqR/u44QMCFmE1wtP+eQtdqIQ+7Ykt0k YRPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Dw/NP9yRmwp6xcmigQ+1uUgOsccaTU8boP/A7FrR5W4=; b=GyeZ1k0uYC7FZ8+mS3MtYFzhSBZB0cRjgVTSDuYyuJrF4gV4FBxdBZqc8xzsc7gIwl B8DQG6KtxYE613AMapzQrJ1MYkSn9HxihNmRZk3zfw/1NHg2eZS/bfmXfIfPUgovKhL1 ga9kdtSHqlI5IoGUyAhJJZObskKIkZZFNBBT9eT1I1RlneqQ5QqLhIGcauOp9wb+GgxM lc5NMA2dNyrnR16L+hFblL5Ri1UHEuEqACtXMw6u7U0gdtAH0GsOA1okQleY77f4uQEM F2pBWt2cfHrjx77YaXciSYzLzcX2THw339WVFRK4O0W6m1Yys1OB1Co327rlR6QmXgps zSPA== X-Gm-Message-State: AFeK/H0wTgUaMw5zeYDcRgBIoPWi9sX0zCwXc13vdE0ALTmpo2jfovFp85iH49j/c2bMDLDJhITOIxE36wsF56Jl X-Received: by 10.36.152.196 with SMTP id n187mr12475272itd.28.1490648107711; Mon, 27 Mar 2017 13:55:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.39.215 with HTTP; Mon, 27 Mar 2017 13:55:06 -0700 (PDT) In-Reply-To: <92500952-2A50-4508-8686-03CDBF72485D@dukhovni.org> References: <4C0807DA-4852-4DAC-80ED-8A25371CFFAA@dukhovni.org> <20170326205218.GN11426@blitiri.com.ar> <92500952-2A50-4508-8686-03CDBF72485D@dukhovni.org> From: Daniel Margolis Date: Mon, 27 Mar 2017 22:55:06 +0200 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c05e9a2fcf127054bbc8ecd" Archived-At: Subject: Re: [Uta] MTA-STS-03 review X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 20:55:13 -0000 --94eb2c05e9a2fcf127054bbc8ecd Content-Type: multipart/alternative; boundary=94eb2c05e9a2f275ed054bbc8ec3 --94eb2c05e9a2f275ed054bbc8ec3 Content-Type: text/plain; charset=UTF-8 re MXs: Right, I think a nonstandard MX list is actually worse than the disease it cures. ;) But you are right to point out that there are multiple approaches that confer similar security advantages. To the matching point, I share the concern about people having to write their own cert matching code, but I think there are a few arguments for it: 1. I believe if we restrict wildcards to the "full" leftmost label (i.e. *. example.com is valid, but mail*.example.com or mail.*.example.com are not) and we do the same in the certs (which RFC6125 seems to allow us to define), wildcard matching is a simple "x ends with y or y ends with x" comparison, so is in fact trivial to implement. 2. It seems (and I suspect this was part of Viktor's motivation) to match nicely with https://tools.ietf.org/html/rfc7672#section-3.2.2, which if I read it correctly leaves the door open to a certificate matching the nexthop domain rather than the MX hostname; by requiring MX hostname matches in STS we would break that behavior. I think #2 is a pretty compelling point. (FWIW, the more I think of it, Viktor, the less compelling I find the other point about MX candidate traversal being unchanged, since I'm not sure it's really a huge difference to say "this host doesn't match the MX pattern; try the next candidate" as opposed to "this host's certificate doesn't match the MX pattern..." It seems like both cases are quite similar, though maybe in some implementations the code structure implies one to be easier than the other?) re JSON: I think when you've reached the point that JSON-vs-key-value-pairs is the main point of contention it's probably not a *bad* sign. ;) I had the same feeling as Albert about using something with pre-existing library support, which was really the main argument for JSON--and I think since we've already implied a dependency on some HTTPS lib an additional JSON lib seems not *too* serious. At the same time, it's true that Postfix's typical deployments may often be likely to be concerned about each additional library dependency, which is less on my mind here at Google. This seems mostly like an issue of aesthetics (which is not to say it's unimportant, but it seems less fundamental than the design questions we've discussed in the past). If there aren't really strong objections I'd probably keep JSON since we already have both code and published policies in that format, but if there are strong objections, I think it's a trivial matter for the early adopters to change. On Mon, Mar 27, 2017 at 3:01 AM, Viktor Dukhovni wrote: > > > On Mar 26, 2017, at 4:52 PM, Alberto Bertogli > wrote: > > > > There are lots of advantages of using JSON for this. It is well defined, > > standard and there are lots of well tested and widely used > > implementations. > > > > It is used widely, it's familiar to many people, and its shortcomings > > (which are not few, admittedly) are well understood and documented. > > Sure JSON is used widely in all kinds of software, but NOT in MTAs, > and STS is for MTAs. > > > It support rich types (such as lists), and common libraries already > > handle difficult situations like non-ascii content, long integers, > > multi-line strings, malformed/malicious input, etc. > > Sure in Perl, Python, Go, ... but Sendmail, Qmail, Postfix and Exim > are in C, and already have code to handle ESMTP attr=value lists, and > don't currently use JSON. The extra features of JSON you mention are > not needed for this specification, and over-engineering to use JSON > is IMHO not useful. > > -- > Viktor. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --94eb2c05e9a2f275ed054bbc8ec3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
re MXs:

Right, I think a nonstandard MX= list is actually worse than the disease it cures. ;) But you are right to = point out that there are multiple approaches that confer similar security a= dvantages.

To the matching point, I share the conc= ern about people having to write their own cert matching code, but I think = there are a few arguments for it:

1. I believe if = we restrict wildcards to the "full" leftmost label (i.e. *.example.com is valid, but mail*.example.com or mail.*.e= xample.com are not) and we do the same in the certs (which RFC6125 seem= s to allow us to define), wildcard matching is a simple "x ends with y= or y ends with x" comparison, so is in fact trivial to implement.=C2= =A0

2. It seems (and I suspect this was part of Vi= ktor's motivation) to match nicely with=C2=A0https://tools.ietf.org/html/rfc7672#sec= tion-3.2.2, which if I read it correctly leaves the door open to a cert= ificate matching the nexthop domain rather than the MX hostname; by requiri= ng MX hostname matches in STS we would break that behavior.=C2=A0

I think #2 is a pretty compelling point.=C2=A0
(FWIW, the more I think of it, Viktor, the less compelling I f= ind the other point about MX candidate traversal being unchanged, since I&#= 39;m not sure it's really a huge difference to say "this host does= n't match the MX pattern; try the next candidate" as opposed to &q= uot;this host's certificate doesn't match the MX pattern..." I= t seems like both cases are quite similar, though maybe in some implementat= ions the code structure implies one to be easier than the other?)=C2=A0

re JSON:

I think when yo= u've reached the point that JSON-vs-key-value-pairs is the main point o= f contention it's probably not a bad=C2=A0sign. ;)=C2=A0

I had the same feeling as Albert about using something wi= th pre-existing library support, which was really the main argument for JSO= N--and I think since we've already implied a dependency on some HTTPS l= ib an additional JSON lib seems not too=C2=A0serious. At the same ti= me, it's true that Postfix's typical deployments may often be likel= y to be concerned about each additional library dependency, which is less o= n my mind here at Google.

This seems mostly like a= n issue of aesthetics (which is not to say it's unimportant, but it see= ms less fundamental than the design questions we've discussed in the pa= st). If there aren't really strong objections I'd probably keep JSO= N since we already have both code and published policies in that format, bu= t if there are strong objections, I think it's a trivial matter for the= early adopters to change.=C2=A0

=
On Mon, Mar 27, 2017 at 3:01 AM, Viktor Dukhovni= <ietf-dane@dukhovni.org> wrote:

> On Mar 26, 2017, at 4:52 PM, Alberto Bertogli <albertito@blitiri.com.ar> wrote:
>
> There are lots of advantages of using JSON for this. It is well define= d,
> standard and there are lots of well tested and widely used
> implementations.
>
> It is used widely, it's familiar to many people, and its shortcomi= ngs
> (which are not few, admittedly) are well understood and documented.
Sure JSON is used widely in all kinds of software, but NOT in MTAs,<= br> and STS is for MTAs.

> It support rich types (such as lists), and common libraries already > handle difficult situations like non-ascii content, long integers,
> multi-line strings, malformed/malicious input, etc.

Sure in Perl, Python, Go, ... but Sendmail, Qmail, Postfix and Exim<= br> are in C, and already have code to handle ESMTP attr=3Dvalue lists, and
don't currently use JSON.=C2=A0 The extra features of JSON you mention = are
not needed for this specification, and over-engineering to use JSON
is IMHO not useful.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

--94eb2c05e9a2f275ed054bbc8ec3-- --94eb2c05e9a2fcf127054bbc8ecd Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+ q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0 TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg 5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27 8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDODK3NKDtMSk8p 9F+HOLWIzi9AtRoyiT9Lfc33ZJoIhDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAzMjcyMDU1MDhaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAPoQR7YYRgFa6veKNNBXpMNkgNzWO0iMV EpNRG58uzcjx4JHv5xtfmTM+Sa5edzkF5Vt1vlzbcwdrw5jmOMLR7JmroV+HrLMYdfk512zUETrZ vuZtU9CHBnY9Y/yzywkKRfUNjWd6XulCBSOmskgJ1Yr5LP5sStxcIi5HPEtkHuXGIrnOQi+uWM6I h5vFmJi3yLzCP9/fYDOMwHh4MEM2++n8Mb19Y3MS6XXU7vBROk6ESMVam+AYMpuMdA84c8v0EbrG uUJ45UW1M2/NPv60bwBvoR80FC9UwAHRgomPTzHhxKoL2p7UauUbUKXLB9h1EXi2b7DqCS6KV1nn lsLZpQ== --94eb2c05e9a2fcf127054bbc8ecd-- From nobody Mon Mar 27 21:20:48 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFE512922E for ; Mon, 27 Mar 2017 21:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FePYlPBagRd8 for ; Mon, 27 Mar 2017 21:20:45 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id C14FF126DED for ; Mon, 27 Mar 2017 21:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1490674845; d=isode.com; s=june2016; i=@isode.com; bh=WGA2qdnixCjXkW+LZIyd0jiLxPBaXuk0jGIJ2sxwW5Q=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=UIbAz7dPg1hW8AnSXY8KW3wWDcEyTsf5mit2cFa1kyV2T1aEZ0X7LQ5DY/IbzPGHuaU0I3 4/t1Vctb0YhzJmTlIuWAh/7HTfhNnlDuFHoHmA++F21WiGZFPt9tK/9m+cIwUrlO1ex5cA b9CE1rWUyDk0JNGdaPvoNHXzuVyDXs8=; Received: from [172.20.86.22] (50-203-222-3-static.hfc.comcastbusiness.net [50.203.222.3]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 28 Mar 2017 05:20:44 +0100 References: <148944539677.20433.7775400419388289046@ietfa.amsl.com> To: uta@ietf.org From: Alexey Melnikov Message-ID: <58D9E49A.7010709@isode.com> Date: Tue, 28 Mar 2017 05:20:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <148944539677.20433.7775400419388289046@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] I-D Action: draft-ietf-uta-email-deep-06.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 04:20:47 -0000 Nit in the latest version: 12.6. Advertisement of STS policies MSPs SHOULD advertise STS policies that include at least tls11, tls- I think "tls11" was changed to "tls-version=1.1". cert and sts-url, with the latter having an associated https URL that can be used to inform clients of service outages or problems impacting client confidentiality. Note that advertising tls-cert is a commitment to maintain and renew server certificates. A MSP MAY also specifically indicate a commitment to support PKIX validation, DANE validation, or both, using tls-cert=pkix, tls-cert=dane, or tls- cert=pkix+dane, respectively. From nobody Tue Mar 28 03:18:11 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0221293D9 for ; Tue, 28 Mar 2017 03:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXPp_2ct1-wa for ; Tue, 28 Mar 2017 03:18:09 -0700 (PDT) Received: from mail3.informatica.it (mail3.informatica.it [151.99.189.163]) by ietfa.amsl.com (Postfix) with ESMTP id 9151F129353 for ; Tue, 28 Mar 2017 03:18:09 -0700 (PDT) From: Federico Santandrea To: uta@ietf.org References: Message-ID: <7113f172-0742-05b3-c504-8763175df7f0@diennea.com> Date: Tue, 28 Mar 2017 12:18:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-GatewayId: federico.santandrea=2.634461300016064633130110@diennea.com Archived-At: Subject: Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 10:18:11 -0000 From Security Considerations section of draft-ietf-uta-mta-sts-03: "Similarly, we consider the possibilty of domains that deliberately allow untrusted users to serve untrusted content on user-specified subdomains. In some cases (e.g. the service Tumblr.com) this takes the form of providing HTTPS hosting of user-registered subdomains [...] In these cases, there is a risk that untrusted users would be able to serve custom content at the "mta-sts" host, including serving an illegitimate SMTP STS policy." It's likely that such domains serve wildcard certificates for user-specified subdomains. I think a further mitigation of this could be to require the HTTPS connection's certificate to be valid precisely for the mta-sts.example.com host, ignoring wildcard matches. -- Federico From nobody Tue Mar 28 03:38:29 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9CF3129353 for ; Tue, 28 Mar 2017 03:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKugykPXvr6u for ; Tue, 28 Mar 2017 03:38:27 -0700 (PDT) Received: from mail3.informatica.it (mail3.informatica.it [151.99.189.163]) by ietfa.amsl.com (Postfix) with ESMTP id 0F617129893 for ; Tue, 28 Mar 2017 03:38:26 -0700 (PDT) From: Federico Santandrea References: To: uta@ietf.org Message-ID: <8a9cd559-d27f-c245-bfb4-2bc2ecea6ea1@diennea.com> Date: Tue, 28 Mar 2017 12:38:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-GatewayId: federico.santandrea=2.601301300016063333123308@diennea.com Archived-At: Subject: Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 10:38:29 -0000 On 27/03/2017 13:41, Daniel Margolis wrote: > Anyway, I'm very open to suggestions on how to make this more > transparent within the scope of TLSRPT, but I don't love the idea of > adding policy complexity by letting recipients specify what to do in > this scenario. To allow the receiving domain owner to spot abnormal situations without complicating the report, we could add semantics to the date-range. The draft says: o "date-time": The date-time indicates the start- and end-times for the report range. It is provided as a string formatted according to Section 5.6, "Internet Date/Time Format", of [RFC3339]. The report should be for a full UTC day, 0000-2400. If we replace that with something along the lines of: o "date-time": The date-time indicates the start- and end-times for the report range. It is provided as a string formatted according to Section 5.6, "Internet Date/Time Format", of [RFC3339]. "start-datetime" should be 0000 UTC of the relevant day or the first time a policy was discovered, whichever comes last. "end-datetime" should be 2400 UTC of the relevant day or the time the last cached policy did expire, whichever comes first. Then one would normally see reports for one whole day, except when one first publishes a policy and in abnormal situations where a policy has been allowed to expire with no new one available. In that case it will be clear that for some part of the day no policy was considered, which can be expected (if the domain doesn't publish a policy anymore) or unexpected (network problems/attacks on the sending MTA or, if the problem is widespread across senders, possible misconfiguration of denial of service on records or endpoints). If in the same day a policy is discovered again after a previous one has expired, then we would have more than one report for that day: for instance, one from 0000 to the time the policy had expired, and another one from the time a new policy had been discovered to 2400. So the gap during which no policy applied would be evident. -- Federico From nobody Tue Mar 28 09:25:54 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845C71296FB for ; Tue, 28 Mar 2017 09:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6PFl2F0tEyY for ; Tue, 28 Mar 2017 09:25:49 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7181D128D8B for ; Tue, 28 Mar 2017 09:25:39 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id e75so61699859itd.1 for ; Tue, 28 Mar 2017 09:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qH15yuUrwltI1WcYuEeVjcf10mlMAtLKhmqLApc49Os=; b=t31PJk0li+BuMi+HmU++PJfq1crXSuE/FhFHCEZtGJPL/1tm04cD07uk16fz1Yn3i3 EojehAzHU+YPwZNmikNUW8SpoMs2Zd7+o8xu+dJfRbK0Om/k7K+QyHGckkShPD2+gNe7 h0pxUTy/dgq73HBIMDPFA06/itVNHGVqHKZ1VJdS9LBeR/+76fx5epZTFeqcKiNUKalt S1FJ0EWxPC3g7F2JIwoHCVBfpwg9rm9SZ9quPJWrID6FET/UoiN8vbMaPVtGSzLqSzny YwL4ZftEDl+qpTMJLI9GZFej84OGdSXc56F6bH5IcE07K2z3BVsqJzU/bvHBImaSmX/v mCJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qH15yuUrwltI1WcYuEeVjcf10mlMAtLKhmqLApc49Os=; b=o13ZGvNw9rXV6724PPbxxyvq0E46ajuvo1tLrevVt9Kw2SetZrIu8EPsrE879E4VGA eOHPrU1EuFvo8VCRRC5zWLOoZA5zBO5kF3F+c1K+H2LQD0eYTf0Z+1p0sIengJ7bRZM8 pNzwq1J56lyr9LUiSsH+L5hQLMIiG8L+Rkuxj9twv0iYtluy+dHYHCk3XJbXl2nff7yU LBVoL+SvtboNJKoWHmjsrG0psI03gnjyFYXsI2QEb+Pr3vr23bv2QgR0c0bj6kBB6M2V I6+oeziahXOJzFM5VNNXxzSzsvroP1H/uznGGAEb+rSS+6HQT1jBQfSU13/D4BCgw7i+ 1GIQ== X-Gm-Message-State: AFeK/H0qWkuDfs+F2JX6eToSXHR2BDwBdiDvovIc3yOFXachq3y++KCbfZYGOEntYfOpeZaFcM5fi55pcOKTyFXc X-Received: by 10.107.133.159 with SMTP id p31mr19004515ioi.101.1490718337011; Tue, 28 Mar 2017 09:25:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.39.215 with HTTP; Tue, 28 Mar 2017 09:25:36 -0700 (PDT) In-Reply-To: <7113f172-0742-05b3-c504-8763175df7f0@diennea.com> References: <7113f172-0742-05b3-c504-8763175df7f0@diennea.com> From: Daniel Margolis Date: Tue, 28 Mar 2017 18:25:36 +0200 Message-ID: To: Federico Santandrea Cc: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113ec5c601589a054bcce9fa" Archived-At: Subject: Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 16:25:52 -0000 --001a113ec5c601589a054bcce9fa Content-Type: multipart/alternative; boundary=001a113ec5c6f18efd054bcce8e6 --001a113ec5c6f18efd054bcce8e6 Content-Type: text/plain; charset=UTF-8 Yes, I think we have discussed the possibility of that before. You could also do this with a new EKU value, I think. Ultimately the value of adding this constraint is unclear to me; for example, dyndns.org would not be saved by that (since a user who has "foo.dyndns.org" can easily get a cert for that name); conversely, it could make it harder for some people to adopt (I guess). So I Don't know. On Tue, Mar 28, 2017 at 12:18 PM, Federico Santandrea < federico.santandrea@diennea.com> wrote: > From Security Considerations section of draft-ietf-uta-mta-sts-03: > > "Similarly, we consider the possibilty of domains that deliberately > allow untrusted users to serve untrusted content on user-specified > subdomains. In some cases (e.g. the service Tumblr.com) this takes > the form of providing HTTPS hosting of user-registered subdomains > [...] In these cases, there is a risk that untrusted users would be > able to serve custom content at the "mta-sts" host, including > serving an illegitimate SMTP STS policy." > > It's likely that such domains serve wildcard certificates for > user-specified subdomains. I think a further mitigation of this could > be to require the HTTPS connection's certificate to be valid precisely > for the mta-sts.example.com host, ignoring wildcard matches. > > -- > Federico > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a113ec5c6f18efd054bcce8e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, I think we have discussed the possibility of that bef= ore. You could also do this with a new EKU value, I think. Ultimately the v= alue of adding this constraint is unclear to me; for example, dyndns.org would not be saved by that (since a user wh= o has "foo.dyndns.org" can = easily get a cert for that name); conversely, it could make it harder for s= ome people to adopt (I guess). So I Don't know.=C2=A0

On Tue, Mar 28, 2017 at 12:= 18 PM, Federico Santandrea <federico.santandrea@diennea.com<= /a>> wrote:
From Security Consi= derations section of draft-ietf-uta-mta-sts-03:

=C2=A0 =C2=A0"Similarly, we consider the possibilty of domains that de= liberately
=C2=A0 =C2=A0allow untrusted users to serve untrusted content on user-speci= fied
=C2=A0 =C2=A0subdomains.=C2=A0 In some cases (e.g. the service Tumblr.com) = this takes
=C2=A0 =C2=A0the form of providing HTTPS hosting of user-registered subdoma= ins
=C2=A0 =C2=A0 [...] In these cases, there is a risk that untrusted users wo= uld be
=C2=A0 =C2=A0able to serve custom content at the "mta-sts" host, = including
=C2=A0 =C2=A0serving an illegitimate SMTP STS policy."

It's likely that such domains serve wildcard certificates for
user-specified subdomains. I think a further mitigation of this could
be to require the HTTPS connection's certificate to be valid precisely<= br> for the mta-sts.example.com host, ignoring wildcard matches.

--
Federico


_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

--001a113ec5c6f18efd054bcce8e6-- --001a113ec5c601589a054bcce9fa Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+ q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0 TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg 5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27 8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDM8f8/ucuO95Q5 8wLsg8p/C6L5nkzMKvdrYs+1a1PJBTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAzMjgxNjI1MzhaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAkCWnGW4Rz4Vg+vc8Rd/zj+2LK4ItTJQY YUvWMT78U3DPMDZhsT793wc5uf/V4TNHWCD/sK8e0qdeKghN1eHQMVARnKdzOJwnDY70ebuUbbC/ HaRkxXsFiNpQNktqjz8Bem7Mp/xGanRHU9qUl624Hf+Ido9LQuq3fAg++2m8mxu6NiHRFfkIInHC 4obRCqb5frU3MVpoZEW0OUoztBSM95qFHP8hMgWTt5P+8tlg7h6NjLdsk0L7/2NjEJ1TmVEKA3t1 tLz3Jb7KQrZVg+jrgZp7j3LMoknt7q3wTZE0ucFtMfYqSS+gFkebqbBJg7TJKVzJJMbVbuwAUkEl WNj2nQ== --001a113ec5c601589a054bcce9fa-- From nobody Tue Mar 28 09:27:06 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D50212944B for ; Tue, 28 Mar 2017 09:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9akMullXeKAB for ; Tue, 28 Mar 2017 09:27:01 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D2E912945F for ; Tue, 28 Mar 2017 09:26:57 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id y18so119645808itc.0 for ; Tue, 28 Mar 2017 09:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uOOMJS7fjKnJMKT807Uf27ZzgvbB/3ocuv12k+lx8w8=; b=mpzMvqqkLbr2IoVbYJQyy3A3bQBMTOQDxtAmh03YS3cZC/BEVy4YlHDI7kUhg0in+c optXVBecLZw9mbL/3miGVJeb42WS5RPtDeLOlmF1cY3uGnOp9r0lc8KeuWv4sSlYIgh8 wWbouyLan7rtlXFtwgf3REyfQuR/21eSCZlbMUrqIVJ9jk3oGZ2X4102QyfaqdrCXW+2 PBiOdDz2IKw4qn4O0mLqEebYZGY/5x9dzKSXKUY6EPKGEqy0loglksUCWepy9PqkvDXb YPitV6EUN5Bf+eLVjiu2+P4TpPcADFcNjjKuF6KnDeYe2AXKNls18ZLqcRzyxa5WyuqN cF7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uOOMJS7fjKnJMKT807Uf27ZzgvbB/3ocuv12k+lx8w8=; b=Oi6VVBulTi0Pjf/sHlxmjc0W8ECxvmECQe3yrNN3CA9Wl00ZO5f4L4BPcAzonRRcwJ xEBDDub/vav264pqC20dcQ7dKlT9U5tmsRo9zGs/Mycs3qr4FwBtnY9vlHICCUZyHTws Z9tpqBQevtixL6/Dzjom2lgLThdHK7HtUVpkUvwJfkYrUFitNsene3P2nf1A6Kzb6ORl zmhOMl7Ls/ofFYj8U0xx7Y++lacsTS7p59GHViuRgxSFX07W0GBGXGQ2wXU7H0rMAwBx jtWUs4DlIPWbPui1XT1KW6jvyd0HycmpcDz43UpD6sNjsp9rxFr3nlYvTk7EYbPN6rEz gRxg== X-Gm-Message-State: AFeK/H00qtz3Rr1fJ+MPzQb2NAlsBvkNtJmDvDl2zAo2/5t0Z7b9LaZ+F3lu1uqu2802RWjRSYLEAV+R5wMBFYo1 X-Received: by 10.36.53.210 with SMTP id k201mr15255875ita.21.1490718415848; Tue, 28 Mar 2017 09:26:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.39.215 with HTTP; Tue, 28 Mar 2017 09:26:54 -0700 (PDT) In-Reply-To: <8a9cd559-d27f-c245-bfb4-2bc2ecea6ea1@diennea.com> References: <8a9cd559-d27f-c245-bfb4-2bc2ecea6ea1@diennea.com> From: Daniel Margolis Date: Tue, 28 Mar 2017 18:26:54 +0200 Message-ID: To: Federico Santandrea Cc: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114a8ac4ae702d054bcced16" Archived-At: Subject: Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 16:27:05 -0000 --001a114a8ac4ae702d054bcced16 Content-Type: multipart/alternative; boundary=001a114a8ac4a36902054bccedc4 --001a114a8ac4a36902054bccedc4 Content-Type: text/plain; charset=UTF-8 Of course a smart attacker who can MITM insecure DNS can spoof reports (and optionally MITM the DKIM lookup to make the reports look valid). So it's sort of turtles all th way down, no? On Tue, Mar 28, 2017 at 12:38 PM, Federico Santandrea < federico.santandrea@diennea.com> wrote: > On 27/03/2017 13:41, Daniel Margolis wrote: > >> Anyway, I'm very open to suggestions on how to make this more >> transparent within the scope of TLSRPT, but I don't love the idea of >> adding policy complexity by letting recipients specify what to do in >> this scenario. >> > > To allow the receiving domain owner to spot abnormal situations without > complicating the report, we could add semantics to the date-range. > > The draft says: > > o "date-time": The date-time indicates the start- and end-times for > the report range. It is provided as a string formatted according > to Section 5.6, "Internet Date/Time Format", of [RFC3339]. The > report should be for a full UTC day, 0000-2400. > > If we replace that with something along the lines of: > > o "date-time": The date-time indicates the start- and end-times for > the report range. It is provided as a string formatted according > to Section 5.6, "Internet Date/Time Format", of [RFC3339]. > "start-datetime" should be 0000 UTC of the relevant day or the > first time a policy was discovered, whichever comes last. > "end-datetime" should be 2400 UTC of the relevant day or the > time the last cached policy did expire, whichever comes first. > > Then one would normally see reports for one whole day, except when one > first publishes a policy and in abnormal situations where a policy > has been allowed to expire with no new one available. > > In that case it will be clear that for some part of the day no policy > was considered, which can be expected (if the domain doesn't publish a > policy anymore) or unexpected (network problems/attacks on the sending > MTA or, if the problem is widespread across senders, possible > misconfiguration of denial of service on records or endpoints). > > If in the same day a policy is discovered again after a previous one > has expired, then we would have more than one report for that day: > for instance, one from 0000 to the time the policy had expired, and > another one from the time a new policy had been discovered to 2400. > So the gap during which no policy applied would be evident. > > -- > Federico > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a114a8ac4a36902054bccedc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Of course a smart attacker who can MITM insecure DNS can s= poof reports (and optionally MITM the DKIM lookup to make the reports look = valid). So it's sort of turtles all th way down, no?

On Tue, Mar 28, 2017 at 12:38 = PM, Federico Santandrea <federico.santandrea@diennea.com= > wrote:
On 27= /03/2017 13:41, Daniel Margolis wrote:
Anyway, I'm very open to suggestions on how to make this more
transparent within the scope of TLSRPT, but I don't love the idea of =C2=A0adding policy complexity by letting recipients specify what to do in<= br> =C2=A0this scenario.

 To allow the receiving domain owner to spot abnormal situations without
complicating the report, we could add semantics to the date-range.

The draft says:

=C2=A0 =C2=A0o=C2=A0 "date-time": The date-time indicates the sta= rt- and end-times for
=C2=A0 =C2=A0 =C2=A0 the report range.=C2=A0 It is provided as a string for= matted according
=C2=A0 =C2=A0 =C2=A0 to Section 5.6, "Internet Date/Time Format",= of [RFC3339].=C2=A0 The
=C2=A0 =C2=A0 =C2=A0 report should be for a full UTC day, 0000-2400.

If we replace that with something along the lines of:

=C2=A0 =C2=A0o=C2=A0 "date-time": The date-time indicates the sta= rt- and end-times for
=C2=A0 =C2=A0 =C2=A0 the report range.=C2=A0 It is provided as a string for= matted according
=C2=A0 =C2=A0 =C2=A0 to Section 5.6, "Internet Date/Time Format",= of [RFC3339].
=C2=A0 =C2=A0 =C2=A0 "start-datetime" should be 0000 UTC of the r= elevant day or the
=C2=A0 =C2=A0 =C2=A0 first time a policy was discovered, whichever comes la= st.
=C2=A0 =C2=A0 =C2=A0 "end-datetime" should be 2400 UTC of the rel= evant day or the
=C2=A0 =C2=A0 =C2=A0 time the last cached policy did expire, whichever come= s first.

Then one would normally see reports for one whole day, except when one
first publishes a policy and in abnormal situations where a policy
has been allowed to expire with no new one available.

In that case it will be clear that for some part of the day no policy
was considered, which can be expected (if the domain doesn't publish a<= br> policy anymore) or unexpected (network problems/attacks on the sending
MTA or, if the problem is widespread across senders, possible
misconfiguration of denial of service on records or endpoints).

If in the same day a policy is discovered again after a previous one
has expired, then we would have more than one report for that day:
for instance, one from 0000 to the time the policy had expired, and
another one from the time a new policy had been discovered to 2400.
So the gap during which no policy applied would be evident.

--
Federico


_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

--001a114a8ac4a36902054bccedc4-- --001a114a8ac4ae702d054bcced16 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+ q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0 TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg 5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27 8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAl4/u2CuWc9D95 tiOIVTaJjpXma3KvibA9Puy4oHjvcjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAzMjgxNjI2NTZaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAZlCcObZ76FpwuWouT66ZDmKPpzGS5QUo 2jACSdskJ+9TAIjuSa68Od+rtK80Ed8jXCaCbJaEQs7srCXLqKW/e58KiHqr1smFC0ozs4FIqBDl rm6/LInbFM9aYqbjiDCkAGcyIMUCd1G6pX80eygvoykVSLyUgB5D9d9XxdL5KPreIMLU8vMZ6hza GkKwEjoQOPEYnLrVh3NDwjVVnN3yX5eELcBtEbhTHTX9969PabRg3RGUf3nB20JkX8uDmDSsFLIB Qr538NZit0nevuBS3h17oxXmoUnWoN8Bv6NEKHcU5/gcAtzk46n4yCez3FuSM/tON3AVvoOK7VcZ r3bvrw== --001a114a8ac4ae702d054bcced16-- From nobody Tue Mar 28 09:48:34 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1853129461 for ; Tue, 28 Mar 2017 09:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yWz6xZGPehe for ; Tue, 28 Mar 2017 09:48:31 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E34A129449 for ; Tue, 28 Mar 2017 09:48:30 -0700 (PDT) Received: from [172.31.30.48] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 13DD37A32F1 for ; Tue, 28 Mar 2017 16:48:30 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: <8a9cd559-d27f-c245-bfb4-2bc2ecea6ea1@diennea.com> Date: Tue, 28 Mar 2017 12:48:11 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: References: <8a9cd559-d27f-c245-bfb4-2bc2ecea6ea1@diennea.com> To: uta@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 16:48:33 -0000 > On Mar 28, 2017, at 6:38 AM, Federico Santandrea = wrote: >=20 > If we replace that with something along the lines of: >=20 > o "date-time": The date-time indicates the start- and end-times for > the report range. It is provided as a string formatted according > to Section 5.6, "Internet Date/Time Format", of [RFC3339]. > "start-datetime" should be 0000 UTC of the relevant day or the > first time a policy was discovered, whichever comes last. > "end-datetime" should be 2400 UTC of the relevant day or the > time the last cached policy did expire, whichever comes first. >=20 > Then one would normally see reports for one whole day, except when one > first publishes a policy and in abnormal situations where a policy > has been allowed to expire with no new one available. Not just when first publishing, but also when each new sending system first discovers a policy, which will make for too much noise in the reports. Also, policy expiration will not be "abnormal". If I implement STS, pre-expiration background policy refresh will not happen in the absence of email to the destination domain. This avoids unbounded fiiling of the cache with junk domains to which email delivery has long ceased. The simplest solution is to accept that STS covers ongoing validation of email to frequently used domains, and is otherwise subject to downgrade. --=20 Viktor. From nobody Thu Mar 30 02:22:13 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEB7128B4E for ; Thu, 30 Mar 2017 02:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.998 X-Spam-Level: X-Spam-Status: No, score=-6.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.796, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CitX9iba17cr for ; Thu, 30 Mar 2017 02:22:09 -0700 (PDT) Received: from out.mail.ec.europa.eu (out.mail.ec.europa.eu [147.67.249.4]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61EC11293E9 for ; Thu, 30 Mar 2017 02:22:07 -0700 (PDT) Received: from S-DC-EMP015-E.net1.cec.eu.int (158.167.3.16) by S-DC-EDG010-Q.rcnet.cec.eu.int (147.67.249.4) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 30 Mar 2017 11:21:58 +0200 Received: from S-DC-EMP013-B.net1.cec.eu.int (158.167.2.37) by S-DC-EMP015-E.net1.cec.eu.int (158.167.3.16) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 30 Mar 2017 11:22:04 +0200 Received: from S-DC-ESTE03-B.net1.cec.eu.int ([169.254.2.152]) by S-DC-EMP013-B.net1.cec.eu.int ([158.167.2.37]) with mapi id 14.03.0301.000; Thu, 30 Mar 2017 11:22:04 +0200 From: To: Thread-Topic: General question on draft-ietf-uta-mta-sts-03 Thread-Index: AQHSqTcY8jps5Nhu0EGU3v8+sjq0sA== Date: Thu, 30 Mar 2017 09:22:04 +0000 Message-ID: <2DB01F3A9898AE41BB3266315D9FDA2704902822@S-DC-ESTE03-B.net1.cec.eu.int> Accept-Language: en-GB, fr-LU, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.167.189.38] Content-Type: multipart/alternative; boundary="_000_2DB01F3A9898AE41BB3266315D9FDA2704902822SDCESTE03Bnet1c_" MIME-Version: 1.0 Archived-At: Subject: [Uta] General question on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 09:22:12 -0000 --_000_2DB01F3A9898AE41BB3266315D9FDA2704902822SDCESTE03Bnet1c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable After reading the MTA-STS drafts, and following the discussions, there's st= ill a question that I do not fully understand. Why using DNS to "announce" the use of MTA-STS but rely on HTTPS for publis= hing the policy? So far, the policy is not that complex. Wouldn't a DNS TXT record suffice in many cases? I understand that in some cases the policy may be longer, depending on how = many MX records a domain may have. Fetching the policy from an HTTPS service could be an option for those who = require longer policy descriptions. Another option for longer policies could be to add an 'include' parameter, = like in SPF, therefore avoiding the need of another service (HTTPS) to deli= ver the policy. It may not simplify the work for the implementation of MTA-STS (fetching fr= om HTTPS would still have to be implemented), but it would make it easier t= o deploy (I think). As example, the TXT records could look like: MTA-STS just DNS: _mta-sts.example.com IN TXT "v=3DSTSv1; id=3D20173003110000Z; mode=3Denforc= e; mx=3D*.example.com; max_age=3D12345600" MTA-STS with DNS and HTTPS: _mta-sts.example.com IN TXT "v=3DSTSv1; id=3D20173003110000Z; use=3Dhttps" MTA-STS with DNS and 'include': _mta-sts.example.com IN TXT "v=3DSTSv1; id=3D20173003110000Z; max_age=3D123= 45600 include=3D_mta-sts01,_mta-sts02;" _mta-sts01.example.com IN TXT "mx=3Dmx1.example.com,mx2.example.com;" _mta-sts02.example.com IN TXT "mx=3D*.example1.com;" Gerard Draper Gil --_000_2DB01F3A9898AE41BB3266315D9FDA2704902822SDCESTE03Bnet1c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
After reading the MTA-STS drafts, and following the discussions, there= 's still a question that I do not fully understand.

Why using DNS to "announce" the use of MTA-STS but rely on HTTPS= for publishing the policy? So far, the policy is not that comp= lex. 
Wouldn't a DNS TXT record suffice in many cases? 
I understand that in some cases the policy may be longer, depending on= how many MX records a domain may have. 
Fetching the policy from an HTTPS service could be an option for those= who require longer policy descriptions. 
Another option for longer policies could be to add an 'include' parame= ter, like in SPF, therefore avoiding the need of another service (HTTPS) to= deliver the policy. 

It may not simplify the work for= the implementation of MTA-STS (fetching from HTTPS would still have to be = implemented), but it would make it easier to deploy (I think).

As example, the TXT records could look like:

MTA-STS just DNS: 
_mta-sts.example.com IN TXT "v= =3DSTSv1; id=3D20173003110000Z; mode=3Denforce; mx=3D*.example.com; max_age= =3D12345600"

MTA-STS with  DNS and HTTPS: = ;
_mta-= sts.example.com IN TXT "v=3DSTSv1; id=3D20173003110000Z; use=3Dhttps&q= uot;

= MTA-STS with  DNS and 'include': 
_mta-sts.example.com IN TXT &quo= t;v=3DSTSv1; id=3D20173003110000Z; max_age=3D12345600&n= bsp;include=3D_mta-sts01,_mta-sts02;"
_mta-sts01.example.com IN TXT &q= uot;mx=3Dmx1.example.com,mx2.e= xample.com;"
_mta-sts02.example.com IN TXT &q= uot;mx=3D*.example1.com;"

Gerard Draper Gil
--_000_2DB01F3A9898AE41BB3266315D9FDA2704902822SDCESTE03Bnet1c_-- From nobody Thu Mar 30 03:56:03 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774951294A3 for ; Thu, 30 Mar 2017 03:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5rzC-LojPlo for ; Thu, 30 Mar 2017 03:55:59 -0700 (PDT) Received: from blitiri.com.ar (cdt.blitiri.com.ar [IPv6:2001:41d0:401:3100::2c1a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 193EF1293F5 for ; Thu, 30 Mar 2017 03:55:58 -0700 (PDT) Received: from blitiri.com.ar (authenticated as alb@blitiri.com.ar) by cdt.blitiri.com.ar (chasquid) (over submission TLS-1.2-TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) (envelope from "albertito@blitiri.com.ar") ; Thu, 30 Mar 2017 12:55:57 +0200 Date: Thu, 30 Mar 2017 11:55:56 +0100 From: Alberto Bertogli To: Daniel Margolis Cc: uta@ietf.org Message-ID: <20170330105556.GR11426@blitiri.com.ar> References: <4C0807DA-4852-4DAC-80ED-8A25371CFFAA@dukhovni.org> <20170326205218.GN11426@blitiri.com.ar> <92500952-2A50-4508-8686-03CDBF72485D@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Uta] MTA-STS-03 review X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 10:56:01 -0000 On Mon, Mar 27, 2017 at 10:55:06PM +0200, Daniel Margolis wrote: > To the matching point, I share the concern about people having to write > their own cert matching code, but I think there are a few arguments for it: > > 1. I believe if we restrict wildcards to the "full" leftmost label (i.e. *. > example.com is valid, but mail*.example.com or mail.*.example.com are not) > and we do the same in the certs (which RFC6125 seems to allow us to > define), wildcard matching is a simple "x ends with y or y ends with x" > comparison, so is in fact trivial to implement. Agreed, but it still carries some hidden complexity. For example, how does this interact with SNI? e.g what name would the client pick to give to the server in the TLS negotiation? > 2. It seems (and I suspect this was part of Viktor's motivation) to match > nicely with https://tools.ietf.org/html/rfc7672#section-3.2.2, which if I > read it correctly leaves the door open to a certificate matching the > nexthop domain rather than the MX hostname; by requiring MX hostname > matches in STS we would break that behavior. Yes, my reading from that reference is that the nexthop domain can be used to match as well. > I think #2 is a pretty compelling point. It is definitely a point, but I'm not sure it's that compelling (sorry Viktor!). There's, AFAIK, no very clear and well defined way to do certificate matching for MTA-to-MTA TLS connections, and this RFC is a chance to fix that. For better or worse, HTTPS is the most widely deployed TLS usage in the world, and has gone through years of all kinds of production exposure. The certificates are validated has been thoroughly reviewed and is well documented and understood. Differring from that, and adding complexity to how SMTP does TLS validation based on a particular section of RFC 7672 which, as far as I know (and please correct me if I'm wrong) is not widely deployed and hasn't got nearly as much production exposure, seems to me to be risky, and is IMHO not worth it. Bringing SMTP certificate validation in line with how HTTPS does it would not only simplify (some) implementations, but make deployments easier, reduce the cognitive load and learning curve for folks running their own servers, and benefit from all the existing analysis and also the future improvements in the area (e.g. certificate revocation, certificate transparency improvements, etc.). Very few existing deployments would be affected, as I don't think many are relying on using [DANE+certificate for the next hop but not the MX name]. Note, in case it's not clear, that I'm not advocating for the removal of the MX list from the policy, but to keep it as in the current draft (i.e. use it as a filter mechanism, and then do TLS validation on the resulting MX name). All this said, I don't want to drag my point along or interfere with the normal flow of things. I much appreciate your thoughtful replies, and if you don't find my arguments convicing, I understand :) Thanks a lot! Alberto PS: As an example of a related RFC that is AFAIK not widely deployed, and which I think most popular deployments violate, is RFC 7817 "Updated TLS Server Identity Check Procedure for Email-Related Protocols". It applies to POP3, IMAP and SMTP submission (excludes MTA-to-MTA), and specifies that servers must have certificates not only for the host name used to access them (e.g. imap.example.net) but also to the top level domain used for email addresses (example.net in this case): https://tools.ietf.org/html/rfc7817#section-6 Neither gmail.com, yahoo.com, live.com or outlook.com imap, pop3 or smtp submission do this (but in fairness, hotmail.com does). From nobody Thu Mar 30 05:45:21 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B7612969F for ; Thu, 30 Mar 2017 05:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2C8A2rB5Qi3 for ; Thu, 30 Mar 2017 05:45:16 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B051296AC for ; Thu, 30 Mar 2017 05:45:16 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id y18so1740469itc.1 for ; Thu, 30 Mar 2017 05:45:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LvIKfca9/lG7Yqdwc07UcEPH/ygj0qnWb7sAEL5E6ww=; b=U2rzlm1FooPOMb9kNuWHjDS8oqQDSJ5zIcsrNeVX54AzhSILohx9o2BaktO1pFk9rT 25NrvRFk3oTBecD6hAG5XqxeI0ZcJGpBVBe8d1tJgEcuHisLswdfGFAkYQqHp9E0Rq+M R/zQRRr9TK0/eGkAF+oXuZuPsYUT1AoZBksKpJYfiKF1k13HJv5VrsXU0DSTcHAyHm/R IQCgEglXzyGYEDh8Ejzh4K+cKVGpQMcNLR/COOTr6gOhylRErfL58mHsyRGUC7Sh9qoW e0XaRJHfwB5nKq+4ja95O7YqwQ6haGWDXwVvsju5TAScuxRbhudiZAsnElXOplh5cDwH ql4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LvIKfca9/lG7Yqdwc07UcEPH/ygj0qnWb7sAEL5E6ww=; b=p6/gcfzQHa2UUpJyrh/C2dCv3j8Pu8ZN5twVi8Qlp3SpVJrq04eafvxEum94lEC/AO Z1wy//msGhKOT779ETjLoeGITh8Uxvvwz2Yo/HBZXnOSJ0VW8TYYouN6fSIKuZbGGnYo a1m0VEnV35G6DqeBohUiaUebK1dRVVzN1WrVhSXpSYjtPk0JUKczqCgBr4Eav9b3HHlo pg+T8tBEcHW9rpVhcC+UaG9+adYnJ5yev+1MxkmbG4gZ/wPOw/q39i45nAe4YS8J0wSJ 1joJaZ8QdxwSItD/aVcgW/rniCw5sN8/1YSmhYOz+GyjEJjczOf5k7/YqhW6ofNP/A6c fU1A== X-Gm-Message-State: AFeK/H1aL1KdZdILFp7hzNcMnpR9j6sgsWi6mL4kQDYOq8qoqRVZyPhgIKdxbbZcF9YriE2gfcDcU1gdUo2rIeAo X-Received: by 10.36.13.149 with SMTP id 143mr169885itx.21.1490877915323; Thu, 30 Mar 2017 05:45:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.39.215 with HTTP; Thu, 30 Mar 2017 05:45:14 -0700 (PDT) In-Reply-To: <2DB01F3A9898AE41BB3266315D9FDA2704902822@S-DC-ESTE03-B.net1.cec.eu.int> References: <2DB01F3A9898AE41BB3266315D9FDA2704902822@S-DC-ESTE03-B.net1.cec.eu.int> From: Daniel Margolis Date: Thu, 30 Mar 2017 14:45:14 +0200 Message-ID: To: Gerard.DRAPER-GIL@ec.europa.eu Cc: Uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1144d5ec95391e054bf210b8" Archived-At: Subject: Re: [Uta] General question on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 12:45:19 -0000 --001a1144d5ec95391e054bf210b8 Content-Type: multipart/alternative; boundary=001a1144d5ec8cba0c054bf21002 --001a1144d5ec8cba0c054bf21002 Content-Type: text/plain; charset=UTF-8 Hi, The point is not to allow larger policy bodies but rather to leverage existing authentication of HTTPS server certificates. We want *some form* of authentication for two reasons: 1. We want it to be relatively hard to induce a DoS (as discussed in "Security Considerations"); requiring a policy to be authenticated helps mitigate that risk slightly. (Otherwise we're creating a variant of the inject-a-bad-MX-record DoS but with a really long TTL!) 2. More importantly, we want to allow recipient domains to update a policy on demand, outside of expirations, so that they can signal a new MX is trusted (and similar). The authentication mechanism need not be HTTPs, and in fact when I started drafting this originally I suggested we just stick the policy + signature + cert chain in a DNS record--but that implies big DNS records, and that people figure out how to fetch and validate them plus the whole cert chain, and ultimately, using HTTPS just seemed a lot easier and well-understood than that. Hopefully that makes sense, but I will note that there are some slight relevancies for the parallel thread going on about SAN vs MX host matching--namely that the motivator for HTTPS (to leverage well-understood existing protocols) is also an argument for host matching, as Alberto has pointed out. Dan On Thu, Mar 30, 2017 at 11:22 AM, wrote: > After reading the MTA-STS drafts, and following the discussions, there's > still a question that I do not fully understand. > > Why using DNS to "announce" the use of MTA-STS but rely on HTTPS for > publishing the policy? So far, the policy is not that complex. > Wouldn't a DNS TXT record suffice in many cases? > I understand that in some cases the policy may be longer, depending on how > many MX records a domain may have. > Fetching the policy from an HTTPS service could be an option for those who > require longer policy descriptions. > Another option for longer policies could be to add an 'include' parameter, > like in SPF, therefore avoiding the need of another service (HTTPS) to > deliver the policy. > > It may not simplify the work for the implementation of MTA-STS (fetching > from HTTPS would still have to be implemented), but it would make it easier > to deploy (I think). > > As example, the TXT records could look like: > > MTA-STS just DNS: > _mta-sts.example.com IN TXT "v=STSv1; id=20173003110000Z; mode=enforce; > mx=*.example.com; max_age=12345600" > > MTA-STS with DNS and HTTPS: > _mta-sts.example.com IN TXT "v=STSv1; id=20173003110000Z; use=https" > > MTA-STS with DNS and 'include': > _mta-sts.example.com IN TXT "v=STSv1; id=20173003110000Z; max_age=12345600 > include=_mta-sts01,_mta-sts02;" > _mta-sts01.example.com IN TXT "mx=mx1.example.com,mx2.example.com;" > _mta-sts02.example.com IN TXT "mx=*.example1.com;" > > Gerard Draper Gil > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > > --001a1144d5ec8cba0c054bf21002 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

The point is not to allow lar= ger policy bodies but rather to leverage existing authentication of HTTPS s= erver certificates. We want some form=C2=A0of authentication=C2=A0fo= r two reasons:

1. We want it to be relatively hard= to induce a DoS (as discussed in "Security Considerations"); req= uiring a policy to be authenticated helps mitigate that risk slightly. (Oth= erwise we're creating a variant of the inject-a-bad-MX-record DoS but w= ith a really long TTL!)

2. More importantly, we wa= nt to allow recipient domains to update a policy on demand, outside of expi= rations, so that they can signal a new MX is trusted (and similar).=C2=A0

The authentication mechanism need not be HTTPs, and= in fact when I started drafting this originally I suggested we just stick = the policy + signature + cert chain in a DNS record--but that implies big D= NS records, and that people figure out how to fetch and validate them plus = the whole cert chain, and ultimately, using HTTPS just seemed a lot easier = and well-understood than that.=C2=A0

Hopefully tha= t makes sense, but I will note that there are some slight relevancies for t= he parallel thread going on about SAN vs MX host matching--namely that the = motivator for HTTPS (to leverage well-understood existing protocols) is als= o an argument for host matching, as Alberto has pointed out.=C2=A0

Dan

On Thu, Mar 30, 2017 at 11:22 AM, <<= a href=3D"mailto:Gerard.DRAPER-GIL@ec.europa.eu" target=3D"_blank">Gerard.D= RAPER-GIL@ec.europa.eu> wrote:
After reading the MTA-STS drafts, and following the discussions, there= 's still a question that I do not fully understand.

Why = using DNS to "announce" the use of MTA-STS but rely on HTTPS for = publishing the policy?=C2=A0So far, the policy is not that complex.= =C2=A0
Wouldn't a DNS TXT record suffice in many cases?=C2=A0
I understand that in some cases the policy may be longer, depending on= how many MX records a domain may have.=C2=A0
Fetching the policy from an HTTPS service could be an option for those= who require longer policy descriptions.=C2=A0
Another option for longer policies could be to add an 'include'= ; parameter, like in SPF, therefore avoiding the need of another service (H= TTPS) to deliver the policy.=C2=A0

It may not simplify the work for t= he implementation of MTA-STS (fetching from HTTPS would still have to be im= plemented), but it would make it easier to deploy (I think).

As example, the TXT records could look like:

MTA-STS just DNS:=C2=A0
_mta-sts.example.com IN TXT "v=3DSTSv1; id=3D201= 73003110000Z; mode=3Denforce; mx=3D*.example.com; max_age=3D12345600"

MTA-STS with =C2=A0DNS and HTTPS:=C2=A0<= /div>
_mta-sts.example.com I= N TXT "v=3DSTSv1; id=3D20173003110000Z; use=3Dhttps"

MTA-= STS with =C2=A0DNS and 'include':=C2=A0
_mta-sts.example.com IN TXT "v=3DSTSv1; id= =3D20173003110000Z;=C2=A0max_age= =3D12345600=C2=A0include=3D= _mta-sts01,_mta-sts02;"

Gerard Draper Gil

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta


--001a1144d5ec8cba0c054bf21002-- --001a1144d5ec95391e054bf210b8 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+ q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0 TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg 5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27 8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAKglzlQpF/2Xx2 ol08nDyr0GBWuSeG5HxeHL4YEuSEcjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAzMzAxMjQ1MTVaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAYvBjDfUsvICpsKsTjp/QXpYCz/KmvHoa vWqdyRrs3JQ+yrSAllu5YkyhggpvCU2AJd2DoTHnJMFj4sAPnFlbewkSfu2eXrmf/E834W8/NvYM oR4L6lQnRTiHBwdcrJqelvAB53KG95Wj2BtyPwpeNw/WaqC2fqzhNb939JjkgfrnNhPaDwnsk9yD 5tJUVPtUci8W9SL4yhUA5zdaOCFQHIquiEWVbX0LTzhPcjHFRLqCtBMPpCXTFf/Rq7FTqM1osl1Q meuQcBUqXAfT30e/4iQE39CGN/X9k45JX5ff0oCba4N4glMwVkmo2RbBrp/kk8stiQGK9YhCHzzo c6bgbw== --001a1144d5ec95391e054bf210b8-- From nobody Thu Mar 30 07:16:14 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31299124BE8 for ; Thu, 30 Mar 2017 07:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kq1h19FmqEzi for ; Thu, 30 Mar 2017 07:16:10 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72704126C26 for ; Thu, 30 Mar 2017 07:16:10 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 598DD7A32F1 for ; Thu, 30 Mar 2017 14:16:09 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: <20170330105556.GR11426@blitiri.com.ar> Date: Thu, 30 Mar 2017 10:16:08 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: <930AE500-DBD5-4AE1-B767-8E8B0CEA6044@dukhovni.org> References: <4C0807DA-4852-4DAC-80ED-8A25371CFFAA@dukhovni.org> <20170326205218.GN11426@blitiri.com.ar> <92500952-2A50-4508-8686-03CDBF72485D@dukhovni.org> <20170330105556.GR11426@blitiri.com.ar> To: uta@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Uta] MTA-STS-03 review X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 14:16:12 -0000 > On Mar 30, 2017, at 6:55 AM, Alberto Bertogli = wrote: >=20 > For example, how does this interact with SNI? e.g what name would the > client pick to give to the server in the TLS negotiation? Always the MX hostname. The server is however free to return its default certificate. While SNI makes some sense for multi-tenant submission servers, it is of little use in MX hosting, where the simplest hosting approach is to use the same MX hostname in the MX records of all the tenant domains. --=20 Viktor. From nobody Thu Mar 30 12:13:19 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9741292FD; Thu, 30 Mar 2017 12:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuR-8vDeN4UZ; Thu, 30 Mar 2017 12:13:10 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0138.outbound.protection.outlook.com [104.47.40.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C50126B6D; Thu, 30 Mar 2017 12:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tqPjjhmHwE2zrx0P77wengOGFm4hSN9OvyRKuEmYgyI=; b=mxRPv7EAFeAQSoXPcgyEBP7VFKw0hXQEWB/wWgR/ck4gWJpIkBJrEmrcnIndWXKaO6wnYEg4EZccYqLBKbVMGhpA+bm+ySSXxg/VQFi5Jgi2r4hnKJRS7LcBkzmmmuDdOXPw9tLq4odKfvvCBAs3qS/INipdqA3SHTA1KKEzLV8= Received: from CY1PR0301MB2122.namprd03.prod.outlook.com (10.164.2.156) by CY1PR0301MB2123.namprd03.prod.outlook.com (10.164.2.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Thu, 30 Mar 2017 19:13:05 +0000 Received: from CY1PR0301MB2122.namprd03.prod.outlook.com ([10.164.2.156]) by CY1PR0301MB2122.namprd03.prod.outlook.com ([10.164.2.156]) with mapi id 15.01.1005.013; Thu, 30 Mar 2017 19:13:05 +0000 From: Orit Levin To: "saag@IETF.org" CC: "uta@ietf.org" Thread-Topic: UTA WG report Thread-Index: AdKpiVl4npOFw8VXR1uQSoEzKgRD0A== Date: Thu, 30 Mar 2017 19:13:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: IETF.org; dkim=none (message not signed) header.d=none;IETF.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [31.133.149.103] x-microsoft-exchange-diagnostics: 1; CY1PR0301MB2123; 7:60H1jpqHzhwMsBKRlEw68BVRc9Yla8O8PbObN0BL4gEdpkybKkk7tj/PFSg0ylv1n0TqGDGhsDUKYG+cPrCjA4l/x8VwGscVAYD5nRJNV/aXd7EFkAibBxysmnB4IwGpA/j2219HKrr2Ku8zeYK38NguLABaapDGTJIs61ttTEW6740JwPsVijEQa+ZbsOGOFhbrsI6SDjtrmMf4uX3uD0QNHEMKoF45cEdz+nqtOWssmCLus/rA0bfCYtDC+YedCX5ZAMIofVR4AqxDlzcynKdIxyA4MgSxQv2YXB1gkCL2kN1pidZi0xusVLth5N/8mfpJJcgwudn6OSTeMb8Nyj1lnt5yX8FtpkOeQEQBv+0= x-ms-office365-filtering-correlation-id: 9606d3c6-3a11-414e-94a7-08d477a0cb54 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CY1PR0301MB2123; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:CY1PR0301MB2123; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB2123; x-forefront-prvs: 02622CEF0A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39410400002)(39400400002)(39840400002)(39860400002)(39450400003)(31014005)(110136004)(6116002)(102836003)(33656002)(790700001)(6916009)(74316002)(25786009)(3280700002)(6306002)(2351001)(9686003)(3480700004)(54896002)(3846002)(86362001)(7696004)(4326008)(122556002)(3660700001)(8936002)(53936002)(5630700001)(66066001)(189998001)(38730400002)(54356999)(450100002)(50986999)(6436002)(10090500001)(86612001)(2501003)(8990500004)(77096006)(55016002)(7736002)(10290500002)(81166006)(5005710100001)(5640700003)(1730700003)(2900100001)(5660300001)(7116003)(99286003)(6506006)(8676002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB2123; H:CY1PR0301MB2122.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB212290BDEA02EDE3ECEE0724AD340CY1PR0301MB2122_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2017 19:13:05.2435 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB2123 Archived-At: Subject: [Uta] UTA WG report X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 19:13:12 -0000 --_000_CY1PR0301MB212290BDEA02EDE3ECEE0724AD340CY1PR0301MB2122_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable UTA WG met on Tue. All agenda topics relate to using TLS with e-mail protoc= ols. MTA-MTA interface: The drafts are very close to WG LC. The only real open i= ssue remains the choice between Jason and tag-value format. Implementers ch= oice is split 50/50. Vast majority (if not all) are OK with implementing ei= ther. The AD (Alexei) will suggest specific syntax for tag-value format. Al= l interested parties (i.e., potential implementers) are encouraged to chime= in on UTA list because we will be resolving this last issue in the upcomin= g weeks and moving the draft to LC. MUA-MTA interface: the draft has been further updated. The relevancy (and t= he complexity) of the proposed protocol has been questioned during the meet= ing. Even if the answer is "irrelevant", the BCP part of the draft is still= very useful. The authors will investigate and proceed according to the res= ults. (Potentially, the draft could be shorten or split and the status chan= ged to BCP, Experimental, or both.) REQUIRE-TLS draft: the draft has been discussed and found valuable for spec= ific critical cases. It was suggested to continue working on the draft with= an intent to be adopted by UTA or other (new) WG going forward. Orit. --_000_CY1PR0301MB212290BDEA02EDE3ECEE0724AD340CY1PR0301MB2122_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

UTA WG met on Tue. All agenda topics relate to us= ing TLS with e-mail protocols.

 

MTA-MTA interface: The drafts are very close to W= G LC. The only real open issue remains the choice between Jason and tag-val= ue format. Implementers choice is split 50/50. Vast majority (if not all) a= re OK with implementing either. The AD (Alexei) will suggest specific syntax for tag-value format. All interes= ted parties (i.e., potential implementers) are encouraged to chime in on UT= A list because we will be resolving this last issue in the upcoming weeks a= nd moving the draft to LC.

 

MUA-MTA interface: the draft has been further upd= ated. The relevancy (and the complexity) of the proposed protocol has been = questioned during the meeting. Even if the answer is “irrelevant̶= 1;, the BCP part of the draft is still very useful. The authors will investigate and proceed according to the results. (Potent= ially, the draft could be shorten or split and the status changed to BCP, E= xperimental, or both.)

 

REQUIRE-TLS draft: the draft has been discussed a= nd found valuable for specific critical cases. It was suggested to continue= working on the draft with an intent to be adopted by UTA or other (new) WG= going forward.

 

Orit.

 

--_000_CY1PR0301MB212290BDEA02EDE3ECEE0724AD340CY1PR0301MB2122_-- From nobody Thu Mar 30 13:50:47 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C80129538; Thu, 30 Mar 2017 13:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJpKg5BC5nIB; Thu, 30 Mar 2017 13:50:38 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0103.outbound.protection.outlook.com [104.47.41.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DC831294A2; Thu, 30 Mar 2017 13:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JdlTtnaDL5TgNpo4ey5QTwyV2a+lsVTGEdBAYp/6vag=; b=WblJ/IcoO64GTbLVlwTfM0P1ZZO4SfVWG50FibVKVQm9ZvbGeRB3a4vCntVYRvLS/9YGyiLheDilAKTw1VSgRAcUaLbGvhtZq++hSqIn681i4C9/x7wGqkbykcgDtgyZlvLpXkOIjoPOSFJV/0C1G3WoanPPaVCFncKBcam1F/c= Received: from CY1PR0301MB2122.namprd03.prod.outlook.com (10.164.2.156) by CY1PR0301MB2122.namprd03.prod.outlook.com (10.164.2.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Thu, 30 Mar 2017 20:50:26 +0000 Received: from CY1PR0301MB2122.namprd03.prod.outlook.com ([10.164.2.156]) by CY1PR0301MB2122.namprd03.prod.outlook.com ([10.164.2.156]) with mapi id 15.01.1005.013; Thu, 30 Mar 2017 20:50:26 +0000 From: Orit Levin To: Keith Moore , "saag@ietf.org" CC: "uta@ietf.org" Thread-Topic: [saag] UTA WG report Thread-Index: AdKpiVl4npOFw8VXR1uQSoEzKgRD0AABFRoAAAIV6MA= Date: Thu, 30 Mar 2017 20:50:26 +0000 Message-ID: References: <866da370-1475-c4cb-f86a-7a92b3778160@network-heretics.com> In-Reply-To: <866da370-1475-c4cb-f86a-7a92b3778160@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: network-heretics.com; dkim=none (message not signed) header.d=none;network-heretics.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:67c:370:128:5cc:d8dd:f79e:d91b] x-microsoft-exchange-diagnostics: 1; CY1PR0301MB2122; 7:9cUaf0kgdpG8Mnp9eeRxQmiXsGpipTouFDnwWpZzws7oPpVLwc0ym8g4ZmfdR6JBm1Eq5VrzlBeyIBT1TYNMjkDqiqGZlhwL5E8yoPAXb+hgRDysIik8I+X+MtdDMGwgpRW2MZ8p552rB1MeRJg5AisnnbV/JfR3a9UCbWX/pOk6kStqn+DATIjJCzFALap6xi6JjIYkv+yMikcVWuWABtrHrZETaOQeIoJ5dsq+V9jTgNrzIRsBtGC/XbgiUTTTOhlqPsge5trL+l80IgFTq6Ul+HoiccTtExSXV4wPC7EfoUhFjxzxJKlFRTV/qo1jLgLkuHpC/wGrCC3Gz6Hf6k530DQORpePPCF072usmhY= x-ms-office365-filtering-correlation-id: 3492a6cc-e855-4de8-de90-08d477ae64cf x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CY1PR0301MB2122; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123562025)(6072148); SRVR:CY1PR0301MB2122; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB2122; x-forefront-prvs: 02622CEF0A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39860400002)(39410400002)(39840400002)(39850400002)(39400400002)(24454002)(31014005)(377454003)(54356999)(236005)(8990500004)(3660700001)(122556002)(50986999)(10090500001)(76176999)(99286003)(6306002)(54896002)(9686003)(81166006)(8676002)(5005710100001)(7696004)(5660300001)(2950100002)(3280700002)(10290500002)(33656002)(53936002)(77096006)(6506006)(6436002)(2501003)(55016002)(4326008)(7906003)(7736002)(6116002)(102836003)(2900100001)(790700001)(6246003)(53546009)(189998001)(2906002)(606005)(74316002)(229853002)(8936002)(86362001)(38730400002)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB2122; H:CY1PR0301MB2122.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB21225D1659C24FD946B66E5AAD340CY1PR0301MB2122_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2017 20:50:26.3723 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB2122 Archived-At: Subject: Re: [Uta] [saag] UTA WG report X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 20:50:41 -0000 --_000_CY1PR0301MB21225D1659C24FD946B66E5AAD340CY1PR0301MB2122_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Keith, Great intro to gathering the very much needed feedback. Adding UTA so we can continue the discussion there. Thanks, Orit. From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Keith Moore Sent: Thursday, March 30, 2017 12:42 PM To: saag@ietf.org Subject: Re: [saag] UTA WG report As co-author of this document, I frankly don't understand what the "BCP par= t" of draft-ietf-email-deep-06 is. BCP is appropriate for process documen= ts, or for specifications that don't lend themselves to interoperability te= sting and thus cannot progress to full standard. Neither of those is the c= ase for deep. The assertion was made by one of the meeting attendees that the goals of th= is specification can be met by mail service providers (MSPs) incrementally = blocking access to customers whose mail user agents (MUAs) don't negotiate = TLS. While I acknowledge that one MSP has successfully employed this stra= tegy, I personally wonder how well this works for very large MSPs. To me i= t seems like the customer support burden would be substantial. But I'm wo= rking on getting feedback on the draft - both from implementors of widely-u= sed MUAs, and from other MSPs - to see what they say about the draft. Regardless of whether this protocol gets support from implementors, I would= not consider this work finished until we have consensus on how to upgrade = all MUA-server traffic to use TLS 1.1 or better, and have confidence that t= his will enable us to deprecate cleartext and TLS <=3D 1.0 access to these = services within a year or two. Of course, if there's general agreement among MSPs that they can do this wi= thout changes to MUAs and servers, so much the better. But the work isn'= t done until we have consensus on a way forward (whether it happens in UTA = or not). Keith On 03/30/2017 03:13 PM, Orit Levin wrote: UTA WG met on Tue. All agenda topics relate to using TLS with e-mail protoc= ols. MTA-MTA interface: The drafts are very close to WG LC. The only real open i= ssue remains the choice between Jason and tag-value format. Implementers ch= oice is split 50/50. Vast majority (if not all) are OK with implementing ei= ther. The AD (Alexei) will suggest specific syntax for tag-value format. Al= l interested parties (i.e., potential implementers) are encouraged to chime= in on UTA list because we will be resolving this last issue in the upcomin= g weeks and moving the draft to LC. MUA-MTA interface: the draft has been further updated. The relevancy (and t= he complexity) of the proposed protocol has been questioned during the meet= ing. Even if the answer is "irrelevant", the BCP part of the draft is still= very useful. The authors will investigate and proceed according to the res= ults. (Potentially, the draft could be shorten or split and the status chan= ged to BCP, Experimental, or both.) REQUIRE-TLS draft: the draft has been discussed and found valuable for spec= ific critical cases. It was suggested to continue working on the draft with= an intent to be adopted by UTA or other (new) WG going forward. Orit. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --_000_CY1PR0301MB21225D1659C24FD946B66E5AAD340CY1PR0301MB2122_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Keith,

Great intro to gath= ering the very much needed feedback.

Adding UTA so we ca= n continue the discussion there.

Thanks,<= /span>

Orit.

 

From:= saag [mailto:saag-bounces@ietf.org] On Behalf Of Keith Moore
Sent: Thursday, March 30, 2017 12:42 PM
To: saag@ietf.org
Subject: Re: [saag] UTA WG report

 

As co-author of this document, I frankly don't understand what the "= ;BCP part" of draft-ietf-email-deep-06 is.   BCP is appropri= ate for process documents, or for specifications that don't lend themselves= to interoperability testing and thus cannot progress to full standard.  Neither of those is the case for deep.

The assertion was made by one of the meeting attendees that the goals of th= is specification can be met by mail service providers (MSPs) incrementally = blocking access to customers whose mail user agents (MUAs) don't negotiate = TLS.   While I acknowledge that one MSP has successfully employed this strategy, I personally wonder how w= ell this works for very large MSPs.  To me it seems like the customer = support burden would be substantial.   But I'm working on getting= feedback on the draft - both from implementors of widely-used MUAs, and from other MSPs - to see what they say about the = draft.

Regardless of whether this protocol gets support from implementors, I would= not consider this work finished until we have consensus on how to upgrade = all MUA-server traffic to use TLS 1.1 or better, and have confidence that t= his will enable us to deprecate cleartext and TLS <=3D 1.0 access to these services within a year or tw= o.  

Of course, if there's general agreement among MSPs that they can do this wi= thout changes to MUAs and servers, so much the better.    Bu= t the work isn't done until we have consensus on a way forward (whether it = happens in UTA or not).

Keith

 

On 03/30/2017 03:13 PM, Orit Levin wrote:=

UTA WG met on Tue. All agenda topics relate to us= ing TLS with e-mail protocols.

 

MTA-MTA interface: The drafts are very close to W= G LC. The only real open issue remains the choice between Jason and tag-val= ue format. Implementers choice is split 50/50. Vast majority (if not all) a= re OK with implementing either. The AD (Alexei) will suggest specific syntax for tag-value format. All interes= ted parties (i.e., potential implementers) are encouraged to chime in on UT= A list because we will be resolving this last issue in the upcoming weeks a= nd moving the draft to LC.

 

MUA-MTA interface: the draft has been further upd= ated. The relevancy (and the complexity) of the proposed protocol has been = questioned during the meeting. Even if the answer is “irrelevant̶= 1;, the BCP part of the draft is still very useful. The authors will investigate and proceed according to the results. (Potent= ially, the draft could be shorten or split and the status changed to BCP, E= xperimental, or both.)

 

REQUIRE-TLS draft: the draft has been discussed a= nd found valuable for specific critical cases. It was suggested to continue= working on the draft with an intent to be adopted by UTA or other (new) WG= going forward.

 

Orit.

 




_______________________________________________
saag mailing list
saag@ietf.org
https://www.iet=
f.org/mailman/listinfo/saag

 

--_000_CY1PR0301MB21225D1659C24FD946B66E5AAD340CY1PR0301MB2122_-- From nobody Thu Mar 30 14:27:00 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CE3129498 for ; Thu, 30 Mar 2017 14:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5QfUDQlj4n6 for ; Thu, 30 Mar 2017 14:26:47 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90862127B31 for ; Thu, 30 Mar 2017 14:26:45 -0700 (PDT) Received: from dhcp-8607.meeting.ietf.org (dhcp-8607.meeting.ietf.org [31.133.134.7]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v2ULQgiR026632 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 30 Mar 2017 14:26:44 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1490909204; bh=KWQerahjMEmMaEQuqWuLpez8rdzZKK/enpYw5GE+Y+c=; h=Subject:To:References:From:Date:In-Reply-To; b=BY4/QavvRd4A0AkR0FWFvn2DGRj1dNyQkqh+ou+X99R+95ldWv9lVqye3z59YaGxP tfeawny317PXUrAfA7rLpBqfSNZqL0V0g7oRizYaXVY56Yy4xNMgael/OM0FyidLYr 8N1kapcLX96vRBQu952eAZb1ooRcNv/m0S3+oyak= To: Orit Levin , Keith Moore , "uta@ietf.org" References: <866da370-1475-c4cb-f86a-7a92b3778160@network-heretics.com> From: Jim Fenton Message-ID: <5356f074-6aa0-e6f6-1dde-173b1772ad69@bluepopcorn.net> Date: Thu, 30 Mar 2017 14:26:41 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DCFF82778DEC2FC08C9AED11" Archived-At: Subject: Re: [Uta] [saag] UTA WG report X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 21:26:59 -0000 This is a multi-part message in MIME format. --------------DCFF82778DEC2FC08C9AED11 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable [removing saag list because this is probably at a lower level of detail than appropriate there. But feel free to add them if I'm wrong] My sense that there is a "BCP part" to the draft is probably more clearly stated that there are really two different things described in the draft, as the draft itself says in section 5 paragraph 4: "Note that security directives are a separate mechanism from minimum confidentiality assurance levels." It appears to me that it's possible independently to implement/deploy confidentiality assurance levels and security directives. So I would split them up into separate documents. I still see confidentiality assurance levels as more of a BCP-ish mechanism. It defines particular security requirements for MUA-MTA connections to meet Confidentiality Assurance Level (CAL) 1, and different ones for CAL 0. That seems like a best current practice to me. I think we should tease these two things apart into separate specifications so that it's clear you can have one or the other or both. But the categorization of these two things doesn't really matter to me (whether CAL is a standards-track protocol or a BCP, specifically). -Jim On 3/30/17 1:50 PM, Orit Levin wrote: > > Keith, > > Great intro to gathering the very much needed feedback. > > Adding UTA so we can continue the discussion there. > > Thanks, > > Orit. > > =20 > > *From:*saag [mailto:saag-bounces@ietf.org] *On Behalf Of *Keith Moore > *Sent:* Thursday, March 30, 2017 12:42 PM > *To:* saag@ietf.org > *Subject:* Re: [saag] UTA WG report > > =20 > > As co-author of this document, I frankly don't understand what the > "BCP part" of draft-ietf-email-deep-06 is. BCP is appropriate for > process documents, or for specifications that don't lend themselves to > interoperability testing and thus cannot progress to full standard.=20 > Neither of those is the case for deep. > > The assertion was made by one of the meeting attendees that the goals > of this specification can be met by mail service providers (MSPs) > incrementally blocking access to customers whose mail user agents > (MUAs) don't negotiate TLS. While I acknowledge that one MSP has > successfully employed this strategy, I personally wonder how well this > works for very large MSPs. To me it seems like the customer support > burden would be substantial. But I'm working on getting feedback on > the draft - both from implementors of widely-used MUAs, and from other > MSPs - to see what they say about the draft. > > Regardless of whether this protocol gets support from implementors, I > would not consider this work finished until we have consensus on how > to upgrade all MUA-server traffic to use TLS 1.1 or better, and have > confidence that this will enable us to deprecate cleartext and TLS <=3D= > 1.0 access to these services within a year or two. =20 > > Of course, if there's general agreement among MSPs that they can do > this without changes to MUAs and servers, so much the better. But > the work isn't done until we have consensus on a way forward (whether > it happens in UTA or not). > > Keith > > =20 > > On 03/30/2017 03:13 PM, Orit Levin wrote: > > UTA WG met on Tue. All agenda topics relate to using TLS with > e-mail protocols. > > =20 > > MTA-MTA interface: The drafts are very close to WG LC. The only > real open issue remains the choice between Jason and tag-value > format. Implementers choice is split 50/50. Vast majority (if not > all) are OK with implementing either. The AD (Alexei) will suggest > specific syntax for tag-value format. All interested parties > (i.e., potential implementers) are encouraged to chime in on UTA > list because we will be resolving this last issue in the upcoming > weeks and moving the draft to LC. > > =20 > > MUA-MTA interface: the draft has been further updated. The > relevancy (and the complexity) of the proposed protocol has been > questioned during the meeting. Even if the answer is =93irrelevant=94= , > the BCP part of the draft is still very useful. The authors will > investigate and proceed according to the results. (Potentially, > the draft could be shorten or split and the status changed to BCP, > Experimental, or both.) > > =20 > > REQUIRE-TLS draft: the draft has been discussed and found valuable > for specific critical cases. It was suggested to continue working > on the draft with an intent to be adopted by UTA or other (new) WG > going forward. > > =20 > > Orit. > > =20 > > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > > =20 > > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta --------------DCFF82778DEC2FC08C9AED11 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
[removing saag list because this is probably at a lower level of detail than appropriate there. But feel free to add them if I'm wrong]

My sense that there is a "BCP part" to the draft is probably more clearly stated that there are really two different things described in the draft, as the draft itself says in section 5 paragraph 4:

"Note that security directives are a separate mechanism from minimum confidentiality assurance levels."

It appears to me that it's possible independently to implement/deploy confidentiality assurance levels and security directives. So I would split them up into separate documents.

I still see confidentiality assurance levels as more of a BCP-ish mechanism. It defines particular security requirements for MUA-MTA connections to meet Confidentiality Assurance Level (CAL) 1, and different ones for CAL 0. That seems like a best current practice to me.

I think we should tease these two things apart into separate specifications so that it's clear you can have one or the other or both. But the categorization of these two things doesn't really matter to me (whether CAL is a standards-track protocol or a BCP, specifically).

-Jim

On 3/30/17 1:50 PM, Orit Levin wrote:

Keith,

Great intro to gathering the very much needed feedback.

Adding UTA so we can continue the discussion there.

Thanks,

Orit.

 

From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Keith Moore
Sent: Thursday, March 30, 2017 12:42 PM
To: saag@ietf.org
Subject: Re: [saag] UTA WG report

 

As co-author of this document, I frankly don't understand what the "BCP part" of draft-ietf-email-deep-06 is.   BCP is appropriate for process documents, or for specifications that don't lend themselves to interoperability testing and thus cannot progress to full standard.  Neither of those is the case for deep.

The assertion was made by one of the meeting attendees that the goals of this specification can be met by mail service providers (MSPs) incrementally blocking access to customers whose mail user agents (MUAs) don't negotiate TLS.   While I acknowledge that one MSP has successfully employed this strategy, I personally wonder how well this works for very large MSPs.  To me it seems like the customer support burden would be substantial.   But I'm working on getting feedback on the draft - both from implementors of widely-used MUAs, and from other MSPs - to see what they say about the draft.

Regardless of whether this protocol gets support from implementors, I would not consider this work finished until we have consensus on how to upgrade all MUA-server traffic to use TLS 1.1 or better, and have confidence that this will enable us to deprecate cleartext and TLS <= 1.0 access to these services within a year or two.  

Of course, if there's general agreement among MSPs that they can do this without changes to MUAs and servers, so much the better.    But the work isn't done until we have consensus on a way forward (whether it happens in UTA or not).

Keith

 

On 03/30/2017 03:13 PM, Orit Levin wrote:

UTA WG met on Tue. All agenda topics relate to using TLS with e-mail protocols.

 

MTA-MTA interface: The drafts are very close to WG LC. The only real open issue remains the choice between Jason and tag-value format. Implementers choice is split 50/50. Vast majority (if not all) are OK with implementing either. The AD (Alexei) will suggest specific syntax for tag-value format. All interested parties (i.e., potential implementers) are encouraged to chime in on UTA list because we will be resolving this last issue in the upcoming weeks and moving the draft to LC.

 

MUA-MTA interface: the draft has been further updated. The relevancy (and the complexity) of the proposed protocol has been questioned during the meeting. Even if the answer is “irrelevant”, the BCP part of the draft is still very useful. The authors will investigate and proceed according to the results. (Potentially, the draft could be shorten or split and the status changed to BCP, Experimental, or both.)

 

REQUIRE-TLS draft: the draft has been discussed and found valuable for specific critical cases. It was suggested to continue working on the draft with an intent to be adopted by UTA or other (new) WG going forward.

 

Orit.

 




_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

 



_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta


--------------DCFF82778DEC2FC08C9AED11-- From nobody Thu Mar 30 14:47:27 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3F8129665 for ; Thu, 30 Mar 2017 14:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ewl7rhj_3lj for ; Thu, 30 Mar 2017 14:47:24 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDAD812960F for ; Thu, 30 Mar 2017 14:47:21 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 684EE20A54; Thu, 30 Mar 2017 17:47:21 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 30 Mar 2017 17:47:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=CuCcpLAaRiG0rpooo+5cylP3170b48RCgDbkdubBJ9Q=; b=Mef+ut41 XT3e5LmX8pXVwHyM1DTftum7HE1JkGYgG1fPTvgmB3FbU9T81Ka4ak3I/r3yfXYf BKv55gvueCLsGO6iKC7RosRAF4UiFN2/tTNQ6z/lBZ9/m+Eobb5O7OF/r3mZWam5 hkbV8WIO6bz/2aLqCIq2CeLhRHc1RxGt+v2SryEDiK/ndKriNOrlEZUS4yHaHF+v +P0IdoYfFL9Reln1uIIOaf03Adg4WsUVGBGC0zJyhIXYapcYn5PxihtHXfkJQeC9 +Y6Dujcqi/phRWcc/0nj5Lzko7tAAOD3R4FGEd4ggv5h4VqIzh+izpBekXQWmm+X fUr1yaiTz0BFKQ== X-ME-Sender: X-Sasl-enc: 2e8Lz4OCOyhfatCrm+V8NvJheHO7gFfSm7Na+PXAtK+F 1490910441 Received: from [31.133.138.173] (unknown [31.133.138.173]) by mail.messagingengine.com (Postfix) with ESMTPA id 259197E334; Thu, 30 Mar 2017 17:47:21 -0400 (EDT) To: Jim Fenton , Orit Levin , "uta@ietf.org" References: <866da370-1475-c4cb-f86a-7a92b3778160@network-heretics.com> <5356f074-6aa0-e6f6-1dde-173b1772ad69@bluepopcorn.net> From: Keith Moore Message-ID: <8162d36f-2365-ddf5-5e58-2c341d846452@network-heretics.com> Date: Thu, 30 Mar 2017 17:47:20 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5356f074-6aa0-e6f6-1dde-173b1772ad69@bluepopcorn.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] [saag] UTA WG report X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 21:47:26 -0000 On 03/30/2017 05:26 PM, Jim Fenton wrote: > [removing saag list because this is probably at a lower level of > detail than appropriate there. But feel free to add them if I'm wrong] > > My sense that there is a "BCP part" to the draft is probably more > clearly stated that there are really two different things described in > the draft, as the draft itself says in section 5 paragraph 4: > > "Note that security directives are a separate mechanism from minimum > confidentiality assurance levels." > > It appears to me that it's possible independently to implement/deploy > confidentiality assurance levels and security directives. So I would > split them up into separate documents. > > I still see confidentiality assurance levels as more of a BCP-ish > mechanism. It defines particular security requirements for MUA-MTA > connections to meet Confidentiality Assurance Level (CAL) 1, and > different ones for CAL 0. That seems like a best current practice to me. Disagree. Compliance with both the CAL and the security directives are a matter of protocol interaction between client and server. The only real difference is that in the CAL case, no new protocol features need to be defined (we're talking about new client interactions with existing server features); whereas for security directives there are changes to the protocols used by the servers. But in both cases these are protocol interactions. A client's compliance with this protocol can be tested, and the protocol could reasonably advance to full standard (or not) based on such testing with multiple client implementations. So I don't understand why BCP is more appropriate. (But if that's what IESG wanted to do, I wouldn't fight it. Let's just try to not let this question delay the document, ok?) I also believe it would be more confusing to have two documents for confidentiality assurance level and security directives, because both of them require the client to disconnect if the requirements aren't met. But I'll think about that some more. The current document is longer than I'd like, and there's a tendency for readers to get overwhelmed by long documents and miss things. But when readers have to read multiple documents in order to implement changes, it usually makes the problem worse. > I think we should tease these two things apart into separate > specifications so that it's clear you can have one or the other or both. The only benefit I can see to that is that server implementors and MSPs and server implementors wouldn't have to read the CAL document [*], since that's all done on the user end. Offhand, I don't see why it's beneficial for an MUA to be able to implement either CAL or security directives or both. The two features were designed to work together. [*] except that MSPs would still need to know about CAL for customer support reasons Keith