From nobody Wed Jan 4 09:16:28 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 2F40B1299F3 for ; Wed, 4 Jan 2017 09:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 YgMFlZPEki9I for ; Wed, 4 Jan 2017 09:16:23 -0800 (PST) Received: from blitiri.com.ar (cdt.blitiri.com.ar [92.222.75.143]) (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 9C532129680 for ; Wed, 4 Jan 2017 09:16:23 -0800 (PST) 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") ; Wed, 04 Jan 2017 18:16:18 +0100 Date: Wed, 4 Jan 2017 17:16:17 +0000 From: Alberto Bertogli To: uta@ietf.org Message-ID: <20170104171617.GE24134@blitiri.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [Uta] MTA-STS - Questions on implementing the latest (02) draft 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, 04 Jan 2017 17:16:26 -0000 Hi! Happy new year! I had some time during the holidays and started to do a basic implementation of the latest MTA-STS draft. While doing so, there were a couple of things I wasn't sure about so I'd thought I'd ask: - What happens if the "mx" field is missing from the policy? Should the MTA skip checking the field but honour the rest of the policy, treat the policy as invalid, or assume no MX is valid? - For the case of an internationalized domain name, the "mx" field should include domain patterns in their U form (e.g. "*.ñaca.com"), A form ("*.*.xn--aca-6ma.com"), or both can be present? - The TXT record is on "_mta-sts" but the policy is on "mta-sts". Is that intentional? Why not putting both on the same domain, to simplify things? - The draft says that clients MUST check the TXT record, but it seems to me it's totaly possible to make a reasonable implementation without doing so. Is it worth using "MUST" for this? I imagine this is related to the previous discussion we had, but forcing MTAs to check seemed quite strong so I was wondering if there was something else. Thanks! Alberto In case you're curious, the implementation I have so far is at https://blitiri.com.ar/git/r/chasquid/b/sts/, in particular https://blitiri.com.ar/git/r/chasquid/c/febad008f38c9ac980a4c0a6179a7681fed7f125/ (patch and branch are subject to rebasing). It's mostly fetching, parsing and checking. It has no caching or reporting yet; I will add them later, but thought these questions are independent anyway. The integration into the MTA itself will come later too, but I expect it to be roughly similar to the integration into the smtp-check tool, which is included. From nobody Thu Jan 5 04:29: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 770F812947C for ; Thu, 5 Jan 2017 04:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 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=-3.1, 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 IDpIpPplfYEM for ; Thu, 5 Jan 2017 04:29:52 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 7621A1288B8 for ; Thu, 5 Jan 2017 04:29:46 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id a10so340982713ywa.3 for ; Thu, 05 Jan 2017 04:29:46 -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=R9i/6GCIC2kHRbJikh3wD21irYBEJF8jnVyy2sQtKmM=; b=QnF+JL8XARw+B5AFrJUJWSGUYdrEXMzRVsqCxUxqjIEqF34m0gz/EV4TsGtwAiBh6C JKyCvf4rlHDDqrtF8r5ICHj3LCKGa+qNZaC98+HeA2TFCNQqooXJiYHCaKPYRd1E4j8W Xoa/Rjm3+u3Xas6+7Jv3gIqMW+KkEEmlJ+iaaK1aRitXmRVe1diPioCs8tBAsEqt1nOz o1O8iVH/6puFCdfT5XbzmQX3u/sTg/E3tdq0yf4Cdieg7L+CE3hQnhwyxeo5rDCfsuUe DJHzEFrFf3Fh5fnCH2ek6hN/N3rHizkTE+z2v77mlOgQoG5p3daRRqXcwadLtxTJoAjd LQRg== 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=R9i/6GCIC2kHRbJikh3wD21irYBEJF8jnVyy2sQtKmM=; b=UgBwtWWi2EjwLD+fVfAkb721xuUnXHPyUSpDy4zeSyzsLWSCavpaBiA8GJRBxO7DDe nzNV1UYE55vWwXmdp/XTWrfoMrRZlNY/QUY6mVOMZvFXiJk+1wOmv/fk5VPzGoI/+FJC 1zEvSi1Xk1B16WDTehBmrZhKiC8Uwm76/KKME4slVeBBR7b3hbBFfDqGj/CW2M5/+HtA oh7pHEbMQo4fIxFEcalwfh/fzCiIvYcyFF/biRlhqIDDZWYv3jPC8JGvv2q2HbpNM336 PImmTuwncreu+jmMng0nlJ9KIRDZMivKm9VttE3vfxRog6o3+sqSfzlgOFdZ2pY1X6g3 eRMA== X-Gm-Message-State: AIkVDXIlQw7dZBzqH+2YBQ5Df0LepX/XlE6m8VwmwvGlg+zyV9kX5luxoVHjo+ef2rOGwYjHDrrj/NYatWuFmcob X-Received: by 10.129.173.93 with SMTP id l29mr65696574ywk.351.1483619385287; Thu, 05 Jan 2017 04:29:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.217.84 with HTTP; Thu, 5 Jan 2017 04:29:44 -0800 (PST) In-Reply-To: <20170104171617.GE24134@blitiri.com.ar> References: <20170104171617.GE24134@blitiri.com.ar> From: Daniel Margolis Date: Thu, 5 Jan 2017 05:29:44 -0700 Message-ID: To: Alberto Bertogli Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045e8a1a7aa0810545580ec9" Archived-At: Cc: uta@ietf.org Subject: Re: [Uta] MTA-STS - Questions on implementing the latest (02) draft 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: Thu, 05 Jan 2017 12:29:54 -0000 --f403045e8a1a7aa0810545580ec9 Content-Type: multipart/alternative; boundary=f403045e8a1a71b1dc0545580e18 --f403045e8a1a71b1dc0545580e18 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Inline: On Wed, Jan 4, 2017 at 10:16 AM, Alberto Bertogli wrote: > > Hi! Happy new year! > > I had some time during the holidays and started to do a basic > implementation of the latest MTA-STS draft. > > While doing so, there were a couple of things I wasn't sure about so I'd > thought I'd ask: > > - What happens if the "mx" field is missing from the policy? > Should the MTA skip checking the field but honour the rest of the polic= y, > treat the policy as invalid, or assume no MX is valid? > The "mx" field is required, so if it is missing, the policy is invalid and should not be honored. (It doesn't make sense to honor the policy anyway, I would say, since a policy without allowed MXs is essentially a way of saying, "There should be TLS and the server identity should match the MX, whatever the MX is." I guess this prevents SSL stripping, but doesn't prevent DNS injection, so it's of relatively little value.) > - For the case of an internationalized domain name, the "mx" field should > include domain patterns in their U form (e.g. "*.=C3=B1aca.com > "), A form > ("*.*.xn--aca-6ma.com"), or both can be present? > I suppose this is underspecified in the draft! I would say based on https://tools.ietf.org/html/rfc6125#section-6.4.2 that it makes the most sense for this to be in the A-form, since otherwise the MTA would have to convert to the A form for checking. What do you think? I proably can make a quick change to clarify this if it seems reasonable to those on this list. > - The TXT record is on "_mta-sts" but the policy is on "mta-sts". Is that > intentional? Why not putting both on the same domain, to simplify thing= s? > Yes, this is intentional. The underscore in "_mta-sts" was kept to be similar to that in (e.g.) _dmarc TXT records, but for the HTTP host this seemed inadvisable: https://www.ietf.org/mail-archive/web/uta/current/msg01524.html. > > - The draft says that clients MUST check the TXT record, but it seems to = me > it's totaly possible to make a reasonable implementation without doing > so. > Is it worth using "MUST" for this? > I imagine this is related to the previous discussion we had, but > forcing MTAs to check seemed quite strong so I was wondering if > there was something else. > I think there's some utility in specifying this as at least a SHOULD so as to ensure common behavior--otherwise, a recipient domain that updates its HTTP but not TXT will work some of the time for some senders, I guess? That seems risky. But need it be a MUST? Probably not. The truth of the matter is, as you say, that nobody would really know (except from slightly higher request rates) if your implementation did HTTP-only. ;) I'm open to making this a SHOULD, but it's not something I have a strong feeling about one way or another. What do you (and others) think--worth changing to SHOULD? Better to keep a "MUST"? > > > Thanks! > Alberto > > > In case you're curious, the implementation I have so far is at > https://blitiri.com.ar/git/r/chasquid/b/sts/, in particular > https://blitiri.com.ar/git/r/chasquid/c/febad008f38c9ac980a4c0a6179a76 > 81fed7f125/ > (patch and branch are subject to rebasing). > > It's mostly fetching, parsing and checking. It has no caching or > reporting yet; I will add them later, but thought these questions are > independent anyway. > I feel slightly bad for not having shared this earlier, but I wrote a toy implementation here: https://github.com/danmarg/smtp-sts. As with yours, it does not do caching or reporting; I wrote it merely to power this: http://sts.x.af0.net. Feel free to copy any code you like, of course, though it's a little late for that. ;) > > The integration into the MTA itself will come later too, but I expect it > to be roughly similar to the integration into the smtp-check tool, which > is included. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --f403045e8a1a71b1dc0545580e18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Inli= ne:

On= Wed, Jan 4, 2017 at 10:16 AM, Alberto Bertogli <albertito@blitiri.= com.ar> wrote:

Hi! Happy new year!

I had some time during the holidays and started to do a basic
implementation of the latest MTA-STS draft.

While doing so, there were a couple of things I wasn't sure about so I&= #39;d
thought I'd ask:

- What happens if the "mx" field is missing from the policy?
=C2=A0 Should the MTA skip checking the field but honour the rest of the po= licy,
=C2=A0 treat the policy as invalid, or assume no MX is valid?

The "mx" field is required, so if it is mi= ssing, the policy is invalid and should not be honored. (It doesn't mak= e sense to honor the policy anyway, I would say, since a policy without all= owed MXs is essentially a way of saying, "There should be TLS and the = server identity should match the MX, whatever the MX is." I guess this= prevents SSL stripping, but doesn't prevent DNS injection, so it's= of relatively little value.)=C2=A0
=C2=A0
- For the case of an internationalized domain name, the "mx" fiel= d should
=C2=A0 include domain patterns in their U form (e.g. "*.=C3=B1aca.com= "), A form
=C2=A0 ("*.*.xn--aca-6ma.com"), or both can be present?

I suppose this is underspecified in the draft!<= /div>

I would say based on https://tools.ietf.org/html/rfc6125#sectio= n-6.4.2 that it makes the most sense for this to be in the A-form, sinc= e otherwise the MTA would have to convert to the A form for checking. What = do you think?=C2=A0

I proably can make a quick cha= nge to clarify this if it seems reasonable to those on this list.=C2=A0
=C2=A0
- The TXT record is on "_mta-sts" but the policy is on "mta-= sts". Is that
=C2=A0 intentional? Why not putting both on the same domain, to simplify th= ings?

Yes, this is intentional. The und= erscore in "_mta-sts" was kept to be similar to that in (e.g.) _d= marc TXT records, but for the HTTP host this seemed inadvisable:=C2=A0http= s://www.ietf.org/mail-archive/web/uta/current/msg01524.html.=C2=A0
=C2=A0

- The draft says that clients MUST check the TXT record, but it seems to me=
=C2=A0 it's totaly possible to make a reasonable implementation without= doing so.
=C2=A0 Is it worth using "MUST" for this?
=C2=A0 I imagine this is related to the previous discussion we had, but
=C2=A0 forcing MTAs to check seemed quite strong so I was wondering if
=C2=A0 there was something else.

I thin= k there's some utility in specifying this as at least a SHOULD so as to= ensure common behavior--otherwise, a recipient domain that updates its HTT= P but not TXT will work some of the time for some senders, I guess? That se= ems risky.=C2=A0

But need it be a MUST? Probably n= ot. The truth of the matter is, as you say, that nobody would really know (= except from slightly higher request rates) if your implementation did HTTP-= only. ;)=C2=A0

I'm open to making this a SHOUL= D, but it's not something I have a strong feeling about one way or anot= her. What do you (and others) think--worth changing to SHOULD? Better to ke= ep a "MUST"?
=C2=A0


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


In case you're curious, the implementation I have so far is at
https://blitiri.com.ar/git/r/chasquid/b/sts/, i= n particular
https://blitiri.com= .ar/git/r/chasquid/c/febad008f38c9ac980a4c0a6179a7681fed7f12= 5/
(patch and branch are subject to rebasing).

It's mostly fetching, parsing and checking. It has no caching or
reporting yet; I will add them later, but thought these questions are
independent anyway.

I feel slightly bad= for not having shared this earlier, but I wrote a toy implementation here:= =C2=A0https://github.com/da= nmarg/smtp-sts. As with yours, it does not do caching or reporting; I w= rote it merely to power this: http://sts.x= .af0.net.=C2=A0

Feel free to copy any code you= like, of course, though it's a little late for that. ;)=C2=A0
=C2=A0

The integration into the MTA itself will come later too, but I expect it to be roughly similar to the integration into the smtp-check tool, which is included.

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

--f403045e8a1a71b1dc0545580e18-- --f403045e8a1a7aa0810545580ec9 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 efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCA0gAQW0dGEXCcO kaptUL8vd2RE2w6tnQYPGnHXCFWb7zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAxMDUxMjI5NDVaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAbaJHjFbIj54VvpthVKtx+Gu27zsqGjWJ TsB2bQc8vmzEifznUwG1kC7LCCXpVSfXNdMQWYimPAoH++35eg66ccyj3pVG9NoYuChsF6Y3ZfzF dlQX81XFTNmT8RpwJTe5pN5gtwYzrS6uP+9SX0gK9+fNamvKOBFQUdr42NDmFivfXgsku6Mdm4k6 8TGzr+wAAkDkJKNKtbigUoWJ6n0J46ZFPUQf/3JZk7ngwui9tk9BqsZeNPQNyvuqJwrAeFJcqg6g Bwm/UIHs8AKQTOSOYCZBxTr6Tvfvq7cJM2jHUYc93lU7Noj8lHcuLac/gyrO3rK1Z2fLjKDbY/4L BLm51g== --f403045e8a1a7aa0810545580ec9-- From nobody Thu Jan 5 09:45:09 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 E846B1295D8 for ; Thu, 5 Jan 2017 09:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 NrLedXtDtTVg for ; Thu, 5 Jan 2017 09:45:05 -0800 (PST) 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 09F871295CF for ; Thu, 5 Jan 2017 09:45:01 -0800 (PST) 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, 05 Jan 2017 18:44:59 +0100 Date: Thu, 5 Jan 2017 17:44:59 +0000 From: Alberto Bertogli To: Daniel Margolis Message-ID: <20170105174458.GF24134@blitiri.com.ar> References: <20170104171617.GE24134@blitiri.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: uta@ietf.org Subject: Re: [Uta] MTA-STS - Questions on implementing the latest (02) draft 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: Thu, 05 Jan 2017 17:45:08 -0000 On Thu, Jan 05, 2017 at 05:29:44AM -0700, Daniel Margolis wrote: > On Wed, Jan 4, 2017 at 10:16 AM, Alberto Bertogli > wrote: > > > > > Hi! Happy new year! > > > > I had some time during the holidays and started to do a basic > > implementation of the latest MTA-STS draft. > > > > While doing so, there were a couple of things I wasn't sure about so I'd > > thought I'd ask: > > > > - What happens if the "mx" field is missing from the policy? > > Should the MTA skip checking the field but honour the rest of the policy, > > treat the policy as invalid, or assume no MX is valid? > > > > The "mx" field is required, so if it is missing, the policy is invalid and > should not be honored. (It doesn't make sense to honor the policy anyway, I > would say, since a policy without allowed MXs is essentially a way of > saying, "There should be TLS and the server identity should match the MX, > whatever the MX is." I guess this prevents SSL stripping, but doesn't > prevent DNS injection, so it's of relatively little value.) Ack, thanks for clarifying! > > - For the case of an internationalized domain name, the "mx" field should > > include domain patterns in their U form (e.g. "*.ñaca.com > > "), A form > > ("*.*.xn--aca-6ma.com"), or both can be present? > > > > I suppose this is underspecified in the draft! > > I would say based on https://tools.ietf.org/html/rfc6125#section-6.4.2 that > it makes the most sense for this to be in the A-form, since otherwise the > MTA would have to convert to the A form for checking. What do you think? > > I proably can make a quick change to clarify this if it seems reasonable to > those on this list. FWIW, I'm fine with any of the options. I think allowing both forms makes it easier to deploy, so I'd be slightly in favour of that. Obviously that implies that the MTAs normalize the domains before doing the comparison, but that's not that big of a burden, I hope. Given the idempotency of the forms, normalizing inconditionally will always work regardless. But as long as it's clear, I don't feel very strongly about it :) > > - The TXT record is on "_mta-sts" but the policy is on "mta-sts". Is that > > intentional? Why not putting both on the same domain, to simplify things? > > > > Yes, this is intentional. The underscore in "_mta-sts" was kept to be > similar to that in (e.g.) _dmarc TXT records, but for the HTTP host this > seemed inadvisable: > https://www.ietf.org/mail-archive/web/uta/current/msg01524.html. Interesting, I didn't know underscores in domains were not HTTP friendly, thanks for the reference. Why not unify them both under the "mta-sts" domain then? I see the appeal of the similarity with things like _dmarc, but is it worth it? > > - The draft says that clients MUST check the TXT record, but it seems to me > > it's totaly possible to make a reasonable implementation without doing > > so. > > Is it worth using "MUST" for this? > > I imagine this is related to the previous discussion we had, but > > forcing MTAs to check seemed quite strong so I was wondering if > > there was something else. > > > > I think there's some utility in specifying this as at least a SHOULD so as > to ensure common behavior--otherwise, a recipient domain that updates its > HTTP but not TXT will work some of the time for some senders, I guess? That > seems risky. > > But need it be a MUST? Probably not. The truth of the matter is, as you > say, that nobody would really know (except from slightly higher request > rates) if your implementation did HTTP-only. ;) > > I'm open to making this a SHOULD, but it's not something I have a strong > feeling about one way or another. What do you (and others) think--worth > changing to SHOULD? Better to keep a "MUST"? I think is worth changing it to SHOULD because there's no technical reason a client must do the lookup, and seeing it as MUST may be confusing. As you say above, a client can skip the lookup and still behave nicely to the domains. But it's mostly a formality, I think; I was mostly worried that there was a strong reason behind the MUST that I wasn't seeing. > > In case you're curious, the implementation I have so far is at > > https://blitiri.com.ar/git/r/chasquid/b/sts/, in particular > > https://blitiri.com.ar/git/r/chasquid/c/febad008f38c9ac980a4c0a6179a76 > > 81fed7f125/ > > (patch and branch are subject to rebasing). > > > > It's mostly fetching, parsing and checking. It has no caching or > > reporting yet; I will add them later, but thought these questions are > > independent anyway. > > > > I feel slightly bad for not having shared this earlier, but I wrote a toy > implementation here: https://github.com/danmarg/smtp-sts. As with yours, it > does not do caching or reporting; I wrote it merely to power this: > http://sts.x.af0.net. > > Feel free to copy any code you like, of course, though it's a little late > for that. ;) Cool, I'll take a look and make sure I'm not missing anything! The web tool is quite handy as well, thanks for doing that :) Thanks! Alberto From nobody Fri Jan 6 02:18:28 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 E0609129499 for ; Fri, 6 Jan 2017 02:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 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=-3.1, 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 aCNOScbrVvvz for ; Fri, 6 Jan 2017 02:18:23 -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 6E12C129486 for ; Fri, 6 Jan 2017 02:18:23 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id v81so264123880ywb.2 for ; Fri, 06 Jan 2017 02:18:23 -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=9JV8rXuqOKucVj0k79MsQk9mU09RUQ34flWHzasp3ic=; b=FoIGMyZvFsQfN5J70GAH0f9eC0kVFaUffLc3dPT3zF97I32Lgoz388Bs06mqXXyk4/ kc4dNKs4gT2a2wKJZuE3RlLL9gIIkwv6dgdPJt+DRBgQfF2WHPfASzQG1HKIob86G4Qa BBtyC9hXt5BzID/ayORAXjSQeI/r18SjVvThGlIj7EZlV1dVDydopFt011BvFU24KoZy 8HROOqffcnCoyNQGwJYmXqmB4ZseSvXmknZq9n5aWJCl2bPKi6oJ3knv1f4mZCa2xrGX XkYmQ4xYlrpCTTWtfFt8iswrI45TLITct+BY3X89fnNrnx24cBACK8RU99fEiClf7H3x oOzQ== 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=9JV8rXuqOKucVj0k79MsQk9mU09RUQ34flWHzasp3ic=; b=gxYLaxLWz3i/xDkrMQLG90MElwuGHeNrD7K5hoIblThtlPIXSx7kN6RE1T1Mk0AnK2 QMfj7t7dcO2pXN9lJrzTz2qJ8eF+iL3DeD5AYvedemGM+hkIsJSDOLYvuX/8KmRktPnZ MMNLtriTb7I16Ghbm6BKJrG0RnBSZhYH78WLGF8GTeZtgzfiF1ggsnE/mAzOjIxfOCXT KvBK/Rh5DYOX2L/brxdnQKfLNuEIMT0fo993zags6B3wH08551SKcCQqTITg/AfqrXTT p6AU0botTg8vL+PPrkx9S1Gzjww53X1JlZL9WIuvQMFlQ2ojqQrRb7FVK8qKou1zwN5c c80A== X-Gm-Message-State: AIkVDXI4f7WYkw8bvYauvqQbgQh3WPoWPIHgjnEVVWPLdrueHMncHq93nsRA25gjeDOhEWCbfWyikePnTltyN6Z2 X-Received: by 10.129.173.93 with SMTP id l29mr70622696ywk.351.1483697902039; Fri, 06 Jan 2017 02:18:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.217.84 with HTTP; Fri, 6 Jan 2017 02:18:21 -0800 (PST) In-Reply-To: <20170105174458.GF24134@blitiri.com.ar> References: <20170104171617.GE24134@blitiri.com.ar> <20170105174458.GF24134@blitiri.com.ar> From: Daniel Margolis Date: Fri, 6 Jan 2017 11:18:21 +0100 Message-ID: To: Alberto Bertogli Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045e8a1a711c7b05456a5619" Archived-At: Cc: uta@ietf.org Subject: Re: [Uta] MTA-STS - Questions on implementing the latest (02) draft 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: Fri, 06 Jan 2017 10:18:26 -0000 --f403045e8a1a711c7b05456a5619 Content-Type: multipart/alternative; boundary=f403045e8a1a68399805456a565c --f403045e8a1a68399805456a565c Content-Type: text/plain; charset=UTF-8 Thanks again for the feedback. On Thu, Jan 5, 2017 at 6:44 PM, Alberto Bertogli wrote: > I think allowing both forms makes it easier to deploy, so I'd be > slightly in favour of that. Obviously that implies that the MTAs > normalize the domains before doing the comparison, but that's not that > big of a burden, I hope. > > Given the idempotency of the forms, normalizing inconditionally will > always work regardless. > > But as long as it's clear, I don't feel very strongly about it :) > Right. Not a big deal either way, I agree. Your point I guess is that we can instead just call out the possibility of IDN MXs and recommend that everyone decode both the hostname and the "mx" property to ASCII before comparing and we're good. I agree. I have no complaints with adding this to the draft to make sure it's explicit. https://github.com/mrisher/smtp-sts/issues/127 for now, and I will try to batch this with any other changes needed. > > > - The TXT record is on "_mta-sts" but the policy is on "mta-sts". Is > that > > > intentional? Why not putting both on the same domain, to simplify > things? > > > > > > > Yes, this is intentional. The underscore in "_mta-sts" was kept to be > > similar to that in (e.g.) _dmarc TXT records, but for the HTTP host this > > seemed inadvisable: > > https://www.ietf.org/mail-archive/web/uta/current/msg01524.html. > > Interesting, I didn't know underscores in domains were not HTTP > friendly, thanks for the reference. > > Why not unify them both under the "mta-sts" domain then? I see the > appeal of the similarity with things like _dmarc, but is it worth it? > *shrug* It's fairly arbitrary. Maybe at most an issue of aesthetics. > But need it be a MUST? Probably not. The truth of the matter is, as you > > say, that nobody would really know (except from slightly higher request > > rates) if your implementation did HTTP-only. ;) > > > > I'm open to making this a SHOULD, but it's not something I have a strong > > feeling about one way or another. What do you (and others) think--worth > > changing to SHOULD? Better to keep a "MUST"? > > I think is worth changing it to SHOULD because there's no technical > reason a client must do the lookup, and seeing it as MUST may be > confusing. As you say above, a client can skip the lookup and still > behave nicely to the domains. > > But it's mostly a formality, I think; I was mostly worried that there > was a strong reason behind the MUST that I wasn't seeing. > Nope, nothing. I'm open to feedback from anyone else reading this. As with the other point, it's mostly aesthetic, I think (but a fair observation nonetheless). --f403045e8a1a68399805456a565c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Than= ks again for the feedback.

On Thu, Jan 5, 2017 at 6:44 PM, Alberto Bertogli <albertito@blitiri.com.ar> wrote:
I think allowing both forms makes it easier to= deploy, so I'd be
slightly in favour of that.=C2=A0 Obviously that implies that the MTAs
normalize the domains before doing the comparison, but that's not that<= br> big of a burden, I hope.

Given the idempotency of the forms, normalizing inconditionally will
always work regardless.

But as long as it's clear, I don't feel very strongly about it :)

Right. Not a big deal either way, I agre= e. Your point I guess is that we can instead just call out the possibility = of IDN MXs and recommend that everyone decode both the hostname and the &qu= ot;mx" property to ASCII before comparing and we're good. I agree.= =C2=A0

I have no complaints with adding this to th= e draft to make sure it's explicit.=C2=A0https://github.com/mrisher/smtp-sts/issues/127= for now, and I will try to batch this with any other changes needed.= =C2=A0
=C2=A0
> > - The TXT record is on "_mta-sts" but the policy is on = "mta-sts". Is that
> >=C2=A0 =C2=A0intentional? Why not putting both on the same domain,= to simplify things?
> >
>
> Yes, this is intentional. The underscore in "_mta-sts" was k= ept to be
> similar to that in (e.g.) _dmarc TXT records, but for the HTTP host th= is
> seemed inadvisable:
> https://www.ietf.org/mail-a= rchive/web/uta/current/msg01524.html.

Interesting, I didn't know underscores in domains were not HTTP<= br> friendly, thanks for the reference.

Why not unify them both under the "mta-sts" domain then? I see th= e
appeal of the similarity with things like _dmarc, but is it worth it?

*shrug*

It's fa= irly arbitrary. Maybe at most an issue of aesthetics.=C2=A0

<= /div>
> But need it be a MUST? Probably not. The truth of the matter is, as= you
> say, that nobody would really know (except from slightly higher reques= t
> rates) if your implementation did HTTP-only. ;)
>
> I'm open to making this a SHOULD, but it's not something I hav= e a strong
> feeling about one way or another. What do you (and others) think--wort= h
> changing to SHOULD? Better to keep a "MUST"?

I think is worth changing it to SHOULD because there's no techni= cal
reason a client must do the lookup, and seeing it as MUST may be
confusing. As you say above, a client can skip the lookup and still
behave nicely to the domains.

But it's mostly a formality, I think; I was mostly worried that there was a strong reason behind the MUST that I wasn't seeing.

Nope, nothing.=C2=A0

I'= m open to feedback from anyone else reading this. As with the other point, = it's mostly aesthetic, I think (but a fair observation nonetheless).=C2= =A0
--f403045e8a1a68399805456a565c-- --f403045e8a1a711c7b05456a5619 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 efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDdrqfEDGDXxfkB Ycg1sipZLv1oHpn226yltfpqG2GSjzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAxMDYxMDE4MjJaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAN+3IORq1OA03BPkw7tE3RtJ0kf/9wabc 9EhmTxnYc1YXipfCIm3mVNTEQj2BHL247uLoO8DIKig9PFds3wQ1iMKoPIkQgUAYfkHb1VX2wS91 18gmEAj4fpaol6Vntj1HylhFk0N0WXwiVk/gexjLxneehUBP75G/JOssqqsCYPbz8+se25Mi3bwd WksZ9OFCqF9hkZCETyOySOs0JCN4ic8CvIeBTYTmt2+zzPLkRUPsebj6C9ZAyUWpsL9gKfjuk+Sh +cAWUlQWdOEmBHqlcKdwQJ715kvSQR7WpPZWKVJpqjb2jv+mLApHBriM5JYD+HmnF9Ra8cpDVA4L 1NMTbw== --f403045e8a1a711c7b05456a5619-- From nobody Fri Jan 6 05:08:35 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 BA928129B0C for ; Fri, 6 Jan 2017 05:08:32 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 3nC1QC9_9RzJ for ; Fri, 6 Jan 2017 05:08:20 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B40D129434 for ; Fri, 6 Jan 2017 05:08:20 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 389FB284B0C; Fri, 6 Jan 2017 13:08:19 +0000 (UTC) Date: Fri, 6 Jan 2017 13:08:19 +0000 From: Viktor Dukhovni To: uta@ietf.org Message-ID: <20170106130819.GF13486@mournblade.imrryr.org> References: <20170104171617.GE24134@blitiri.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Uta] MTA-STS - Questions on implementing the latest (02) draft 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: Fri, 06 Jan 2017 13:08:33 -0000 On Thu, Jan 05, 2017 at 05:29:44AM -0700, Daniel Margolis wrote: > > - For the case of an internationalized domain name, the "mx" field should > > include domain patterns in their U form (e.g. "*.ñaca.com > > "), A form > > ("*.*.xn--aca-6ma.com"), or both can be present? > > > > I suppose this is underspecified in the draft! > > I would say based on https://tools.ietf.org/html/rfc6125#section-6.4.2 that > it makes the most sense for this to be in the A-form, since otherwise the > MTA would have to convert to the A form for checking. What do you think? For domains that actually have MX records (not just implicit "domain. IN MX 0 domain.") the MX records will already be in A-label form, since they're the result of a DNS lookup. Nobody should have to convert these to U-labels just in case the domain owner's STS policy uses unicode. Since domains for domains that actually receive email (not just parked) lack of MX records is the exception and not the rule, the same should apply to the implicit MX. In any case the name needs to be converted to A-label form in order to perform the lookup that determines that there are no MX records. So, bottom line, for simple and deterministic behaviour the mx property must be in A-label (ASCII) form, the client must compare A-label names against this property, and U-label forms, should not match. -- Viktor. From nobody Fri Jan 6 07:55:51 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 20EB8129B3A for ; Fri, 6 Jan 2017 07:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 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=-3.1, 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 kFD-6eKVM6Dr for ; Fri, 6 Jan 2017 07:55:44 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 622F6129B39 for ; Fri, 6 Jan 2017 07:55:44 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id v81so270874904ywb.2 for ; Fri, 06 Jan 2017 07:55: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; bh=z4GXU2gbmcU+3aWwM1Sx421FJVw6v0yAtMjutk7BMfE=; b=ZsJwNjvWL/RqLGBXUsKWQAX6OEJDBQItthZVWw07G/3GkXXaM14I+fL2OKKWjxoeMJ gCQ5SuhyFbP8b5re28nxklWtTqtOGVmh5XXqV/tktLFC/6iVGQtxaCOzPikdUim7hM4P csWUCHMwrKlqjjkRhuTIQv+VpnUupsGvN7PJYSDTlcwBfnMvCLxMxjeBi9Axj+xaScFJ 59Y1oCmPVwHUd7W/cIpkPqvaZS5S/+Y5dmrwkbhg/ly12VKK9tCFZ8kviFM/v3B5aqfr sdBkOZURn7BWsTe5aAPMi4TkIRYDzuJnu2UM73jpqqxwy5XRyPTx9Jh6wSgpJVlVjaX9 sU/Q== 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=z4GXU2gbmcU+3aWwM1Sx421FJVw6v0yAtMjutk7BMfE=; b=O2N4Ua7eNFUaWlFQLv+ar1HxNmhrmVA8g0AN7TQgg0i1utBp0ziFW16Ot+qFZwQ6Y7 UJQETCUVw4NWO79m+qwhhFkij5PV2aujl+QsbIgbMeGoBS9Xyp8AXDekX+eY96Y4uruE PM1DCAJCSn05SCRFv8fp5xgC5RU9bdURzw72Hil8QNa+5SpFnxXsTUPKUmdAhrqxUWsv WdHdk/tZQ4L184ZWwa0gu2rbedpjxopGeGpSOhLzn25LRnYaxlfILBvcsaK54Y2TCfrX gso0zcf0t9Tcd+G2CJFKqhxZ5k9cmk2W8jLdXqwVTNUvwKdb5n6M/4MdkiBRExRzLyfa N3NQ== X-Gm-Message-State: AIkVDXKIiM8mYiccfa1nmnB9c8RouCO7Ota/6qiEQJNoGsZgTw+SClPRHCPbRsVv4OI2SKx+CKGJQPloyQyoXp12 X-Received: by 10.129.118.4 with SMTP id r4mr77544203ywc.24.1483718142913; Fri, 06 Jan 2017 07:55:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.217.84 with HTTP; Fri, 6 Jan 2017 07:55:42 -0800 (PST) In-Reply-To: <20170106130819.GF13486@mournblade.imrryr.org> References: <20170104171617.GE24134@blitiri.com.ar> <20170106130819.GF13486@mournblade.imrryr.org> From: Daniel Margolis Date: Fri, 6 Jan 2017 16:55:42 +0100 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045ef482e6096505456f0c5f" Archived-At: Subject: Re: [Uta] MTA-STS - Questions on implementing the latest (02) draft 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: Fri, 06 Jan 2017 15:55:47 -0000 --f403045ef482e6096505456f0c5f Content-Type: multipart/alternative; boundary=f403045ef482db72f805456f0c6e --f403045ef482db72f805456f0c6e Content-Type: text/plain; charset=UTF-8 On Fri, Jan 6, 2017 at 2:08 PM, Viktor Dukhovni wrote: > For domains that actually have MX records (not just implicit "domain. > IN MX 0 domain.") the MX records will already be in A-label form, > since they're the result of a DNS lookup. Nobody should have to > convert these to U-labels just in case the domain owner's STS policy > uses unicode. > The opposite, I assume--that you would convert the U-labels in the policy to punycode before comparing to the MX records. But as I said in my first reply, I think keeping everything A-form makes everything easier. On the other hand, as Alberto says, simply converting everything to A isn't that big a deal. *shrug* --f403045ef482db72f805456f0c6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Jan 6, 2017 at 2:08 PM, Viktor Dukhovni <ietf-dane@dukhovni.o= rg> wrote:
For domains that actually have MX re= cords (not just implicit "domain.
IN MX 0 domain.") the MX records will already be in A-label form,
since they're the result of a DNS lookup.=C2=A0 Nobody should have to convert these to U-labels just in case the domain owner's STS policy uses unicode.

The opposite, I assume--that = you would convert the U-labels in the policy to punycode before comparing t= o the MX records.=C2=A0

But as I said in my first reply, I think keeping everythi= ng A-form makes everything easier. On the other hand, as Alberto says, simp= ly converting everything to A isn't that big a deal. *shrug*
--f403045ef482db72f805456f0c6e-- --f403045ef482e6096505456f0c5f 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 efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBvMS+P2LC4g40u 2G1nmFOO3WDqjkWWbTUJ5feKTNV5gzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAxMDYxNTU1NDNaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAAwq2vqaYEeN8YWXG9Lwc6VjPFGDnlGAj ffpyDP+MCcq6N38iVYPZoNyi1XWIqs0n3EIg/7wlM6f1kFseDH87GBhSaoc/MycRKHMJTONrvhOM brLnW0Tm9BasU+uSmu8j0gnlb7IQsJv03S1g9DjG8gWx2W0lX9TCNaqRYfuFnFlwSW3ra7wsyNuy h5dds0IWLtahpFHevTIuVA+pXdrJ1I5bc/OHuRHCrHB48yMjN+NYEIKzsl2jXeUAp6dHXM62Ap0w ylmpw36kE3uoV10DuETjkqs9MtQk5TxK7Bx5xlLDi+jdQhzqWiIVjjK4VaaU6Fmc/addoIXq0vXw j6t37Q== --f403045ef482e6096505456f0c5f-- From nobody Fri Jan 6 08:24:23 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 172BC129411 for ; Fri, 6 Jan 2017 08:24:22 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 es7uj4WOH7sA for ; Fri, 6 Jan 2017 08:24:20 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63056124281 for ; Fri, 6 Jan 2017 08:24:20 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 352CA284B0C; Fri, 6 Jan 2017 16:24:19 +0000 (UTC) Date: Fri, 6 Jan 2017 16:24:19 +0000 From: Viktor Dukhovni To: uta@ietf.org Message-ID: <20170106162418.GG13486@mournblade.imrryr.org> References: <20170104171617.GE24134@blitiri.com.ar> <20170106130819.GF13486@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Uta] MTA-STS - Questions on implementing the latest (02) draft 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: Fri, 06 Jan 2017 16:24:22 -0000 On Fri, Jan 06, 2017 at 04:55:42PM +0100, Daniel Margolis wrote: > On Fri, Jan 6, 2017 at 2:08 PM, Viktor Dukhovni > wrote: > > > For domains that actually have MX records (not just implicit "domain. > > IN MX 0 domain.") the MX records will already be in A-label form, > > since they're the result of a DNS lookup. Nobody should have to > > convert these to U-labels just in case the domain owner's STS policy > > uses unicode. > > The opposite, I assume--that you would convert the U-labels in the policy > to punycode before comparing to the MX records. I am suggesting that policies should not contain U-labels, and therefore, there should be no conversion requirement. > But as I said in my first reply, I think keeping everything A-form makes > everything easier. Exactly. STS should require A-labels in the mx policy attribute. > On the other hand, as Alberto says, simply converting > everything to A isn't that big a deal. *shrug* Unnecessary complexity. The client will already have the A-label forms of both the domain name and the MX hostnames, and should not have to generate A-label encodings. Nor should it have to compute the A-label forms of the policy data. Especially because wildcards are not valid domain names, and U-to-A libraries may not directly support converting these, making the code to do so a bit more complex. -- Viktor. From nobody Fri Jan 6 09:49:01 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 02EA61295A2 for ; Fri, 6 Jan 2017 09:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 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=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jhcloos.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 Soj2McANSToa for ; Fri, 6 Jan 2017 09:48:59 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.22.87]) (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 1126C1295A0 for ; Fri, 6 Jan 2017 09:48:59 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id CD18C23721; Fri, 6 Jan 2017 17:48:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1483724937; bh=wppxBB+s42anU5TxvsgsnwM9raTecY4aiNllKWtIf+Y=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=FHVacVzczaxKDbncEEPksqLDD24cRw76EH/Ka8Je0B7Bj4Dhs1pKGIGlYt0h/DxNY EghiU4SUJqk+jRy8y3O8WHtfW38MguyszJZctTHc6c8ziu7eLPjldqFqyLxqFCP5Bb rGfIdafvxFiCksdowiGzWIwVaZMzghG8x6UmXJ5M= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 20115106F8EDF; Fri, 6 Jan 2017 17:48:53 +0000 (UTC) From: James Cloos To: Daniel Margolis In-Reply-To: (Daniel Margolis's message of "Fri, 6 Jan 2017 11:18:21 +0100") References: <20170104171617.GE24134@blitiri.com.ar> <20170105174458.GF24134@blitiri.com.ar> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2016 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 06 Jan 2017 12:48:53 -0500 Message-ID: Lines: 13 MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: uta@ietf.org, Alberto Bertogli Subject: Re: [Uta] MTA-STS - Questions on implementing the latest (02) draft 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: Fri, 06 Jan 2017 17:49:00 -0000 On the issue of mta-sts vs _mta-sts: The TXT and A/AAAA records should be under the same label. W/ or w/o an underscore *will* lead to implementors getting things wrong. And the two always should be in the same zone, even where zone cuts exist. It is not just aesthetics. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Fri Jan 6 13:00: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 63791129ECB for ; Fri, 6 Jan 2017 13:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no 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 YinNhwEbHGWk for ; Fri, 6 Jan 2017 13:00:16 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2596A129ECC for ; Fri, 6 Jan 2017 13:00:13 -0800 (PST) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d18 with ME id V90B1u00V17Lgi40390C9C; Fri, 06 Jan 2017 22:00:12 +0100 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Fri, 06 Jan 2017 22:00:12 +0100 X-ME-IP: 92.170.5.52 To: uta@ietf.org From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <333f7d8d-12af-ead4-dfc2-c5b4f1dd3b1a@trigofacile.com> Date: Fri, 6 Jan 2017 22:00:11 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Uta] Obsolete TLS wording in IMAP specification 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: Fri, 06 Jan 2017 21:00:17 -0000 Hi all, I've just seen that IMAP specification (RFC 3501) mentions in Section 11.1 that "IMAP client and server implementations MUST implement the TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite". Section 11.1 also does not give latest recommendations for certificate validation. Shouldn't it be updated in favour of following RFC 7525 (BCP for TLS) and RFC 6125 (guideline for certificate validation)? -- Julien ÉLIE « The following two statements are usually both true: There's not enough documentation. There's too much documentation. » (Larry Wall) From nobody Mon Jan 9 03:09:07 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 38A99129BE6 for ; Mon, 9 Jan 2017 03:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199, 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 0gfPqdVN2csB for ; Mon, 9 Jan 2017 03:09:05 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 08857129BE8 for ; Mon, 9 Jan 2017 03:09:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1483960144; d=isode.com; s=june2016; i=@isode.com; bh=eVNmcs8/Ulxt1gFGYPAmR/q5lM9z4xwkAZshTDm0B68=; 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=UMrnbZG7fUaPBT6fr+/JfA15tmJfJ7CG5e4JwtNKVzxR+CTO4m4Oc2pzZzVMBy3dk4A8J8 w9C503OM18WagCr/Psh8BKxWaqRgri4lYJOILQMYoZKzvfZQQWag5DUxCxaBe9xgeGEAVD syGvtDOvWM14egJGKKQMUJ55jOesaJc=; Received: from [172.20.1.74] (dhcp-74.isode.net [172.20.1.74]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 9 Jan 2017 11:09:03 +0000 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (14A456) In-Reply-To: <333f7d8d-12af-ead4-dfc2-c5b4f1dd3b1a@trigofacile.com> Date: Mon, 9 Jan 2017 11:26:22 +0000 Message-Id: <032C7805-AFDB-4256-9D87-9B3B7BEDD58D@isode.com> References: <333f7d8d-12af-ead4-dfc2-c5b4f1dd3b1a@trigofacile.com> To: =?utf-8?Q?Julien_=C3=89LIE?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: uta@ietf.org Subject: Re: [Uta] Obsolete TLS wording in IMAP specification 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, 09 Jan 2017 11:09:06 -0000 Hi Julien, > On 6 Jan 2017, at 21:00, Julien =C3=89LIE wrote: >=20 > Hi all, >=20 > I've just seen that IMAP specification (RFC 3501) mentions in Section 11.1= that "IMAP client and server implementations MUST implement the TLS_RSA_WIT= H_RC4_128_MD5 [TLS] cipher suite". > Section 11.1 also does not give latest recommendations for certificate val= idation. >=20 > Shouldn't it be updated in favour of following RFC 7525 (BCP for TLS) and R= FC 6125 (guideline for certificate validation)? Yes, that would be a good idea. Best Regards, Alexey From nobody Mon Jan 9 06:22: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 F0146129D03 for ; Mon, 9 Jan 2017 06:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5] 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 BqOUlZVMx1au for ; Mon, 9 Jan 2017 06:22:12 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CCA129D04 for ; Mon, 9 Jan 2017 06:21:55 -0800 (PST) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d65 with ME id WEMt1u00U17Lgi403EMtLU; Mon, 09 Jan 2017 15:21:53 +0100 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Mon, 09 Jan 2017 15:21:53 +0100 X-ME-IP: 92.170.5.52 References: <333f7d8d-12af-ead4-dfc2-c5b4f1dd3b1a@trigofacile.com> <032C7805-AFDB-4256-9D87-9B3B7BEDD58D@isode.com> To: uta@ietf.org From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <40f388b0-589b-0b10-6d70-5b0a40ffe4b5@trigofacile.com> Date: Mon, 9 Jan 2017 15:21:53 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <032C7805-AFDB-4256-9D87-9B3B7BEDD58D@isode.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Uta] Obsolete TLS wording in IMAP specification 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, 09 Jan 2017 14:22:15 -0000 Hi Alexey, >> I've just seen that IMAP specification (RFC 3501) mentions in >> Section 11.1 that "IMAP client and server implementations MUST >> implement the TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite". Section >> 11.1 also does not give latest recommendations for certificate >> validation. >> >> Shouldn't it be updated in favour of following RFC 7525 (BCP for >> TLS) and RFC 6125 (guideline for certificate validation)? > > Yes, that would be a good idea. Could the part about the cipher suites be included in a future version of draft-ietf-uta-email-deep? (The part about certificate validation was dealt with by RFC 7817.) draft-ietf-uta-email-deep already updates RFC 3501, and its goal is to improve email confidentiality between a mail user agent and a mail submission or mail access server, so I believe referencing RFC 7525 would be in the scope of this document. draft-ietf-uta-email-deep could then update Sections 2.1 and 2.2 of RFC 2595 (Using TLS with IMAP, POP3 and ACAP) and Section 11.1 of RFC 3501 (IMAPv4) to no longer require these obsolete cipher suites. Latest recommendation of RFC 7525 should just be followed. -- Julien ÉLIE « Ça n'a été qu'un coup de glaive dans l'eau. » (Astérix) From nobody Thu Jan 12 09:49: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 AE47B129447 for ; Thu, 12 Jan 2017 09:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.2 X-Spam-Level: X-Spam-Status: No, score=-5.2 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=-3.199, SPF_PASS=-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 kf44uBTwsEXx for ; Thu, 12 Jan 2017 09:49:08 -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 41CEE1293FC for ; Thu, 12 Jan 2017 09:49:07 -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 v0CHn4YC011007 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 12 Jan 2017 09:49:06 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1484243346; bh=xftAC3ayvsXgkNbwRr6g4lY17j9lLvoSwA+JuHbPdUQ=; h=Subject:To:References:From:Date:In-Reply-To; b=MFegeuJBRJ9e88r1AemAy11hmpW1MJ9ZWtgQR89RTceHneKBsNU7hdXplr7kTWdh+ opFREQMVdbVivWt40WjfGajBp6KWumNmM4s1GCW42O7vAsIqE96sCDupVbpJOjAH6p pszCC/+vMImYA+dGLpgvoaUpENzAi4mkp4IfxDwM= To: uta@ietf.org References: <20161209161308.51594.qmail@ary.lan> <20161210063812.GU13486@mournblade.imrryr.org> <01Q8AS96AJAC011H9Q@mauve.mrochek.com> <4BBD3B01-A43B-43E6-9FF1-807D0F00A6E1@dukhovni.org> From: Jim Fenton Message-ID: <1ce8a3e9-55b1-3a92-39c5-3eecc95c2994@bluepopcorn.net> Date: Thu, 12 Jan 2017 09:48:59 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <4BBD3B01-A43B-43E6-9FF1-807D0F00A6E1@dukhovni.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Uta] REQUIRETLS update 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: Thu, 12 Jan 2017 17:49:09 -0000 On 12/16/16 3:31 PM, Viktor Dukhovni wrote: >> On Dec 16, 2016, at 5:53 PM, Jim Fenton wrote= : >> >> It seems that Viktor and I have differing views on the usefulness of >> MAYTLS and REQUIRETLS. That said, I agree that it doesn't make sense t= o >> have two mechanisms for this, so I will try to formulate a hybrid >> mechanism for the next iteration of the draft. > Thanks. With that out of the way, I can elaborate on some of the polic= y > details that need to be discussed as part of this. > I'm working on the revision of the REQUIRETLS draft, and ran into a situation with "MAYTLS" that I'm not sure how to resolve. In the case of REQUIRETLS, it makes sense to make sure that the SMTP server to which the message is being sent supports REQUIRETLS, because otherwise the REQUIRETLS characteristics of the message will be lost and the message may be sent in the clear on a subsequent hop. But with MAYTLS (or what I'm thinking of as REQUIRETLS=3DNO, since it's asking that TLS not be required), there are two ways to handle this: 1. Go ahead and send message to an SMTP server not supporting the extension. But then the sender's request to send regardless of DANE or STS policy gets lost on subsequent hops. If the need was only to do this for a single hop, the SMTP client can just ignore the DANE or STS policy and wouldn't need the extension at all. 2. Make sure that the server supports the extension, but then the message will be more likely to be blocked/bounced, which is the opposite of the sender's intent (this is for urgent, non-sensitive messages). In other words, MAYTLS is very fragile unless onward support is confirmed and doing so is likely to run counter to the sender's request. Thoughts? -Jim From nobody Thu Jan 12 09:59:18 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 06E6F128E19 for ; Thu, 12 Jan 2017 09:59:18 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 0osQTEZzanEG for ; Thu, 12 Jan 2017 09:59:16 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B77129421 for ; Thu, 12 Jan 2017 09:59:15 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 95B39284E49; Thu, 12 Jan 2017 17:59:14 +0000 (UTC) Date: Thu, 12 Jan 2017 17:59:14 +0000 From: Viktor Dukhovni To: uta@ietf.org Message-ID: <20170112175914.GG3081@mournblade.imrryr.org> References: <20161209161308.51594.qmail@ary.lan> <20161210063812.GU13486@mournblade.imrryr.org> <01Q8AS96AJAC011H9Q@mauve.mrochek.com> <4BBD3B01-A43B-43E6-9FF1-807D0F00A6E1@dukhovni.org> <1ce8a3e9-55b1-3a92-39c5-3eecc95c2994@bluepopcorn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1ce8a3e9-55b1-3a92-39c5-3eecc95c2994@bluepopcorn.net> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Uta] REQUIRETLS update 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: Thu, 12 Jan 2017 17:59:18 -0000 On Thu, Jan 12, 2017 at 09:48:59AM -0800, Jim Fenton wrote: > I'm working on the revision of the REQUIRETLS draft, and ran into a > situation with "MAYTLS" that I'm not sure how to resolve. [ Thanks for moving forward with this work! ] > In the case of REQUIRETLS, it makes sense to make sure that the SMTP > server to which the message is being sent supports REQUIRETLS, because > otherwise the REQUIRETLS characteristics of the message will be lost and > the message may be sent in the clear on a subsequent hop. Yes. > But with MAYTLS (or what I'm thinking of as REQUIRETLS=NO, since it's > asking that TLS not be required), there are two ways to handle this: > > 1. Go ahead and send message to an SMTP server not supporting the > extension. But then the sender's request to send regardless of DANE or > STS policy gets lost on subsequent hops. If the need was only to do this > for a single hop, the SMTP client can just ignore the DANE or STS policy > and wouldn't need the extension at all. Yes. Send regardless. The signal is a best-effort signal. Since the MAYTLS feature is intended to facilitate delivery over security, mail needs to be delivered whether the feature is supported or not. So in some cases the signal may not get through all the requisite hops, but typically it only needs to get as far as the border MTA of the sender's organization. The MSA may not be that border MTA. Another approach is to define a new message header that requests a delivery despite apparent security downgrade. Such a signal would tunnel through MTAs that are oblivious to the signal. > 2. Make sure that the server supports the extension, but then the > message will be more likely to be blocked/bounced, which is the opposite > of the sender's intent (this is for urgent, non-sensitive messages). So no this. > In other words, MAYTLS is very fragile unless onward support is > confirmed and doing so is likely to run counter to the sender's request. > > Thoughts? I think that best-effort support is sufficient. Sites that support DANE or STS are early adopters with comparatively new MTAs, and are also more likely to also have MAYTLS support (once that's implemented in the most recent versions of popular MTAs). -- Viktor. From nobody Mon Jan 16 13:59: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 0DF4B1296CE for ; Mon, 16 Jan 2017 13:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 DeHM3UidiF3m for ; Mon, 16 Jan 2017 13:59:52 -0800 (PST) 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 190311296BD for ; Mon, 16 Jan 2017 13:59:51 -0800 (PST) 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") ; Mon, 16 Jan 2017 22:59:50 +0100 Date: Mon, 16 Jan 2017 21:59:47 +0000 From: Alberto Bertogli To: Daniel Margolis Message-ID: <20170116215947.GA7487@blitiri.com.ar> References: <20170104171617.GE24134@blitiri.com.ar> <20170105174458.GF24134@blitiri.com.ar> 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: Cc: uta@ietf.org Subject: Re: [Uta] MTA-STS - Questions on implementing the latest (02) draft 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, 16 Jan 2017 21:59:54 -0000 On Fri, Jan 06, 2017 at 11:18:21AM +0100, Daniel Margolis wrote: > Thanks again for the feedback. Sorry for the late reply, I was (almost) without internet the entire week. Responses inline as usual! > On Thu, Jan 5, 2017 at 6:44 PM, Alberto Bertogli > wrote: > > > I think allowing both forms makes it easier to deploy, so I'd be > > slightly in favour of that. Obviously that implies that the MTAs > > normalize the domains before doing the comparison, but that's not that > > big of a burden, I hope. > > > > Given the idempotency of the forms, normalizing inconditionally will > > always work regardless. > > > > But as long as it's clear, I don't feel very strongly about it :) > > > > Right. Not a big deal either way, I agree. Your point I guess is that we > can instead just call out the possibility of IDN MXs and recommend that > everyone decode both the hostname and the "mx" property to ASCII before > comparing and we're good. I agree. What you're saying SGTM. Whatever form is used (Viktor had some arguments towards A form in the other sub thread), I think it's worth calling it out explicitly to make it more clear to both software and policy writers, to avoid problems in the future once policies start to appear in the wild :) > > > > - The TXT record is on "_mta-sts" but the policy is on "mta-sts". Is > > that > > > > intentional? Why not putting both on the same domain, to simplify > > things? > > > > > > > > > > Yes, this is intentional. The underscore in "_mta-sts" was kept to be > > > similar to that in (e.g.) _dmarc TXT records, but for the HTTP host this > > > seemed inadvisable: > > > https://www.ietf.org/mail-archive/web/uta/current/msg01524.html. > > > > Interesting, I didn't know underscores in domains were not HTTP > > friendly, thanks for the reference. > > > > Why not unify them both under the "mta-sts" domain then? I see the > > appeal of the similarity with things like _dmarc, but is it worth it? > > > > *shrug* > > It's fairly arbitrary. Maybe at most an issue of aesthetics. Yes, I know it makes no functional difference, but having one record instead of two may make some things simpler and reduce the chance of confusion (even if it's easily detected). Not a big deal, but just thought I'd ask. Thanks again for being so patient and receptive to feedback! Alberto From nobody Mon Jan 16 14:08:41 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 575BD1296B3 for ; Mon, 16 Jan 2017 14:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 yJwcjELXteBC for ; Mon, 16 Jan 2017 14:08:39 -0800 (PST) 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 0590112941D for ; Mon, 16 Jan 2017 14:08:38 -0800 (PST) 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") ; Mon, 16 Jan 2017 23:08:37 +0100 Date: Mon, 16 Jan 2017 22:08:36 +0000 From: Alberto Bertogli To: uta@ietf.org Message-ID: <20170116220836.GB7487@blitiri.com.ar> References: <20170104171617.GE24134@blitiri.com.ar> <20170106130819.GF13486@mournblade.imrryr.org> <20170106162418.GG13486@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170106162418.GG13486@mournblade.imrryr.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Uta] MTA-STS - Questions on implementing the latest (02) draft 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, 16 Jan 2017 22:08:40 -0000 On Fri, Jan 06, 2017 at 04:24:19PM +0000, Viktor Dukhovni wrote: > On Fri, Jan 06, 2017 at 04:55:42PM +0100, Daniel Margolis wrote: > > > On Fri, Jan 6, 2017 at 2:08 PM, Viktor Dukhovni > > wrote: > > > > > For domains that actually have MX records (not just implicit "domain. > > > IN MX 0 domain.") the MX records will already be in A-label form, > > > since they're the result of a DNS lookup. Nobody should have to > > > convert these to U-labels just in case the domain owner's STS policy > > > uses unicode. > > > > The opposite, I assume--that you would convert the U-labels in the policy > > to punycode before comparing to the MX records. > > I am suggesting that policies should not contain U-labels, and > therefore, there should be no conversion requirement. > > > But as I said in my first reply, I think keeping everything A-form makes > > everything easier. > > Exactly. STS should require A-labels in the mx policy attribute. > > > On the other hand, as Alberto says, simply converting > > everything to A isn't that big a deal. *shrug* > > Unnecessary complexity. The client will already have the A-label > forms of both the domain name and the MX hostnames, and should not > have to generate A-label encodings. Nor should it have to compute > the A-label forms of the policy data. Especially because wildcards > are not valid domain names, and U-to-A libraries may not directly > support converting these, making the code to do so a bit more complex. You'd be making the code more complex but the policy writing simpler, so it wouldn't be entirely unnecessary. Whether it is a worth tradeoff, I'm sure it's arguable :) In any case, the main objective of my comment was to suggest that it's worth picking an option (A/U/both) and making it explicit, to avoid inconsistencies from appearing once implementations and policies start to appear. Thanks, Alberto