From nobody Wed Nov 1 03:59:42 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2A913B10E for ; Wed, 1 Nov 2017 03:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yOo9MBVMUBc for ; Wed, 1 Nov 2017 03:59:38 -0700 (PDT) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (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 4845D13A441 for ; Wed, 1 Nov 2017 03:59:38 -0700 (PDT) Received: by mail-io0-x244.google.com with SMTP id f20so5125550ioj.9 for ; Wed, 01 Nov 2017 03:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EF5HVPM2Al3+kVLABLYjWnycbC25opuhC42cPB/MTKY=; b=I9xzsYc+AjH2WL29luoWGueE9FGvmZQLri/knGSFoI4vBp1unX3rx/L79+KDyiloGC /GjGEypIt83nI1OQCnqa/mB8LHLDWhVLzpGEKAMKIP1FZEgOPd/u0PN4SwxM/uoZoE/B arx/ngvUJHfZeILLI0iI5khqVFl7ALMW31dDpBIMy22rMYlzAXQfTowDyTRrjyKUC0V/ 7AizRYADWSiA0rUkCTlRnmqYJSs9O01Crzk7NKOFUwIZZ8VgzUzfIpVeugDInwywz88S l4ptnl4fqt236h3EaePC+GLa8KB8v3ngAwbCJROrUZxRV5rplaLlbAdnnWjJdAwzdhrp aOrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EF5HVPM2Al3+kVLABLYjWnycbC25opuhC42cPB/MTKY=; b=hQvevB054z/RlgrotqFTkq3R+RCOi8kS8+66J2IWV/QbeoR7zgCreZYV7W6ph8Jg5I HOUiNtHFAgP9onSaptYNgrSKe3F4U/EGtllK5MIH1GgOwWwK+1KNvx2/6+Hxz8ruNt5H zA7QBNQFBhCuieLjB+sLbkJsvix8kICgyHXyTnaqvGk7x6wTEIMZxdyUlDL/YberJjZV msNWuEhhZxfMYVnhs+8eW8NhKjvPwktWJbqMv4YsnTsNr/gwyowxFKIRB6gxtWe+OCb7 ylVhp8eP1effMOnFmIAWZxPklqLHxW3dtjuCX/0wTapGUHPRF1MBTQb63RmjQu3UkAp5 OkRg== X-Gm-Message-State: AMCzsaWsr7WR5SAt0zzVeiFVgAPKVjTGGNwdZSDqEM2MHjNTd00bcmtN 3GDcSgPZM8IohxKKX+N+wt6cvtmkozc8ttJ32kS4Zkh+ X-Google-Smtp-Source: ABhQp+SmULOOPAk6Kq24Akgjfx5J9+wQyg9an4Z7uLJBn0mbjWMB1kP5MAJMzZjZ+Q70kONXdZFTlBlOt5MIVCqxT54= X-Received: by 10.36.254.140 with SMTP id w134mr7251208ith.73.1509533977001; Wed, 01 Nov 2017 03:59:37 -0700 (PDT) MIME-Version: 1.0 References: <285D4781-74B0-44EA-9776-5DE23D745DB3@dukhovni.org> <8673FAEC-CD26-4092-AFD5-5A681A167B6D@dukhovni.org> <60325D1E-EDC5-4FAF-91FD-5B40BD67FAB4@dukhovni.org> <52B55172-A2F6-4E42-9B12-D8C5C60A666F@bluepopcorn.net> <7DD01770-0DDE-4391-8A0F-406915A816B8@dukhovni.org> <9c096748-dd92-c227-64b2-e3600a68330b@bluepopcorn.net> <20171027163916.g57sdwg3us6dfzq4@blitiri.com.ar> In-Reply-To: <20171027163916.g57sdwg3us6dfzq4@blitiri.com.ar> From: Daniel Margolis Date: Wed, 01 Nov 2017 10:59:20 +0000 Message-ID: To: Alberto Bertogli Cc: uta@ietf.org, Leif Johansson Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c035a8a861e92055ce9c49d" Archived-At: Subject: [Uta] STS and SAN (vs Host) matching X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 10:59:40 -0000 --94eb2c035a8a861e92055ce9c49d Content-Type: multipart/alternative; boundary="94eb2c035a8a7a4855055ce9c4a4" --94eb2c035a8a7a4855055ce9c4a4 Content-Type: text/plain; charset="UTF-8" The decision to use policy-to-SAN matching instead of policy-to-hostname matching was discussed here ( https://www.ietf.org/mail-archive/web/uta/current/msg01938.html). I think the WG was at the time largely in consensus (or we misread the consensus). I thought we also discussed this at IETF95, but at this point my memory is hazy. To be clear, I think you are right that this affects a small number of users. RFC 7672 also allows this "nexthop" matching, but I think it's OK for STS to enforce a "must match the hostname" policy. On the flip side, I believe SAN matching is also fairly easy to implement (~10 lines of pseudocode in the Appendix--hopefully correct!--and Viktor says OpenSSL already exposes such a function). My understanding is that while you and Jim would prefer hostname matching and Viktor (and others?) would prefer SAN matching, nobody has said that if their non-preferred option is chosen this is a blocker for implementation. Am I right? If that's correct, process-wise, should we treat this as resolved previously (in draft 03), or should we try to revisit the consensus and close it out quickly? On Fri, Oct 27, 2017 at 6:39 PM Alberto Bertogli wrote: > On Thu, Oct 26, 2017 at 09:35:34PM -0400, Viktor Dukhovni wrote: > > > On Oct 26, 2017, at 9:21 PM, Jim Fenton > wrote: > > > > > > The question I have is: Why are we matching the certificate against the > > > policy rather than against the hostname, and is that done in any other > > > context? Does that offer any additional flexibility? > > > > This was discussed when the change was made, and again in response > > to Ivan's questions just in the past week or so. The flexibility > > in question allows the policy to specify that the certificate will > > match (say) the recipient domain and not the MX hostname, or either, > > or some unspecified hostname in a domain, leaving the match somewhat > > fuzzy, which you describe as "wildcard to wildcard". > > Note that according to the analysis linked by Daniel [1], "only > 0.6% of domains present trusted certificates that match their domain > name, while 34.2% present trusted certificates that match their MX > server". > > So to me you are arguing to add a non trivial amount of complexity to > certificate validation, and make it differ significantly from widely > used and tested logic; in exchange for making it easier for <1% of the > hosts to potentially adopt STS. > > I think that is a terrible tradeoff: the implementation complexity and > security risks are not worth the marginal benefit. > > Thanks, > Alberto > > > [1]: http://conferences.sigcomm.org/imc/2015/papers/p27.pdf > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --94eb2c035a8a7a4855055ce9c4a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The decision to use policy-to-SAN matching instead of poli= cy-to-hostname matching was discussed here (https://www.ietf.org/mail-arch= ive/web/uta/current/msg01938.html). I think the WG was at the time larg= ely in consensus (or we misread the consensus). I thought we also discussed= this at IETF95, but at this point my memory is hazy.=C2=A0

<= div>To be clear, I think you are right that this affects a small number of = users. RFC 7672 also allows this "nexthop" matching, but I think = it's OK for STS to enforce a "must match the hostname" policy= . On the flip side, I believe SAN matching is also fairly easy to implement= (~10 lines of pseudocode in the Appendix--hopefully correct!--and Viktor s= ays OpenSSL already exposes such a function).

My u= nderstanding is that while you and Jim would prefer hostname matching and V= iktor (and others?) would prefer SAN matching, nobody has said that if thei= r non-preferred option is chosen this is a blocker for implementation. Am I= right?

If that's correct, process-wise, shoul= d we treat this as resolved previously (in draft 03), or should we try to r= evisit the consensus and close it out quickly?=C2=A0


On Fri, Oct 27, 2017 at = 6:39 PM Alberto Bertogli <al= bertito@blitiri.com.ar> wrote:
On Thu, Oct 26, 2017 at 09:35:34PM -0400, Viktor Dukhovni wrote:
> > On Oct 26, 2017, at 9:21 PM, Jim Fenton <fenton@bluepopcorn.net> wrote= :
> >
> > The question I have is: Why are we matching the certificate again= st the
> > policy rather than against the hostname, and is that done in any = other
> > context? Does that offer any additional flexibility?
>
> This was discussed when the change was made, and again in response
> to Ivan's questions just in the past week or so.=C2=A0 The flexibi= lity
> in question allows the policy to specify that the certificate will
> match (say) the recipient domain and not the MX hostname, or either, > or some unspecified hostname in a domain, leaving the match somewhat > fuzzy, which you describe as "wildcard to wildcard".

Note that according to the analysis linked by Daniel [1], "only
0.6% of domains present trusted certificates that match their domain
name, while 34.2% present trusted certificates that match their MX
server".

So to me you are arguing to add a non trivial amount of complexity to
certificate validation, and make it differ significantly from widely
used and tested logic; in exchange for making it easier for <1% of the hosts to potentially adopt STS.

I think that is a terrible tradeoff: the implementation complexity and
security risks are not worth the marginal benefit.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alberto


[1]: http://conferences.sigcomm.org/imc/2015/p= apers/p27.pdf

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
--94eb2c035a8a7a4855055ce9c4a4-- --94eb2c035a8a861e92055ce9c49d 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMYvQlQqbPmlmUoZynMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODE4NDIxNloXDTE4MDMx NzE4NDIxNlowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDI3sfyM5pHCY0cDNbbiDAn17uPa3PG0G98FftCEkej/WTh RcWVnnX7STqcEnQwK7z8r8SckwfHWqDMNnb6PMXVZUOCv9iewPrxXlQfmFvDQQnRXbUKp7WgUjzm 5v1BIs/mIvqkrBsiPJLvNbO8b7BxewUnTP24wHaCYvlVFXd/A+hbq5CJciR230oH0bmB6zMlpxQe 45PlPkEkLb2cUaad14IV2ulfK8pcsLLM+NntC9jxKVAp3GCSAp6gjOmCJdCB4YlyC943ej9IoryJ fOVpmm6IOchzDTJH/rgPUWbQnZFhVw4V1EkHfrYugci2Up30l4SsMieOPgfd6oAwDzlbAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFFQQtjTE3yoZgnE8infGLj+S7TiRMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQBpExGZx6F4 zM7Y/n7mnIsXl81PZas0VWUjE0MMdlX+FBxLg6+tSAZL+pi0i/iRb9bNg3KLqo0mpN2cnHa0Cyeo 9+DUJYdHtitY7O0oDfN6qsTLKkI2ff4VhVRahJMa9RlBHuiJa09Tlu/d1BqqjF8Vlf+1ygExN6dx PL95kbdwYM+0GILX+rt4okmVWgj4ol9JgBcQG6MA6rQvuoJHpfxv0I6yNXMMe3R86vfnz5XFHrX1 RfudaTWxM29kR44KxN19+TtVs2HTb/YAgGyyI3sxsX/keInYwKOZEpX3PwXn30CjjzPDjXR9+Zye K9iJUpsLFz8YJkPSc2e90JrrGAFuMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM YvQlQqbPmlmUoZynMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAIFwDs/cIkxLHr 3XHF5A0iwvKOAjrcyPHAawmRBvOFozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzExMDExMDU5MzdaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAeG6KfPkf1WmvdVGQ7vzthMf0v3T+H5yv uyI5brUExxOdyDM6u/wXqGIhDsUCf2DSoMJ9tjFsRSCdfvo5h+zb1NQEGYyzvLoLL6d2UujEACJr tUB20+w/H4qcULa+OKbLhPMpX/tAYPQ/Xot7nvvst1zo8j4GfmbxIOnTBYtTQSgQrr5WUVF2oaYE oypmN8t2TYwWfBRpQ6x0/KCEcP7cYAJx/PCOUDgldLhq9fGtfOlKU8TCTmk9FyOFAxiKtxWpzcjE 4Z0XmFlToaC7mO3OLSIypeb/zPfua6yKZ3D4iJfAFReJd5L/ga+2iskgkDktaXXCqH9TvsThNMp8 Ou30JA== --94eb2c035a8a861e92055ce9c49d-- From nobody Wed Nov 1 04:02:58 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 A271313F5FB for ; Wed, 1 Nov 2017 04:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKTyiO9SUNbP for ; Wed, 1 Nov 2017 04:02:55 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 0642213F601 for ; Wed, 1 Nov 2017 04:02:55 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id 101so5190765ioj.3 for ; Wed, 01 Nov 2017 04:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=RnZ/JIpdSGjU8uHfM6llCG/3lp5H1qB7x4aJv5M+484=; b=knhmjcQozB6FdDAfKEI4xne2N4pxqnBr9bBy2rjVrbup37Mkc+Pj21njotMbR31Ro0 rBhqCdnHhwmuw1gI7UuIpxTNh2HHn0+8/AFAkYjZZfrFpKUBXi3VIMM4PwMJ/uniXmj7 Ena9Jk6n4IiwgCQYN/i9QstT8d1PZyi1jx0DX/s8VrWoo7nZsiwudwIXJf3PPOlmvckF CYtaf0s0WiUV8oC5B+P1dyqAvnKgIKg2HtBvVkM8aFusnj9PBz2ORJoFr+TZ45Od1/m9 U2eks63ZCZ5yVHMx8wbRMdNW2gyppOTOgDODbqm1WLiJ6avE41cR8fl9cXtm1dxRqXKt jkQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=RnZ/JIpdSGjU8uHfM6llCG/3lp5H1qB7x4aJv5M+484=; b=qckvbAcUs/u0uqFh2Qt3q5FSTs1xs7hb1c/+zNuLtsupUJG2vkNMF2+u6vAtndpVCA s/uO7YwR+JlKKkjUT7jKEa0vdp7VZov7INoT4/fdHs7dTwo/JXl9Yx4kZJqYAgG8tJTu DxiBAJ5w0iUKpqK8+c4iml9VNNw9EgdL46r24zcUWNwbwPb+rZF99Nl9fzlHfFkPPKJ7 LlHQDUH8Q0HcdUf9ifU5vwqOTx0oGtZ914kaKJslV9uDuWT8gRhJ78D4OY+azAr2y3KY zLHwIp8hhaFb1MqkSJuHROJwK0zjB6iWOvrDDgB7oVrsvXwARMRevdqBXAEiL/G247Fw QXww== X-Gm-Message-State: AMCzsaVLY9/O3TAolmXIiJJhRBN6sS5YSe3qzHu8/tl4fuUbAu7F257q 3XH5rjqXMYiR0wdfGsOJ8w1vICMywLwvux6jlVFB7qQe X-Google-Smtp-Source: ABhQp+Qe2zo7uj3zdsyGi9LTQVCNO7oI5aGTN3f+aPZlMAV6kjf+ZLBqdiCxQvRjiex7ZAuH97siXkgzm2VXDnHesSE= X-Received: by 10.107.222.17 with SMTP id v17mr6317698iog.283.1509534173588; Wed, 01 Nov 2017 04:02:53 -0700 (PDT) MIME-Version: 1.0 References: <20171024124400.yiisnjnfp6mujemv@LK-Perkele-VII> <23C60EE6-A769-43FA-8715-7365ABF4E307@dukhovni.org> <20171027110253.3191b6fc@pc1> <20171028223238.0654117f@pc1> In-Reply-To: From: Daniel Margolis Date: Wed, 01 Nov 2017 11:02:40 +0000 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403043d0a083a1c8f055ce9d0b7" Archived-At: Subject: Re: [Uta] Establishing minimum TLS requirements for use with STS X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 11:02:56 -0000 --f403043d0a083a1c8f055ce9d0b7 Content-Type: multipart/alternative; boundary="f403043d0a083250d4055ce9d0c7" --f403043d0a083250d4055ce9d0c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've draft language stolen from HTTP/2 that just requires TLS 1.2 or higher. If people want more specific language on this (e.g. blacklisted cipher suites, MTI ciphers), please suggest it. On Sun, Oct 29, 2017 at 1:05 AM Viktor Dukhovni wrote: > > > > On Oct 28, 2017, at 4:32 PM, Hanno B=C3=B6ck wrote: > > > > That's not how Bleichenbacher attacks work... (which you should know as > > a co-author of the drown paper.) > > You can safely drop the word "should"... > > > As it has been pointed out multiple > > times this attack works cross-protocol and cross-server, so the mere > > existence of a vulnerable TLS RSA implementaiton with the same cert is > > a risk. You don't need any downgrade attack for that. > > Yes, in the DROWN case the attack was a cross-protocol attack that > leveraged servers that exposed a certificate used with SSLv3+ (on > the same or some other server) via SSLv2. > > With SSLv2 out of the picture, which attacks from RFC7457 do see > as the motivation to set a floor higher than the TLS 1.2 MTI cipher > [ TLS_RSA_WITH_AES_128_CBC_SHA ] in SMTP? Sure, clients and servers > will typically negotiate other ciphers (PFS and AESGCM are quite > common, and perhaps more secure, barring GCM pitfalls and ECDHE > being broken by quantum computers any day now...). > > -- > Viktor. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --f403043d0a083250d4055ce9d0c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've draft language stolen from HTTP/2 that just requi= res TLS 1.2 or higher. If people want more specific language on this (e.g. = blacklisted cipher suites, MTI ciphers), please suggest it.=C2=A0

=
On Sun, Oct 29, 2017 at 1:0= 5 AM Viktor Dukhovni <ietf-dan= e@dukhovni.org> wrote:


> On Oct 28, 2017, at 4:32 PM, Hanno B=C3=B6ck <hanno@hboeck.de> wrote:
>
> That's not how Bleichenbacher attacks work... (which you should kn= ow as
> a co-author of the drown paper.)

You can safely drop the word "should"...

> As it has been pointed out multiple
> times this attack works cross-protocol and cross-server, so the mere > existence of a vulnerable TLS RSA implementaiton with the same cert is=
> a risk. You don't need any downgrade attack for that.

Yes, in the DROWN case the attack was a cross-protocol attack that
leveraged servers that exposed a certificate used with SSLv3+ (on
the same or some other server) via SSLv2.

With SSLv2 out of the picture, which attacks from RFC7457 do see
as the motivation to set a floor higher than the TLS 1.2 MTI cipher
[ TLS_RSA_WITH_AES_128_CBC_SHA ] in SMTP?=C2=A0 Sure, clients and servers will typically negotiate other ciphers (PFS and AESGCM are quite
common, and perhaps more secure, barring GCM pitfalls and ECDHE
being broken by quantum computers any day now...).

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

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
--f403043d0a083250d4055ce9d0c7-- --f403043d0a083a1c8f055ce9d0b7 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMYvQlQqbPmlmUoZynMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODE4NDIxNloXDTE4MDMx NzE4NDIxNlowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDI3sfyM5pHCY0cDNbbiDAn17uPa3PG0G98FftCEkej/WTh RcWVnnX7STqcEnQwK7z8r8SckwfHWqDMNnb6PMXVZUOCv9iewPrxXlQfmFvDQQnRXbUKp7WgUjzm 5v1BIs/mIvqkrBsiPJLvNbO8b7BxewUnTP24wHaCYvlVFXd/A+hbq5CJciR230oH0bmB6zMlpxQe 45PlPkEkLb2cUaad14IV2ulfK8pcsLLM+NntC9jxKVAp3GCSAp6gjOmCJdCB4YlyC943ej9IoryJ fOVpmm6IOchzDTJH/rgPUWbQnZFhVw4V1EkHfrYugci2Up30l4SsMieOPgfd6oAwDzlbAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFFQQtjTE3yoZgnE8infGLj+S7TiRMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQBpExGZx6F4 zM7Y/n7mnIsXl81PZas0VWUjE0MMdlX+FBxLg6+tSAZL+pi0i/iRb9bNg3KLqo0mpN2cnHa0Cyeo 9+DUJYdHtitY7O0oDfN6qsTLKkI2ff4VhVRahJMa9RlBHuiJa09Tlu/d1BqqjF8Vlf+1ygExN6dx PL95kbdwYM+0GILX+rt4okmVWgj4ol9JgBcQG6MA6rQvuoJHpfxv0I6yNXMMe3R86vfnz5XFHrX1 RfudaTWxM29kR44KxN19+TtVs2HTb/YAgGyyI3sxsX/keInYwKOZEpX3PwXn30CjjzPDjXR9+Zye K9iJUpsLFz8YJkPSc2e90JrrGAFuMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM YvQlQqbPmlmUoZynMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCXh4HBKJzGtQ42 WUKLHe6PxdWuPHbCBZ1M5uiSz37INTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzExMDExMTAyNTRaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAiil4JAr5DIsnBVIVEaz5jB0T1zYdTzhl 9iSQttoQ7wagrlAS31netDb/+3OT6ALcRC2PU83GEQLJZ/X8Rde4nYuRA26kN2lsMskjLkV9aNxW pzVCV6Rcpxzo3fX2LvWS74XUHps/qdIJnOwOnQWdCfbOmw7wYLz4nKdgALpcdTmgsnzuGnkvmswY 8wg/pdlnYRrIX4uOX/FkSGTG6qxkETuTYkj3FdrWgrTK5dx2SrrjUzJOcSIIQCInPhEbdvAKjdDS axm6z+qcI42z82FtfurYLi5EqQwu4A6W/9xUXYs6iFtp4n7lCg0VY3PygTeLmbOTiK6Cbvhdi4C8 nAREUQ== --f403043d0a083a1c8f055ce9d0b7-- From nobody Wed Nov 1 08:24:26 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE67F13FD61 for ; Wed, 1 Nov 2017 08:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.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 WtmKBOF0p5iG for ; Wed, 1 Nov 2017 08:24:22 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AEE113FCAD for ; Wed, 1 Nov 2017 08:24:22 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id r129so2940292lff.8 for ; Wed, 01 Nov 2017 08:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=HMkmJNWhEIZ2Y06ln8ygqKeKcGYZUn1OjL0MjDPfou8=; b=r1XNjHt74DaWNFiRYEkFuqvwCTUP8B8G0yhxh/7wnP9cEFY2h//wepCR6lbYq+gE0c p1Stl3bVGZ+5cCpJxY4JbOQvwkd2bMRN7IAN5dk22RRuzWfCPtteitGZMEcKWS2e0Ymh qBQLFVZfh554/yIocmPCJEw8kQorB6JwpRYzljrdbflvcMwSb/xKrkOS+rGRJoSE/b3y P8Pl97VZHG6x3umS843uRG3E1TtuPMDgK1C+v2MlsNL0HC11Rk69D6y4i1IIf0l8QCE0 tspH4ECxTsTtT/IzltlfEahB0NgmaoNUlsXxMhz/UxE/EkyUltJjXbbKvwUP5p89kMYC iGxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HMkmJNWhEIZ2Y06ln8ygqKeKcGYZUn1OjL0MjDPfou8=; b=lqEWTDNVMfXLunFZbWTFZwMcYozyiObtiC/spIo2/6E6fGWU3T9lXiXJhVqB8uHeuH jmlVZerrcIYh/bNjVZhehIgyEetiiiAzDjSKLlU2JJWFkZoVBSXipIXusaSYeExzQ9p/ uX9fl28EyQnWcKy4egzJYXmOpIpjm+gMTwPLfmAbPrzHMLQC+McGgiCVZxHIjSo/gN7a 6wvrt1ri/yWkMAxNx3/FAqDP09JhtEsiDOOqDBWyKXJgJYrQqRtg/7E8ovsUd+cHktP4 48NRh6wkCjP9aoGKV5UAJG2x9taVtIgECvsvubQ8QEwH9sL3lfixPoAro7nohzTdkj+W rJHw== X-Gm-Message-State: AJaThX6QLIaVXwlFURTLQLGmd1QIG8nf4RZhbk7rKKheJtqQBViQ4avm h6wb4KkyZA9ul4u6BA5TZd3SLt5qNos= X-Google-Smtp-Source: ABhQp+RO8Dc0ThsSOmbtaALgJAtU4x7lVpg76zzJmk0uYlkodbReo0T8hngZx3be/wNHLd/4O7q3Nw== X-Received: by 10.25.32.149 with SMTP id g143mr64457lfg.115.1509549860476; Wed, 01 Nov 2017 08:24:20 -0700 (PDT) Received: from [10.0.0.129] (h-155-4-129-189.NA.cust.bahnhof.se. [155.4.129.189]) by smtp.gmail.com with ESMTPSA id g29sm148066lfh.3.2017.11.01.08.24.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Nov 2017 08:24:16 -0700 (PDT) To: uta@ietf.org References: <285D4781-74B0-44EA-9776-5DE23D745DB3@dukhovni.org> <8673FAEC-CD26-4092-AFD5-5A681A167B6D@dukhovni.org> <60325D1E-EDC5-4FAF-91FD-5B40BD67FAB4@dukhovni.org> <52B55172-A2F6-4E42-9B12-D8C5C60A666F@bluepopcorn.net> <7DD01770-0DDE-4391-8A0F-406915A816B8@dukhovni.org> <9c096748-dd92-c227-64b2-e3600a68330b@bluepopcorn.net> <20171027163916.g57sdwg3us6dfzq4@blitiri.com.ar> From: Leif Johansson Message-ID: Date: Wed, 1 Nov 2017 16:24:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Uta] STS and SAN (vs Host) matching X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 15:24:25 -0000 On 2017-11-01 11:59, Daniel Margolis wrote: > The decision to use policy-to-SAN matching instead of policy-to-hostname > matching was discussed here > (https://www.ietf.org/mail-archive/web/uta/current/msg01938.html). I > think the WG was at the time largely in consensus (or we misread the > consensus). I thought we also discussed this at IETF95, but at this > point my memory is hazy.  > > To be clear, I think you are right that this affects a small number of > users. RFC 7672 also allows this "nexthop" matching, but I think it's OK > for STS to enforce a "must match the hostname" policy. On the flip side, > I believe SAN matching is also fairly easy to implement (~10 lines of > pseudocode in the Appendix--hopefully correct!--and Viktor says OpenSSL > already exposes such a function). > > My understanding is that while you and Jim would prefer hostname > matching and Viktor (and others?) would prefer SAN matching, nobody has > said that if their non-preferred option is chosen this is a blocker for > implementation. Am I right? > > If that's correct, process-wise, should we treat this as resolved > previously (in draft 03), or should we try to revisit the consensus and > close it out quickly? I have to agree. Given that few people are speaking up in explicit support for this change, existing consensus hold. Cheers Leif From nobody Wed Nov 1 10:26:44 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E4413FAF6 for ; Wed, 1 Nov 2017 10:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYVKZNQQnnHw for ; Wed, 1 Nov 2017 10:26:40 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D140F13F99C for ; Wed, 1 Nov 2017 10:26:40 -0700 (PDT) Received: from splunge.local (sfosf0017s350801.wiline.com [64.71.6.2] (may be forged)) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id vA1HQcpY032417 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 1 Nov 2017 10:26:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1509557200; bh=Y+U1O51jR/6YrHEOQox9g4oHPILJP8J09RnTy48xuvU=; h=Subject:To:References:From:Date:In-Reply-To; b=FIAFJ5+tzgoNzid5Bm8WbBB3mvmOpUsjwdKQxnvyM7MIl6R8v14pV/j/DFVlvF3jr cv48B7/61XsLmPAHiiYjBiMgstClGkQOpDABEc395SFPTqtFDpr84N1JYNWA1Nlu8L /UhrnbrJ5HXmGVINAtrfDVQhsRQsswKA/aFruNYM= To: uta@ietf.org References: <285D4781-74B0-44EA-9776-5DE23D745DB3@dukhovni.org> <8673FAEC-CD26-4092-AFD5-5A681A167B6D@dukhovni.org> <60325D1E-EDC5-4FAF-91FD-5B40BD67FAB4@dukhovni.org> <52B55172-A2F6-4E42-9B12-D8C5C60A666F@bluepopcorn.net> <7DD01770-0DDE-4391-8A0F-406915A816B8@dukhovni.org> <9c096748-dd92-c227-64b2-e3600a68330b@bluepopcorn.net> <20171027163916.g57sdwg3us6dfzq4@blitiri.com.ar> From: Jim Fenton Message-ID: <65a41c7c-611d-6e5c-762d-fcbd9dd2a0fb@bluepopcorn.net> Date: Wed, 1 Nov 2017 10:26:37 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [Uta] STS and SAN (vs Host) matching X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 17:26:43 -0000 On 11/1/17 3:59 AM, Daniel Margolis wrote: > The decision to use policy-to-SAN matching instead of > policy-to-hostname matching was discussed here > (https://www.ietf.org/mail-archive/web/uta/current/msg01938.html). I > think the WG was at the time largely in consensus (or we misread the > consensus). I thought we also discussed this at IETF95, but at this > point my memory is hazy.=C2=A0 > > To be clear, I think you are right that this affects a small number of > users. RFC 7672 also allows this "nexthop" matching, but I think it's > OK for STS to enforce a "must match the hostname" policy. On the flip > side, I believe SAN matching is also fairly easy to implement (~10 > lines of pseudocode in the Appendix--hopefully correct!--and Viktor > says OpenSSL already exposes such a function). > > My understanding is that while you and Jim would prefer hostname > matching and Viktor (and others?) would prefer SAN matching, nobody > has said that if their non-preferred option is chosen this is a > blocker for implementation. Am I right? It looks like this is conflating a couple of different things: (1) matching CN vs. SAN on the certificate, and (2) matching whatever on the certificate against hostname vs. STS policy. For (1) I favor doing whatever browsers do, which I thought was to match against either CN or any of the names listed in the SAN. (2) I favor matching the certificate against hostname rather than policy, because MTAs that already verify TLS certificates (even if it's only advisory info for log files and Received header fields) do it this way currently. Otherwise, certificates are matched against different things depending on whether there's an STS policy or not, and I don't see a reason to change current behavior. What's the advantage of matching against policy? If this is already decided, it's already decided, but I wanted to at least frame the issue correctly. -Jim From nobody Wed Nov 1 11:03: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 2349413871A for ; Wed, 1 Nov 2017 11:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BsfMLF17hqu for ; Wed, 1 Nov 2017 11:03:14 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1874713F9F1 for ; Wed, 1 Nov 2017 11:03:09 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id 189so7903888iow.10 for ; Wed, 01 Nov 2017 11:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Etvxdep1elKKYPdFuzzd8p8fnE9dRFgl4fzlq8/hN6U=; b=ZuWduObMjtPmwfgGx1gWMe2g0NvnL9AQGPze26U3EMSfceqxzLP/GztykjEtT3i7wN X3zBYiecrOQdY3DeoLjWqksXcrVJjlfmG3AsJaL8vl6nzpS2G++mN7k3fdJqXvOYCMEG 5grJdAg+Jf3S/Iv5Xvn6G3FP8IwnF6+mHzSOc7U+hJvsV2a5D+CgBtq9XGofyw3PQurp vHHdlJWvE4hmnDbv0osgP1k6CafKuXH5AtMQThSD2qv6vR2TnF9Y91JXJCJMgMSTIORo u2eKjaGWkMunQ1D6v/9QGHvNLKB6a4fu939xkVRnQfeuZv+3o+i6VMZ7lkjkR9zRHImy AbqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Etvxdep1elKKYPdFuzzd8p8fnE9dRFgl4fzlq8/hN6U=; b=BnDGK62O7nC7kj+9ojFtXJVAduq7IFvv+LSANC+F5BlwjRwCrgDxC6ad+otGGQaUm6 wfX+4wdcwkQVERQuVk/2GwEaiNdVqR9gXoJ6/QPjmqLf9UTRDaNsm6wEmMTaAyicv9BX sEhMEAPCAUfh2Cin8Tail58FEJ56QqIeMloEGatIkusnacbxywLdyTbyyiNg84C2fCif NKoq+m6pm2jgJwTQCNkLscbGJkqq29DMh8g1Gt4t/c/PHMEqc04jp6odmVwdvLpH8xuv A7LcO+5793LgcpbSy1/oizKSvQ9r4vlgo8QWtgo0KV4M1ctWstVLilLymOQ8n6MoFF+j BtKw== X-Gm-Message-State: AMCzsaX2Y+0zWeP2zCwjie+l8A4elcuQIcMmpHbf3vtWiqiP8D43hwli DYAcZsFmE9fgwNzqMdPFvASugnxUyI4+Vyo2AUPNMY6uA5o= X-Google-Smtp-Source: ABhQp+RxezHxaNEGpMe0gnH73PSY2TJetG2t+sCUBHFFjm5xA02GFf9m5lAxi1MRzOH3WgAgR9Ui50DCKRRSog9B3qc= X-Received: by 10.107.222.17 with SMTP id v17mr865221iog.283.1509559387854; Wed, 01 Nov 2017 11:03:07 -0700 (PDT) MIME-Version: 1.0 References: <285D4781-74B0-44EA-9776-5DE23D745DB3@dukhovni.org> <8673FAEC-CD26-4092-AFD5-5A681A167B6D@dukhovni.org> <60325D1E-EDC5-4FAF-91FD-5B40BD67FAB4@dukhovni.org> <52B55172-A2F6-4E42-9B12-D8C5C60A666F@bluepopcorn.net> <7DD01770-0DDE-4391-8A0F-406915A816B8@dukhovni.org> <9c096748-dd92-c227-64b2-e3600a68330b@bluepopcorn.net> <20171027163916.g57sdwg3us6dfzq4@blitiri.com.ar> <65a41c7c-611d-6e5c-762d-fcbd9dd2a0fb@bluepopcorn.net> In-Reply-To: <65a41c7c-611d-6e5c-762d-fcbd9dd2a0fb@bluepopcorn.net> From: Daniel Margolis Date: Wed, 01 Nov 2017 18:02:54 +0000 Message-ID: To: Jim Fenton Cc: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403043d0a08203dcf055cefafc4" Archived-At: Subject: Re: [Uta] STS and SAN (vs Host) matching X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 18:03:17 -0000 --f403043d0a08203dcf055cefafc4 Content-Type: multipart/alternative; boundary="f403043d0a08157771055cefaf2c" --f403043d0a08157771055cefaf2c Content-Type: text/plain; charset="UTF-8" Sorry, I was referring only to the second issue. I don't think the CN vs SAN matching is in contention, but you're right to clarify; thanks for that. The issue was discussed in more detail in the linked thread ( https://www.ietf.org/mail-archive/web/uta/current/msg01938.html). The main point made in favor of SAN matching, I think, is that there may be some (empirically rare, as Alberto pointed out) cases where people have existing certificates that match the nexthop domain and not the MX hostname; RFC7672 explicitly supports this, as I recall. There was also a concern (discussed previously) that hostname matching lends itself to modifying the MX traversal algorithm in potentially broken ways--this is avoidable, but it is a bit of an implementation gotcha. These are solvable issues, and valid options very much exist in the hostname matching direction, but I'm trying to distinguish between a compromise and a decision that would impede implementation or result in a seriously broken design going forward. I read this as the former and not the latter. To answer your point specifically about existing matching logic, *certificates *which already match the hostname will continue to work perfectly in this model, and in fact admins who are unaware that we match SANs and think we match hostnames will nonetheless always craft working policies. *MTAs* who match certificates against hostnames can, of course, continue to do so, but *in addition* will have to match certificates against policies. The policy and hostname checks may result in different outcomes, and an MTA who is implementing some other certificate validation will have to figure out what to do then, but this is beyond the scope of the spec here. Anyway, I am still not hearing strong objections, but I'm happy to hold out a bit longer. I hope to have a new draft with fixes for the other discussions on this list shortly. On Wed, Nov 1, 2017 at 6:26 PM Jim Fenton wrote: > On 11/1/17 3:59 AM, Daniel Margolis wrote: > > The decision to use policy-to-SAN matching instead of > > policy-to-hostname matching was discussed here > > (https://www.ietf.org/mail-archive/web/uta/current/msg01938.html). I > > think the WG was at the time largely in consensus (or we misread the > > consensus). I thought we also discussed this at IETF95, but at this > > point my memory is hazy. > > > > To be clear, I think you are right that this affects a small number of > > users. RFC 7672 also allows this "nexthop" matching, but I think it's > > OK for STS to enforce a "must match the hostname" policy. On the flip > > side, I believe SAN matching is also fairly easy to implement (~10 > > lines of pseudocode in the Appendix--hopefully correct!--and Viktor > > says OpenSSL already exposes such a function). > > > > My understanding is that while you and Jim would prefer hostname > > matching and Viktor (and others?) would prefer SAN matching, nobody > > has said that if their non-preferred option is chosen this is a > > blocker for implementation. Am I right? > It looks like this is conflating a couple of different things: (1) > matching CN vs. SAN on the certificate, and (2) matching whatever on the > certificate against hostname vs. STS policy. > > For (1) I favor doing whatever browsers do, which I thought was to match > against either CN or any of the names listed in the SAN. > > (2) I favor matching the certificate against hostname rather than > policy, because MTAs that already verify TLS certificates (even if it's > only advisory info for log files and Received header fields) do it this > way currently. Otherwise, certificates are matched against different > things depending on whether there's an STS policy or not, and I don't > see a reason to change current behavior. What's the advantage of > matching against policy? > > If this is already decided, it's already decided, but I wanted to at > least frame the issue correctly. > > -Jim > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --f403043d0a08157771055cefaf2c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, I was referring only to the second issue. I don'= ;t think the CN vs SAN matching is in contention, but you're right to c= larify; thanks for that.

The issue was discussed in more= detail in the linked thread (https://www.ietf.org/mail-archive/web/uta/cu= rrent/msg01938.html). The main point made in favor of SAN matching, I t= hink, is that there may be some (empirically rare, as Alberto pointed out) = cases where people have existing certificates that match the nexthop domain= and not the MX hostname; RFC7672 explicitly supports this, as I recall. Th= ere was also a concern (discussed previously) that hostname matching lends = itself to modifying the MX traversal algorithm in potentially broken ways--= this is avoidable, but it is a bit of an implementation gotcha.
<= br>
These are solvable issues, and valid options very much exist = in the hostname matching direction, but I'm trying to distinguish betwe= en a compromise and a decision that would impede implementation or result i= n a seriously broken design going forward. I read this as the former and no= t the latter.

To answer your point specifically ab= out existing matching logic, certificates which already match the ho= stname will continue to work perfectly in this model, and in fact admins wh= o are unaware that we match SANs and think we match hostnames will nonethel= ess always craft working policies. MTAs=C2=A0who match certificates = against hostnames can, of course, continue to do so, but in addition= =C2=A0will have to match certificates against policies. The policy and host= name checks may result in different outcomes, and an MTA who is implementin= g some other certificate validation will have to figure out what to do then= , but this is beyond the scope of the spec here. =C2=A0

Anyway, I am still not hearing strong objections, but I'm happy t= o hold out a bit longer. I hope to have a new draft with fixes for the othe= r discussions on this list shortly.=C2=A0


On Wed, Nov 1, 2017 at 6:26 PM Jim Fenton <= ;fenton@bluepopcorn.net> w= rote:
On 11/1/17 3:59 AM, Daniel Ma= rgolis wrote:
> The decision to use policy-to-SAN matching instead of
> policy-to-hostname matching was discussed here
> (https://www.ietf.org/mail-archi= ve/web/uta/current/msg01938.html). I
> think the WG was at the time largely in consensus (or we misread the > consensus). I thought we also discussed this at IETF95, but at this > point my memory is hazy.=C2=A0
>
> To be clear, I think you are right that this affects a small number of=
> users. RFC 7672 also allows this "nexthop" matching, but I t= hink it's
> OK for STS to enforce a "must match the hostname" policy. On= the flip
> side, I believe SAN matching is also fairly easy to implement (~10
> lines of pseudocode in the Appendix--hopefully correct!--and Viktor > says OpenSSL already exposes such a function).
>
> My understanding is that while you and Jim would prefer hostname
> matching and Viktor (and others?) would prefer SAN matching, nobody > has said that if their non-preferred option is chosen this is a
> blocker for implementation. Am I right?
It looks like this is conflating a couple of different things: (1)
matching CN vs. SAN on the certificate, and (2) matching whatever on the certificate against hostname vs. STS policy.

For (1) I favor doing whatever browsers do, which I thought was to match against either CN or any of the names listed in the SAN.

(2) I favor matching the certificate against hostname rather than
policy, because MTAs that already verify TLS certificates (even if it's=
only advisory info for log files and Received header fields) do it this
way currently. Otherwise, certificates are matched against different
things depending on whether there's an STS policy or not, and I don'= ;t
see a reason to change current behavior. What's the advantage of
matching against policy?

If this is already decided, it's already decided, but I wanted to at least frame the issue correctly.

-Jim


_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
--f403043d0a08157771055cefaf2c-- --f403043d0a08203dcf055cefafc4 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMYvQlQqbPmlmUoZynMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODE4NDIxNloXDTE4MDMx NzE4NDIxNlowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDI3sfyM5pHCY0cDNbbiDAn17uPa3PG0G98FftCEkej/WTh RcWVnnX7STqcEnQwK7z8r8SckwfHWqDMNnb6PMXVZUOCv9iewPrxXlQfmFvDQQnRXbUKp7WgUjzm 5v1BIs/mIvqkrBsiPJLvNbO8b7BxewUnTP24wHaCYvlVFXd/A+hbq5CJciR230oH0bmB6zMlpxQe 45PlPkEkLb2cUaad14IV2ulfK8pcsLLM+NntC9jxKVAp3GCSAp6gjOmCJdCB4YlyC943ej9IoryJ fOVpmm6IOchzDTJH/rgPUWbQnZFhVw4V1EkHfrYugci2Up30l4SsMieOPgfd6oAwDzlbAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFFQQtjTE3yoZgnE8infGLj+S7TiRMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQBpExGZx6F4 zM7Y/n7mnIsXl81PZas0VWUjE0MMdlX+FBxLg6+tSAZL+pi0i/iRb9bNg3KLqo0mpN2cnHa0Cyeo 9+DUJYdHtitY7O0oDfN6qsTLKkI2ff4VhVRahJMa9RlBHuiJa09Tlu/d1BqqjF8Vlf+1ygExN6dx PL95kbdwYM+0GILX+rt4okmVWgj4ol9JgBcQG6MA6rQvuoJHpfxv0I6yNXMMe3R86vfnz5XFHrX1 RfudaTWxM29kR44KxN19+TtVs2HTb/YAgGyyI3sxsX/keInYwKOZEpX3PwXn30CjjzPDjXR9+Zye K9iJUpsLFz8YJkPSc2e90JrrGAFuMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM YvQlQqbPmlmUoZynMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCD6evzmP34wzVnj MSHYpXLLKAtqmYVUhrM38waxo4fH0jAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzExMDExODAzMDhaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAaACHP9beXxhyBBpHmGwTIQjxkCC5ah1v L+5rXx2zVkuDE+pG5hm9bkNDyUUpwzPi+my9RFiwrJf+2QaGBXdQsRN3mzLCSjpi0rbaQi/cNNnW tFb4IklI/YFfRDnznJPjLsu82CkXHGQAMhssR/DOrTQXWqbzHAvRzHnQmjU4rC/jwSdIlwSy2CZB 796rtZMGSCifIBkApwqVkXOpSMcIZbwzXJlQV8LfdekxcvhBLaJrmu+6DNLbtFyimBj1s3AbpqGR csiXqnlHXtS18gfJL4H43iS92yKFVa7ZL5u8DsBel4O26YO3ub2D2CdEggn87oFBv5t57L0GP1xA Y7cJ0g== --f403043d0a08203dcf055cefafc4-- From nobody Thu Nov 9 16:23:54 2017 Return-Path: X-Original-To: uta@ietf.org Delivered-To: uta@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6278127076; Thu, 9 Nov 2017 16:23:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: uta@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151027342677.29878.2191117424702761135@ietfa.amsl.com> Date: Thu, 09 Nov 2017 16:23:46 -0800 Archived-At: Subject: [Uta] I-D Action: draft-ietf-uta-mta-sts-11.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 00:23:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Using TLS in Applications WG of the IETF. Title : SMTP MTA Strict Transport Security (MTA-STS) Authors : Daniel Margolis Mark Risher Binu Ramakrishnan Alexander Brotman Janet Jones Filename : draft-ietf-uta-mta-sts-11.txt Pages : 25 Date : 2017-11-09 Abstract: SMTP Mail Transfer Agent Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections, and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-uta-mta-sts-11 https://datatracker.ietf.org/doc/html/draft-ietf-uta-mta-sts-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-mta-sts-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 9 16:25:13 2017 Return-Path: X-Original-To: uta@ietf.org Delivered-To: uta@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69372129443; Thu, 9 Nov 2017 16:25:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: uta@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151027350939.29919.2499405505967096686@ietfa.amsl.com> Date: Thu, 09 Nov 2017 16:25:09 -0800 Archived-At: Subject: [Uta] I-D Action: draft-ietf-uta-smtp-tlsrpt-11.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 00:25:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Using TLS in Applications WG of the IETF. Title : SMTP TLS Reporting Authors : Daniel Margolis Alexander Brotman Binu Ramakrishnan Janet Jones Mark Risher Filename : draft-ietf-uta-smtp-tlsrpt-11.txt Pages : 26 Date : 2017-11-09 Abstract: A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents, including STARTTLS, DANE TLSA, and MTA-STS. These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains. Recipient domains can then use this information to both detect potential attackers and diagnose unintentional misconfigurations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-tlsrpt/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-uta-smtp-tlsrpt-11 https://datatracker.ietf.org/doc/html/draft-ietf-uta-smtp-tlsrpt-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-smtp-tlsrpt-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Nov 10 05:48:02 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFAD120727 for ; Fri, 10 Nov 2017 05:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvpmu6ibAO8G for ; Fri, 10 Nov 2017 05:48:00 -0800 (PST) Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) (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 324501242F7 for ; Fri, 10 Nov 2017 05:48:00 -0800 (PST) X-AuditID: 60729ed4-f0a6d70000008fd7-70-5a05ae0fb248 Received: from COPDCEX20.cable.comcast.com (Unknown_Domain [96.114.156.147]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 14.3F.36823.F0EA50A5; Fri, 10 Nov 2017 06:47:59 -0700 (MST) Received: from COPDCEX19.cable.comcast.com (147.191.124.150) by COPDCEX20.cable.comcast.com (147.191.124.151) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 10 Nov 2017 06:47:58 -0700 Received: from COPDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8380]) by COPDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8380%19]) with mapi id 15.00.1347.000; Fri, 10 Nov 2017 06:47:58 -0700 From: "Brotman, Alexander" To: "uta@ietf.org" Thread-Topic: Updated MTA-STS & TLSRPT Thread-Index: AdNaKfLOtIXyQ7daQ6Kz5JfrZPwi6A== Date: Fri, 10 Nov 2017 13:47:58 +0000 Message-ID: <249cbf338d534a52af511fcacb790e95@COPDCEX19.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [96.115.73.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsWSUDRnsi7/OtYog2+HNS1OHW1mdGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxr51N1kKprJUTJ3wnK2BcRlzFyMnh4SAicTvb09Yuxi5OIQE VjBJ/J95Dco5xCgxY9sqZgjnJKPE7+8vWUFa2ASsJN7+bwdrFxFQlHjx5z17FyMHhzCQffBd LURYTeLA7tfsELaexPa/hxlBbBYBVYmntx6B2bwCXhI92/eAjWQUEJP4fmoNE4jNLCAucevJ fCaI6wQkluw5D3WpqMTLx/9YIWwDia1L97FA2IoS+z6sYIbo1ZFYsPsTG4StLbFs4WtmiF2C EidnPoGqF5c4fGQH6wRG0VlI1s1C0j4LSfssJO0LGFlWMfJZmukZGproGZpa6BkZGm1iBMfB vCs7GC9P9zjEKMDBqMTDa9PMGiXEmlhWXJkLDEYOZiUR3sB5QCHelMTKqtSi/Pii0pzU4kOM 0hwsSuK83/KZo4QE0hNLUrNTUwtSi2CyTBycUg2MylMuSfLM1TI48eTg16jKG+f2Lk8vO378 4IyqeUuau2exqH49IJX0b8bNS0HqTwMjd9tkHe5kFsiec9pu6sYX51dui5VOyz6k23mriXmj U4nEfdX8FIu01O1RNhMXLZu8znrKvbkP2A/fuBMbLOs5YVsR0wVHziStQ7s1TW8suR09rT58 Q/k3FyWW4oxEQy3mouJEAMbRNkR/AgAA Archived-At: Subject: [Uta] Updated MTA-STS & TLSRPT X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 13:48:01 -0000 Hello folks, These two drafts were uploaded last night, and we'd like any feedback. For= the MTA-STS, there are changes relating to SNI, minimum TLS version, and r= everse proxy language. There are also some minor nits that were resolved. = For TLSRPT, we added some language about DoS attacks, omitting report TLS = failures from reporting, and allow reporting on more than one policy type p= er report. We look forward to hearing from the group. Thank you. -- Alex Brotman Sr. Engineer, Anti-Abuse Comcast From nobody Sun Nov 12 03:02: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 431571293D6 for ; Sun, 12 Nov 2017 03:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 1kPmBI2mwZ77 for ; Sun, 12 Nov 2017 03:02:17 -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 23DD0128D44 for ; Sun, 12 Nov 2017 03:02:17 -0800 (PST) Received: from splunge.local ([202.55.67.146]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id vACB1d82022651 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 12 Nov 2017 03:02:16 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1510484536; bh=GPa3mH23X8DKBi6WMu0w7PFZ0bf3vK104KcP16Qd0+8=; h=From:Subject:To:Date; b=MQaqLOkrMZl4hO6/P1ck5ye1V4Od0sB2JKL8rcrw4cSNn/5/S9nZa6Qj4620XznCj oTCmP/4jnBYsFmdaH9t3Tt/LQNywZp75JkQ1xXTsSpBK+9vzcoIVh3UiANuU8Z5DPk b+zYNWI9nVBqeKCJaVva/Z+q+G6D0CbyIt4DX0AI= From: Jim Fenton To: "uta@ietf.org" Message-ID: <0a1c7674-865a-a85e-f432-3aa99663eb4c@bluepopcorn.net> Date: Sun, 12 Nov 2017 03:01:37 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: [Uta] Comments on mta-sts-11 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 11:02:18 -0000 Hi, On the flight to Singapore, I went through the latest mta-sts draft, and have a number of comments. Some of these I have probably made before, but (at the risk of belaboring old items) I think they warrant revisiting= =2E My overarching concern is whether MTA-STS would be effective against an attacker that is able to mount a downgrade or man-in-the-middle attack on STARTTLS. An attacker that is positioned between mail servers to be able to block the negotiation of STARTTLS probably is also positioned to be able to block the _mta-sts TXT record response, making it look like there's no policy. - In the introduction, it lists as one of the goals countering attacks by those who can overwrite the resolved MX record of the delivery domain. This is a good goal, and largely addressed by verifying certificates, but if DNS attacks are on the table, we need to talk more about attackers who can block the mta-sts TXT record (see below). - 2. Related technologies: I wouldn't describe as "upgrading plaintext transmission" -- if STARTTLS couldn't be negotiated, it still won't. Suggest upgrade -> inhibit - Section 2 paragraph 2 makes it sound like DANE does reporting, and it doesn't. This should refer instead to relevant stuff in tlsrpt. - Section 3.2 "mode" key/value pair: What does "report" do now that tlsrpt is separate? It seems like the modes now ought to be "enforce" and "none". - max_age: Does expiration of max_age trigger a refresh or does it simply age out of the cache? I had thought that TXT record suppresion attacks were mitigated by only requiring the TXT record initially, but this makes it sound like it ages out and has to be rediscovered the next time a message is sent to the domain. The paragraph also encourages use of very long max_age values to mitigate attacks at policy refresh time; what sorts of attacks are anticipated? Just to be clear, I do not consider use of long cache times to be an effective security measure. - Section 3.3: Does certificate expiration constrain the max_age of a cached policy? (if the certificate expires very soon) - Section 3.4: #Policy Validation section header looks like an unconverted section header from Markdown. - Section #Policy Validation: "does not dictate the behavior of sending MTAs when policies fail to validate" but following the semicolon it says that "report" or "none" MUST NOT be interpreted as delivery failures, which seems like exactly that. Suggest removing "in particular" and everything before it in the sentence. - Section 3.5 paragraph 3: Mangled reference to RFC 6125. - Section 4 "enforce" prohibits delivering when things fail mta-sts, but Section 2 says, "MTA-STS is designed not to interfere with DANE deployments where the two overlap". Doesn't this requirement constitute that sort of interference? - Section 4 "report": delete? (because this is in tlsrpt) - Section 6.1: Why is SNI always required? Can't a small MTA that only ever serves one domain get by without it? - Section 7.1 leads me to question the benefit of having a policy ID in the TXT record as opposed to just a hint whether might be a MTA-STS policy. Apparently the only time the a sender i. required to check the TXT record is when they don't have a policy (first message or it has expired). Of course senders could check TXT more often but I don't see any guidance for that. With the record being checked on max_age expiration (assuming it doesn't just age out, see question above) and max_age being expressed in weeks, the number of HTTPS transactions saved is going to be small. Balance that against the added operational complexity of having to update both DNS and the policy server when the policy changes. - Section 7.2 paragraph 3: Suggest "a host" -> "an address" - Section 7.3 item 2: This could also be simpler if there is no policy ID; in any case it's not clear what triggers retrieval of the TXT record if the sender already thinks it knows a policy for recipient domain. - Section 9.2 paragraph 1 refers to a "victim sending domain" and 9.3 paragraph 2 refers to a "victim domain" that is apparently the domain setting up an MTA-STS policy. This terminology needs to be more consistent. Perhaps avoid use the word "victim" at all (although it would be good to better understand who benefits from publishing MTA-STS).= - Sections 11 and 12 should be real appendices; xml2rfc can do this. Should also be marked informative in case there is an inconsistency with the spec. -Jim From nobody Sun Nov 12 10:48:34 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72069124C27 for ; Sun, 12 Nov 2017 10:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzKsuNmXzEal for ; Sun, 12 Nov 2017 10:48:31 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E530612008A for ; Sun, 12 Nov 2017 10:48:30 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id AB15C7A3309 for ; Sun, 12 Nov 2017 18:48:29 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Viktor Dukhovni In-Reply-To: <0a1c7674-865a-a85e-f432-3aa99663eb4c@bluepopcorn.net> Date: Sun, 12 Nov 2017 13:48:28 -0500 Content-Transfer-Encoding: 7bit Reply-To: uta@ietf.org Message-Id: References: <0a1c7674-865a-a85e-f432-3aa99663eb4c@bluepopcorn.net> To: uta@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [Uta] Comments on mta-sts-11 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 18:48:33 -0000 > On Nov 12, 2017, at 6:01 AM, Jim Fenton wrote: > > An attacker that is positioned between mail servers to be > able to block the negotiation of STARTTLS probably is also positioned to > be able to block the _mta-sts TXT record response, making it look like > there's no policy. This is an unavoidable feature of STS. It is vulnerable to "cold start" downgrade attacks, that is to downgrades when the sending system has no cached policy. > - Section 3.2 "mode" key/value pair: What does "report" do now that > tlsrpt is separate? It seems like the modes now ought to be "enforce" > and "none". It does exactly what it says, delivery proceeds despite lack of STARTTLS or authentication failure, but such failures to establish a secure channel for delivery are reported. There are no such reports to domains with no policy. Perhaps the receiving domain is unsure how interoperable its TLS stack or certificate chain would be if enforced. Though to be honest I am not convinced that support for reporting will be universal, I expect that some systems will treat "report" and "none" as synonymous (by never sending reports). > - max_age: Does expiration of max_age trigger a refresh or does it > simply age out of the cache? A sensible implementation of STS will make (multiple if necessary) refresh attempts long *before* the cached policy expires, provided there is sufficient ongoing traffic to the destination domain. Such refresh would happen after a delivery of a message after 1/2 max_age, 3/4 max_age, ... ultimately down to (say) ~5 minutes before expiration. So with a 180 day max_age, and steady message flow to a domain with a poorly available HTTPS service, the refreshes would happen (rounded): * shortly after 90 days, but failing that * shortly after 135 days, but failing that * shortly after 157 days, but failing that * shortly after 168 days, but failing that * shortly after 173 days, but failing that * shortly after 177 days, but failing that * shortly after 178 days, but failing that * shortly after 179 days, but failing that * shortly after 12 hours to go, but failing that * shortly after 6 hours to go, but failing that * shortly after 3 hours to go, but failing that * shortly after 90 minutes to go, but failing that * shortly after 45 minutes to to, but failing that * shortly after 22 minutes to go, but failing that * shortly after 11 minutes to go, but failing that * shortly after 5 minutes to go, but failing that ... policy expires ... * periodic lookup after each message delivery, but not more often than once every (say) 5 minutes. The details of the refresh policy, and frequency of probes for domains with no cached policy would be implementation dependent. I think that based in part on my feedback the text in Section 9.2 says (somewhat less prescriptively): https://tools.ietf.org/html/draft-ietf-uta-mta-sts-11#section-9.2 9.2. Preventing Policy Discovery ... Because this attack is also possible upon refresh of a cached policy, we suggest implementers do not wait until a cached policy has expired before checking for an update; if senders attempt to refresh the cache regularly (for instance, by checking their cached version string against the TXT record on each successful send, or in a background task that runs daily or weekly), an attacker would have to foil policy discovery consistently over the lifetime of a cached policy to prevent a successful refresh. > I had thought that TXT record suppresion > attacks were mitigated by only requiring the TXT record initially, but > this makes it sound like it ages out and has to be rediscovered the next > time a message is sent to the domain. See above, refresh should happen long before expiration. An ongoing MiTM attack can defeat this, but the attack has to be ongoing for the lifetime of the policy. It may be easier to get a forged certificate from some DV CA (via MiTM of the traffic between the CA and the target domain). > Just to be clear, I do not consider use of long cache times to be an > effective security measure. If that's the case, then STS is not for you. DANE has stronger downgrade resistance, please join the existing > 173000 domains that have DNSSEC and DANE-enabled MX hosts. I'd especially like to see some US-based hosting providers emulate domeneshop.no, transip.nl, udmedia.de and bhosted.nl by enabling DANE on the SMTP servers used for their hosted domains. If anyone reading this knows the right people at Godaddy, Dreamhost, ... please let them know I'm available to answer any questions they may have and suggest key rotation strategies. > - Section 3.3: Does certificate expiration constrain the max_age of a > cached policy? (if the certificate expires very soon) No. Neither the mta-sts HTTPS server certificate, nor even more so the expirations of MX host certificates affect the policy expiration time. > - Section 4 "enforce" prohibits delivering when things fail mta-sts, but > Section 2 says, "MTA-STS is designed not to interfere with DANE > deployments where the two overlap". Doesn't this requirement constitute > that sort of interference? I would read that as "STS is entirely out of scope when DANE policy is in effect". Of course sending machines get to decide whether DANE policy is in effect or not, by choosing to enable DANE or STS in the first place, and potentially choose one or the other explicitly for some domains. Thus, for example, while DANE policy is generally driven by the remote domain's publishing of TLSA records, a sending Postfix MTA can be configured to *require* DANE for some set of destinations, in which case delivery will only happen when the destinations publish ("secure" DNSSEC) DANE TLSA records, and not otherwise. Similarly, a sending system might *require* STS for some set of destinations, and refuse to send in the absence of a cached policy. So, the way I would read and implement this would be to prefer DANE over STS barring local policy that prefers one over the other for some destinations or perhaps suppressed both. > - Section 4 "report": delete? (because this is in tlsrpt) Sorry, the "report" mode is not superseded by "tlsrpt", which does not provide any downgrade protected signalling. > - Section 6.1: Why is SNI always required? Can't a small MTA that only > ever serves one domain get by without it? SNI is required from the *sending* MTA and HTTPS policy lookup client. It is not (should not be) required at receiving systems, except when they in fact have multiple certificate chains and need to use the SNI signal from the client to choose the right one. Even then, at the MX host it is required that when the client's SNI does not match any name known to the server, it should continue and send its default chain. The HTTPS server can do whatever it is that HTTPS servers do with SNI, it is not for this specification to redefine HTTPS. > - Section 7.1 leads me to question the benefit of having a policy ID in > the TXT record as opposed to just a hint whether might be a MTA-STS > policy. This was subject to considerable earlier discussion, and is in fact needed. > Apparently the only time the a sender i. required to check the > TXT record is when they don't have a policy (first message or it has > expired). There's your confusion. This is not the case. > Of course senders could check TXT more often but I don't see > any guidance for that. Section 9.2. -- Viktor. From nobody Sun Nov 12 21:28: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 652021287A7 for ; Sun, 12 Nov 2017 21:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHXnvb7ZQpUX for ; Sun, 12 Nov 2017 21:27:57 -0800 (PST) Received: from mail-ua0-x242.google.com (mail-ua0-x242.google.com [IPv6:2607:f8b0:400c:c08::242]) (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 D5A9E127337 for ; Sun, 12 Nov 2017 21:27:56 -0800 (PST) Received: by mail-ua0-x242.google.com with SMTP id j14so10576892uag.11 for ; Sun, 12 Nov 2017 21:27:56 -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=PznSO/3heFRPtNOLMqBQV/fy8mMqC+8N/5BGrMcjecA=; b=hX0n4vWCH106SjID/tyV5/NAxqLAkBvJOuEcjf6+SMSgdsI4itxpAoOw/tV1I3T9+o T+A6tHEwfGFGcMPHKXujQuWJh0XhT9EMGxwcfa0v31cAE9etEkJfCKgk5u2gj5ihO1t+ kpcYyjHJcc2Pf5nm2UEh+DD1C+ZPxPE28v7Tf6ssE3YXpo+lyh5XaivfZLFFADOaBjy0 sq0vAtMjRwYXZPzfPn6TZtdRBNKNg7zboyiDGmhFVUmh+Ho2n3LKvgqmbN0I8BGQJv0p izinG4xsF74hD44ZIfAqYFFywtFlLUK9k0jsz2spGeGK0sCs24bthplTWwkXTfHQq8CA NVOA== 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=PznSO/3heFRPtNOLMqBQV/fy8mMqC+8N/5BGrMcjecA=; b=t2pR99Z0farU5wZSg/XaqDfsBJIzMBWCnHEnS/M3a/GBn5svRAb3Fu4u14tj1Yhv9S iAw1fp06TZ3U0zm58j0faI4m4UEmT0DUxZylMVnyPgAqemgvQzLq0Gf9wO8vmBr8NJwI A4Eyn+3LgLucLMkXTI5W3NoIQqS/+SJWVC0frmBxnkezgLLC/ezaUPeYlfZnlEUIAgwu YV0geN3GtkKBOTcf8tIi1szxw2nicZR0Qw8lRktn20P69lgamdIXs7cJ7gztbifEiN13 unQW/VPXN9wQhQMncUQMP1WFZNiHav3LT1m6SwxU+C1hH9cxgR3O0MxyRIUIJQ93Vuhv t6ZA== X-Gm-Message-State: AJaThX7PfigH4BHHHHhxHexhZC/7bavRiLT0OUPmzb6DVPd9fRUFL0Sg tXzw679xG72ashjCxsUNtkPjEzWFbTbWtfbB9GqfSc2tO3Y= X-Google-Smtp-Source: AGs4zMZvyNTRsmlcdtqsmi4BJBraIXCZkj8Jmyem4PN6jC113EliI41nTXOoqj/ccTofJsZVXrjBvl9D/naS8DJzc0Y= X-Received: by 10.176.74.15 with SMTP id q15mr6640247uae.120.1510550874365; Sun, 12 Nov 2017 21:27:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.136.84 with HTTP; Sun, 12 Nov 2017 21:27:21 -0800 (PST) In-Reply-To: References: <0a1c7674-865a-a85e-f432-3aa99663eb4c@bluepopcorn.net> From: Nicolas Lidzborski Date: Mon, 13 Nov 2017 13:27:21 +0800 Message-ID: To: uta@ietf.org Content-Type: multipart/alternative; boundary="f403045f6d2c489f75055dd688d8" Archived-At: Subject: Re: [Uta] Comments on mta-sts-11 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 05:28:00 -0000 --f403045f6d2c489f75055dd688d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Mon, Nov 13, 2017 at 2:48 AM, Viktor Dukhovni wrote: > > > > On Nov 12, 2017, at 6:01 AM, Jim Fenton wrote: > > > > An attacker that is positioned between mail servers to be > > able to block the negotiation of STARTTLS probably is also positioned to > > be able to block the _mta-sts TXT record response, making it look like > > there's no policy. > > This is an unavoidable feature of STS. It is vulnerable to "cold start" > downgrade attacks, that is to downgrades when the sending system has > no cached policy. > > > - Section 3.2 "mode" key/value pair: What does "report" do now that > > tlsrpt is separate? It seems like the modes now ought to be "enforce" > > and "none". > > It does exactly what it says, delivery proceeds despite lack of STARTTLS > or authentication failure, but such failures to establish a secure channel > for delivery are reported. There are no such reports to domains with no > policy. Perhaps the receiving domain is unsure how interoperable its > TLS stack or certificate chain would be if enforced. Though to be honest > I am not convinced that support for reporting will be universal, I expect > that some systems will treat "report" and "none" as synonymous (by never > sending reports). Would it make sense to call it "dry-run" or "testing" instead to prevent confusion and as reporting is now managed in separate TLSRPT? > > - max_age: Does expiration of max_age trigger a refresh or does it > > simply age out of the cache? > > A sensible implementation of STS will make (multiple if necessary) > refresh attempts long *before* the cached policy expires, provided > there is sufficient ongoing traffic to the destination domain. > > Such refresh would happen after a delivery of a message after 1/2 > max_age, 3/4 max_age, ... ultimately down to (say) ~5 minutes before > expiration. So with a 180 day max_age, and steady message flow to > a domain with a poorly available HTTPS service, the refreshes would > happen (rounded): > > * shortly after 90 days, but failing that > * shortly after 135 days, but failing that > * shortly after 157 days, but failing that > * shortly after 168 days, but failing that > * shortly after 173 days, but failing that > * shortly after 177 days, but failing that > * shortly after 178 days, but failing that > * shortly after 179 days, but failing that > * shortly after 12 hours to go, but failing that > * shortly after 6 hours to go, but failing that > * shortly after 3 hours to go, but failing that > * shortly after 90 minutes to go, but failing that > * shortly after 45 minutes to to, but failing that > * shortly after 22 minutes to go, but failing that > * shortly after 11 minutes to go, but failing that > * shortly after 5 minutes to go, but failing that > ... policy expires ... > * periodic lookup after each message delivery, but > not more often than once every (say) 5 minutes. > > The details of the refresh policy, and frequency of probes > for domains with no cached policy would be implementation > dependent. I think that based in part on my feedback the > text in Section 9.2 says (somewhat less prescriptively): > > https://tools.ietf.org/html/draft-ietf-uta-mta-sts-11#section-9.2 > > 9.2. Preventing Policy Discovery > ... > > Because this attack is also possible upon refresh of a cached policy, > we suggest implementers do not wait until a cached policy has expired > before checking for an update; if senders attempt to refresh the > cache regularly (for instance, by checking their cached version > string against the TXT record on each successful send, or in a > background task that runs daily or weekly), an attacker would have to > foil policy discovery consistently over the lifetime of a cached > policy to prevent a successful refresh. > > > I had thought that TXT record suppresion > > attacks were mitigated by only requiring the TXT record initially, but > > this makes it sound like it ages out and has to be rediscovered the next > > time a message is sent to the domain. > > See above, refresh should happen long before expiration. An ongoing > MiTM attack can defeat this, but the attack has to be ongoing for the > lifetime of the policy. It may be easier to get a forged certificate > from some DV CA (via MiTM of the traffic between the CA and the target > domain). > > > Just to be clear, I do not consider use of long cache times to be an > > effective security measure. > > If that's the case, then STS is not for you. DANE has stronger > downgrade resistance, please join the existing > 173000 domains > that have DNSSEC and DANE-enabled MX hosts. I'd especially like > to see some US-based hosting providers emulate domeneshop.no, > transip.nl, udmedia.de and bhosted.nl by enabling DANE on the > SMTP servers used for their hosted domains. If anyone reading > this knows the right people at Godaddy, Dreamhost, ... please > let them know I'm available to answer any questions they may > have and suggest key rotation strategies. > > > - Section 3.3: Does certificate expiration constrain the max_age of a > > cached policy? (if the certificate expires very soon) > > No. Neither the mta-sts HTTPS server certificate, nor even more so > the expirations of MX host certificates affect the policy expiration > time. > > > - Section 4 "enforce" prohibits delivering when things fail mta-sts, but > > Section 2 says, "MTA-STS is designed not to interfere with DANE > > deployments where the two overlap". Doesn't this requirement constitute > > that sort of interference? > > I would read that as "STS is entirely out of scope when DANE policy > is in effect". Of course sending machines get to decide whether > DANE policy is in effect or not, by choosing to enable DANE or STS > in the first place, and potentially choose one or the other explicitly > for some domains. > > Thus, for example, while DANE policy is generally driven by the > remote domain's publishing of TLSA records, a sending Postfix > MTA can be configured to *require* DANE for some set of destinations, > in which case delivery will only happen when the destinations publish > ("secure" DNSSEC) DANE TLSA records, and not otherwise. > > Similarly, a sending system might *require* STS for some set of > destinations, and refuse to send in the absence of a cached policy. > > So, the way I would read and implement this would be to prefer > DANE over STS barring local policy that prefers one over the > other for some destinations or perhaps suppressed both. > > > - Section 4 "report": delete? (because this is in tlsrpt) > > Sorry, the "report" mode is not superseded by "tlsrpt", which > does not provide any downgrade protected signalling. I think renaming "report" as suggested above will remove possible confusion. > > > - Section 6.1: Why is SNI always required? Can't a small MTA that only > > ever serves one domain get by without it? > > SNI is required from the *sending* MTA and HTTPS policy lookup client. > It is not (should not be) required at receiving systems, except when they > in fact have multiple certificate chains and need to use the SNI signal > from the client to choose the right one. Even then, at the MX host > it is required that when the client's SNI does not match any name > known to the server, it should continue and send its default chain. > The HTTPS server can do whatever it is that HTTPS servers do with > SNI, it is not for this specification to redefine HTTPS. > > > - Section 7.1 leads me to question the benefit of having a policy ID in > > the TXT record as opposed to just a hint whether might be a MTA-STS > > policy. > > This was subject to considerable earlier discussion, and is in fact > needed. It here to enable checking the currency of a cached policy without fetching the policy again. > > > Apparently the only time the a sender i. required to check the > > TXT record is when they don't have a policy (first message or it has > > expired). > > There's your confusion. This is not the case. > > > Of course senders could check TXT more often but I don't see > > any guidance for that. > > Section 9.2. > --f403045f6d2c489f75055dd688d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit


On Mon, Nov 13, 2017 at 2:48 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:


> On Nov 12, 2017, at 6:01 AM, Jim Fenton <fenton@bluepopcorn.net> wrote:
>
> An attacker that is positioned between mail servers to be
> able to block the negotiation of STARTTLS probably is also positioned to
> be able to block the _mta-sts TXT record response, making it look like
> there's no policy.

This is an unavoidable feature of STS.  It is vulnerable to "cold start"
downgrade attacks, that is to downgrades when the sending system has
no cached policy.

> - Section 3.2 "mode" key/value pair: What does "report" do now that
> tlsrpt is separate? It seems like the modes now ought to be "enforce"
> and "none".

It does exactly what it says, delivery proceeds despite lack of STARTTLS
or authentication failure, but such failures to establish a secure channel
for delivery are reported.  There are no such reports to domains with no
policy.  Perhaps the receiving domain is unsure how interoperable its
TLS stack or certificate chain would be if enforced.  Though to be honest
I am not convinced that support for reporting will be universal, I expect
that some systems will treat "report" and "none" as synonymous (by never
sending reports).
Would it make sense to call it "dry-run" or "testing" instead to prevent confusion and as reporting is now managed in separate TLSRPT?
 
> - max_age: Does expiration of max_age trigger a refresh or does it
> simply age out of the cache?

A sensible implementation of STS will make (multiple if necessary)
refresh attempts long *before* the cached policy expires, provided
there is sufficient ongoing traffic to the destination domain.

Such refresh would happen after a delivery of a message after 1/2
max_age, 3/4 max_age, ... ultimately down to (say) ~5 minutes before
expiration.  So with a 180 day max_age, and steady message flow to
a domain with a poorly available HTTPS service, the refreshes would
happen (rounded):

        * shortly after 90 days, but failing that
        * shortly after 135 days, but failing that
        * shortly after 157 days, but failing that
        * shortly after 168 days, but failing that
        * shortly after 173 days, but failing that
        * shortly after 177 days, but failing that
        * shortly after 178 days, but failing that
        * shortly after 179 days, but failing that
        * shortly after 12 hours to go, but failing that
        * shortly after 6 hours to go, but failing that
        * shortly after 3 hours to go, but failing that
        * shortly after 90 minutes to go, but failing that
        * shortly after 45 minutes to to, but failing that
        * shortly after 22 minutes to go, but failing that
        * shortly after 11 minutes to go, but failing that
        * shortly after 5 minutes to go, but failing that
        ... policy expires ...
        * periodic lookup after each message delivery, but
          not more often than once every (say) 5 minutes.

The details of the refresh policy, and frequency of probes
for domains with no cached policy would be implementation
dependent.  I think that based in part on my feedback the
text in Section 9.2 says (somewhat less prescriptively):

  https://tools.ietf.org/html/draft-ietf-uta-mta-sts-11#section-9.2

  9.2.  Preventing Policy Discovery
   ...

   Because this attack is also possible upon refresh of a cached policy,
   we suggest implementers do not wait until a cached policy has expired
   before checking for an update; if senders attempt to refresh the
   cache regularly (for instance, by checking their cached version
   string against the TXT record on each successful send, or in a
   background task that runs daily or weekly), an attacker would have to
   foil policy discovery consistently over the lifetime of a cached
   policy to prevent a successful refresh.

> I had thought that TXT record suppresion
> attacks were mitigated by only requiring the TXT record initially, but
> this makes it sound like it ages out and has to be rediscovered the next
> time a message is sent to the domain.

See above, refresh should happen long before expiration.  An ongoing
MiTM attack can defeat this, but the attack has to be ongoing for the
lifetime of the policy.  It may be easier to get a forged certificate
from some DV CA (via MiTM of the traffic between the CA and the target
domain).

> Just to be clear, I do not consider use of long cache times to be an
> effective security measure.

If that's the case, then STS is not for you.  DANE has stronger
downgrade resistance, please join the existing > 173000 domains
that have DNSSEC and DANE-enabled MX hosts.  I'd especially like
to see some US-based hosting providers emulate domeneshop.no,
transip.nl, udmedia.de and bhosted.nl by enabling DANE on the
SMTP servers used for their hosted domains.  If anyone reading
this knows the right people at Godaddy, Dreamhost, ... please
let them know I'm available to answer any questions they may
have and suggest key rotation strategies.

> - Section 3.3: Does certificate expiration constrain the max_age of a
> cached policy? (if the certificate expires very soon)

No.  Neither the mta-sts HTTPS server certificate, nor even more so
the expirations of MX host certificates affect the policy expiration
time.

> - Section 4 "enforce" prohibits delivering when things fail mta-sts, but
> Section 2 says, "MTA-STS is designed not to interfere with DANE
> deployments where the two overlap". Doesn't this requirement constitute
> that sort of interference?

I would read that as "STS is entirely out of scope when DANE policy
is in effect".  Of course sending machines get to decide whether
DANE policy is in effect or not, by choosing to enable DANE or STS
in the first place, and potentially choose one or the other explicitly
for some domains.

Thus, for example, while DANE policy is generally driven by the
remote domain's publishing of TLSA records, a sending Postfix
MTA can be configured to *require* DANE for some set of destinations,
in which case delivery will only happen when the destinations publish
("secure" DNSSEC) DANE TLSA records, and not otherwise.

Similarly, a sending system might *require* STS for some set of
destinations, and refuse to send in the absence of a cached policy.

So, the way I would read and implement this would be to prefer
DANE over STS barring local policy that prefers one over the
other for some destinations or perhaps suppressed both.

> - Section 4 "report": delete? (because this is in tlsrpt)

Sorry, the "report" mode is not superseded by "tlsrpt", which
does not provide any downgrade protected signalling.
I think renaming "report" as suggested above will remove possible confusion.
 

> - Section 6.1: Why is SNI always required? Can't a small MTA that only
> ever serves one domain get by without it?

SNI is required from the *sending* MTA and HTTPS policy lookup client.
It is not (should not be) required at receiving systems, except when they
in fact have multiple certificate chains and need to use the SNI signal
from the client to choose the right one.  Even then, at the MX host
it is required that when the client's SNI does not match any name
known to the server, it should continue and send its default chain.
The HTTPS server can do whatever it is that HTTPS servers do with
SNI, it is not for this specification to redefine HTTPS.

> - Section 7.1 leads me to question the benefit of having a policy ID in
> the TXT record as opposed to just a hint whether might be a MTA-STS
> policy.

This was subject to considerable earlier discussion, and is in fact
needed.

It here to enable checking the currency of a cached policy without fetching the policy again.
 

> Apparently the only time the a sender i. required to check the
> TXT record is when they don't have a policy (first message or it has
> expired).

There's your confusion.  This is not the case.

> Of course senders could check TXT more often but I don't see
> any guidance for that.

Section 9.2.
--f403045f6d2c489f75055dd688d8-- From nobody Sun Nov 12 21:56:29 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8705D127977 for ; Sun, 12 Nov 2017 21:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFxneee1n73T for ; Sun, 12 Nov 2017 21:56:24 -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 E4E50128B91 for ; Sun, 12 Nov 2017 21:56:10 -0800 (PST) Received: from dhcp-88ec.meeting.ietf.org ([IPv6:2001:67c:370:128:5c2e:c8bc:75d9:c9ad]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id vAD5u6GA002263 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 12 Nov 2017 21:56:09 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1510552570; bh=KwFtWeUN4yH5b1rvfaRhwT71GprHQJwOIqCy7dWK6f0=; h=Subject:To:References:From:Date:In-Reply-To; b=UjkFyAg1a+JjXfX7evifZIMOhp20xfBvGqwoxynX1xb0i5aTA/SwpUf8PUB2QICNx bGi7vsjj9blKjTmNS0CGHl/P7D9ksm34dEkEjeSREgWRFO6JuERSYBXjQ+9mkNNDyw G0yCzlQRP/AwQO7s1O4Bqbko2G8a8JPYp2XdrGxE= To: uta@ietf.org References: <0a1c7674-865a-a85e-f432-3aa99663eb4c@bluepopcorn.net> From: Jim Fenton Message-ID: <14d814d8-cc32-a111-225b-4da60b2649de@bluepopcorn.net> Date: Sun, 12 Nov 2017 21:56:04 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [Uta] Comments on mta-sts-11 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 05:56:27 -0000 On 11/12/17 10:48 AM, Viktor Dukhovni wrote: > >> On Nov 12, 2017, at 6:01 AM, Jim Fenton wrote= : >> >> An attacker that is positioned between mail servers to be >> able to block the negotiation of STARTTLS probably is also positioned = to >> be able to block the _mta-sts TXT record response, making it look like= >> there's no policy. > This is an unavoidable feature of STS. It is vulnerable to "cold start= " > downgrade attacks, that is to downgrades when the sending system has > no cached policy. =C2=A0Yes -- I'm probably repeating repeating myself here, but thought it= worth saying. > >> - Section 3.2 "mode" key/value pair: What does "report" do now that >> tlsrpt is separate? It seems like the modes now ought to be "enforce" >> and "none". > It does exactly what it says, delivery proceeds despite lack of STARTTL= S > or authentication failure, but such failures to establish a secure chan= nel > for delivery are reported. There are no such reports to domains with n= o > policy. Perhaps the receiving domain is unsure how interoperable its > TLS stack or certificate chain would be if enforced. Though to be hone= st > I am not convinced that support for reporting will be universal, I expe= ct > that some systems will treat "report" and "none" as synonymous (by neve= r > sending reports). So maybe the problem is the choice of the name "report" since it doesn't actually cause any reports to be generated. It's really a passive policy. I was thinking that expressing a policy along with "none" (along with a tlsrpt policy record) would accomplish this, but maybe the semantics of "none" are wrong given its role in removing MTA-STS (Section 7.3), but I don't see that it necessarily conflicts. Or maybe just change it to enforce: [yes/no]. > >> - max_age: Does expiration of max_age trigger a refresh or does it >> simply age out of the cache? > A sensible implementation of STS will make (multiple if necessary) > refresh attempts long *before* the cached policy expires, provided > there is sufficient ongoing traffic to the destination domain. > > Such refresh would happen after a delivery of a message after 1/2 > max_age, 3/4 max_age, ... ultimately down to (say) ~5 minutes before > expiration. So with a 180 day max_age, and steady message flow to > a domain with a poorly available HTTPS service, the refreshes would > happen (rounded): > > * shortly after 90 days, but failing that > * shortly after 135 days, but failing that > * shortly after 157 days, but failing that > * shortly after 168 days, but failing that > * shortly after 173 days, but failing that > * shortly after 177 days, but failing that > * shortly after 178 days, but failing that > * shortly after 179 days, but failing that > * shortly after 12 hours to go, but failing that > * shortly after 6 hours to go, but failing that > * shortly after 3 hours to go, but failing that > * shortly after 90 minutes to go, but failing that > * shortly after 45 minutes to to, but failing that > * shortly after 22 minutes to go, but failing that > * shortly after 11 minutes to go, but failing that > * shortly after 5 minutes to go, but failing that > ... policy expires ... > * periodic lookup after each message delivery, but > not more often than once every (say) 5 minutes. > > The details of the refresh policy, and frequency of probes > for domains with no cached policy would be implementation > dependent. Without some guidance (perhaps a SHOULD), many implementations will never check the TXT record if they have a policy in their cache. Unless senders are going to be actually checking the TXT records for updates, it's not worthwhile for recipient domains to publish them. I also wonder how useful it is given that recipient domains are going to have to assume that their policies will be used until max-age anyway, and these policies aren't likely to change very often. > I think that based in part on my feedback the > text in Section 9.2 says (somewhat less prescriptively): > > https://tools.ietf.org/html/draft-ietf-uta-mta-sts-11#section-9.2 > > 9.2. Preventing Policy Discovery > ... > > Because this attack is also possible upon refresh of a cached policy= , > we suggest implementers do not wait until a cached policy has expire= d > before checking for an update; if senders attempt to refresh the > cache regularly (for instance, by checking their cached version > string against the TXT record on each successful send, or in a > background task that runs daily or weekly), an attacker would have t= o > foil policy discovery consistently over the lifetime of a cached > policy to prevent a successful refresh. A comment that I forgot to make is that, if this is a normative requirement (even a MAY or SHOULD), it should be in one of the earlier sections of the document, not in Security Considerations where it's likely to be overlooked by implementers. >> - Section 3.3: Does certificate expiration constrain the max_age of a >> cached policy? (if the certificate expires very soon) > No. Neither the mta-sts HTTPS server certificate, nor even more so > the expirations of MX host certificates affect the policy expiration > time. I'm wondering if the document should say that. > >> - Section 4 "enforce" prohibits delivering when things fail mta-sts, b= ut >> Section 2 says, "MTA-STS is designed not to interfere with DANE >> deployments where the two overlap". Doesn't this requirement constitut= e >> that sort of interference? > I would read that as "STS is entirely out of scope when DANE policy > is in effect". Of course sending machines get to decide whether > DANE policy is in effect or not, by choosing to enable DANE or STS > in the first place, and potentially choose one or the other explicitly > for some domains. > > Thus, for example, while DANE policy is generally driven by the > remote domain's publishing of TLSA records, a sending Postfix > MTA can be configured to *require* DANE for some set of destinations, > in which case delivery will only happen when the destinations publish > ("secure" DNSSEC) DANE TLSA records, and not otherwise. > > Similarly, a sending system might *require* STS for some set of > destinations, and refuse to send in the absence of a cached policy. > > So, the way I would read and implement this would be to prefer > DANE over STS barring local policy that prefers one over the > other for some destinations or perhaps suppressed both. That's the way I would read and implement it too, but it would be good to say that in Section 4 so that it doesn't conflict with Section 2. > >> - Section 6.1: Why is SNI always required? Can't a small MTA that only= >> ever serves one domain get by without it? > SNI is required from the *sending* MTA and HTTPS policy lookup client. > It is not (should not be) required at receiving systems, except when th= ey > in fact have multiple certificate chains and need to use the SNI signal= > from the client to choose the right one. Even then, at the MX host > it is required that when the client's SNI does not match any name > known to the server, it should continue and send its default chain. > The HTTPS server can do whatever it is that HTTPS servers do with > SNI, it is not for this specification to redefine HTTPS. Agreed, so the text shouldn't unconditionally require SNI. >> Apparently the only time the a sender i. required to check the >> TXT record is when they don't have a policy (first message or it has >> expired). > There's your confusion. This is not the case. Please point me at text that says otherwise. From nobody Mon Nov 13 08:06:30 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 EDBB21294EF for ; Mon, 13 Nov 2017 08:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VziIAgQDnAQO for ; Mon, 13 Nov 2017 08:06:25 -0800 (PST) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (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 85A70127843 for ; Mon, 13 Nov 2017 08:06:25 -0800 (PST) Received: by mail-io0-x242.google.com with SMTP id g73so5568463ioj.8 for ; Mon, 13 Nov 2017 08:06:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S7E3QOTtp9lc0XMvBMLHhQmi7F2lVX3nBYZ39ySt9Jw=; b=mOGu7HqC63vTJOGrNa1dZrf+HaoG5+87wRkxr/PoRoh5A4tPFcjg1JmmZcJY4SWeYr u0/fgMwy5MLIspzvsjuUoTt4UpCDtxykUyTb+7ajMrPlKSI/26cSI+7umzLjZCIo6cEg IDo2S1LRdjY/HIM1q14tSsbIncnUyyHsgP93A05ee/ZPI4t1mo1XXv41u3wtogYpHVNF x35iMTgmqyjTgATlU31ISngn320jfrnvG/hLC/sisxNmYhoXl1VwBME4QMI6TJiM4cs9 Qtq2ufQugI6jNNuby1aRJnm2f8MUqDMuv+HYcv/0AAqAwHTdSgjOOxzqF8LSJJZYoGaS PdbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S7E3QOTtp9lc0XMvBMLHhQmi7F2lVX3nBYZ39ySt9Jw=; b=OVzkDTyhDsNJCDagxrMCUj7l2PCakqtcMRib1fsO8Fe0cnKWqA0R4WOCP17klIhzWf nf3hAlV6+dz8506foGslad8hCQN19M9nFVD/2BvrGcg0hkFUvOFt5jmLl22TYVQIk8wg 3MQNHdWegp7hhFMQO5uQKv5VJL3kzcIApRZTNwLvDd0OihqtZvG/7R1SnpT/2LBUPI6g G0vPFT5QEvHAV86qrKDTZjNH6ryKaZIdZQ/q8R2kHuOM9pMoe81mOWZCTG2x8OUc0OIz 4Ss7k6EQ5Mz0VjUyA9eZ3CNcaQe0Kn7yHvJac6cgSFMoVb8BD2S28UxJ9AZN6FfAbtBL aFPg== X-Gm-Message-State: AJaThX7yGycXpwPHo0KsPv4oMmk5S2YRDRZoK9q9CIVPTYmIup+jgbgt l4/0bz5KakizDz/SGkjMTPzS84rHvUqr8YtNBZ+KTHrd X-Google-Smtp-Source: AGs4zMbb9hjGZ7KZvplK2hDel6Gv+OMBmp2DJNkVftIoYISpSazvV6lqTlpxU2tioG6thK2dma2dEwWtVxYrZD+VQXs= X-Received: by 10.107.222.17 with SMTP id v17mr10831030iog.283.1510589184077; Mon, 13 Nov 2017 08:06:24 -0800 (PST) MIME-Version: 1.0 References: <0a1c7674-865a-a85e-f432-3aa99663eb4c@bluepopcorn.net> <14d814d8-cc32-a111-225b-4da60b2649de@bluepopcorn.net> In-Reply-To: <14d814d8-cc32-a111-225b-4da60b2649de@bluepopcorn.net> From: Daniel Margolis Date: Mon, 13 Nov 2017 16:06:11 +0000 Message-ID: To: Jim Fenton Cc: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403043d0a08c6dbaa055ddf73d9" Archived-At: Subject: Re: [Uta] Comments on mta-sts-11 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 16:06:29 -0000 --f403043d0a08c6dbaa055ddf73d9 Content-Type: multipart/alternative; boundary="f403043d0a08b90f13055ddf731b" --f403043d0a08b90f13055ddf731b Content-Type: text/plain; charset="UTF-8" Hey, thanks to you both for the discussion. I'll try to centralize the issues here a little bit, if you don't mind. > Security properties of policy discovery and risks of persistent MITM preventing discovery. I'm going to take a pass on this discussion, Jim, unless it's a blocker. As Viktor said, this is a tradeoff that's been there since the beginning, but we've discussed it many times before and resolved (I think) to go forward. So this is simply a risk we have to document, as we have done in Security Considerations. > Mode "report" vs "none". You make a fair point that "report" is a no-op if there's no TLSRPT, but I think it's somewhat nice to call it out as "report" because it indicates the likely usage of this setting--to generate data for observers. This isn't TLSRPT-specific; it's just that absent TLSRPT or human intervention there's no good way to share reports with the domain admin. Nicolas's suggestion of "testing" works for me, but frankly I would prefer not to change this since it requires changing a bit of code in a few places and will take a few minutes longer than it takes for me to just say I'd prefer to be lazy and keep "report". If you feel strongly, let me know. ;) > SNI To be clear, SNI is only required to be *sent* by the SMTP and HTTPS clients. This is necessary in that servers cannot use SNI if they cannot assume clients will send it. But that doesn't mean servers must support SNI; they can simply ignore it if they want. So this is the minimum requirement to make SNI functional, as was discussed on this list before. > Cert validity and max_age. There's no relationship at all between max_age and cert lifetimes. Certificate validation involves checking the cert as one normally would, i.e., by verifying the signing chain and the expiry (and, optionally, revocation). There's no implication of policy ages applying to anything other than the policy, I think. I'm happy to clarify this if you suggest language, of course. > How strongly to require senders to proactively refresh the policy (as currently in 9.2). I'm OK with moving this up in the doc and making it more prominent. I don't know if we want to make it normative (MUST) because a) the system works "fine" without it and b) there's no way to really say someone is "not compliant" if they don't do this. But I think it makes sense to make it a SHOULD and (as discussed already in Security Considerations) make clear the risks in not doing so regularly. Beyond that, I think most of the comments are (much needed) editorial and formatting fixes, which I very much appreciate, but I think there were no blockers I missed. Correct me if I'm wrong. Of course we will take a stab at all of those fixes shortly. Thanks again! On Mon, Nov 13, 2017 at 6:56 AM Jim Fenton wrote: > On 11/12/17 10:48 AM, Viktor Dukhovni wrote: > > > >> On Nov 12, 2017, at 6:01 AM, Jim Fenton wrote: > >> > >> An attacker that is positioned between mail servers to be > >> able to block the negotiation of STARTTLS probably is also positioned to > >> be able to block the _mta-sts TXT record response, making it look like > >> there's no policy. > > This is an unavoidable feature of STS. It is vulnerable to "cold start" > > downgrade attacks, that is to downgrades when the sending system has > > no cached policy. > Yes -- I'm probably repeating repeating myself here, but thought it > worth saying. > > > > >> - Section 3.2 "mode" key/value pair: What does "report" do now that > >> tlsrpt is separate? It seems like the modes now ought to be "enforce" > >> and "none". > > It does exactly what it says, delivery proceeds despite lack of STARTTLS > > or authentication failure, but such failures to establish a secure > channel > > for delivery are reported. There are no such reports to domains with no > > policy. Perhaps the receiving domain is unsure how interoperable its > > TLS stack or certificate chain would be if enforced. Though to be honest > > I am not convinced that support for reporting will be universal, I expect > > that some systems will treat "report" and "none" as synonymous (by never > > sending reports). > > So maybe the problem is the choice of the name "report" since it doesn't > actually cause any reports to be generated. It's really a passive > policy. I was thinking that expressing a policy along with "none" (along > with a tlsrpt policy record) would accomplish this, but maybe the > semantics of "none" are wrong given its role in removing MTA-STS > (Section 7.3), but I don't see that it necessarily conflicts. Or maybe > just change it to enforce: [yes/no]. > > > > >> - max_age: Does expiration of max_age trigger a refresh or does it > >> simply age out of the cache? > > A sensible implementation of STS will make (multiple if necessary) > > refresh attempts long *before* the cached policy expires, provided > > there is sufficient ongoing traffic to the destination domain. > > > > Such refresh would happen after a delivery of a message after 1/2 > > max_age, 3/4 max_age, ... ultimately down to (say) ~5 minutes before > > expiration. So with a 180 day max_age, and steady message flow to > > a domain with a poorly available HTTPS service, the refreshes would > > happen (rounded): > > > > * shortly after 90 days, but failing that > > * shortly after 135 days, but failing that > > * shortly after 157 days, but failing that > > * shortly after 168 days, but failing that > > * shortly after 173 days, but failing that > > * shortly after 177 days, but failing that > > * shortly after 178 days, but failing that > > * shortly after 179 days, but failing that > > * shortly after 12 hours to go, but failing that > > * shortly after 6 hours to go, but failing that > > * shortly after 3 hours to go, but failing that > > * shortly after 90 minutes to go, but failing that > > * shortly after 45 minutes to to, but failing that > > * shortly after 22 minutes to go, but failing that > > * shortly after 11 minutes to go, but failing that > > * shortly after 5 minutes to go, but failing that > > ... policy expires ... > > * periodic lookup after each message delivery, but > > not more often than once every (say) 5 minutes. > > > > The details of the refresh policy, and frequency of probes > > for domains with no cached policy would be implementation > > dependent. > > Without some guidance (perhaps a SHOULD), many implementations will > never check the TXT record if they have a policy in their cache. Unless > senders are going to be actually checking the TXT records for updates, > it's not worthwhile for recipient domains to publish them. I also wonder > how useful it is given that recipient domains are going to have to > assume that their policies will be used until max-age anyway, and these > policies aren't likely to change very often. > > > I think that based in part on my feedback the > > text in Section 9.2 says (somewhat less prescriptively): > > > > https://tools.ietf.org/html/draft-ietf-uta-mta-sts-11#section-9.2 > > > > 9.2. Preventing Policy Discovery > > ... > > > > Because this attack is also possible upon refresh of a cached policy, > > we suggest implementers do not wait until a cached policy has expired > > before checking for an update; if senders attempt to refresh the > > cache regularly (for instance, by checking their cached version > > string against the TXT record on each successful send, or in a > > background task that runs daily or weekly), an attacker would have to > > foil policy discovery consistently over the lifetime of a cached > > policy to prevent a successful refresh. > > A comment that I forgot to make is that, if this is a normative > requirement (even a MAY or SHOULD), it should be in one of the earlier > sections of the document, not in Security Considerations where it's > likely to be overlooked by implementers. > > >> - Section 3.3: Does certificate expiration constrain the max_age of a > >> cached policy? (if the certificate expires very soon) > > No. Neither the mta-sts HTTPS server certificate, nor even more so > > the expirations of MX host certificates affect the policy expiration > > time. > > I'm wondering if the document should say that. > > > > >> - Section 4 "enforce" prohibits delivering when things fail mta-sts, but > >> Section 2 says, "MTA-STS is designed not to interfere with DANE > >> deployments where the two overlap". Doesn't this requirement constitute > >> that sort of interference? > > I would read that as "STS is entirely out of scope when DANE policy > > is in effect". Of course sending machines get to decide whether > > DANE policy is in effect or not, by choosing to enable DANE or STS > > in the first place, and potentially choose one or the other explicitly > > for some domains. > > > > Thus, for example, while DANE policy is generally driven by the > > remote domain's publishing of TLSA records, a sending Postfix > > MTA can be configured to *require* DANE for some set of destinations, > > in which case delivery will only happen when the destinations publish > > ("secure" DNSSEC) DANE TLSA records, and not otherwise. > > > > Similarly, a sending system might *require* STS for some set of > > destinations, and refuse to send in the absence of a cached policy. > > > > So, the way I would read and implement this would be to prefer > > DANE over STS barring local policy that prefers one over the > > other for some destinations or perhaps suppressed both. > > That's the way I would read and implement it too, but it would be good > to say that in Section 4 so that it doesn't conflict with Section 2. > > > > >> - Section 6.1: Why is SNI always required? Can't a small MTA that only > >> ever serves one domain get by without it? > > SNI is required from the *sending* MTA and HTTPS policy lookup client. > > It is not (should not be) required at receiving systems, except when they > > in fact have multiple certificate chains and need to use the SNI signal > > from the client to choose the right one. Even then, at the MX host > > it is required that when the client's SNI does not match any name > > known to the server, it should continue and send its default chain. > > The HTTPS server can do whatever it is that HTTPS servers do with > > SNI, it is not for this specification to redefine HTTPS. > > Agreed, so the text shouldn't unconditionally require SNI. > > >> Apparently the only time the a sender i. required to check the > >> TXT record is when they don't have a policy (first message or it has > >> expired). > > There's your confusion. This is not the case. > > Please point me at text that says otherwise. > > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --f403043d0a08b90f13055ddf731b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey, thanks to you both for the discussion. I'll try t= o centralize the issues here a little bit, if you don't mind.=C2=A0
> Security properties of policy discovery and risks of p= ersistent MITM preventing discovery.=C2=A0

I'm= going to take a pass on this discussion, Jim, unless it's a blocker. A= s Viktor said, this is a tradeoff that's been there since the beginning= , but we've discussed it many times before and resolved (I think) to go= forward. So this is simply a risk we have to document, as we have done in = Security Considerations.=C2=A0

> Mode "rep= ort" vs "none".

You make a fair poi= nt that "report" is a no-op if there's no TLSRPT, but I think= it's somewhat nice to call it out as "report" because it ind= icates the likely usage of this setting--to generate data for observers. Th= is isn't TLSRPT-specific; it's just that absent TLSRPT or human int= ervention there's no good way to share reports with the domain admin.= =C2=A0

Nicolas's suggestion of "testing&q= uot; works for me, but frankly I would prefer not to change this since it r= equires changing a bit of code in a few places and will take a few minutes = longer than it takes for me to just say I'd prefer to be lazy and keep = "report". If you feel strongly, let me know. ;)=C2=A0
<= br>
> SNI

To be clear, SNI is only re= quired to be sent=C2=A0by the SMTP and HTTPS clients. This is necess= ary in that servers cannot use SNI if they cannot assume clients will send = it. But that doesn't mean servers must support SNI; they can simply ign= ore it if they want. So this is the minimum requirement to make SNI functio= nal, as was discussed on this list before.=C2=A0

&= gt; Cert validity and max_age.

There's no rela= tionship at all between max_age and cert lifetimes. Certificate validation = involves checking the cert as one normally would, i.e., by verifying the si= gning chain and the expiry (and, optionally, revocation). There's no im= plication of policy ages applying to anything other than the policy, I thin= k. I'm happy to clarify this if you suggest language, of course.
<= div>
> How strongly to require senders to proactively refr= esh the policy (as currently in 9.2).

I'm OK w= ith moving this up in the doc and making it more prominent. I don't kno= w if we want to make it normative (MUST) because a) the system works "= fine" without it and b) there's no way to really say someone is &q= uot;not compliant" if they don't do this. But I think it makes sen= se to make it a SHOULD and (as discussed already in Security Considerations= ) make clear the risks in not doing so regularly.=C2=A0

Beyond that, I think most of the comments are (much needed) editorial= and formatting fixes, which I very much appreciate, but I think there were= no blockers I missed. Correct me if I'm wrong.=C2=A0

Of course we will take a stab at all of those fixes shortly.=C2=A0<= /div>

Thanks again!


On Mon, Nov 13, 2017 at 6:56 AM Jim Fenton <<= a href=3D"mailto:fenton@bluepopcorn.net">fenton@bluepopcorn.net> wro= te:
On 11/12/17 10:48 AM, Viktor Du= khovni wrote:
>
>> On Nov 12, 2017, at 6:01 AM, Jim Fenton <fenton@bluepopcorn.net> wrote:=
>>
>> An attacker that is positioned between mail servers to be
>> able to block the negotiation of STARTTLS probably is also positio= ned to
>> be able to block the _mta-sts TXT record response, making it look = like
>> there's no policy.
> This is an unavoidable feature of STS.=C2=A0 It is vulnerable to "= ;cold start"
> downgrade attacks, that is to downgrades when the sending system has > no cached policy.
=C2=A0Yes -- I'm probably repeating repeating myself here, but thought = it
worth saying.

>
>> - Section 3.2 "mode" key/value pair: What does "rep= ort" do now that
>> tlsrpt is separate? It seems like the modes now ought to be "= enforce"
>> and "none".
> It does exactly what it says, delivery proceeds despite lack of STARTT= LS
> or authentication failure, but such failures to establish a secure cha= nnel
> for delivery are reported.=C2=A0 There are no such reports to domains = with no
> policy.=C2=A0 Perhaps the receiving domain is unsure how interoperable= its
> TLS stack or certificate chain would be if enforced.=C2=A0 Though to b= e honest
> I am not convinced that support for reporting will be universal, I exp= ect
> that some systems will treat "report" and "none" a= s synonymous (by never
> sending reports).

So maybe the problem is the choice of the name "report" since it = doesn't
actually cause any reports to be generated. It's really a passive
policy. I was thinking that expressing a policy along with "none"= (along
with a tlsrpt policy record) would accomplish this, but maybe the
semantics of "none" are wrong given its role in removing MTA-STS<= br> (Section 7.3), but I don't see that it necessarily conflicts. Or maybe<= br> just change it to enforce: [yes/no].

>
>> - max_age: Does expiration of max_age trigger a refresh or does it=
>> simply age out of the cache?
> A sensible implementation of STS will make (multiple if necessary)
> refresh attempts long *before* the cached policy expires, provided
> there is sufficient ongoing traffic to the destination domain.
>
> Such refresh would happen after a delivery of a message after 1/2
> max_age, 3/4 max_age, ... ultimately down to (say) ~5 minutes before > expiration.=C2=A0 So with a 180 day max_age, and steady message flow t= o
> a domain with a poorly available HTTPS service, the refreshes would > happen (rounded):
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0* shortly after 90 days, but failing that >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* shortly after 135 days, but failing= that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0* shortly after 157 days, but failing that >=C2=A0 =C2=A0 =C2=A0 =C2=A0* shortly after 168 days, but failing that >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* shortly after 173 days, but failing= that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0* shortly after 177 days, but failing that >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* shortly after 178 days, but failing= that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* shortly after 179 days, but failing= that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* shortly after 12 hours to go, but f= ailing that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* shortly after 6 hours to go, but fa= iling that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* shortly after 3 hours to go, but fa= iling that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0* shortly after 90 minutes to go, but failin= g that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0* shortly after 45 minutes to to, but failin= g that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0* shortly after 22 minutes to go, but failin= g that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0* shortly after 11 minutes to go, but failin= g that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* shortly after 5 minutes to go, but = failing that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0... policy expires ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0* periodic lookup after each message deliver= y, but
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not more often than once every= (say) 5 minutes.
>
> The details of the refresh policy, and frequency of probes
> for domains with no cached policy would be implementation
> dependent.

Without some guidance (perhaps a SHOULD), many implementations will
never check the TXT record if they have a policy in their cache. Unless
senders are going to be actually checking the TXT records for updates,
it's not worthwhile for recipient domains to publish them. I also wonde= r
how useful it is given that recipient domains are going to have to
assume that their policies will be used until max-age anyway, and these
policies aren't likely to change very often.

>=C2=A0 =C2=A0I think that based in part on my feedback the
> text in Section 9.2 says (somewhat less prescriptively):
>
>=C2=A0 =C2=A0https://tools.ietf= .org/html/draft-ietf-uta-mta-sts-11#section-9.2
>
>=C2=A0 =C2=A09.2.=C2=A0 Preventing Policy Discovery
>=C2=A0 =C2=A0 ...
>
>=C2=A0 =C2=A0 Because this attack is also possible upon refresh of a ca= ched policy,
>=C2=A0 =C2=A0 we suggest implementers do not wait until a cached policy= has expired
>=C2=A0 =C2=A0 before checking for an update; if senders attempt to refr= esh the
>=C2=A0 =C2=A0 cache regularly (for instance, by checking their cached v= ersion
>=C2=A0 =C2=A0 string against the TXT record on each successful send, or= in a
>=C2=A0 =C2=A0 background task that runs daily or weekly), an attacker w= ould have to
>=C2=A0 =C2=A0 foil policy discovery consistently over the lifetime of a= cached
>=C2=A0 =C2=A0 policy to prevent a successful refresh.

A comment that I forgot to make is that, if this is a normative
requirement (even a MAY or SHOULD), it should be in one of the earlier
sections of the document, not in Security Considerations where it's
likely to be overlooked by implementers.

>> - Section 3.3: Does certificate expiration constrain the max_age o= f a
>> cached policy? (if the certificate expires very soon)
> No.=C2=A0 Neither the mta-sts HTTPS server certificate, nor even more = so
> the expirations of MX host certificates affect the policy expiration > time.

I'm wondering if the document should say that.

>
>> - Section 4 "enforce" prohibits delivering when things f= ail mta-sts, but
>> Section 2 says, "MTA-STS is designed not to interfere with DA= NE
>> deployments where the two overlap". Doesn't this requirem= ent constitute
>> that sort of interference?
> I would read that as "STS is entirely out of scope when DANE poli= cy
> is in effect".=C2=A0 Of course sending machines get to decide whe= ther
> DANE policy is in effect or not, by choosing to enable DANE or STS
> in the first place, and potentially choose one or the other explicitly=
> for some domains.
>
> Thus, for example, while DANE policy is generally driven by the
> remote domain's publishing of TLSA records, a sending Postfix
> MTA can be configured to *require* DANE for some set of destinations,<= br> > in which case delivery will only happen when the destinations publish<= br> > ("secure" DNSSEC) DANE TLSA records, and not otherwise.
>
> Similarly, a sending system might *require* STS for some set of
> destinations, and refuse to send in the absence of a cached policy. >
> So, the way I would read and implement this would be to prefer
> DANE over STS barring local policy that prefers one over the
> other for some destinations or perhaps suppressed both.

That's the way I would read and implement it too, but it would be good<= br> to say that in Section 4 so that it doesn't conflict with Section 2.
>
>> - Section 6.1: Why is SNI always required? Can't a small MTA t= hat only
>> ever serves one domain get by without it?
> SNI is required from the *sending* MTA and HTTPS policy lookup client.=
> It is not (should not be) required at receiving systems, except when t= hey
> in fact have multiple certificate chains and need to use the SNI signa= l
> from the client to choose the right one.=C2=A0 Even then, at the MX ho= st
> it is required that when the client's SNI does not match any name<= br> > known to the server, it should continue and send its default chain. > The HTTPS server can do whatever it is that HTTPS servers do with
> SNI, it is not for this specification to redefine HTTPS.

Agreed, so the text shouldn't unconditionally require SNI.

>> Apparently the only time the a sender i. required to check the
>> TXT record is when they don't have a policy (first message or = it has
>> expired).
> There's your confusion.=C2=A0 This is not the case.

Please point me at text that says otherwise.



_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
--f403043d0a08b90f13055ddf731b-- --f403043d0a08c6dbaa055ddf73d9 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMYvQlQqbPmlmUoZynMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODE4NDIxNloXDTE4MDMx NzE4NDIxNlowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDI3sfyM5pHCY0cDNbbiDAn17uPa3PG0G98FftCEkej/WTh RcWVnnX7STqcEnQwK7z8r8SckwfHWqDMNnb6PMXVZUOCv9iewPrxXlQfmFvDQQnRXbUKp7WgUjzm 5v1BIs/mIvqkrBsiPJLvNbO8b7BxewUnTP24wHaCYvlVFXd/A+hbq5CJciR230oH0bmB6zMlpxQe 45PlPkEkLb2cUaad14IV2ulfK8pcsLLM+NntC9jxKVAp3GCSAp6gjOmCJdCB4YlyC943ej9IoryJ fOVpmm6IOchzDTJH/rgPUWbQnZFhVw4V1EkHfrYugci2Up30l4SsMieOPgfd6oAwDzlbAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFFQQtjTE3yoZgnE8infGLj+S7TiRMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQBpExGZx6F4 zM7Y/n7mnIsXl81PZas0VWUjE0MMdlX+FBxLg6+tSAZL+pi0i/iRb9bNg3KLqo0mpN2cnHa0Cyeo 9+DUJYdHtitY7O0oDfN6qsTLKkI2ff4VhVRahJMa9RlBHuiJa09Tlu/d1BqqjF8Vlf+1ygExN6dx PL95kbdwYM+0GILX+rt4okmVWgj4ol9JgBcQG6MA6rQvuoJHpfxv0I6yNXMMe3R86vfnz5XFHrX1 RfudaTWxM29kR44KxN19+TtVs2HTb/YAgGyyI3sxsX/keInYwKOZEpX3PwXn30CjjzPDjXR9+Zye K9iJUpsLFz8YJkPSc2e90JrrGAFuMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM YvQlQqbPmlmUoZynMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBmHiD+UV1bbOIO Tyyuk5cc1HrnDgxnzi2t4wZzBaYJkTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzExMTMxNjA2MjVaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAdEoM+VLr94+5/w9FqWidvlzVVZtMHy2z LqafeIjjFhIfV1AVzPraC3L+t9FZ9sNfRz4l1Ct87kN50XJ7nHgIdUm12UusSLfL4r3yL4iVj2cW b6bsAlGeae1nMHwzm8dld0p8LbHvLWXRskCPwl/62eHSw80T+1dRle6qP+hKcp6BGkfulX6eTGZI RwE8Zxuak6F/8qYIovjDzg3556Zatg2z9dky5mil5Y9+PRmq9VV/yQvxtMeLgJbC3BSRzDRrZU/W TMmKG2GCqtm0RYUb5i+UFYdp/wvusTgZ6rsx2T98oF085khovtL/fIIAaICLV5cJP/klmc+UaBWl 5GpX6Q== --f403043d0a08c6dbaa055ddf73d9-- From nobody Mon Nov 13 18:16:39 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 0FA8912954B for ; Mon, 13 Nov 2017 18:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 eVdbN5lZ0VpR for ; Mon, 13 Nov 2017 18:16:30 -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 B423512941D for ; Mon, 13 Nov 2017 18:16:30 -0800 (PST) Received: from dhcp-88ec.meeting.ietf.org ([IPv6:2001:67c:370:128:41fd:faa9:463c:1019]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id vAE2GOId017369 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 13 Nov 2017 18:16:27 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1510625788; bh=W1qHl+hTN2TbbzOIla51KgO97XPKP3niULYGX/AkA5g=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=NRq+G/C8NO6sQEFPWkJ6ULVRZXXbv79NY7UtplT1E0xdv4qT4Ty58JFgnzC79CnF3 V6pWWZwx/CU0CivUfwKlxf/RXaVMZLbWfiTSOTSt/nSA3JEd9JWPGhDlDxp0XtcTV8 5VzvamFmsIkHbSjQaYDucqYGrvOk/0AEqirYBc/Q= To: Daniel Margolis Cc: uta@ietf.org References: <0a1c7674-865a-a85e-f432-3aa99663eb4c@bluepopcorn.net> <14d814d8-cc32-a111-225b-4da60b2649de@bluepopcorn.net> From: Jim Fenton Message-ID: Date: Mon, 13 Nov 2017 18:16:22 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0C9D1CC15FAAA44E232D48E4" Content-Language: en-US Archived-At: Subject: Re: [Uta] Comments on mta-sts-11 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 02:16:37 -0000 This is a multi-part message in MIME format. --------------0C9D1CC15FAAA44E232D48E4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/13/17 8:06 AM, Daniel Margolis wrote: > Hey, thanks to you both for the discussion. I'll try to centralize the > issues here a little bit, if you don't mind. Good summary, thanks for organizing it. Comments inline. > > > Security properties of policy discovery and risks of persistent MITM > preventing discovery.=C2=A0 > > I'm going to take a pass on this discussion, Jim, unless it's a > blocker. As Viktor said, this is a tradeoff that's been there since > the beginning, but we've discussed it many times before and resolved > (I think) to go forward. So this is simply a risk we have to document, > as we have done in Security Considerations. OK. > > > Mode "report" vs "none". > > You make a fair point that "report" is a no-op if there's no TLSRPT, > but I think it's somewhat nice to call it out as "report" because it > indicates the likely usage of this setting--to generate data for > observers. This isn't TLSRPT-specific; it's just that absent TLSRPT or > human intervention there's no good way to share reports with the > domain admin.=C2=A0 > > Nicolas's suggestion of "testing" works for me, but frankly I would > prefer not to change this since it requires changing a bit of code in > a few places and will take a few minutes longer than it takes for me > to just say I'd prefer to be lazy and keep "report". If you feel > strongly, let me know. ;) I'm mixed on this. This is at the draft stage so some changes should be expected. The key question that I have, and implementers will need to know, is if there is any semantic difference between "report" and "none". I can't find any, except possibly in Section 7.3, "Removing MTA-STS", and I'm not sure if that is really a difference. My main concern with "report", which I probably said before, is that it might confuse domains that are publishing MTA-STS policies and don't know about TLSRPT. > > > SNI > > To be clear, SNI is only required to be /sent/=C2=A0by the SMTP and HTT= PS > clients. This is necessary in that servers cannot use SNI if they > cannot assume clients will send it. But that doesn't mean servers must > support SNI; they can simply ignore it if they want. So this is the > minimum requirement to make SNI functional, as was discussed on this > list before. My mistake here; the spec does clearly say the client MUST have SNI support, not the server. > > > Cert validity and max_age. > > There's no relationship at all between max_age and cert lifetimes. > Certificate validation involves checking the cert as one normally > would, i.e., by verifying the signing chain and the expiry (and, > optionally, revocation). There's no implication of policy ages > applying to anything other than the policy, I think. I'm happy to > clarify this if you suggest language, of course. Seems reasonable, it's just a question that came up in my head while I was reading the spec.=C2=A0 Not sure it warrants clarification. > > > How strongly to require senders to proactively refresh the policy > (as currently in 9.2). > > I'm OK with moving this up in the doc and making it more prominent. I > don't know if we want to make it normative (MUST) because a) the > system works "fine" without it and b) there's no way to really say > someone is "not compliant" if they don't do this. But I think it makes > sense to make it a SHOULD and (as discussed already in Security > Considerations) make clear the risks in not doing so regularly. Yes, please move it up. Security considerations is more of a discussion of the characteristics of the protocol, and implementers are likely to miss it there. I would also add, since it's a SHOULD: Publishers of MTA-STS policies MUST NOT depend on updates to be retrieved before the expiration of the max_age. -Jim --------------0C9D1CC15FAAA44E232D48E4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/13/17 8:06 AM, Daniel Margolis wrote:
Hey, thanks to you both for the discussion. I'll try to centralize the issues here a little bit, if you don't mind.

Good summary, thanks for organizing it. Comments inline.


> Security properties of policy discovery and risks of persistent MITM preventing discovery. 

I'm going to take a pass on this discussion, Jim, unless it's a blocker. As Viktor said, this is a tradeoff that's been there since the beginning, but we've discussed it many times before and resolved (I think) to go forward. So this is simply a risk we have to document, as we have done in Security Considerations.

OK.


> Mode "report" vs "none".

You make a fair point that "report" is a no-op if there's no TLSRPT, but I think it's somewhat nice to call it out as "report" because it indicates the likely usage of this setting--to generate data for observers. This isn't TLSRPT-specific; it's just that absent TLSRPT or human intervention there's no good way to share reports with the domain admin. 

Nicolas's suggestion of "testing" works for me, but frankly I would prefer not to change this since it requires changing a bit of code in a few places and will take a few minutes longer than it takes for me to just say I'd prefer to be lazy and keep "report". If you feel strongly, let me know. ;)

I'm mixed on this. This is at the draft stage so some changes should be expected. The key question that I have, and implementers will need to know, is if there is any semantic difference between "report" and "none". I can't find any, except possibly in Section 7.3, "Removing MTA-STS", and I'm not sure if that is really a difference. My main concern with "report", which I probably said before, is that it might confuse domains that are publishing MTA-STS policies and don't know about TLSRPT.


> SNI

To be clear, SNI is only required to be sent by the SMTP and HTTPS clients. This is necessary in that servers cannot use SNI if they cannot assume clients will send it. But that doesn't mean servers must support SNI; they can simply ignore it if they want. So this is the minimum requirement to make SNI functional, as was discussed on this list before.

My mistake here; the spec does clearly say the client MUST have SNI support, not the server.


> Cert validity and max_age.

There's no relationship at all between max_age and cert lifetimes. Certificate validation involves checking the cert as one normally would, i.e., by verifying the signing chain and the expiry (and, optionally, revocation). There's no implication of policy ages applying to anything other than the policy, I think. I'm happy to clarify this if you suggest language, of course.

Seems reasonable, it's just a question that came up in my head while I was reading the spec.  Not sure it warrants clarification.



> How strongly to require senders to proactively refresh the policy (as currently in 9.2).

I'm OK with moving this up in the doc and making it more prominent. I don't know if we want to make it normative (MUST) because a) the system works "fine" without it and b) there's no way to really say someone is "not compliant" if they don't do this. But I think it makes sense to make it a SHOULD and (as discussed already in Security Considerations) make clear the risks in not doing so regularly.

Yes, please move it up. Security considerations is more of a discussion of the characteristics of the protocol, and implementers are likely to miss it there. I would also add, since it's a SHOULD: Publishers of MTA-STS policies MUST NOT depend on updates to be retrieved before the expiration of the max_age.

-Jim

--------------0C9D1CC15FAAA44E232D48E4-- From nobody Mon Nov 13 19:46:02 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3A01273E2 for ; Mon, 13 Nov 2017 19:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tl3S8hQD9YUf for ; Mon, 13 Nov 2017 19:45:58 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49EC5129544 for ; Mon, 13 Nov 2017 19:45:47 -0800 (PST) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 8249C7A3309 for ; Tue, 14 Nov 2017 03:45:46 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Viktor Dukhovni In-Reply-To: Date: Mon, 13 Nov 2017 22:45:03 -0500 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: <85C001E5-CD39-4D5C-8722-C5A6F595E041@dukhovni.org> References: <0a1c7674-865a-a85e-f432-3aa99663eb4c@bluepopcorn.net> <14d814d8-cc32-a111-225b-4da60b2649de@bluepopcorn.net> To: uta@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [Uta] Comments on mta-sts-11 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 03:46:01 -0000 > On Nov 13, 2017, at 9:16 PM, Jim Fenton = wrote: >=20 > I'm mixed on this. This is at the draft stage so some changes should = be expected. The key question that I have, and implementers will need to = know, is if there is any semantic difference between "report" and = "none". There is a semantic difference: * With "none" no verification of the destination is expected and no reports are generated on verification "failure" * With "report", verification is expected, and failure reports may be generated, but delivery proceeds despite failure. The request to "report" failures is subject to the usual downgrade protection (except on cold-start, loss of state at the sending MTA, or too little traffic to keep the cache "warm"). --=20 Viktor. From nobody Mon Nov 13 21:58:48 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25481270AE for ; Mon, 13 Nov 2017 21:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Hb8RNsA9oKka for ; Mon, 13 Nov 2017 21:58:44 -0800 (PST) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33F11270A0 for ; Mon, 13 Nov 2017 21:58:44 -0800 (PST) Received: by mail-ua0-x234.google.com with SMTP id v27so13086620uav.7 for ; Mon, 13 Nov 2017 21:58: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=xiY91CCd6QKMqkfCH5hNbaRLuli9IGB+1ZhiI/B3/eQ=; b=m0tcs0zSqhoJb4201rZ4rPMPOgufABTc7adwFpQQeL30fiyeawbEBQVABlHCfpUn6r PpIvcTikLrsLnjJO4bC95b0EgafYCwRrUpEEkdOjxQHTToEpCQLycmFyQVGP9xQslE2Q /0LWpqLUiKMbNSutF0WMG3Ub1lYNRw4dUn+3MDy2Hw/e7vF56d9e32/FOv8OH1IyFQOW vVjbpG98nIse69C4xY4SGoLZLGVHX75oWAlNZ39Ul8HqlmF77IcXMaw2449lC34Uc0XM hoLwmKHa1iZx5mI1Mu+sXzET0pbTYNBmynZ/5mhi8Gvxx8+B9hU5ZN8R8MYTMSiYfiuX z3wQ== 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=xiY91CCd6QKMqkfCH5hNbaRLuli9IGB+1ZhiI/B3/eQ=; b=Busv1Yzm+c6WjEcakfaLQlX6MjYsrCK0hfl8UV0DtLC+K+O10/DRoMr9G/BTsclD+v lpEDd6eQxPlkwCWLcl/iOsQZDXE19lIrkyOp/XVrNS/8wnPcQhpkS5eVptHBZMJtfzrZ /6vvIH1Iq5KVx4oRdqD7QDZJT3ZU5VQaSotNG0frG5hgyYDw7EJeAxd01d7pJWOp90OK hMUjFUL6hX0TqPxWZaJukQvCi+qmKB1BnBW8LG/a6OrcObLrSJUiEO+8qGQiVVqAyuT1 cVTAj+QcU0ZE+5WEfZgKb5mBzhbAaWN9PRHtU7RH5LvAe8cRMCh+n9ycIkntUoCPPYi1 Moqg== X-Gm-Message-State: AJaThX7MzYiy4bTaOxFIKTEw+P9ENxWtIJQv4dlcwiNTvCUOLT8ItbDT LiKPHVsAK/aj81PfhQagjeim2irzKViqKHpb+TeVtj2L X-Google-Smtp-Source: AGs4zMbQRMhuIHhU8dx2bEVuJD4/fwjDWQjRbvcFnYuix7yW37xdwRfWsn7IqltY9n+AAxatpNVEtLBzvpJ6Xtb1Tn8= X-Received: by 10.159.61.1 with SMTP id l1mr9402599uai.132.1510639122269; Mon, 13 Nov 2017 21:58:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.136.84 with HTTP; Mon, 13 Nov 2017 21:58:10 -0800 (PST) In-Reply-To: <85C001E5-CD39-4D5C-8722-C5A6F595E041@dukhovni.org> References: <0a1c7674-865a-a85e-f432-3aa99663eb4c@bluepopcorn.net> <14d814d8-cc32-a111-225b-4da60b2649de@bluepopcorn.net> <85C001E5-CD39-4D5C-8722-C5A6F595E041@dukhovni.org> From: =?UTF-8?Q?=F0=9F=94=A5_Nicolas_Lidzborski?= Date: Tue, 14 Nov 2017 13:58:10 +0800 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045f6d7c4e8ca7055deb1403" Archived-At: Subject: Re: [Uta] Comments on mta-sts-11 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 05:58:47 -0000 --f403045f6d7c4e8ca7055deb1403 Content-Type: multipart/alternative; boundary="f403045f6d7c44e2b9055deb14d0" --f403045f6d7c44e2b9055deb14d0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Tue, Nov 14, 2017 at 11:45 AM, Viktor Dukhovni wrote: > > > > On Nov 13, 2017, at 9:16 PM, Jim Fenton wrote: > > > > I'm mixed on this. This is at the draft stage so some changes should be > expected. The key question that I have, and implementers will need to know, > is if there is any semantic difference between "report" and "none". > > There is a semantic difference: > > * With "none" no verification of the destination is expected and > no reports are generated on verification "failure" > I would suggest calling this mode "disabled" for clarity. > * With "report", verification is expected, and failure reports > may be generated, but delivery proceeds despite failure. > As mentioned, I would suggest renaming this mode "testing" for clarity. > The request to "report" failures is subject to the usual downgrade > protection (except on cold-start, loss of state at the sending MTA, > or too little traffic to keep the cache "warm"). > --f403045f6d7c44e2b9055deb14d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit
On Tue, Nov 14, 2017 at 11:45 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:


> On Nov 13, 2017, at 9:16 PM, Jim Fenton <fenton@bluepopcorn.net> wrote:
>
> I'm mixed on this. This is at the draft stage so some changes should be expected. The key question that I have, and implementers will need to know, is if there is any semantic difference between "report" and "none".

There is a semantic difference:

* With "none" no verification of the destination is expected and
  no reports are generated on verification "failure"
I would suggest calling this mode "disabled" for clarity.
 
* With "report", verification is expected, and failure reports
  may be generated, but delivery proceeds despite failure.
As mentioned, I would suggest renaming this mode "testing" for clarity.
 
The request to "report" failures is subject to the usual downgrade
protection (except on cold-start, loss of state at the sending MTA,
or too little traffic to keep the cache "warm").
--f403045f6d7c44e2b9055deb14d0-- --f403045f6d7c4e8ca7055deb1403 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5QYJKoZIhvcNAQcCoIIS1jCCEtICAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBLMIIEXDCCA0SgAwIBAgIOSBtqDm4P/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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEYjCCA0qgAwIBAgIMZeYFG1tcnrkLhFF3MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDgyMjE4NDI0OFoXDTE4MDIx ODE4NDI0OFowITEfMB0GCSqGSIb3DQEJAQwQbmxpZHpAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAJizmbcIA4fUUxUnVLcEbp7fyGg10UN4BfdILhOLWjO85A2PACqU fpfYHLhLAAAQlSU1VOhuj/0BTUkox1MxfXAg/zsYU1yphmFWhtA8Pyaeapy8baepMWGOYXd+0PVI cldWh6wCXUwW3HDVykODW4U0/oCRKaQt184UhoNBZF97nMaQhpEQ87ZzNJe0/rU0JXc0cJOXocu8 VCXNe87F4IDq1aU3XIA0wGU4ZQHqUPP5BE2pfiadrHdvQeDPCri3OngS5LAhGRZ7LfX8ULuXSAKi yHRKI7D1QM0k75mRJI5A5eA3149xhRZ7S1McAH3Ay30X++QRFidENi8Fl9Xyd+ECAwEAAaOCAW0w ggFpMBsGA1UdEQQUMBKBEG5saWR6QGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUF BzAChjRodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0 MB0GA1UdDgQWBBRMPMO+sM71DSlJka01WaFGqosY0zAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV 5vQmYsDgPzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3 dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3Js Lmdsb2JhbHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAG1KtMlpLsJmKaAepAz/D iYGXcjmct7+fvu1wLw6fDj3+tUbrX6Mnpo8ZJXhfnWHrRnB5fBeuszyGGwf0ZDUOb6H19we+E3YV W4UwX65gcQnfZMdev45bi1TrFkMc4c/sUrCuM4Dxk09NwNRFd+kshOUrgDqQ1xL0QJXjYZb2vPuq uX3RyDVZp9zLxv0iy2sPDYLEurDxaxIfgbyzHSr1jBMPHiDguwx2R7I9nYr+g60S7XGw+9NFUNlA U6aGTU1h361djm13IHav1954eWUy8pWl3M420H8s71SZHm1xBNXaoWOExkmur0vp1qW8QrqKcdNJ avcUkZdUJjGdvve/uTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2Jh bFNpZ24gbnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDGXmBRtbXJ65 C4RRdzANBglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgGXCC1NJAA7wV0U1qjxQMAdWT iCW+alfhmGH9sg6jdv8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTcxMTE0MDU1ODQyWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZI AWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAFhNWWHg9xLpgVJ2z8wmBEY7KJVh+t7gCMvxL7mlTQFU lRd7rQCxdawWh99JuvB6UWTacDzGgcQnOQeowvZIO/yOIqZ97DV6Ec6MeTidmKZ0NaPoo1eb0PIl mMXmxYiqbZfVCHCULGuLg8PdZxouv0PHf+zjtg+QlUN+gLP/dLLRmWMoHAo8Ggax5j40rX04UzGZ tBlqVb/DeRLnVksMHnsJjOjxHzo35jORcf6tI414DaUg4LOZcBic0Snng38Ut9HOrLMfWPfXaYqP gOljexdfbu5+kmeb7otF/4HFSg5ZuFQv/e7ku/1L+Dm1+qzFqM0O2s0fVsrzsXZJYlL4KsY= --f403045f6d7c4e8ca7055deb1403-- From nobody Tue Nov 14 00:52:24 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C745D126C0F for ; Tue, 14 Nov 2017 00:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 1dsV5EX_nxJ8 for ; Tue, 14 Nov 2017 00:52:12 -0800 (PST) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 12DFF12008A for ; Tue, 14 Nov 2017 00:52:12 -0800 (PST) Received: by mail-it0-x22a.google.com with SMTP id x28so7032577ita.0 for ; Tue, 14 Nov 2017 00:52:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PtiFN9tW1Ug4zYw1lzea8UvUUBjst+kVkAA3Oi68B+g=; b=eYJvd26x+zjwoWJvASq6Dxb5oD0dVvgSq+8XmtVldktD3HVMbg0xLMn72AuQSe6Yek I8RYzyaqP5tOWycGwqUfOYRH4mp+xyr3Xohy1OkWlRHW0Iy7U/ILXquxFfyd2qlDpPPn 2AMU2AsXiNB4owvjZip9yZ4yyabbzv/D7zHCWGrD6OD+sYFCmhpnSGb4dpQlt21c90ve bMNPDlF5le9/Q/csVoBJSsnrkMtH9tAGxoL3OqHe4RvEfSO1p1uDANZjHqnveTxaYzKu aFxp4G/biiGOkv2RLOnvvsiSW61QLt97qxewzP47jmBd/pSYT9jOx5zM3Xotqdc8DwlP TCAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PtiFN9tW1Ug4zYw1lzea8UvUUBjst+kVkAA3Oi68B+g=; b=kM3sgfhsXxxQBcL2Q3R12knVEU9f8lP+HTWksuzgmzaUub2kCrU6nG8lGa1v9IgZUS 5IKKBf2aVU4b019E+4u85NO02Ht9qeRPPyjhLlv5zWvhdmb+cuKHpzBVF5wjn7t1TmpE 3iTUAk4Kxjp3nNatE7oLbLKdwUH+Ez5THhwFoSebspe8jdjc2jT/cOeTfKtEe9pMsNU/ MCA0mfy8q62Ea8f9SxyHHynqTsEnvehFptXnQBY59Ula2FGHmKXux4RlVyc7T/ivi8gZ DaiYpzY8oFNGywXNjJP9/gTVmxVmoixT+Mh5wG8KLaDMYhuXzfn0Ae/WrlX0367znEKy E6Kg== X-Gm-Message-State: AJaThX5iLzB+kFBd7T20jNtsFpt6EfcdJ5NQXzBvfBKtxe4lkFx6W6lY +0ul1AK1RViqNx/eYzPZGaSMrKELTW0BM9hhTtks7g== X-Google-Smtp-Source: AGs4zMa7Aqebq16IWLXDGcF/s4a96K2epdg00iZyvsJatSQPdTgAHnLTRN16O5bbVBvRP/iFvaybVm9/0KbuQn4MR54= X-Received: by 10.36.175.17 with SMTP id t17mr14485933ite.66.1510649530779; Tue, 14 Nov 2017 00:52:10 -0800 (PST) MIME-Version: 1.0 References: <0a1c7674-865a-a85e-f432-3aa99663eb4c@bluepopcorn.net> <14d814d8-cc32-a111-225b-4da60b2649de@bluepopcorn.net> <85C001E5-CD39-4D5C-8722-C5A6F595E041@dukhovni.org> In-Reply-To: From: Daniel Margolis Date: Tue, 14 Nov 2017 08:51:57 +0000 Message-ID: To: =?UTF-8?Q?Nicolas_Lidzborski=E2=90=84?= Cc: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c198400b5f10d055ded80e2" Archived-At: Subject: Re: [Uta] Comments on mta-sts-11 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 08:52:24 -0000 --94eb2c198400b5f10d055ded80e2 Content-Type: multipart/alternative; boundary="94eb2c198400ab107d055ded804b" --94eb2c198400ab107d055ded804b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Works for me. To sum up the thread: 1. Bunch of editorial stuff. I will try to collate the list from Jim's original email sometime next week and get it into a new draft. I expect we may have some feedback from the UTA session as well. ;) 2. Rename "report" to "testing". Not a big deal, I agree, and a bit more clear. 3. Jim's suggested language with a SHOULD on proactive policy refresh and a MUST NOT on publishers expecting that to happen. I think that's all of it? Thanks everyone. On Tue, Nov 14, 2017 at 6:58 AM =F0=9F=94=A5 Nicolas Lidzborski wrote: > On Tue, Nov 14, 2017 at 11:45 AM, Viktor Dukhovni > wrote: > >> >> >> > On Nov 13, 2017, at 9:16 PM, Jim Fenton wrote= : >> > >> > I'm mixed on this. This is at the draft stage so some changes should b= e >> expected. The key question that I have, and implementers will need to kn= ow, >> is if there is any semantic difference between "report" and "none". >> >> There is a semantic difference: >> >> * With "none" no verification of the destination is expected and >> no reports are generated on verification "failure" >> > I would suggest calling this mode "disabled" for clarity. > > >> * With "report", verification is expected, and failure reports >> may be generated, but delivery proceeds despite failure. >> > As mentioned, I would suggest renaming this mode "testing" for clarity. > > >> The request to "report" failures is subject to the usual downgrade >> protection (except on cold-start, loss of state at the sending MTA, >> or too little traffic to keep the cache "warm"). >> > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --94eb2c198400ab107d055ded804b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Works for me. To sum up the thread:

1. = Bunch of editorial stuff. I will try to collate the list from Jim's ori= ginal email sometime next week and get it into a new draft. I expect we may= have some feedback from the UTA session as well. ;)

2. Rename "report" to "testing". Not a big deal, I a= gree, and a bit more clear.=C2=A0

3. Jim's sug= gested language with a SHOULD on proactive policy refresh and a MUST NOT on= publishers expecting that to happen.=C2=A0

I thin= k that's all of it?=C2=A0

Thanks everyone.=C2= =A0


On Tue, = Nov 14, 2017 at 6:58 AM =F0=9F=94=A5 Nicolas Lidzborski <nlidz@google.com> wrote:
On Tue, Nov 14, 2017 at 11:45 AM, Viktor Dukhovni <ie= tf-dane@dukhovni.org> wrote:
fenton@bluepopcorn.net> wrote:
>
> I'm mixed on this. This is at the draft stage so some changes shou= ld be expected. The key question that I have, and implementers will need to= know, is if there is any semantic difference between "report" an= d "none".

There is a semantic difference:

* With "none" no verification of the destination is expected and<= br> =C2=A0 no reports are generated on verification "failure"
I would suggest calling this mode "disabled" for cl= arity.
=C2=A0
* With "report", verification is expected, and failure reports =C2=A0 may be generated, but delivery proceeds despite failure.
As mentioned, I would suggest renaming this mode "testing&qu= ot; for clarity.
=C2=A0
The request to "report" failures is subject to the usual downgrad= e
protection (except on cold-start, loss of state at the sending MTA,
or too little traffic to keep the cache "warm").
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
--94eb2c198400ab107d055ded804b-- --94eb2c198400b5f10d055ded80e2 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMYvQlQqbPmlmUoZynMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODE4NDIxNloXDTE4MDMx NzE4NDIxNlowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDI3sfyM5pHCY0cDNbbiDAn17uPa3PG0G98FftCEkej/WTh RcWVnnX7STqcEnQwK7z8r8SckwfHWqDMNnb6PMXVZUOCv9iewPrxXlQfmFvDQQnRXbUKp7WgUjzm 5v1BIs/mIvqkrBsiPJLvNbO8b7BxewUnTP24wHaCYvlVFXd/A+hbq5CJciR230oH0bmB6zMlpxQe 45PlPkEkLb2cUaad14IV2ulfK8pcsLLM+NntC9jxKVAp3GCSAp6gjOmCJdCB4YlyC943ej9IoryJ fOVpmm6IOchzDTJH/rgPUWbQnZFhVw4V1EkHfrYugci2Up30l4SsMieOPgfd6oAwDzlbAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFFQQtjTE3yoZgnE8infGLj+S7TiRMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQBpExGZx6F4 zM7Y/n7mnIsXl81PZas0VWUjE0MMdlX+FBxLg6+tSAZL+pi0i/iRb9bNg3KLqo0mpN2cnHa0Cyeo 9+DUJYdHtitY7O0oDfN6qsTLKkI2ff4VhVRahJMa9RlBHuiJa09Tlu/d1BqqjF8Vlf+1ygExN6dx PL95kbdwYM+0GILX+rt4okmVWgj4ol9JgBcQG6MA6rQvuoJHpfxv0I6yNXMMe3R86vfnz5XFHrX1 RfudaTWxM29kR44KxN19+TtVs2HTb/YAgGyyI3sxsX/keInYwKOZEpX3PwXn30CjjzPDjXR9+Zye K9iJUpsLFz8YJkPSc2e90JrrGAFuMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM YvQlQqbPmlmUoZynMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDHRjbwyqVg+ebK P5UzU+p57lZ20y509JmXpQ3HpI4gYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzExMTQwODUyMTFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEATlCDV+MJoGVXgEZ/aZxOdId4PTY2cgjd FqRQsGGUmVjcRvIl4K7XMtf9PcPStrJgWYrv1euiAn/lcgooBUrxsiCXEtZ1mFmvP/Rl5sobLKeW sLQlB44uW5zkMPnTPB5atABnSyJ5ZsRV7QdyizR+aix5eiHQkju18uBak1gtUuQrvJa+k1WMKtI2 tFsZuZPdkm3DzfpCHdFYK2sLLHxxcMTMFMbALcl7iF/LRv30xl5tHRHO5zuYdy/jhtJKupJLHeQa azh0NaFPp0sFDbnlAtSWgr04Pb2SaatU7fD7yN98AiZ6fMDTaZ+C+okDC0bqpoSGvJOxvpG5GfIB tc109A== --94eb2c198400b5f10d055ded80e2-- From nobody Tue Nov 14 07:04:57 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 646EE127333 for ; Tue, 14 Nov 2017 07:04:49 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.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 SuwcsZyHt5oQ for ; Tue, 14 Nov 2017 07:04:47 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 C286B12426E for ; Tue, 14 Nov 2017 07:04:47 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id b6so14357265pff.10 for ; Tue, 14 Nov 2017 07:04:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=AkOLMWceug9OYbSUjfO72kp6GUfYDQuOlq+Gy0WJJQA=; b=NnxXiZsKL52blxxi/MmIbz1mtC25gBx2zivYJXfsigdxV6wyiJEb+G0i6TwYb828wR dz9OvtMAiEcUHNMkwCYTKisOqF+Gf5EJq2BscKPqZuPp9Mq8cKXSuAF4kI8RQUiSez9+ ideNOEMnczBhl/yIOcA0sGAfh+GBQtJMiVT3s5HAfep9y7K2F/II53xTnSeloJWk/bX7 AhSG7eTRzkPCFNaYqIFtsmZgX4q1/j0A+IeIokcHZerD3p8yVXJncDpGYlMh1d5SRNdc gJ7xngDll6N5EmjE18vmwEUCFQjHvumCS08pApA6F6y3s+ph8k+tUCCHDY1yvlxlKDiI O+/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AkOLMWceug9OYbSUjfO72kp6GUfYDQuOlq+Gy0WJJQA=; b=TBLUbAVxUeh3Ifq8FDr85g93yY2lhFEIczc/YdAoBpM/u374YOWtx1AsDr8P7cl8H4 MVGlK62qjNOSSrsF7AzLbQYg+PMJ60xSV75RkeQKuc/q4kw/QO3+EEldBd7JDHf/Db4C wmvoah3e73/Ygo0A/u3LLrHDPtMEwyadEG5W5qYKdwnW+FLdOmcMCjg3orodk04+cKaL NfBJx4HltYDXEvkk7TglS5wcJQ1X/z0dDrHjQaPebPYRfBk2ddJSugXYz5zc+q2ehpxU +O6h1gBYldlAsyP8+S2wQkEjxcIwLNuAyg8ovPKHrCm3oYNRX43hDIZOks0vuGsxb+wG uvyQ== X-Gm-Message-State: AJaThX46Gf4Vrff+rF7zKOgS6znt7EYrdz7iFDuF1qoDMFDPazZ962bK YBsFXrMqwQPz+xb6rwZZMPgfn14qV88= X-Google-Smtp-Source: AGs4zMZIMhuNlu9WVWULWEPTVdlhdDkU4vHrlk8E4bR5cM5jDwDTKoDX+eLFBd1GXGCIjsDIwehcrQ== X-Received: by 10.101.81.139 with SMTP id h11mr12288472pgq.233.1510671887049; Tue, 14 Nov 2017 07:04:47 -0800 (PST) Received: from ?IPv6:2001:67c:1232:144:418a:5b2a:53f5:49b? ([2001:67c:1232:144:418a:5b2a:53f5:49b]) by smtp.gmail.com with ESMTPSA id d6sm38042723pfc.29.2017.11.14.07.04.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 07:04:45 -0800 (PST) To: uta@ietf.org References: <0a1c7674-865a-a85e-f432-3aa99663eb4c@bluepopcorn.net> <14d814d8-cc32-a111-225b-4da60b2649de@bluepopcorn.net> <85C001E5-CD39-4D5C-8722-C5A6F595E041@dukhovni.org> From: Leif Johansson Message-ID: <628b013e-cad4-deec-0962-322e71d81a9f@mnt.se> Date: Tue, 14 Nov 2017 16:04:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Uta] Comments on mta-sts-11 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 15:04:49 -0000 On 2017-11-14 09:51, Daniel Margolis wrote: > Works for me. To sum up the thread: > > 1. Bunch of editorial stuff. I will try to collate the list from Jim's > original email sometime next week and get it into a new draft. I expect > we may have some feedback from the UTA session as well. ;) > > 2. Rename "report" to "testing". Not a big deal, I agree, and a bit more > clear.  > > 3. Jim's suggested language with a SHOULD on proactive policy refresh > and a MUST NOT on publishers expecting that to happen.  > > I think that's all of it?  > Yeah I think so. I think we can treat these things as WGLC comments. Barring people speaking up on new things at the meeting tomorrow I expect to push the IESG button on MTA-STS and TLSRPT sometime next week or so. Cheers Leif > Thanks everyone.  > > > On Tue, Nov 14, 2017 at 6:58 AM 🔥 Nicolas Lidzborski > wrote: > > On Tue, Nov 14, 2017 at 11:45 AM, Viktor Dukhovni > > wrote: > > > > > On Nov 13, 2017, at 9:16 PM, Jim Fenton > wrote: > > > > I'm mixed on this. This is at the draft stage so some changes should be expected. The key question that I have, and implementers will need to know, is if there is any semantic difference between "report" and "none". > > There is a semantic difference: > > * With "none" no verification of the destination is expected and >   no reports are generated on verification "failure" > > I would suggest calling this mode "disabled" for clarity. >   > > * With "report", verification is expected, and failure reports >   may be generated, but delivery proceeds despite failure. > > As mentioned, I would suggest renaming this mode "testing" for clarity. >   > > The request to "report" failures is subject to the usual downgrade > protection (except on cold-start, loss of state at the sending MTA, > or too little traffic to keep the cache "warm"). > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > From nobody Wed Nov 15 13:29:04 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 7E51A126DD9 for ; Wed, 15 Nov 2017 13:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=yKVC0HHC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JO3AVK+p 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 5adU7kBy1s7w for ; Wed, 15 Nov 2017 13:29:01 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D84A1250B8 for ; Wed, 15 Nov 2017 13:29:01 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B519D20BA4; Wed, 15 Nov 2017 16:29:00 -0500 (EST) Received: from web1 ([10.202.2.211]) by compute7.internal (MEProxy); Wed, 15 Nov 2017 16:29:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=8+vY4w0NqQUUYH1Y8PyXSoFUF5PCShJFeXYtumLDSa4=; b=yKVC0HHC KMTlSljjJQy4WwZ21YcrjFiFGpHWBLEzar8BnA/D4DVTPqh8gatFtYYkv+zNRElk +Sup7HfXQIWmGDJExSVvxINvHGyh8vbrj5CWBp/FDv1m0qEIlwUAVx6Q4IW8yA2s jorEf94LgEPnIfWd+hFXE2Qw0gDvAiC1+x9x5V5EEcpylvXRAudqh6QSSWAbNrK/ hBSHZTe1p5PXqGe9x+V9IbbLrYRVgrRIBxrx5MhasozgbsBzBVghnBgoYrEJj66a HeoMC+dDdq7bt5JaNZir9aYXhkMAXE64ec/TlTBMBbMSnDMmZDWO23XbYbta07PB sgQaGXV4fdZxUw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=8+vY4w0NqQUUYH1Y8PyXSoFUF5PCS hJFeXYtumLDSa4=; b=JO3AVK+puqvQt6k6vk/uRwr5LDIRklYOpOXECSehusZOM NPzzD2YLX/dxZFJexUO8GB1MVpXjY14bJ3M4OaW9w4B18olHDbvBg2Yv/TJc6STB r3ME2nuTU7W7Tmg0kWqO365arGvbcB4IICUtjQppCmAlT1wbx87W88kmE35JMR9g a8MADlTtwEQvRj2PJCpuCxMiiqa6UguJz85t5os91XTXKU3daGz8/MzHLl4qQYsL aoUiNd8Du6n3BmnXOCjJu3ZGC4oka49qOsX2SHMDENxaDW/RxZ/PED9OEL9bZ0do p7eEXKqq+rzIF2tdUMEs0HjxvxONkMX12eBeFf31g== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9AD5E957AC; Wed, 15 Nov 2017 16:29:00 -0500 (EST) Message-Id: <1510781340.4104313.1173890952.797D9295@webmail.messagingengine.com> From: Alexey Melnikov To: uta@ietf.org Cc: Valery Smyslov , Leif Johansson MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-f89283c9 Date: Wed, 15 Nov 2017 21:29:00 +0000 Archived-At: Subject: [Uta] New UTA co-chair X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 21:29:02 -0000 Dear UTA WG, I am pleased to announce that Leif now has another co-chair: Valery Smyslov . Valery edited several documents in IPSECME and is now looking forward to help the UTA WG. Thank you, Alexey From nobody Thu Nov 16 15:29:44 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C461274D2 for ; Thu, 16 Nov 2017 15:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaklxF833uj2 for ; Thu, 16 Nov 2017 15:29:42 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15B221270A0 for ; Thu, 16 Nov 2017 15:29:41 -0800 (PST) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 5AE797A3309 for ; Thu, 16 Nov 2017 23:29:40 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) From: Viktor Dukhovni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: uta@ietf.org Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: <824A749B-AB55-42A6-A387-33F0032DF085@dukhovni.org> Date: Thu, 16 Nov 2017 18:29:39 -0500 To: uta@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [Uta] TLS report sensitivity X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 23:29:43 -0000 Just listening to the recording of the meeting about sensitivity of reports. One thing to keep in mind is that reports will often need to be sent to the very domain which is failing STS validation, so in fact one may well need to deliver the reports at *reduced* security, relative to normal mail traffic, so that the reports get through! Therefore, the considerations as such should not mandate strong transport protection, but rather should only promote avoiding putting anything in the report that would not already be observed by a passive wiretap. -- Viktor. From nobody Thu Nov 16 15:49:39 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 A0A5A124B09 for ; Thu, 16 Nov 2017 15:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpTbq7O4VMbm for ; Thu, 16 Nov 2017 15:49:35 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20D141274D2 for ; Thu, 16 Nov 2017 15:49:35 -0800 (PST) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 474B07A3309 for ; Thu, 16 Nov 2017 23:49:34 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) From: Viktor Dukhovni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: uta-chairs@ietf.org Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: <144822CE-832F-4FB6-A33D-08DA337F7F8E@dukhovni.org> Date: Thu, 16 Nov 2017 18:49:33 -0500 To: uta@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [Uta] REQUIRETLS vs. headers X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 23:49:37 -0000 1. I agree that REQUIRETLS=NO needs a header so it can be tunnelled via an "agnostic" MTA. 2. However, even REQUIRETLS=YES needs a header, because: a. Within an MTA a message may make multiple internal hops, for example processing via a loopback SMTP proxy that does virus scanning, or forwarding via a spam-scanning appliance that is statically configured to always do TLS both upstream and downstream, but does not support REQUIRETLS=YES explicitly. b. Messages may get filtered via procmail and the like and then forwarded, and again the delivery channel has no means to preserve REQUIRETLS=YES except via a header. 3. Therefore, REQUIRETLS will need a header for both YES and NO, but the YES case will also want to see a "REQUIRETLS" in the EHLO response of a remote MTA, so it can commit to honouring the extension. -- Viktor. From nobody Thu Nov 16 16:02:02 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2D21274A5 for ; Thu, 16 Nov 2017 16:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNXpidkFZXit for ; Thu, 16 Nov 2017 16:02:00 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B401273E2 for ; Thu, 16 Nov 2017 16:02:00 -0800 (PST) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 106FE7A3309 for ; Fri, 17 Nov 2017 00:02:00 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) From: Viktor Dukhovni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: uta@ietf.org Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> Date: Thu, 16 Nov 2017 19:01:58 -0500 To: uta@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [Uta] Require TLS=NO is very much needed X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 00:02:02 -0000 People are forgetting that especially smaller sites that implement STS or DANE don't always have the operational discipline to keep these working. I have considerable evidence to support this claim. A sender with urgent non-sensitive messages may well reasonably want to see the message delivered despite such failures. Indeed, this is typically the right thing to do with failure reports! At present, the sender address I use to send DANE failure notices is statically exempted from enforcing DANE policy (rather than message by message). -- Viktor. From nobody Thu Nov 16 17:56:58 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 B10211267BB for ; Thu, 16 Nov 2017 17:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.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 BlaoKtuTfCls for ; Thu, 16 Nov 2017 17:56:55 -0800 (PST) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 5A077124239 for ; Thu, 16 Nov 2017 17:56:55 -0800 (PST) Received: by mail-pf0-x229.google.com with SMTP id i15so768666pfa.3 for ; Thu, 16 Nov 2017 17:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=5o2LddSlj589JgEOwldFC0cBXymBl8AmhdmivgXBshE=; b=Lvwyf3X5TMiBYg7J4vemd+qY9mNoMJ8Rv2trV/6fXIpTyjkpgPK/buI7x8RGkCbdTH t8FXTRul+K9TQREzdtJq2jl5KlaR9qWk/jkEgng4q+4yP7F39JM5sUiBR8XpXcNWENHN dhxpJu+alH0QZM0L4aJ5G7N+kUMjoRXsyQJtkocb2mCES06ysx9mGMIjlEzvfE6YcMTK 4OvDxSFVEtuJsdMUvL3HDhYe+2Df2DpEuaLgFO1D3g1ohiI07v6Gy24tlmb2ZLO4bg6w 1119E8MzCfNx/re5tQRGAqhoUO/1jKc/1NuUq1+NygbtEt03qH1GYx/GmxzovE2WoRKi XKvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5o2LddSlj589JgEOwldFC0cBXymBl8AmhdmivgXBshE=; b=s7peDN8UWv586yRb0Z1ex5QOIbaxn3gEnUaWzqUoyxnj4UdMFsbQaBKC6RnxQoZfkc dZ14dCUARBxFQ/YXmo5JqRI216gLm5OkgQIP9tdSZRpLcSwHbqI4/BjL73ymItXKHosT aeuGGUUPXR9PvYllGxuWPTgs/3kKqdROq+lNvCO08olDPzoP/0rKs8znlYV9OgU3z61E /1UKtRXiGlHFtZhCjLLfyuZUPxRrwl2XEM83xEBPrQpUdSVHybxJyAbUtL+ykdWb0ae6 2tNDT2zdqPvXhpfeT+ntYmTQw78EKIByP0CPXuiiKeuOcdTnWThO1QUX8zf+uu0UzJzC 2QxQ== X-Gm-Message-State: AJaThX4BHsKh2RZu4n7dZ9iyw3KlLtPhYdNJ9rB1SoLFkQPw2f8iwdkF j0Vd/G3MgixzF0aJKkvshl9g2nmYkL0= X-Google-Smtp-Source: AGs4zMYxkuFouRcNGo8a8tnDEf2/XBlXL0ptKB3gOv42bNpBsm0ji63fXKELNjND4q9X+o1SIzxwww== X-Received: by 10.98.242.67 with SMTP id y3mr338361pfl.82.1510883814544; Thu, 16 Nov 2017 17:56:54 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:f997:38d0:925e:12d8? ([2001:67c:370:128:f997:38d0:925e:12d8]) by smtp.gmail.com with ESMTPSA id a4sm5185031pfj.72.2017.11.16.17.56.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 17:56:53 -0800 (PST) To: uta@ietf.org References: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> From: Leif Johansson Message-ID: Date: Fri, 17 Nov 2017 02:56:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] Require TLS=NO is very much needed X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 01:56:58 -0000 On 2017-11-17 01:01, Viktor Dukhovni wrote: > > People are forgetting that especially smaller sites > that implement STS or DANE don't always have the > operational discipline to keep these working. I > have considerable evidence to support this claim. > > A sender with urgent non-sensitive messages may well > reasonably want to see the message delivered despite > such failures. Indeed, this is typically the right > thing to do with failure reports! > > At present, the sender address I use to send DANE > failure notices is statically exempted from enforcing > DANE policy (rather than message by message). > The sense of the room in Singapore was that the semantics of REQUIRETLS=NO was sufficiently different from REQUIRETLS that it would be better to move it to a separate document. It was suggested that REQUIRETLS=NO might be better represented as a message header even. In any case it is not clear to me that there is or ever was consensus to keep this feature /in its current form/ in the REQUIRETLS draft. As always, discussions on the list will determine this but barring clear support for keeping the feature in the draft we need to find another form for this feature. Cheers Leif From nobody Thu Nov 16 18:56:06 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754951275C5 for ; Thu, 16 Nov 2017 18:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_Ws9Jc6xcHF for ; Thu, 16 Nov 2017 18:55:56 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1EC12700F for ; Thu, 16 Nov 2017 18:55:56 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id ACEA77A3309 for ; Fri, 17 Nov 2017 02:55:55 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 16 Nov 2017 21:55:54 -0500 Content-Transfer-Encoding: 7bit Reply-To: uta@ietf.org Message-Id: <7FD24C09-99A6-4847-BCE7-4455F62188FC@dukhovni.org> References: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> To: uta@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [Uta] Require TLS=NO is very much needed X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 02:55:58 -0000 > On Nov 16, 2017, at 8:56 PM, Leif Johansson wrote: > > The sense of the room in Singapore was that the semantics > of REQUIRETLS=NO was sufficiently different from REQUIRETLS > that it would be better to move it to a separate document. > It was suggested that REQUIRETLS=NO might be better > represented as a message header even. The room was not populated by enough folks with deep operational experience in email, especially operational experience with email transport security policy. As I pointed out in another message, BOTH REQUIRETLS=YES *and* REQUIRETLS=NO need to be encapsulated in headers, but the YES case *also* needs an ESMTP extension, while the NO case does not. It makes sense to define both in the same document. > In any case it is not clear to me that there is or ever was > consensus to keep this feature /in its current form/ in the > REQUIRETLS draft. Consensus can yet be achieved after more discussion with folks getting a chance to think through the issues more deeply. > As always, discussions on the list will determine this but > barring clear support for keeping the feature in the draft > we need to find another form for this feature. We're far from done with REQUIRETLS, there are still many questions around *specificity* of what REQUIRETLS means. The present draft makes possible overly prescriptive security criteria, this needs to change. The client can't reasonably expect to know the hop-by-hop security "topology", therefore CHAIN,DANE,DNSSEC are too much detail. The policy needs to be just ternary: * Yes. Require an authenticated secure-channel. * No. Proceed despite authentication failure that would normally prevent message delivery. * No REQUIRETLS verb or header, do the default thing. -- Viktor. From nobody Thu Nov 16 19:06:37 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 604D51276AF for ; Thu, 16 Nov 2017 19:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.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 eTYrRiXjGQzQ for ; Thu, 16 Nov 2017 19:06:27 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 2034B128B93 for ; Thu, 16 Nov 2017 19:06:09 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id c123so881199pga.11 for ; Thu, 16 Nov 2017 19:06:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=R4KPHr1qNJE5cdQQJ4mmmCqY9DhU39LpowUWck784gM=; b=ieUZ8GBPtYa8ySBlii1yuh+JZFRX+e/f7bS93arX5Bpxb8B2V+GJAnyqcetf7RiKLF yL4thh+Yz1qVqDmhyfmjnzbjict39fs/k6LbwA3ZejaEaL9ib0pxGgdR56zWNBIKd8bp 1ekaYEKSMBQlwLgeK0+q5DlE0PIXv0+Lhw9z8TMfyyG2tcPdrI+YTW/lvJZDjhT8XI29 rwEIf3vfHVLaooE0VxpAFABUBvz9sk3i2PGowwAdCscD2F4/7+qYKoewkepx+zp/AxFU /py4HqCfh2R2OS0FAaGsmS6FAcKCaTp+C3uCUBsS5btgcDgv/nToP2/FIpbmQ0pveRYi OV/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=R4KPHr1qNJE5cdQQJ4mmmCqY9DhU39LpowUWck784gM=; b=Q3Iurcbjngj7EMshrrTOx9YfYlf2MgfAUKOHLvSjdV9nlFGRBFkqb3DXPOPU4V41C1 EtltoBkIWIwClJH54MRTPdpi8F0hajR+3qjvC9bhykp44ALkQpcLusQiWkIFOjcGKwyg gzFBaOqGRx5Uj2nBjEJglmjqnB0NG+9ILKz1zb+k+tOe2PI7p7VqtODswwaZnlHCKsfo IIAGrH5VMug823q7IPRUZE+whNHW6M153PwhGk5Pea3ajUOf4MBh7dd+b4aD0H/LfTyI DvvYdOpqCGnJZXYWAHCfDkL4a6gadbhH0RhzCs0PIgL36AluovrQMmbjeqGo0V6521aG 6vyw== X-Gm-Message-State: AJaThX6NYWuSVoqxHOlUHKJVjrpeSoSwaSt6quFoBoXSZvaksfaL8asp BQXQtKYgwsMnt2Ym4LS5dmvNJ78jgJk= X-Google-Smtp-Source: AGs4zMagUgOqqRQIjpYi2354rNfwpvSf96i70cpHtLWTPL3Yi0fD7IFak6O0iM7XMEELoC+uxYkSig== X-Received: by 10.99.95.138 with SMTP id t132mr3695687pgb.66.1510887968274; Thu, 16 Nov 2017 19:06:08 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:f997:38d0:925e:12d8? ([2001:67c:370:128:f997:38d0:925e:12d8]) by smtp.gmail.com with ESMTPSA id o65sm3645735pga.71.2017.11.16.19.06.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 19:06:06 -0800 (PST) To: uta@ietf.org References: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> <7FD24C09-99A6-4847-BCE7-4455F62188FC@dukhovni.org> From: Leif Johansson Message-ID: <3be212da-54bf-faf4-baa6-efd05fb5cef0@mnt.se> Date: Fri, 17 Nov 2017 04:06:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <7FD24C09-99A6-4847-BCE7-4455F62188FC@dukhovni.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] Require TLS=NO is very much needed X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 03:06:32 -0000 On 2017-11-17 03:55, Viktor Dukhovni wrote: > > >> On Nov 16, 2017, at 8:56 PM, Leif Johansson wrote: >> >> The sense of the room in Singapore was that the semantics >> of REQUIRETLS=NO was sufficiently different from REQUIRETLS >> that it would be better to move it to a separate document. >> It was suggested that REQUIRETLS=NO might be better >> represented as a message header even. > > The room was not populated by enough folks with deep operational > experience in email, especially operational experience with > email transport security policy. I will set this aside for now. I encourage everyone to express their opinions on this topic. Right now the consensus is not clear either way. > > As I pointed out in another message, BOTH REQUIRETLS=YES > *and* REQUIRETLS=NO need to be encapsulated in headers, but > the YES case *also* needs an ESMTP extension, while the > NO case does not. It makes sense to define both in the > same document. > >> In any case it is not clear to me that there is or ever was >> consensus to keep this feature /in its current form/ in the >> REQUIRETLS draft. > > Consensus can yet be achieved after more discussion with > folks getting a chance to think through the issues more deeply. Indeed. My response to your message was meant to encourage discussion! Cheers Leif From nobody Thu Nov 16 22:11: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 D0F821200E5 for ; Thu, 16 Nov 2017 22:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 SkcgPmKv9s33 for ; Thu, 16 Nov 2017 22:11:04 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 53465126B72 for ; Thu, 16 Nov 2017 22:11:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1510899063; d=isode.com; s=june2016; i=@isode.com; bh=j1yPRd/Mw17WfkijpQza2yh28ZWknaaZWgC+cbrzaM8=; 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=jqNX7C6QMkXt97UOaAAhNt9mINySgcJDIsYsCigH5x/tmYn9+3g7ACNSEV5yjTs2dfOv99 xj66UXYCbICvGMxeLJ4wgJSyuOUQE5J7QqlvavqHwezGb5Pq7EBNQIY3KlAixve2X5FY8u 7VksWeShF0f/KhT2R3IUbezWHp1VYhc=; Received: from [31.130.236.134] ((unknown) [31.130.236.134]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 17 Nov 2017 06:11:03 +0000 X-SMTP-Protocol-Errors: NORDNS To: Leif Johansson , uta@ietf.org References: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> From: Alexey Melnikov Message-ID: <5A0E7D70.6060302@isode.com> Date: Fri, 17 Nov 2017 14:10:56 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] Require TLS=NO is very much needed X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 06:11:06 -0000 On 17/11/2017 09:56, Leif Johansson wrote: > On 2017-11-17 01:01, Viktor Dukhovni wrote: >> >> People are forgetting that especially smaller sites >> that implement STS or DANE don't always have the >> operational discipline to keep these working. I >> have considerable evidence to support this claim. >> >> A sender with urgent non-sensitive messages may well >> reasonably want to see the message delivered despite >> such failures. Indeed, this is typically the right >> thing to do with failure reports! >> >> At present, the sender address I use to send DANE >> failure notices is statically exempted from enforcing >> DANE policy (rather than message by message). >> > > The sense of the room in Singapore was that the semantics > of REQUIRETLS=NO was sufficiently different from REQUIRETLS > that it would be better to move it to a separate document. > It was suggested that REQUIRETLS=NO might be better > represented as a message header even. > > In any case it is not clear to me that there is or ever was > consensus to keep this feature /in its current form/ in the > REQUIRETLS draft. (As a participant) Maybe write a separate draft? > As always, discussions on the list will determine this but > barring clear support for keeping the feature in the draft > we need to find another form for this feature. From nobody Thu Nov 16 23:01:48 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13181286C7 for ; Thu, 16 Nov 2017 23:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iwm8DBISzvYw for ; Thu, 16 Nov 2017 23:01:45 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 241E612741D for ; Thu, 16 Nov 2017 23:01:45 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 3FA3A7A3309 for ; Fri, 17 Nov 2017 07:01:44 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Viktor Dukhovni In-Reply-To: <5A0E7D70.6060302@isode.com> Date: Fri, 17 Nov 2017 02:01:42 -0500 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: References: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> <5A0E7D70.6060302@isode.com> To: uta@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [Uta] Require TLS=NO is very much needed X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 07:01:46 -0000 > On Nov 17, 2017, at 1:10 AM, Alexey Melnikov = wrote: >=20 > (As a participant) Maybe write a separate draft? There'd be considerable overlap between the documents, both need essentially the same mechanisms to tunnel TLS policy in headers, and there should only be one such header to avoid having to resolve conflicts. The security issues are two sides of the same coin and should be discussed together. Both features override default TLS policy, one to require greater than default security, the other to deliver despite failure of default security policy. The obstacle in the current draft was that the "NO" case appeared to over-complicate the ESMTP extension, but it is now clear that the "NO" case need not use the "ESMTP" extension and should be carried exclusively via a header. However, since the same TLS policy header is also needed for the "YES" case (but with a slightly different payload), the same draft should specify both. We should not force these to be separate just to hurry the "YES" case out the door. Let's do this right. --=20 Viktor. From nobody Thu Nov 16 23:29:00 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C077127601 for ; Thu, 16 Nov 2017 23:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.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 t4fYEWZplw7a for ; Thu, 16 Nov 2017 23:28:57 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C7CE12741D for ; Thu, 16 Nov 2017 23:28:56 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id c123so1332399pga.11 for ; Thu, 16 Nov 2017 23:28:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=3HZDrtVWmVPQrQ8HHSn75Fa6NtGkICbDiH3AoiYrZ+E=; b=OMcphXgSDTdT4+qlZa/zXexTV7M/BRPLVuwIp8PQK+1cLT1lG/QgA1+LnqnprTD8Gt RmHkaObuX0ZMgd9o4YUZbNQQdRobx3ole8f+2fkppg0/MXV5ACYCzwZt8WzcfUJn+Yvr wilEy0dRrMs5aixfRec5l3mTwDMzlRk+U/GcmFhBWgrzwZQtpt8X9H+SiGXtCGQDkJT/ eEBwcIx5xyYBV9IT1pIkg8PLsbrNSXr8TBVPQ7hdVEWxKjlXNc7SlO/lcySekTEvrbYc jZ4ZT7zN6XmCfaowdqyKmBdb5rx2Djrgw3PrNBgLfiaHbkHOCWWq/ZgEihIQceUAq+Lq KpJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3HZDrtVWmVPQrQ8HHSn75Fa6NtGkICbDiH3AoiYrZ+E=; b=Q12PShXvmIoBjNP4Z57S+euWQntfs4VJ/55KxG34NmbNoNdNcTf+TQ4MHmOdDKtT95 ULydIz7httK0+5/oWEnf7tUXtk02IrA9Hr+evr6L8dtcs9mI6zIT8PbQgpVKoZ+AXW/Y XHcJ317kZAGadJWN5TcbTMqTU0QiB158bWWFzOFnorMlJf33Kwf8RBFkXs6pZmZsAY9S jLFpbXjWrCaHeDCbP6yVhpNCZ0MP0eV6j6kTyYv8cSSdddhgCbuum17iMv1gRCTOi6Vd O4iodPMpJn2Qmi23wFUMFwt9gjECT5U5Z+vj7FxCP+NfdVcOWlK+mqiPc493jqO7J1ku KnIA== X-Gm-Message-State: AJaThX6XA3TyKnEQ0XsViokw8Yuz33QWG7EXhho0oKF1aOvdIs50q6x5 hPg1e7pje0EstgHq+5bc6HURqzSsw3VoMQ== X-Google-Smtp-Source: AGs4zMZNCLG22m8WezTed3qjiXDqZcd2RPIOnmB07cGs2STaqEQ9Dt8lWVkZrQEx9ihfmZFVVIKrog== X-Received: by 10.101.73.8 with SMTP id p8mr4344539pgs.106.1510903736124; Thu, 16 Nov 2017 23:28:56 -0800 (PST) Received: from [172.16.166.76] ([101.100.166.67]) by smtp.gmail.com with ESMTPSA id z17sm5621358pfd.124.2017.11.16.23.28.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 23:28:55 -0800 (PST) To: Alexey Melnikov , uta@ietf.org References: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> <5A0E7D70.6060302@isode.com> From: Leif Johansson Message-ID: Date: Fri, 17 Nov 2017 08:28:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <5A0E7D70.6060302@isode.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] Require TLS=NO is very much needed X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 07:28:59 -0000 On 2017-11-17 07:10, Alexey Melnikov wrote: > On 17/11/2017 09:56, Leif Johansson wrote: >> On 2017-11-17 01:01, Viktor Dukhovni wrote: >>> >>> People are forgetting that especially smaller sites >>> that implement STS or DANE don't always have the >>> operational discipline to keep these working. I >>> have considerable evidence to support this claim. >>> >>> A sender with urgent non-sensitive messages may well >>> reasonably want to see the message delivered despite >>> such failures. Indeed, this is typically the right >>> thing to do with failure reports! >>> >>> At present, the sender address I use to send DANE >>> failure notices is statically exempted from enforcing >>> DANE policy (rather than message by message). >>> >> >> The sense of the room in Singapore was that the semantics >> of REQUIRETLS=NO was sufficiently different from REQUIRETLS >> that it would be better to move it to a separate document. >> It was suggested that REQUIRETLS=NO might be better >> represented as a message header even. >> >> In any case it is not clear to me that there is or ever was >> consensus to keep this feature /in its current form/ in the >> REQUIRETLS draft. > > (As a participant) Maybe write a separate draft? Yes I think thats a fine way to resolve this. My sense of the room is that there is wide support for /the idea/ but people feel that the current SMTP-focused draft becomes overly complex by having this feature in there. > >> As always, discussions on the list will determine this but >> barring clear support for keeping the feature in the draft >> we need to find another form for this feature. > From nobody Fri Nov 17 00:00: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 AE63C128E00 for ; Fri, 17 Nov 2017 00:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lr-PVRUU7pzo for ; Fri, 17 Nov 2017 00:00:48 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB20C1243F6 for ; Fri, 17 Nov 2017 00:00:47 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id C21457A3309 for ; Fri, 17 Nov 2017 08:00:46 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Viktor Dukhovni In-Reply-To: Date: Fri, 17 Nov 2017 03:00:45 -0500 Content-Transfer-Encoding: 7bit Reply-To: uta@ietf.org Message-Id: <0620480C-32FB-43B3-8C5A-C4752C1C62E3@dukhovni.org> References: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> <5A0E7D70.6060302@isode.com> To: uta@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [Uta] Require TLS=NO is very much needed X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 08:00:50 -0000 > On Nov 17, 2017, at 2:28 AM, Leif Johansson wrote: > > Yes I think thats a fine way to resolve this. My sense of > the room is that there is wide support for /the idea/ but > people feel that the current SMTP-focused draft becomes > overly complex by having this feature in there. My sense is that it was just a gut reaction from an audience not steeped in the subject matter, based on a perceived difficulty that does not actually exist, because the "NO" case turns out to have no footprint at the ESMTP layer. However, both the "YES" and "NO" cases have closely related and mutually exclusive message header footprints with similar reasons for existence and closely related security considerations. My take is that the vibe from the "room" arrived at a hasty conclusion from false premises, and should be ignored. It was premature, the draft is not yet far enough along to decide the question at hand. First the design space needs to be more clearly understood. -- Viktor. From nobody Fri Nov 17 00:49:47 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAEF9129417 for ; Fri, 17 Nov 2017 00:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 yhZE0fzpxEJk for ; Fri, 17 Nov 2017 00:49:42 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 D899C12944A for ; Fri, 17 Nov 2017 00:49:39 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAH8lDDY013017 for ; Fri, 17 Nov 2017 08:49:37 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=mYKulIaZTe8MNa0cgqULflOQp2TUCJPcw8QNikbip2A=; b=HJ8RcXJDixivGWCYwJSHpcWHlwUX7XLtxcLwkfd0S+1+UzG0Z4B7cITun4SMjPeu16mZ YONhWC1udMLXEit2RHsEQGYpXh75LkmlcgAAAPQoxCtFhcptdPKEfSw2DXkqzUu2iKVw f4/XFH81LAz/lmNwP6KiX5MNhMgdfkOZcC8fzsClkyKFUdlUSzeYBnMSW//fWwwQZO+Q rcZEMC3Ia2qR5B8dRylU1U3XD5nRw6r1aoPMsxkfgn8EnR9JDUdS62E1m4WoIMubc5g/ f2o3Vn/r8dB+qHSBZOiDbQyqSc8EOJTUIbiXyPDkV0QNlp/LS6pv5Q2A3rJiMx3tqwLx pA== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050102.ppops.net-00190b01. with ESMTP id 2e8d567bb5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 17 Nov 2017 08:49:37 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vAH8kFeN029737 for ; Fri, 17 Nov 2017 03:49:37 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2e7p40au0f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 17 Nov 2017 03:49:36 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb6.msg.corp.akamai.com (172.27.123.54) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 17 Nov 2017 00:49:36 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 17 Nov 2017 03:49:35 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Fri, 17 Nov 2017 03:49:35 -0500 From: "Salz, Rich" To: "uta@ietf.org" Thread-Topic: [Uta] Require TLS=NO is very much needed Thread-Index: AQHTXzdPtY8ypNKiO0aRBwBokTD3aaMYJA6AgABG/gCAABXFgIAACOmAgAANpAA= Date: Fri, 17 Nov 2017 08:49:35 +0000 Message-ID: References: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> <5A0E7D70.6060302@isode.com> <0620480C-32FB-43B3-8C5A-C4752C1C62E3@dukhovni.org> In-Reply-To: <0620480C-32FB-43B3-8C5A-C4752C1C62E3@dukhovni.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.147.36] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-17_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711170119 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-17_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711170119 Archived-At: Subject: Re: [Uta] Require TLS=NO is very much needed X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 08:49:46 -0000 4p6iIE15IHRha2UgaXMgdGhhdCB0aGUgdmliZSBmcm9tIHRoZSAicm9vbSIgYXJyaXZlZCBhdCBh IGhhc3R5DQogICAgY29uY2x1c2lvbiBmcm9tIGZhbHNlIHByZW1pc2VzLCBhbmQgc2hvdWxkIGJl IGlnbm9yZWQuICBJdCB3YXMNCiAgICBwcmVtYXR1cmUsIHRoZSBkcmFmdCBpcyBub3QgeWV0IGZh ciBlbm91Z2ggYWxvbmcgdG8gZGVjaWRlIHRoZQ0KICAgIHF1ZXN0aW9uIGF0IGhhbmQuIEZpcnN0 IHRoZSBkZXNpZ24gc3BhY2UgbmVlZHMgdG8gYmUgbW9yZSBjbGVhcmx5DQogICAgdW5kZXJzdG9v ZC4NCg0KSSB3YXMgdGhlcmUgYW5kIEkgZGlzYWdyZWUgd2l0aCB5b3VyIGNoYXJhY3Rlcml6YXRp b24uDQoNCg== From nobody Fri Nov 17 00:50: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 8984012871F for ; Fri, 17 Nov 2017 00:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 aitJ7wIQJORF for ; Fri, 17 Nov 2017 00:50:49 -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 EEB361200CF for ; Fri, 17 Nov 2017 00:50:48 -0800 (PST) Received: from splunge.local (c-24-4-226-141.hsd1.ca.comcast.net [24.4.226.141]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id vAH8oh2w011401 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 17 Nov 2017 00:50:47 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1510908648; bh=hnWZcJVWIvR+VUTlGeR9qgaQUEj8Okg6Eeacht1TRSk=; h=Subject:To:References:From:Date:In-Reply-To; b=aLxLYLzoQLUml9Z14EsUuqFWbwVpwlkrds1X06UuEcqdjMFjSupjuYl3bcNrrgLtq mFARozH+m84Ik7f9cSuluVsR2wgTV29qukovwSbu9NBf6opbAiv72ltxV7eMB+bMAt FFgDGbbyABwj+vBPnjWIUz0ZO61FvVXbVV8V3xuk= To: uta@ietf.org References: <824A749B-AB55-42A6-A387-33F0032DF085@dukhovni.org> From: Jim Fenton Message-ID: <670e259b-6d9b-ba77-9eeb-8e884ddbbece@bluepopcorn.net> Date: Fri, 17 Nov 2017 00:50:37 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <824A749B-AB55-42A6-A387-33F0032DF085@dukhovni.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Uta] TLS report sensitivity X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 08:50:50 -0000 On 11/16/17 3:29 PM, Viktor Dukhovni wrote: > Just listening to the recording of the meeting about sensitivity of > reports. One thing to keep in mind is that reports will often need > to be sent to the very domain which is failing STS validation, so > in fact one may well need to deliver the reports at *reduced* > security, relative to normal mail traffic, so that the reports get > through! > > Therefore, the considerations as such should not mandate strong > transport protection, but rather should only promote avoiding > putting anything in the report that would not already be observed > by a passive wiretap. > We weren't talking about mandating anything, just saying something in the spec to cause people to think about it. It might be the case that some report recipients don't want to use SMTP for their reports at all. From nobody Fri Nov 17 01:02:46 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 657D81293E4 for ; Fri, 17 Nov 2017 01:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 nAis4Sckw6GR for ; Fri, 17 Nov 2017 01:02:40 -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 E042F124D6C for ; Fri, 17 Nov 2017 01:02:40 -0800 (PST) Received: from splunge.local (c-24-4-226-141.hsd1.ca.comcast.net [24.4.226.141]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id vAH92Zra011540 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 17 Nov 2017 01:02:39 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1510909360; bh=XupnwofJ5fH3Ww8EmPh3ymu2+Tpx4hNXOVphQHvmhoo=; h=Subject:To:References:From:Date:In-Reply-To; b=RkA+juchZiK0RwSNuDR7NOeGYV4HUShr+5rNcu7YbTmqNZx9CZUmCepds/A30n0VJ ZyYW4U/7cTY8Llf5PmOc1kLyDZQhFmFd7UN70eWLfSn4oxc1KoCXOuAG6xb7RAxlAZ /IwizJadh1mixL1aj50I04+9TcjZZnvMyzjZQGnA= To: uta@ietf.org References: <144822CE-832F-4FB6-A33D-08DA337F7F8E@dukhovni.org> From: Jim Fenton Message-ID: Date: Fri, 17 Nov 2017 01:02:30 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <144822CE-832F-4FB6-A33D-08DA337F7F8E@dukhovni.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [Uta] REQUIRETLS vs. headers X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 09:02:43 -0000 On 11/16/17 3:49 PM, Viktor Dukhovni wrote: > 1. I agree that REQUIRETLS=3DNO needs a header so it can be > tunnelled via an "agnostic" MTA. > > 2. However, even REQUIRETLS=3DYES needs a header, because: > > a. Within an MTA a message may make multiple internal > hops, for example processing via a loopback SMTP > proxy that does virus scanning, or forwarding via > a spam-scanning appliance that is statically configured > to always do TLS both upstream and downstream, but does > not support REQUIRETLS=3DYES explicitly. > > b. Messages may get filtered via procmail and the like > and then forwarded, and again the delivery channel > has no means to preserve REQUIRETLS=3DYES except via a > header. Let me think about the procmail->forward case a bit. Is that considered forwarding of the same message or origination of a new one (same question for mailing lists)? We could define a header field that is consulted when a message is originated (transitions from something else to SMTP) to set the REQUIRETLS option for that first hop. I would want it to be clear that for all other hops, the REQUIRETLS option on MAIL FROM is what gets used.= > > 3. Therefore, REQUIRETLS will need a header for both YES and > NO, but the YES case will also want to see a "REQUIRETLS" > in the EHLO response of a remote MTA, so it can commit to > honouring the extension. > Having the NO option only be a header field simplifies things. It was making a mess of negotiation of the REQUIRETLS SMTP extension having REQUIRETLS=3DNO not actually require REQUIRETLS to be negotiated. But I still see these as two separate features, REQUIRETLS and IgnoreTLSPolicy. I can picture that there would be implementations of IgnoreTLSPolicy that might not include REQUIRETLS and vice versa. That's why I see them as separate documents. -Jim From nobody Fri Nov 17 01:08:30 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 06147126CF6 for ; Fri, 17 Nov 2017 01:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_qUSJvOh6po for ; Fri, 17 Nov 2017 01:08:28 -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 98C771200CF for ; Fri, 17 Nov 2017 01:08:28 -0800 (PST) Received: from splunge.local (c-24-4-226-141.hsd1.ca.comcast.net [24.4.226.141]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id vAH98OHf011581 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 17 Nov 2017 01:08:27 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1510909708; bh=N796mzgqDrVBCugKg2Pzj87dtdfisggBLbd47PVCP+4=; h=Subject:To:References:From:Date:In-Reply-To; b=LoPId6IdU9KauLbUFwi88bp0Cw5cmHgS1AQ54Ab07CnVKqIvur2j3381GnVELjjR8 V4BXT9JfHXdTkkrVwHnv3Sekaev5T3B13xvk6ugCbPW/gRYmx9zlrAEfxz5fM6UAjl 1UPqX2g4zVWTapI6ZFjgmbe+f5WzXRCqe4Pj4x40= To: uta@ietf.org References: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> <7FD24C09-99A6-4847-BCE7-4455F62188FC@dukhovni.org> <3be212da-54bf-faf4-baa6-efd05fb5cef0@mnt.se> From: Jim Fenton Message-ID: <6138741a-51c8-67c6-f465-7f1beddd4a01@bluepopcorn.net> Date: Fri, 17 Nov 2017 01:08:18 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <3be212da-54bf-faf4-baa6-efd05fb5cef0@mnt.se> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Uta] Require TLS=NO is very much needed X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 09:08:30 -0000 On 11/16/17 7:06 PM, Leif Johansson wrote: > > On 2017-11-17 03:55, Viktor Dukhovni wrote: >> >>> On Nov 16, 2017, at 8:56 PM, Leif Johansson wrote: >>> >>> The sense of the room in Singapore was that the semantics >>> of REQUIRETLS=NO was sufficiently different from REQUIRETLS >>> that it would be better to move it to a separate document. >>> It was suggested that REQUIRETLS=NO might be better >>> represented as a message header even. >> The room was not populated by enough folks with deep operational >> experience in email, especially operational experience with >> email transport security policy. > I will set this aside for now. I encourage everyone to express > their opinions on this topic. Right now the consensus is not > clear either way. (as an individual, not document editor): As I mentioned in another thread, I see REQUIRETLS and the "REQUIRETLS=NO" (but under a different name, as a header field) as being different enough and implemented independently of each other that the latter should be a separate draft. -Jim From nobody Fri Nov 17 01:15:37 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 9E208126CF6 for ; Fri, 17 Nov 2017 01:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dozJ7PZ8bG2b for ; Fri, 17 Nov 2017 01:15:34 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BE0B1267BB for ; Fri, 17 Nov 2017 01:15:34 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 57BB47A3309 for ; Fri, 17 Nov 2017 09:15:33 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Viktor Dukhovni In-Reply-To: Date: Fri, 17 Nov 2017 04:15:32 -0500 Content-Transfer-Encoding: 7bit Reply-To: uta@ietf.org Message-Id: <3C48EC8E-FA2E-4E16-9C02-63ED5E4C46A1@dukhovni.org> References: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> <5A0E7D70.6060302@isode.com> <0620480C-32FB-43B3-8C5A-C4752C1C62E3@dukhovni.org> To: uta@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [Uta] Require TLS=NO is very much needed X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 09:15:35 -0000 > On Nov 17, 2017, at 3:49 AM, Salz, Rich wrote: > > I was there and I disagree with your characterization. I watched the entire session after the fact, I stand by my assessment that the conclusions were premature. I've been focused on this space for ~15 years now, so I am probably not making stuff up... We should also keep in mind that as DANE and STS gain more adoption, it will be the "NO" case that will be far more useful to the majority of users. The "YES" case will see very little use. In particular email reports from the "tlsrpt" draft, will need "NO", to make sure they get to the problem destination, despite their expired or otherwise invalid certificates, disabled STARTTLS, ... -- Viktor. From nobody Fri Nov 17 01:40: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 8C59C127868 for ; Fri, 17 Nov 2017 01:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULJYa7K3p0ft for ; Fri, 17 Nov 2017 01:40:16 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 893BE124D6C for ; Fri, 17 Nov 2017 01:40:16 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id B3CF17A3309 for ; Fri, 17 Nov 2017 09:40:15 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Viktor Dukhovni In-Reply-To: Date: Fri, 17 Nov 2017 04:40:14 -0500 Content-Transfer-Encoding: 7bit Reply-To: uta@ietf.org Message-Id: <7AB4A530-E15C-465D-A84E-6B5D28320030@dukhovni.org> References: <144822CE-832F-4FB6-A33D-08DA337F7F8E@dukhovni.org> To: uta@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [Uta] REQUIRETLS vs. headers X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 09:40:18 -0000 > On Nov 17, 2017, at 4:02 AM, Jim Fenton wrote: > >> b. Messages may get filtered via procmail and the like >> and then forwarded, and again the delivery channel >> has no means to preserve REQUIRETLS=YES except via a >> header. > > Let me think about the procmail->forward case a bit. Is that considered > forwarding of the same message or origination of a new one (same > question for mailing lists)? Typical (or at least common) use of procmail and similar tools is forwarding some or all mail to another system where the user will actually access the email, so if TLS is be used at each hop from sender's MUA to the intended recipient's mailbox, it needs to be enable to tunnel through the occasional non-SMTP hop, or a secure SMTP hop that does not (explicitly) support REQUIRETLS. For example, at my place of work we have SMTP spam-filtering appliances that receive all mail over TLS, scan it, and re-inject non-spam back into the mailstream via authenticated TLS. However, they don't support REQUIRETLS, so the ESMTP signal will be lost in transit through these devices. However a header will make it through, and the mail can then continue on its way with TLS enforced again downstream. > We could define a header field that is consulted when a message is > originated (transitions from something else to SMTP) to set the > REQUIRETLS option for that first hop. I would want it to be clear that > for all other hops, the REQUIRETLS option on MAIL FROM is what gets used. Yes, the ESMTP handshake will be required on all SMTP hops, except for any where local configuration statically asserts that the nexthop preserves REQUIRETLS passively (via the header as above, because once email leaves the REQUIRETLS-agnostic handler, it re-enters the mail stream in a way that revives REQUIRETLS from the header). This may mean that mailing list software will need to strip REQUIRETLS, this can be done by stripping the header at the MTA before giving it to the list manager. Users resending unencapsulated messages (mutt's "bounce" feature, or Mail.app's "Redirect") may (bug or feature?) then also trigger REQUIRETLS when the message is resent. One way to deal with that is to look at "Resent-Require-TLS:" rather than "Require-TLS:" when a message has "Resent-From:" or "Resent-To:" headers. One might similarly look for "List-Require-TLS:" when a message has "List-*" headers. So this requires a bit more care. >> 3. Therefore, REQUIRETLS will need a header for both YES and >> NO, but the YES case will also want to see a "REQUIRETLS" >> in the EHLO response of a remote MTA, so it can commit to >> honouring the extension. >> > Having the NO option only be a header field simplifies things. It was > making a mess of negotiation of the REQUIRETLS SMTP extension having > REQUIRETLS=NO not actually require REQUIRETLS to be negotiated. Naturally. > But I still see these as two separate features, REQUIRETLS and > IgnoreTLSPolicy. I can picture that there would be implementations of > IgnoreTLSPolicy that might not include REQUIRETLS and vice versa. That's > why I see them as separate documents. The possibility of partial support does not make a strong case for separate specification, folks have implemented parts of specifications before. The overlaps of the designs, is more compelling. Furthermore, the "NO" case will be by far the more frequently used feature. If we want STS and DANE to not be crippled by service providers with downgrade resistant enforcement on by default, we need to give users an opt-out mechanism. There'll be enough operational errors to require occasional work-arounds by senders. -- Viktor. From nobody Fri Nov 17 01:44:03 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8826A1293E4 for ; Fri, 17 Nov 2017 01:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8q_N7zWIUNN for ; Fri, 17 Nov 2017 01:43:59 -0800 (PST) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (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 36D76124D6C for ; Fri, 17 Nov 2017 01:43:59 -0800 (PST) Received: by mail-io0-x244.google.com with SMTP id g73so8138881ioj.8 for ; Fri, 17 Nov 2017 01:43:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sgoRCcLUL6VkLqLrncctd2grnoG5P3j71gxWLg+K9uo=; b=rEgCSXVOpeQ7KGyrFQ1rCB5tmBgoPVqT/3qodbcCocdbptGmdVdvfntarVgRozLmMh W9ghlxv4jkHT6PoqD32No05utF9HZAfufgBDk1U2Sh+ZpOOBZvenhl2L/xvh5UUC/l9/ i+6O1yS/Dz1WoFsyL+RpQVww7VC6GMeOSE/9R9AjAHNN85fuUiat4Kw93JBhxH3ouDhW WGk6RFT4KcnpNfa/265BjvBOVcan9BeaJihfq6wjO9Qi36lk06qBNJkjXXDvczqBjyIe mrkoWKfVXwwsk4g1f7+RAN+6tRZ/rfY8t4o+hcT2Ea7WD9/+UKIW213THSno2dX/UT32 8nSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sgoRCcLUL6VkLqLrncctd2grnoG5P3j71gxWLg+K9uo=; b=rJDUSfLq4CqdDtrFRYdLvo+MnBd3xQIgCQz/qbFyfCo7VmjgiQ4W7ee/FYM7PIT5lj TMyqTj048I0Se3bZPpEwK8W1qar5u3/wqeJw5Mlpss9/o4Y+32JHdI7c1Sag1gcnKSQR ExDbzsf5jow1cMNl5QfaVOjVj1n5sXBkCn0HiIQAxcnt9soZjHI/rxAbBA8g03opQbt6 oLuxXuIPhwCLkcnSvA2X40EPvnWgh39G5ubulVUR0wiW5qRkqBYBbtWrGvKGJuX/nPji g22ZwHTULgkmYa+Ar5pjE/klX9lIz8GjtpOYW+mNYH7MOfl192hymKvN9iAvhFeA1xJZ 8Q4A== X-Gm-Message-State: AJaThX6VCsxSjeSXielY3chhE8ey4hbaC2UeCcDLEo3Sqv4uKY5Sv2D9 vUWMXxUat86YTAXRYZ4l4aY/pHtzYToVUDLA4X+dB6f0 X-Google-Smtp-Source: AGs4zMZmg2KdgblIZlgOR4IcvSgD6j3Oh4VqsJnAZivfYP8sP5nZ57GJfjuKcFxQvJgh6F6cyJEGwkWzXzZEwnTQ5Tc= X-Received: by 10.107.6.81 with SMTP id 78mr2076009iog.204.1510911838183; Fri, 17 Nov 2017 01:43:58 -0800 (PST) MIME-Version: 1.0 References: <824A749B-AB55-42A6-A387-33F0032DF085@dukhovni.org> <670e259b-6d9b-ba77-9eeb-8e884ddbbece@bluepopcorn.net> In-Reply-To: <670e259b-6d9b-ba77-9eeb-8e884ddbbece@bluepopcorn.net> From: Daniel Margolis Date: Fri, 17 Nov 2017 09:43:42 +0000 Message-ID: To: Jim Fenton Cc: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113ee4586f4a1e055e2a93bc" Archived-At: Subject: Re: [Uta] TLS report sensitivity X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 09:44:01 -0000 --001a113ee4586f4a1e055e2a93bc Content-Type: multipart/alternative; boundary="001a113ee458678606055e2a9369" --001a113ee458678606055e2a9369 Content-Type: text/plain; charset="UTF-8" Yeah, I think this is why we support HTTPS delivery. :) It's all a generally fair point. One comment I had made in the Jabber was that in general a MITM who can observe a lot of traffic over the reporting period (e.g. 24h) can probably infer passively most of the details of the report itself. So the very attack that allows one to read a report sent over plaintext or unauthenticated SMTP, extended for a mere day, allows one to generate one's own report. So there's some sensitivity, and HTTPS is a useful fallback also in case SMTP delivery itself simply doesn't work, but I am not too hung up on this. On Fri, Nov 17, 2017 at 9:50 AM Jim Fenton wrote: > On 11/16/17 3:29 PM, Viktor Dukhovni wrote: > > Just listening to the recording of the meeting about sensitivity of > > reports. One thing to keep in mind is that reports will often need > > to be sent to the very domain which is failing STS validation, so > > in fact one may well need to deliver the reports at *reduced* > > security, relative to normal mail traffic, so that the reports get > > through! > > > > Therefore, the considerations as such should not mandate strong > > transport protection, but rather should only promote avoiding > > putting anything in the report that would not already be observed > > by a passive wiretap. > > > We weren't talking about mandating anything, just saying something in > the spec to cause people to think about it. It might be the case that > some report recipients don't want to use SMTP for their reports at all. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a113ee458678606055e2a9369 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, I think this is why we support HTTPS delivery. :)=C2= =A0

It's all a generally fair point. One comment I h= ad made in the Jabber was that in general a MITM who can observe a lot of t= raffic over the reporting period (e.g. 24h) can probably infer passively mo= st of the details of the report itself. So the very attack that allows one = to read a report sent over plaintext or unauthenticated SMTP, extended for = a mere day, allows one to generate one's own report.=C2=A0
So there's some sensitivity, and HTTPS is a useful fallbac= k also in case SMTP delivery itself simply doesn't work, but I am not t= oo hung up on this.=C2=A0


On Fri, Nov 17, 2017 at 9:50 AM Jim Fenton <fenton@bluepopcorn.net> wrote:
=
On 11/16/17 3:29 PM, Viktor Dukhovni wrote:<= br> > Just listening to the recording of the meeting about sensitivity of > reports.=C2=A0 One thing to keep in mind is that reports will often ne= ed
> to be sent to the very domain which is failing STS validation, so
> in fact one may well need to deliver the reports at *reduced*
> security, relative to normal mail traffic, so that the reports get
> through!
>
> Therefore, the considerations as such should not mandate strong
> transport protection, but rather should only promote avoiding
> putting anything in the report that would not already be observed
> by a passive wiretap.
>
We weren't talking about mandating anything, just saying something in the spec to cause people to think about it. It might be the case that
some report recipients don't want to use SMTP for their reports at all.=

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
--001a113ee458678606055e2a9369-- --001a113ee4586f4a1e055e2a93bc 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMYvQlQqbPmlmUoZynMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODE4NDIxNloXDTE4MDMx NzE4NDIxNlowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDI3sfyM5pHCY0cDNbbiDAn17uPa3PG0G98FftCEkej/WTh RcWVnnX7STqcEnQwK7z8r8SckwfHWqDMNnb6PMXVZUOCv9iewPrxXlQfmFvDQQnRXbUKp7WgUjzm 5v1BIs/mIvqkrBsiPJLvNbO8b7BxewUnTP24wHaCYvlVFXd/A+hbq5CJciR230oH0bmB6zMlpxQe 45PlPkEkLb2cUaad14IV2ulfK8pcsLLM+NntC9jxKVAp3GCSAp6gjOmCJdCB4YlyC943ej9IoryJ fOVpmm6IOchzDTJH/rgPUWbQnZFhVw4V1EkHfrYugci2Up30l4SsMieOPgfd6oAwDzlbAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFFQQtjTE3yoZgnE8infGLj+S7TiRMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQBpExGZx6F4 zM7Y/n7mnIsXl81PZas0VWUjE0MMdlX+FBxLg6+tSAZL+pi0i/iRb9bNg3KLqo0mpN2cnHa0Cyeo 9+DUJYdHtitY7O0oDfN6qsTLKkI2ff4VhVRahJMa9RlBHuiJa09Tlu/d1BqqjF8Vlf+1ygExN6dx PL95kbdwYM+0GILX+rt4okmVWgj4ol9JgBcQG6MA6rQvuoJHpfxv0I6yNXMMe3R86vfnz5XFHrX1 RfudaTWxM29kR44KxN19+TtVs2HTb/YAgGyyI3sxsX/keInYwKOZEpX3PwXn30CjjzPDjXR9+Zye K9iJUpsLFz8YJkPSc2e90JrrGAFuMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM YvQlQqbPmlmUoZynMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCdIHIWhpZyA4KO yUpFQzA3IcM7FbD/YAdOVKb+3UXC9TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzExMTcwOTQzNThaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAYGuHclGf+7Wnjzkf7P0zv0IFFNOIoByx NZ2hhYVRqan+lScmdP0OzIoXg9kjdsn3meyGsEG8GeUroNHOTUTUDOVzxJA/ChDgHzjAleDokdkq 6UFZIK/Zg82qYh5+knTriV0g8grL9pmn2UlUzvIJ7qniJkOalAAFDTntQ132PPA/9qlZv6rMxfvF 0eeP3QiBsTqzbzX5Q15BUsyravBGRcInhiCfrUT4Oy5VCwyyGQq45ZOeZaBhhrOgOSChWJforPXB AnWshWiA5zamv4PRLefNzTDH6hgwKab6SWD1tz+gvyGMHfHp30yeffCPXT5jBir70VspigN5GAUc XSjCzQ== --001a113ee4586f4a1e055e2a93bc-- From nobody Fri Nov 17 01:48:47 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5843E128896 for ; Fri, 17 Nov 2017 01:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJooMw1R18cI for ; Fri, 17 Nov 2017 01:48:44 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F25127333 for ; Fri, 17 Nov 2017 01:48:44 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 12CF57A3309 for ; Fri, 17 Nov 2017 09:48:44 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Viktor Dukhovni In-Reply-To: <670e259b-6d9b-ba77-9eeb-8e884ddbbece@bluepopcorn.net> Date: Fri, 17 Nov 2017 04:48:43 -0500 Content-Transfer-Encoding: 7bit Reply-To: uta@ietf.org Message-Id: References: <824A749B-AB55-42A6-A387-33F0032DF085@dukhovni.org> <670e259b-6d9b-ba77-9eeb-8e884ddbbece@bluepopcorn.net> To: uta@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [Uta] TLS report sensitivity X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 09:48:46 -0000 > On Nov 17, 2017, at 3:50 AM, Jim Fenton wrote: > > We weren't talking about mandating anything, just saying something in > the spec to cause people to think about it. It might be the case that > some report recipients don't want to use SMTP for their reports at all. Sure some recipients may prefer HTTPS, but keep in mind that the sender does not get much choice, the "rua" is chosen by the receiving system. So the sender may have to send at least some reports via email. Furthermore, email has the advantage that sending systems already support queueing and retries, while with HTTPS, one would have to build some new system to increase the odds of "eventual" delivery of the report. Many domains (for better or worse) will have the same wildcard certificate for HTTPS and SMTP, and will have a non-working report HTTPS URI at the same time that their MTAs starts having problems. So email (with REQUIRETLS=NO) has advantages over HTTPS for report delivery. -- Viktor. From nobody Fri Nov 17 02:01:33 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98FB127333 for ; Fri, 17 Nov 2017 02:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.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 Yd3JsdI3IaPx for ; Fri, 17 Nov 2017 02:01:30 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40DC3120724 for ; Fri, 17 Nov 2017 02:01:29 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id m88so1596694pfi.9 for ; Fri, 17 Nov 2017 02:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=pGW2ErdPWbAfd1ply+QKhj2XWN2hFvVX6gQalNZKI7U=; b=pq9OqxVhf9+HRWjVqRbbz1RWX3/h1fRjWHQQ2+5sT+P6wo0RZEEs5ZDUYuRPW5I77X lkbdC0IoT2j55O94LWQ2sbKq7Q1n8Uvwrj0HDsGc1lFodFDG3f37CcyLkQABmcvi9wrc nwnM4nRO/n+jsk671EekfAkapXFtpycQ4wGANMD32I4vluBdFI1qm/4Yu919OtpkOMjr cgFohBp3XHbHatqOoxCt6f3NJtA2L7NOeTjRBMdJPHpGXQPvezoSbY12J26NEwJ3CHNH t16wMFY8VUCH9rJjSM9hwJ2nokrEReICoKWpabmFVmefMp6FlmIgAxKJlQaQHXo1etmd 6NiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pGW2ErdPWbAfd1ply+QKhj2XWN2hFvVX6gQalNZKI7U=; b=LlD0dJvARIip/xD4nvaorPwHOo21Wc+9d3vNR1GWcpJ/6Tujnj4iAp57jgvXAPSJ+E gTybbHpUSjqmmMCI/0IPakHMVV9HcmljTrtnQ7ZNstP3IObgT1w0+05g2pX6S+FSMVCC JY65JgmqsEVDQuEWOARXRmFoikcgRXRftgZzDQun9/earMkx6IeHcylFGnn7IW46MojK H9flwQKAsNStwB5ctZwvDo8oAZvh7F/9YYhKTBOL0irTt3LTljr2M82+IasvhnnerrV4 7AjNVGZYw8jc6xvun98IdQLxToksTTihJQ2fEgTxNIvmMYiZYq+mVlxdg27URc1Re488 Xfpg== X-Gm-Message-State: AJaThX5enUqyYpPG131mZb43AQkNuRAF3CVxHxw6/LEctsmIzOa1eeSW c1ZyZSBl/S3mxLE17UHjUaJ8aMhQ09A= X-Google-Smtp-Source: AGs4zMbuSJWWrLrNg9umg2HZ+spv1K0rijGBkYoxoMHYH/iuV3WXpwu0FWb0DP7F2pl5EWNdHbyZTw== X-Received: by 10.84.210.66 with SMTP id z60mr4763515plh.168.1510912888663; Fri, 17 Nov 2017 02:01:28 -0800 (PST) Received: from [172.16.166.76] ([101.100.166.67]) by smtp.gmail.com with ESMTPSA id l22sm8711309pfk.45.2017.11.17.02.01.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Nov 2017 02:01:28 -0800 (PST) To: uta@ietf.org References: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> <5A0E7D70.6060302@isode.com> <0620480C-32FB-43B3-8C5A-C4752C1C62E3@dukhovni.org> From: Leif Johansson Message-ID: Date: Fri, 17 Nov 2017 11:01:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Uta] Require TLS=NO is very much needed X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 10:01:32 -0000 On 2017-11-17 09:49, Salz, Rich wrote: > ➢ My take is that the vibe from the "room" arrived at a hasty > conclusion from false premises, and should be ignored. It was > premature, the draft is not yet far enough along to decide the > question at hand. First the design space needs to be more clearly > understood. > > I was there and I disagree with your characterization. Yeah I also disagree (as an individual). The person who made the comment is the same person who first suggested the feature be added. Cheers Leif From nobody Fri Nov 17 02:06: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 B64311293E0 for ; Fri, 17 Nov 2017 02:06:07 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.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 37Ro5aJUv_0M for ; Fri, 17 Nov 2017 02:06:06 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55E35120724 for ; Fri, 17 Nov 2017 02:06:06 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id x7so1626770pfa.1 for ; Fri, 17 Nov 2017 02:06:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=RiAwjsb1s3gUPzarQrsltAIZTjbYZ3b1GvtbwebU++U=; b=RHRf6jyZrnRen2iO0JmsgqLOzDdX0UBNVJWjAd5PnAkAc2iavUZAH7f2hivGV7+RFa zzWHA1+UKuneTM/57hUbBgCxQetaF8bqais0MsJC3Vs2Uiefp2HYTH8Yw8AA4flGIBrL 0QXS5No+MAzwrK05s6HzB9RTaBMNMYkjd4W55IvW5aOJJCJlW/4MXgm/KJDZS06Del/G 5SyEVGEzt3zO001DVI/HAEJgbTlZb0W7P06XY88khnlHJM4t30un9In5KWSPxQSOWvHp PbR4ikcgNE1nDKAASsSDcCaRauAhThSzLI7pdNKqrfKWyAIZcBpX4cL+/oYSt25otyqa tnuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RiAwjsb1s3gUPzarQrsltAIZTjbYZ3b1GvtbwebU++U=; b=Q1WnlslyS4TiJTRRQwsqJXt4ZuwB8FHFSoQOH67qdnSOfmraGw31jVCUXgupE0psv4 h9sryHtZiqXCMsmScZXZ/MvYzYKZgiFnDTQH1JriOOQPfEcBSAStYJEhLTc52rtskn3P VeqSZuxLam7gnys1wvQhsnnYxOXnCyE4991pFwsDwh+gAOmHR5SHv/9Of8Pl76plkoXg QMy7lpJdJ0ZMqsQ1drIuLSCsjtRh9GFFSKrhrVvAnqZ2AVohsRnIzxO5i2iiTjV2S9E+ m+zU05Jtlw53Ytwp+eWaM+GQuzPA1BPovZINhS2RREE+8a7BRfkRw2nRPicCI6GUsKJX R27g== X-Gm-Message-State: AJaThX4qRbSGo8yyt97hrOd+liZsHSkKDNqFbCxGyx+GUG2fbPQ7BX16 njezCzvZ2hF5YqDrMII8kF3nws8WONU= X-Google-Smtp-Source: AGs4zMYqn2S7uqe7Pmk+MO5oLmzIdxnBOUHdj7skO2vjCrTsJazfvGuVQ+JIbWx1AovEwMz8evhONg== X-Received: by 10.84.138.1 with SMTP id 1mr4677029plo.156.1510913165664; Fri, 17 Nov 2017 02:06:05 -0800 (PST) Received: from [172.16.166.76] ([101.100.166.67]) by smtp.gmail.com with ESMTPSA id m6sm6957746pfm.121.2017.11.17.02.06.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Nov 2017 02:06:04 -0800 (PST) To: uta@ietf.org References: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> <5A0E7D70.6060302@isode.com> <0620480C-32FB-43B3-8C5A-C4752C1C62E3@dukhovni.org> <3C48EC8E-FA2E-4E16-9C02-63ED5E4C46A1@dukhovni.org> From: Leif Johansson Message-ID: <53c5d4e8-bbfa-fb1f-639b-23ceaedfd74b@sunet.se> Date: Fri, 17 Nov 2017 11:06:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <3C48EC8E-FA2E-4E16-9C02-63ED5E4C46A1@dukhovni.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] Require TLS=NO is very much needed X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 10:06:08 -0000 On 2017-11-17 10:15, Viktor Dukhovni wrote: > > >> On Nov 17, 2017, at 3:49 AM, Salz, Rich wrote: >> >> I was there and I disagree with your characterization. > > I watched the entire session after the fact, I stand by my > assessment that the conclusions were premature. I've been > focused on this space for ~15 years now, so I am probably > not making stuff up.. I feel a certain level of frustration from you Victor but let me assure you you have no reason to feel that way - as usual in the IETF the only decisions that matter are the ones made on the list. Let me suggest that we focus less on who said what and why and instead focus on the issue at hand: should we split the draft or not! As chair I want to encourage everyone to present their views regardless of how many years they may have under their belt. Cheers Leif From nobody Fri Nov 17 03:24:20 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 70D76127977 for ; Fri, 17 Nov 2017 03:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYmBjoVfnuGm for ; Fri, 17 Nov 2017 03:24:17 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D758B1275C5 for ; Fri, 17 Nov 2017 03:24:17 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 2714F7A3309 for ; Fri, 17 Nov 2017 11:24:17 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Viktor Dukhovni In-Reply-To: Date: Fri, 17 Nov 2017 06:24:16 -0500 Content-Transfer-Encoding: 7bit Reply-To: uta@ietf.org Message-Id: <326E7AA1-6DCA-4376-ACCD-7749CD9ACD30@dukhovni.org> References: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> <5A0E7D70.6060302@isode.com> <0620480C-32FB-43B3-8C5A-C4752C1C62E3@dukhovni.org> To: uta@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [Uta] Require TLS=NO is very much needed X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 11:24:19 -0000 > On Nov 17, 2017, at 5:01 AM, Leif Johansson wrote: > > Yeah I also disagree (as an individual). The person who made the > comment is the same person who first suggested the feature be added. FWIW, my recollection is that I was the who suggested the need for the "NO" case when Jim first presented the idea REQUIRETLS (in Berlin IIRC). But of course who suggested it first should not grant any special privilege to have work in that direction stop or continue. -- Viktor. From nobody Fri Nov 17 06:20:57 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 A5A42120727 for ; Fri, 17 Nov 2017 06:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 uKftVqRV3QmZ for ; Fri, 17 Nov 2017 06:20:54 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BF56126CB6 for ; Fri, 17 Nov 2017 06:20:54 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QLKSZBTR8W00MJHV@mauve.mrochek.com> for uta@ietf.org; Fri, 17 Nov 2017 06:15:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1510928150; bh=QBcbBo96YM6NS/IT+ycNekQrjcqbib+whTQ8xlLoZMs=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=l3JCF4uLfWDDYSQW2E7dsD8zi2R4hUkyxE0xoAykNAdE4fk5VZqxOGJpLz2loa+rW pzOj26+tbt96tVHNlsWw4T5vfh78r2mB01NkYu87zH2J1aJ20jnfUDkQYRbE6jDrQm ZNnBH8XqqmIQ0PyIXKv5OhcuIifZknARQqh8QmtY= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QLJV50XY9S00004G@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for uta@ietf.org; Fri, 17 Nov 2017 06:15:49 -0800 (PST) From: ned+uta@mrochek.com Cc: uta@ietf.org Message-id: <01QLKSZAKXVU00004G@mauve.mrochek.com> Date: Fri, 17 Nov 2017 06:12:41 -0800 (PST) In-reply-to: "Your message dated Fri, 17 Nov 2017 02:01:42 -0500" References: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> <5A0E7D70.6060302@isode.com> To: Viktor Dukhovni Archived-At: Subject: Re: [Uta] Require TLS=NO is very much needed X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 14:20:56 -0000 > The obstacle in the current draft was that the "NO" > case appeared to over-complicate the ESMTP extension, > but it is now clear that the "NO" case need not use > the "ESMTP" extension and should be carried exclusively > via a header. However, since the same TLS policy > header is also needed for the "YES" case (but with > a slightly different payload), the same draft should > specify both. We should not force these to be separate > just to hurry the "YES" case out the door. Let's do > this right. I'm with Viktor on this one. Having two documents where only one is needed will not only create redundant material that needs to be kept in sync, it's more stuff people implementing this have to read. This is already too complicated and spread over too many specifications. Let's please not make it more so. Ned From nobody Fri Nov 17 06:23:46 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 AEE08120727 for ; Fri, 17 Nov 2017 06:23:44 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.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 3eMr9c0VXv9W for ; Fri, 17 Nov 2017 06:23:42 -0800 (PST) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e: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 CA535126B7F for ; Fri, 17 Nov 2017 06:23:42 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id o7so2074439pgc.4 for ; Fri, 17 Nov 2017 06:23:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=fsihz5mLdLyckP9qeXzqJaTMiTYAfW9Yp2WT+8sXz6I=; b=Fl4w1fTtLLftUpMs2MZ2yVs5PzGcXOZcbN0F7X2Pe9Ju+PF1nPpAxBLW+xtqRZPnWa 7ORLPfFLkBasMe5FLuKE+a74yoFlRwa2MeaBgiAjGNZ9nCxy2BjJw4b859Fy730oq45u 1EO1AjrStfbyfZccwVDy8bXlQYEvnTkOab0YAsZUFUMCygLJGHI0HT4vVvvc27uQfdJ/ 9w9COF7fdl5Cvfyetqcd9vu6AN0G0OaEzblLftGsoYc/4XlPoBbcH6ZYnsoOG9UBmIVT eN9LR5d9iZpLcnnacSXXArYD0QgNqV390T1SD28chPXlxaE5SpsvKOYwhW9ZnyCppBKR pwFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fsihz5mLdLyckP9qeXzqJaTMiTYAfW9Yp2WT+8sXz6I=; b=Vo8KYj5R2JfNnK/tEbfeJAbReAaL/hHaqfY3HzznhEAvDrZuUeEZwRsiaI+Yq9nt0Z /T/ynQdTzcOBo5zNSX6E159DS3t06iTmd/MgjJZxJpd43EGnjX4XirwX47NcmrrtMV7A fuDv7Z1MIFE+GQgLMdO2jXWG4Xu4Y6ohS+H1kn9wkciIsHAOWw5E5F/q8TXPUJjz+QoL nYFJCEBHZBTmvvOknkCV37QgNtsSvwP83X2vOfgQ3rjhAknCoJfQa2rVjoLnZIOrwUjL 4uSOsWwwjRv4ZEG9xMHgt842DuySTZ/RqN5/ve178T+/UOU5UtDukdwXQ1fMIEpsFPZn 7mfQ== X-Gm-Message-State: AJaThX6kA01RjLUg9uZTMUo2XFaVo4ZckFgXhic/KBoDQ3uMoVWJsFKw 2AHww/FNXLRCoBOxFZ5CrTlnZIVmRyY= X-Google-Smtp-Source: AGs4zMaSntDYOS8b4YM3o1AFAJ2+xlkMfgyuhHuLpoWHTD2eoc7Po5hI5ToQFCAy5Szifk+wq4RKeQ== X-Received: by 10.159.253.68 with SMTP id b4mr5531391plx.113.1510928622031; Fri, 17 Nov 2017 06:23:42 -0800 (PST) Received: from [172.16.166.76] ([101.100.166.67]) by smtp.gmail.com with ESMTPSA id x1sm8855798pfh.113.2017.11.17.06.23.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Nov 2017 06:23:41 -0800 (PST) To: uta@ietf.org References: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> <5A0E7D70.6060302@isode.com> <0620480C-32FB-43B3-8C5A-C4752C1C62E3@dukhovni.org> <326E7AA1-6DCA-4376-ACCD-7749CD9ACD30@dukhovni.org> From: Leif Johansson Message-ID: Date: Fri, 17 Nov 2017 15:23:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <326E7AA1-6DCA-4376-ACCD-7749CD9ACD30@dukhovni.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] Require TLS=NO is very much needed X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 14:23:44 -0000 On 2017-11-17 12:24, Viktor Dukhovni wrote: > >> On Nov 17, 2017, at 5:01 AM, Leif Johansson wrote: >> >> Yeah I also disagree (as an individual). The person who made the >> comment is the same person who first suggested the feature be added. > > FWIW, my recollection is that I was the who suggested the need for the > "NO" case when Jim first presented the idea REQUIRETLS (in Berlin IIRC). > But of course who suggested it first should not grant any special > privilege to have work in that direction stop or continue. > I meant that as an indication that the person probably know what they were talking about. From nobody Fri Nov 17 06:28:48 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039AD126DCA for ; Fri, 17 Nov 2017 06:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ySSJP-uA875H for ; Fri, 17 Nov 2017 06:28:46 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BC9A126CB6 for ; Fri, 17 Nov 2017 06:28:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2271; q=dns/txt; s=iport; t=1510928926; x=1512138526; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=eMFMjB77zUtTDfJEFlDnOwEdorBp5ldRAlZZ/PvOZP8=; b=K6IpfQ2bEE1r6W54hcSfFuXSeaHwW3hDRLOG/bkmS6uF2Pe3nx5dCM5n 4uKT7Xh6qbTzGHxwK00pKsh8TIOG9yrJZtEsV/4j38XYsH2anncytQ+/w JP9wCpB1ZW0GORIVKsVZNftuHwxpHg2/yLC0SHJKPnkVotwhNrwsY2rWP E=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7AQAR8Q5a/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUOhCaLE5AIJphzBwOFOwKFKRUBAQEBAQEBAQFrKIUfAQUjZgs?= =?us-ascii?q?YKgICVwYBDAgBAYohqhiCJ4sBAQEBAQEBBAEBAQEBAQESD4M0hW4LgneIMIJjB?= =?us-ascii?q?aI+hEmCKI4bgX2KB4dIljKBOjUjgXQ0IQgdFYMuhF9AiwwBAQE?= X-IronPort-AV: E=Sophos;i="5.44,409,1505779200"; d="asc'?scan'208";a="280090" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Nov 2017 14:28:44 +0000 Received: from [10.61.227.56] ([10.61.227.56]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vAHESh1v024081; Fri, 17 Nov 2017 14:28:43 GMT To: uta@ietf.org, Viktor Dukhovni References: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> <7FD24C09-99A6-4847-BCE7-4455F62188FC@dukhovni.org> From: Eliot Lear Message-ID: <5d638100-295a-8b05-7958-470abaaf3ac3@cisco.com> Date: Fri, 17 Nov 2017 15:28:23 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <7FD24C09-99A6-4847-BCE7-4455F62188FC@dukhovni.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2mfLDpOqW7bJsvcgvBafja4cNnIEMHjgL" Archived-At: Subject: Re: [Uta] Require TLS=NO is very much needed X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 14:28:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2mfLDpOqW7bJsvcgvBafja4cNnIEMHjgL Content-Type: multipart/mixed; boundary="AJwDvokJULsXu8PRG344NBAs1sRmxcHh1"; protected-headers="v1" From: Eliot Lear To: uta@ietf.org, Viktor Dukhovni Message-ID: <5d638100-295a-8b05-7958-470abaaf3ac3@cisco.com> Subject: Re: [Uta] Require TLS=NO is very much needed References: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> <7FD24C09-99A6-4847-BCE7-4455F62188FC@dukhovni.org> In-Reply-To: <7FD24C09-99A6-4847-BCE7-4455F62188FC@dukhovni.org> --AJwDvokJULsXu8PRG344NBAs1sRmxcHh1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US I've been watching the back and forth and trying to get my hands around the technical issues between the two cases.=C2=A0 The closest I see for a= technical explanation in this thread is this: On 11/17/17 3:55 AM, Viktor Dukhovni wrote: > As I pointed out in another message, BOTH REQUIRETLS=3DYES > *and* REQUIRETLS=3DNO need to be encapsulated in headers, but > the YES case *also* needs an ESMTP extension, while the > NO case does not. It makes sense to define both in the > same document. For those of us who were not in the room, can someone explain the case in technical detail for *not* doing REQUIRETLS=3DNO in the same document?= =C2=A0 Jim? Eliot --AJwDvokJULsXu8PRG344NBAs1sRmxcHh1-- --2mfLDpOqW7bJsvcgvBafja4cNnIEMHjgL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJaDvIIAAoJEIe2a0bZ0nozDOcH/37aNHw0Lb/GArtcp1VbBu2W gKgAwlYGf4f01JAi4H3OIlfJhM0NcZV/OlxqOPWZnbU7UOkM109C2AFzvE/CO8bN tfGMsZGRfu5D5PEqRoGp7pUcKOtoaDKVPMxVmHK50vdhuf6+CesHmttKraOrWbFw TaarLqYzR3ftWcMRBcmk/d/t5z9o0jHhU7v2A78Sd2WJir6oIj4FU17KDstTb1XB dhygcRDrzHTikUfDXJd45954qPMRqhSugjTTcap4sL9EGIV1BUCp8W8N1WNYC2Qw eD/zdxINCYNkbN/4TimaOm3km9GeZnI0r1Y0M9+r7f4skCu/cJUkaU4P0ssHyI4= =NqwZ -----END PGP SIGNATURE----- --2mfLDpOqW7bJsvcgvBafja4cNnIEMHjgL-- From nobody Fri Nov 17 08:19: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 A12A3128B8D for ; Fri, 17 Nov 2017 08:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 lcMmqkT9smcY for ; Fri, 17 Nov 2017 08:19:15 -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 7ECA11243FE for ; Fri, 17 Nov 2017 08:19:15 -0800 (PST) Received: from splunge.local ([202.55.67.146]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id vAHGJB2K020638 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 17 Nov 2017 08:19:14 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1510935554; bh=F4umQtv836uNMGBBo4KSh/vaPkWqC1/3xgkavtdH9RM=; h=Subject:To:References:From:Date:In-Reply-To; b=kr7hQHM0bxHs5DiXCF4kfOEOvDKfvdaWElm8V0nU56P+8Eci95En8hR601fyRuwwS CQdpuwF4voy61mR+ZF7DoBZAfifo4IvHw27EwcXHMcyi5uFtTJAW7pM6+D+wcoz9g+ uFI5+A9kI//hAI2LhGq6x7dKQJ+8ARejC3tP0DR8= To: uta@ietf.org References: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> <7FD24C09-99A6-4847-BCE7-4455F62188FC@dukhovni.org> <5d638100-295a-8b05-7958-470abaaf3ac3@cisco.com> From: Jim Fenton Message-ID: <847cec60-7cb6-4168-9916-71c835d5919c@bluepopcorn.net> Date: Fri, 17 Nov 2017 08:19:10 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <5d638100-295a-8b05-7958-470abaaf3ac3@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [Uta] Require TLS=NO is very much needed X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 16:19:17 -0000 On 11/17/17 6:28 AM, Eliot Lear wrote: > I've been watching the back and forth and trying to get my hands around= > the technical issues between the two cases.=C2=A0 The closest I see for= a > technical explanation in this thread is this: > > > On 11/17/17 3:55 AM, Viktor Dukhovni wrote: >> As I pointed out in another message, BOTH REQUIRETLS=3DYES >> *and* REQUIRETLS=3DNO need to be encapsulated in headers, but >> the YES case *also* needs an ESMTP extension, while the >> NO case does not. It makes sense to define both in the >> same document. > For those of us who were not in the room, can someone explain the case > in technical detail for *not* doing REQUIRETLS=3DNO in the same documen= t?=C2=A0 > Jim? The "yes" and "no" cases solve different problems: in the case of "yes" it's stating a security requirement, and in the case of "no" it's enhancing deliverability in the presence of MTA-STS or DANE policies. I can picture that some MTAs might deploy one and not the other, which makes it confusing if we're calling them both REQUIRETLS and putting them in the same specification. The "yes" case involves negotiation of an SMTP extension and may also involve the addition of a header field. The "no" case involves only the addition of a header field. -Jim From nobody Fri Nov 17 08:31:54 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F17128B90 for ; Fri, 17 Nov 2017 08:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ncsc.nl 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 H6hAekdjnCgH for ; Fri, 17 Nov 2017 08:31:51 -0800 (PST) Received: from min1.ncsc.nl (min1.ncsc.nl [147.181.97.77]) (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 2EA5A1243FE for ; Fri, 17 Nov 2017 08:31:51 -0800 (PST) Received: from mailer DMARC-Filter: OpenDMARC Filter v1.3.2 min1.ncsc.nl 579C1E0003 Authentication-Results: min1.ncsc.nl; dmarc=none (p=none dis=none) header.from=ncsc.nl Authentication-Results: min1.ncsc.nl; spf=none smtp.mailfrom=Maarten.Aertsen@ncsc.nl DKIM-Filter: OpenDKIM Filter v2.11.0 min1.ncsc.nl 579C1E0003 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.nl; s=ncsc2015; t=1510936309; bh=Os8/ca8+y4LqT2n4DDGH4t+4CkR//PBIU1VVUzNehUs=; h=Subject:References:From:To:Date:In-Reply-To:From; b=KA5r9A6N/FrOgn/w4N/IJm9eUMnRYI4LKH0fMZSKnbGLxJTc/l0hWUqGVpM1UVE/C 0YweS2/91ySH3A2pEPcZgj2TvR9lYzKmZrBuj8lSGSXKfuvSVKjT2nvpmPYgnHpNcW uW7o9mZKitpzMrnWuvC9dL00UH1nz3OuvhLfsszfTWUj+aMR/1oogLpYMSZ7koxr0i 67uG1EZBdzgNfmGGGmbm2WA0uOelYFhf8QgkkPQmY/WQkh385vwYzcGS6+MzGphi9Z 5EXNKQpwrMWWfFdtEb3HUXjYbJGLONwszVIBV0/MtNWUZHCCd17d7YP4BH7nZSGZQf UzyAsgDWDUX/g== Received: from mailer References: <249cbf338d534a52af511fcacb790e95@COPDCEX19.cable.comcast.com> From: "Maarten Aertsen (NCSC-NL)" To: Message-ID: <84833103-7acf-0e4f-bf29-b8fbfbce8513@ncsc.nl> Date: Fri, 17 Nov 2017 17:31:35 +0100 MIME-Version: 1.0 In-Reply-To: <249cbf338d534a52af511fcacb790e95@COPDCEX19.cable.comcast.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] Updated MTA-STS & TLSRPT X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 16:31:54 -0000 Hi, On 10-11-2017 14:47, Brotman, Alexander wrote: > These two drafts were uploaded last night, and we'd like any > feedback. [..] We look forward to hearing from the group. Thank you. I have feedback on the current draft from the perspective of smaller e-mail providers. MTA-STS competes with DANE TLSA for the achievement of similar security goals of e-mail providers. As such, e-mail providers will be faced with the choice of which protocols to support and enable: DANE TLSA, MTA-STS or both. E-mail providers will be limited by their vendors (i.e. implementors) in their freedom of choice. Implementors partially choose support based on the guidance in this (later) spec. I have quoted the relevant parts of the draft that treat considerations for such choices below: > 2. Related Technologies > > The DANE TLSA record [RFC7672] is similar, [..]; the mechanism > described here instead relies on certificate authorities (CAs) and > does not require DNSSEC, at a cost of risking malicious downgrades. > For a thorough discussion of this trade-off, see Section 9, "Security > Considerations". Section 9 _does_ include the security considerations relating to downgrades. It _does not_ make explicit the considerations for choice, which is what I expected to find after reading this paragraph. On the other hand, these are partly, and /implicitly/ covered two paragraphs later in Section 2: > The primary motivation of MTA-STS is to provide a mechanism for > domains to upgrade their transport security even when deploying > DNSSEC is undesirable or impractical. However, MTA-STS is designed > not to interfere with DANE deployments when the two overlap; in > particular, senders who implement MTA-STS validation MUST NOT allow > "valid" or "report-only" MTA-STS validation to override a failing > DANE validation. This paragraph seems to imply that DANE TLSA takes priority over MTA-STS. This assumption is never explicitly stated in the document. I would argue to explicitly include guidance on the choice implementors face. This is important in a world where it is likely that large receivers will only support MTA-STS due to their preference not to implement DNSSEC. The tendency to go along with large organisations should be offset by being crystal clear about the differences between DANE TLSA and MTA-STS with respect to their ability to meet stated security goals. To this end, I would propose adding: "and are therefor RECOMMENDED to perform this validation prior to MTA-STS validation. To avoid risking malicious downgrades, receivers that deploy DNSSEC are RECOMMENDED to maintain DANE TLSA records for MX hosts." Relevant inspiration for this proposal came from earlier conversation between Jim Fenton and Viktor Dukhovni quoted below. For brevity, I have not included the "local policy" angle", but this may well be worth doing. best regards, Maarten On 12-11-2017 19:48, Viktor Dukhovni wrote: > On Nov 12, 2017, at 6:01 AM, Jim Fenton > wrote: >> - Section 4 "enforce" prohibits delivering when things fail >> mta-sts, but Section 2 says, "MTA-STS is designed not to interfere >> with DANE deployments where the two overlap". Doesn't this >> requirement constitute that sort of interference? > > I would read that as "STS is entirely out of scope when DANE policy > is in effect". Of course sending machines get to decide whether DANE > policy is in effect or not, by choosing to enable DANE or STS in the > first place, and potentially choose one or the other explicitly for > some domains. > > Thus, for example, while DANE policy is generally driven by the > remote domain's publishing of TLSA records, a sending Postfix MTA can > be configured to *require* DANE for some set of destinations, in > which case delivery will only happen when the destinations publish > ("secure" DNSSEC) DANE TLSA records, and not otherwise. > > Similarly, a sending system might *require* STS for some set of > destinations, and refuse to send in the absence of a cached policy. > > So, the way I would read and implement this would be to prefer DANE > over STS barring local policy that prefers one over the other for > some destinations or perhaps suppressed both. From nobody Sun Nov 19 01:46: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 AF3F1126CD8 for ; Sun, 19 Nov 2017 01:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Ol1etMOU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LSIQwdnr 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 rmQvHDKGR2ys for ; Sun, 19 Nov 2017 01:45:59 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1DB126D0C for ; Sun, 19 Nov 2017 01:45:55 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 75A7920A7C for ; Sun, 19 Nov 2017 04:45:54 -0500 (EST) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Sun, 19 Nov 2017 04:45:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=8al9lScZK7Y2QbQUk hdGRKcms5uHGqf4gIUvQ/EO+r0=; b=Ol1etMOUS47MtYMEM8KKblBeZbRiLTpd0 YnzEia/29UBY0QVMp3q5yfIoOzMECRA93DpSQ82hx/7qeUL074ARsjN8XKz8G97z S5OjxCFzzhf2Brp33L5+h26pp+O1rRq1cOTiEtteGYJbUzI0elDQbhFolI1ZlJFX 2yNM1WJwFOrsa/qhYLIIqg24e+bE1b4UM8ztdfv7EplOMpQ5ULSZ8U+Q1z6DeQKw P7SAlnUuVbkHh9/3Y452al91yVFYjbTNHmFdiyQ4roTUF8XpNgupIDkP5oejdfGh yJ7XEzuwsQCkuUWpGw5KMaGe/ROK3/54Oma1wRoUamBSfUovV/efw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=8al9lS cZK7Y2QbQUkhdGRKcms5uHGqf4gIUvQ/EO+r0=; b=LSIQwdnrY0SHLaPhfdcjXv X8UyqCfL6xLMWB5xZ9Vncwi8CD64PAVg3v6SD0KW3KwU0lUaEJ9YyN8BFyA2zcWg 2Nx8vOgXHoTXse1CZSZEzh7Hn1yum/pHT9LM6bS2fpdsg4T0k9SLtC8Y7ZansX/N NqQPy+hwlX6y52wqRqwA99ylAK6AtWg62oLogcXJfGOCVJuAYKE7cQ+qpgQL9HoG EgevabweRwn1+gV3zMGtNZ56oI7fiHzqdb7XxMmPKlqzPM1xwXg9f3GQ+IgnVmHB mUwyfwMhGPoqPtyWMyzvX0gvcFvfIcr0Q+df/PjEwDl2QVQIiPwaZwQKSOUfgBUQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 4F394BAB61; Sun, 19 Nov 2017 04:45:54 -0500 (EST) Message-Id: <1511084754.1013830.1177377576.08837C8D@webmail.messagingengine.com> From: Bron Gondwana To: uta@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151108475410138301" X-Mailer: MessagingEngine.com Webmail Interface - ajax-4ef04c51 Date: Sun, 19 Nov 2017 20:45:54 +1100 References: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> <5A0E7D70.6060302@isode.com> <0620480C-32FB-43B3-8C5A-C4752C1C62E3@dukhovni.org> <3C48EC8E-FA2E-4E16-9C02-63ED5E4C46A1@dukhovni.org> In-Reply-To: <3C48EC8E-FA2E-4E16-9C02-63ED5E4C46A1@dukhovni.org> Archived-At: Subject: Re: [Uta] Require TLS=NO is very much needed X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 09:46:00 -0000 This is a multi-part message in MIME format. --_----------=_151108475410138301 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Fri, 17 Nov 2017, at 20:15, Viktor Dukhovni wrote: > > >> On Nov 17, 2017, at 3:49 AM, Salz, Rich wrote: >> >> I was there and I disagree with your characterization. > > I watched the entire session after the fact, I stand by my > assessment that the conclusions were premature. I've been > focused on this space for ~15 years now, so I am probably > not making stuff up... I have, admittedly, only been focused on this space for 13 years, which I guess means you win on pure number of years. I was a person who stood up in both Prague and again in Singapore and argued for a header rather than REQUIRETLS=NO at SMTP stage. I see no benefit to adding anything at SMTP stage, or even checking if the receiver claims to support REQUIRETLS. If you have a message that doesn't want TLS checking, then you need to try your best to deliver it regardless, so you won't be checking for this extension before trying to send. > We should also keep in mind that as DANE and STS gain more > adoption, it will be the "NO" case that will be far more > useful to the majority of users. The "YES" case will see > very little use. In particular email reports from the > "tlsrpt" draft, will need "NO", to make sure they get to > the problem destination, despite their expired or otherwise > invalid certificates, disabled STARTTLS, ... I agree with this. There needs to be a way to contact misconfigured sites. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_151108475410138301 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Fri, 17 Nov 2017, at 20:15, Viktor Dukhovni wrote:


On Nov 17, 2017, at 3:49 AM, Salz, Rich <rsalz@akamai.com> wrote:

I was there and I disagree with your characterization.

I watched the entire session after the fact, I stand by my
assessment that the conclusions were premature.  I've been
focused on this space for ~15 years now, so I am probably
not making stuff up...

I have, admittedly, only been focused on this space for 13 years, which I guess means you win on pure number of years.

I was a person who stood up in both Prague and again in Singapore and argued for a header rather than REQUIRETLS=NO at SMTP stage.  I see no benefit to adding anything at SMTP stage, or even checking if the receiver claims to support REQUIRETLS.  If you have a message that doesn't want TLS checking, then you need to try your best to deliver it regardless, so you won't be checking for this extension before trying to send.

We should also keep in mind that as DANE and STS gain more
adoption, it will be the "NO" case that will be far more
useful to the majority of users.  The "YES" case will see
very little use.  In particular email reports from the
"tlsrpt" draft, will need "NO", to make sure they get to
the problem destination, despite their expired or otherwise
invalid certificates, disabled STARTTLS, ...

I agree with this.  There needs to be a way to contact misconfigured sites.

Bron.


--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_151108475410138301-- From nobody Sun Nov 19 01:52:36 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 944551243F6 for ; Sun, 19 Nov 2017 01:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=CgDbPqUF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=E3x9gCVu 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 NFuVB9DOaoUf for ; Sun, 19 Nov 2017 01:52:33 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A0B1200C1 for ; Sun, 19 Nov 2017 01:52:33 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id EDF8E20AEA for ; Sun, 19 Nov 2017 04:52:32 -0500 (EST) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Sun, 19 Nov 2017 04:52:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=FQoY1odTH9J540C7H 33GGkMDTFihSEAg9rTVtM5Ldto=; b=CgDbPqUFGn1pa6V/ubnvPKj3vsA5Efuaq HOYKgDNoopXGul3WWZvlw7agA3KGQAV3zy6njpIFF6lzf0Ch6tciLuVnWOIups9D BzNrIqo132QaS9ZffSGax428nz/I1wopMHaKvH8fgcCIc3zNQ9Sk2o6z9/FxFGyX OdxmEbZCr66DH6VlhEPKoleKeB3+F84cst6OJGWYH/aRrLm5tFU7d3tpU6Y0UAT3 wQ5oEkZ23q7yH+oCaCnNm0FFkpKyjT8TY1RJSI+bIvakSc6ioMMMev4kKWPCnztb zNa3HmHSe8aBRM4V0NEW13GhHsjh+YexCxQnCTDBafSuPZsQABP4w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=FQoY1o dTH9J540C7H33GGkMDTFihSEAg9rTVtM5Ldto=; b=E3x9gCVu0O0GCm61Y7UJZB bbmfXINOOy8offzoIrMIJSKBjV0krxEg+usSxQIWNLdGezr+rzAdn31r3vnJUgQl D0a7kzAILhKGfINKPn+obir6KNzsN+9TLaLa0UM09lu5jN9VavvxHVKnbHvmPepc ihHBEHjAOr9ZfOkbMfQ+Zc7XuVon1G7DqyIIlhIoq7etPU9HabZR74U9Uuw1RYCp jjksvg4E/sklhZ14lUcYPY4494VTcVeYXsrTYfopdMsPlUPQmrAFYAwh4voTyGSf N+1AgyPIdX7VwAYROH8lt/vdFw6Ql+Nk32pBcQUxaZraBQJsm8WufM9Wlv1wNpbw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B834CBAB61; Sun, 19 Nov 2017 04:52:32 -0500 (EST) Message-Id: <1511085152.1017831.1177389176.594B270D@webmail.messagingengine.com> From: Bron Gondwana To: uta@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151108515210178311" X-Mailer: MessagingEngine.com Webmail Interface - ajax-4ef04c51 References: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> <7FD24C09-99A6-4847-BCE7-4455F62188FC@dukhovni.org> <5d638100-295a-8b05-7958-470abaaf3ac3@cisco.com> In-Reply-To: <5d638100-295a-8b05-7958-470abaaf3ac3@cisco.com> Date: Sun, 19 Nov 2017 20:52:32 +1100 Archived-At: Subject: Re: [Uta] Require TLS=NO is very much needed X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 09:52:34 -0000 This is a multi-part message in MIME format. --_----------=_151108515210178311 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Sat, 18 Nov 2017, at 01:28, Eliot Lear wrote: > I've been watching the back and forth and trying to get my > hands around> the technical issues between the two cases. The closest I see for a > technical explanation in this thread is this: > > > On 11/17/17 3:55 AM, Viktor Dukhovni wrote: >> As I pointed out in another message, BOTH REQUIRETLS=YES >> **and** REQUIRETLS=NO need to be encapsulated in headers, but >> the YES case **also** needs an ESMTP extension, while the >> NO case does not. It makes sense to define both in the >> same document. > > For those of us who were not in the room, can someone explain the case> in technical detail for **not** doing REQUIRETLS=NO in the same > document?> Jim? > > Eliot That's a great summary of the key point, and I totally agree with Viktor here, though I would even more strongly argue that definining REQUIRETLS=NO as an ESMTP extension would be a mistake. It doesn't add any additional signal on top of the header, and creates more cases where the two sets of information could be out of alignment. I would argue that if REQUIRETLS=YES is given via ESMTP then the lack of a REQUIRETLS=YES header on the same message MUST cause a rejection, meaning that nobody would deploy the YES case unless they had both in alignment. Whereas the NO case is always just a hint to intermediate sites to relax their tests. For NO a header is plenty, since you never want to stop trying to deliver just because you can't negotiate something at ESMTP for the NO case. I'm really quite happy for it to be a single document for the reasons Ned and Viktor have suggested - it's easier to get adoption. That said, I could see sites deploying NO support without deploying YES, since YES requires you to to ensure that your downstreams are at least claiming to play ball. So that's an argument for either two separate documents or the spec saying that it's legitimate to implement NO only. It's less important how many documents are produced than the ability for sites to offer NO without YES. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_151108515210178311 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Sat, 18 Nov 2017, at 01:28, Eliot Lear wrote:
I've been watching the back and forth and trying to get my hands around
the technical issues between the two cases.  The closest I see for a
technical explanation in this thread is this:


On 11/17/17 3:55 AM, Viktor Dukhovni wrote:
As I pointed out in another message, BOTH REQUIRETLS=YES
*and* REQUIRETLS=NO need to be encapsulated in headers, but
the YES case *also* needs an ESMTP extension, while the
NO case does not.  It makes sense to define both in the
same document.

For those of us who were not in the room, can someone explain the case
in technical detail for *not* doing REQUIRETLS=NO in the same document? 
Jim?

Eliot

That's a great summary of the key point, and I totally agree with Viktor here, though I would even more strongly argue that definining REQUIRETLS=NO as an ESMTP extension would be a mistake.  It doesn't add any additional signal on top of the header, and creates more cases where the two sets of information could be out of alignment.

I would argue that if REQUIRETLS=YES is given via ESMTP then the lack of a REQUIRETLS=YES header on the same message MUST cause a rejection, meaning that nobody would deploy the YES case unless they had both in alignment.

Whereas the NO case is always just a hint to intermediate sites to relax their tests.  For NO a header is plenty, since you never want to stop trying to deliver just because you can't negotiate something at ESMTP for the NO case.

I'm really quite happy for it to be a single document for the reasons Ned and Viktor have suggested - it's easier to get adoption.

That said, I could see sites deploying NO support without deploying YES, since YES requires you to to ensure that your downstreams are at least claiming to play ball.  So that's an argument for either two separate documents or the spec saying that it's legitimate to implement NO only.  It's less important how many documents are produced than the ability for sites to offer NO without YES.

Cheers,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_151108515210178311-- From nobody Sun Nov 19 10:58:32 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 AFBE3124B0A for ; Sun, 19 Nov 2017 10:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35vkMgdVCiIb for ; Sun, 19 Nov 2017 10:58:30 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62BAB1200E5 for ; Sun, 19 Nov 2017 10:58:30 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 299BF7A3309 for ; Sun, 19 Nov 2017 18:58:29 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Viktor Dukhovni In-Reply-To: <1511085152.1017831.1177389176.594B270D@webmail.messagingengine.com> Date: Sun, 19 Nov 2017 13:58:28 -0500 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: <18A85ED0-BC3E-431F-A8FD-0CDCEC812910@dukhovni.org> References: <32C4B825-C3D6-4C25-9C1D-BCF4354CA326@dukhovni.org> <7FD24C09-99A6-4847-BCE7-4455F62188FC@dukhovni.org> <5d638100-295a-8b05-7958-470abaaf3ac3@cisco.com> <1511085152.1017831.1177389176.594B270D@webmail.messagingengine.com> To: uta@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [Uta] Require TLS=NO is very much needed X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 18:58:31 -0000 > On Nov 19, 2017, at 4:52 AM, Bron Gondwana = wrote: >=20 > That said, I could see sites deploying NO support without deploying = YES, since YES requires you to to ensure that your downstreams are at = least claiming to play ball. So that's an argument for either two = separate documents or the spec saying that it's legitimate to implement = NO only. It's less important how many documents are produced than the = ability for sites to offer NO without YES. I think that a single specification in no way obligates anyone to implement all its features, a site could implement any of the four possibilities regardless of the number of documents the IETF publishes in this space. A single specification is IMHO simpler, since it concerns the same security policy issue: * Whether to deliver despite lack of a secure channel The "REQUIRETLS=3DYES" case says "stop" and asks the nexthop to do likewise both via out-of-band (ESMTP) and in-band (header) signalling. The "REQUIRETLS=3DNO" case says "go", and asks the nexthop to do likewise just via in-band (header) signalling. The header should I think be a common header, and the same considerations apply wrt. "Resent" and "List" messages. That is, if the header is normally: TLS-Required: Yes|No Then in a resent message (that has a Resent-=46rom or a Resent-Message-Id header) the above header is ignored and any TLS policy override would need to be: Resent-TLS-Required: Yes|No and in a list message (that has a List-Id header) any override would have to be a "List-TLS-Required" header. --=20 Viktor. From nobody Mon Nov 20 08:48:10 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 DB9EB129BEC for ; Mon, 20 Nov 2017 08:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uu2sT5gPC8GZ for ; Mon, 20 Nov 2017 08:48:06 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 0D8F6129BDB for ; Mon, 20 Nov 2017 08:48:06 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id m191so12526242itg.2 for ; Mon, 20 Nov 2017 08:48:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o7BYREgnb6BsxiV7CecLDctAOfTjjJ+orFfANRdNtuM=; b=iABZAuuHgMwF72czlkJzduPFdrbFj7iTTGq/3fKv9sRJx6AWBQsKIVaYOD3FCBkdeb Do1F2vY3TuSHBWZwuHxSpXkxXbveBEpHpdBLaC/rveQvxQXDaFszgSIHq2ixLp1BxSdT v47xp5fTwKcWgPATdd3hJjzT56+eFXHnW9UfTAd4wG0noo5mqoFMLzsKvxA2rAuFcAp8 hksudZYU+ATDPn7+t/0jmZC1JRvuVX/ucYs+tCJre6FAkYTNbe9P3sMIU59gfCFObhQ5 xidoFLQpfAn2G4es24Z8ZuuTNnsUIL7uN91rjfKU14of/HIGKivqKl98/HylYCddsfdE HcFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o7BYREgnb6BsxiV7CecLDctAOfTjjJ+orFfANRdNtuM=; b=WkY7w5FRnxb6s8zPurCsoDri9K7d84Z/IBzUSKUbD/BPIQ/vk5vL6kUdClLzsVGhgT hT2Ijo+8Tjhw5n49DirPnwDVjb+YEHugw1/hJYSnSyxLhgRJXMmCiFvpXbp2aONAOszP XT9rtI5MkR1ZRytY3KxhtFQghm/6rF6MgL+pNk3MbIRQUIMy+LaYnlRaKJhbqsD73Hty pkTTWR1ZXr1dSkkL0do0W0fwoiu+unOXnjrH48F1jjdp4p0kDk+wse+EfJLxPrQBfTV4 si91W69/89JFD4FMMEHTLNAWTyUpMQjOc/IFPa6ukQVFgng2c6o/eEVZkbMT4d4Rx4MN tfog== X-Gm-Message-State: AJaThX7L1PqROGnWh3f5YIl+7yrc0IluDIKkY7PVSTlpHqPIsdMQZ9Z6 5rTBhAkaoUOjzqyMUHAMf4V6Fnft0lFZ17S6PjYUFA== X-Google-Smtp-Source: AGs4zMaLZGYTdtybujl7Mx8uKWDYm+u26vPv2QXXiVlOKs8otLD0EQEX67Sv8cE7u1YtlOSSDt/1AlccrvMS18DZo/o= X-Received: by 10.36.145.203 with SMTP id i194mr19339777ite.73.1511196484718; Mon, 20 Nov 2017 08:48:04 -0800 (PST) MIME-Version: 1.0 References: <249cbf338d534a52af511fcacb790e95@COPDCEX19.cable.comcast.com> <84833103-7acf-0e4f-bf29-b8fbfbce8513@ncsc.nl> In-Reply-To: <84833103-7acf-0e4f-bf29-b8fbfbce8513@ncsc.nl> From: Daniel Margolis Date: Mon, 20 Nov 2017 16:47:46 +0000 Message-ID: To: maarten.aertsen@ncsc.nl Cc: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c0ef650b4af0b055e6cd906" Archived-At: Subject: Re: [Uta] Updated MTA-STS & TLSRPT X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 16:48:09 -0000 --94eb2c0ef650b4af0b055e6cd906 Content-Type: multipart/alternative; boundary="94eb2c0ef650a8f5e3055e6cd924" --94eb2c0ef650a8f5e3055e6cd924 Content-Type: text/plain; charset="UTF-8" As Viktor said, this is mostly up to sending MTAs. I may be wrong--and welcome feedback about what's commonly done on similar RFCs--but I see the scope of the MTA-STS RFC as being outlining the protocol itself, not guidelines on when to deploy it versus other protocols. As such, I don't really want to be recommending to implementors whether or when to prefer STS to TLSA, or vice versa. What we define is what a compliant MTA who validates STS does--and the TLSA RFC does similarly for that protocol. I should think that someone who checks both should fail a message if either fails, but if someone wants to check only one or the other--or only one if the other is missing--they are of course free to do so. Obviously a recipient cannot expect that a valid TLSA record will override an invalid STS policy, or vice versa, since they are not guaranteed senders will check both, so there's no real need to specify this behavior anyway, I think. My impression is that recommendations of when to deploy which would make more sense in a separate BCP than as part of the STS draft, but I may be mistaken. What's the common convention here? On Fri, Nov 17, 2017 at 5:31 PM Maarten Aertsen (NCSC-NL) < maarten.aertsen@ncsc.nl> wrote: > Hi, > > On 10-11-2017 14:47, Brotman, Alexander wrote: > > These two drafts were uploaded last night, and we'd like any > > feedback. [..] We look forward to hearing from the group. Thank you. > I have feedback on the current draft from the perspective of smaller > e-mail providers. > > MTA-STS competes with DANE TLSA for the achievement of similar security > goals of e-mail providers. As such, e-mail providers will be faced with > the choice of which protocols to support and enable: DANE TLSA, MTA-STS > or both. E-mail providers will be limited by their vendors (i.e. > implementors) in their freedom of choice. Implementors partially choose > support based on the guidance in this (later) spec. > > I have quoted the relevant parts of the draft that treat considerations > for such choices below: > > > 2. Related Technologies > > > > The DANE TLSA record [RFC7672] is similar, [..]; the mechanism > > described here instead relies on certificate authorities (CAs) and > > does not require DNSSEC, at a cost of risking malicious downgrades. > > For a thorough discussion of this trade-off, see Section 9, "Security > > Considerations". > Section 9 _does_ include the security considerations relating to > downgrades. It _does not_ make explicit the considerations for choice, > which is what I expected to find after reading this paragraph. On the > other hand, these are partly, and /implicitly/ covered two paragraphs > later in Section 2: > > > The primary motivation of MTA-STS is to provide a mechanism for > > domains to upgrade their transport security even when deploying > > DNSSEC is undesirable or impractical. However, MTA-STS is designed > > not to interfere with DANE deployments when the two overlap; in > > particular, senders who implement MTA-STS validation MUST NOT allow > > "valid" or "report-only" MTA-STS validation to override a failing > > DANE validation. > This paragraph seems to imply that DANE TLSA takes priority over > MTA-STS. This assumption is never explicitly stated in the document. > > I would argue to explicitly include guidance on the choice implementors > face. This is important in a world where it is likely that large > receivers will only support MTA-STS due to their preference not to > implement DNSSEC. The tendency to go along with large organisations > should be offset by being crystal clear about the differences between > DANE TLSA and MTA-STS with respect to their ability to meet stated > security goals. > > To this end, I would propose adding: "and are therefor RECOMMENDED to > perform this validation prior to MTA-STS validation. To avoid risking > malicious downgrades, receivers that deploy DNSSEC are RECOMMENDED to > maintain DANE TLSA records for MX hosts." > > Relevant inspiration for this proposal came from earlier conversation > between Jim Fenton and Viktor Dukhovni quoted below. For brevity, I have > not included the "local policy" angle", but this may well be worth doing. > > best regards, Maarten > > On 12-11-2017 19:48, Viktor Dukhovni wrote: > > On Nov 12, 2017, at 6:01 AM, Jim Fenton > > wrote: >> - Section 4 "enforce" prohibits delivering when things fail > >> mta-sts, but Section 2 says, "MTA-STS is designed not to interfere > >> with DANE deployments where the two overlap". Doesn't this > >> requirement constitute that sort of interference? > > > I would read that as "STS is entirely out of scope when DANE policy > > is in effect". Of course sending machines get to decide whether DANE > > policy is in effect or not, by choosing to enable DANE or STS in the > > first place, and potentially choose one or the other explicitly for > > some domains. > > > > Thus, for example, while DANE policy is generally driven by the > > remote domain's publishing of TLSA records, a sending Postfix MTA can > > be configured to *require* DANE for some set of destinations, in > > which case delivery will only happen when the destinations publish > > ("secure" DNSSEC) DANE TLSA records, and not otherwise. > > > > Similarly, a sending system might *require* STS for some set of > > destinations, and refuse to send in the absence of a cached policy. > > > > So, the way I would read and implement this would be to prefer DANE > > over STS barring local policy that prefers one over the other for > > some destinations or perhaps suppressed both. > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --94eb2c0ef650a8f5e3055e6cd924 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As Viktor said, this is mostly up to sending MTAs. I may b= e wrong--and welcome feedback about what's commonly done on similar RFC= s--but I see the scope of the MTA-STS RFC as being outlining the protocol i= tself, not guidelines on when to deploy it versus other protocols.

=
As such, I don't really want to be recommending to implement= ors whether or when to prefer STS to TLSA, or vice versa. What we define is= what a compliant MTA who validates STS does--and the TLSA RFC does similar= ly for that protocol. I should think that someone who checks both should fa= il a message if either fails, but if someone wants to check only one or the= other--or only one if the other is missing--they are of course free to do = so.

Obviously a recipient cannot expect that a val= id TLSA record will override an invalid STS policy, or vice versa, since th= ey are not guaranteed senders will check both, so there's no real need = to specify this behavior anyway, I think.=C2=A0

My= impression is that recommendations of when to deploy which would make more= sense in a separate BCP than as part of the STS draft, but I may be mistak= en. What's the common convention here?=C2=A0


On Fri, Nov 17, 2017 at 5:31 PM Maarte= n Aertsen (NCSC-NL) <maarten.= aertsen@ncsc.nl> wrote:
Hi,<= br>
On 10-11-2017 14:47, Brotman, Alexander wrote:
> These two drafts were uploaded last night, and we'd like any
> feedback. [..] We look forward to hearing from the group. Thank you. I have feedback on the current draft from the perspective of smaller
e-mail providers.

MTA-STS competes with DANE TLSA for the achievement of similar security
goals of e-mail providers. As such, e-mail providers will be faced with
the choice of which protocols to support and enable: DANE TLSA, MTA-STS
or both. E-mail providers will be limited by their vendors (i.e.
implementors) in their freedom of choice. Implementors partially choose
support based on the guidance in this (later) spec.

I have quoted the relevant parts of the draft that treat considerations
for such choices below:

> 2. Related Technologies
>
> The DANE TLSA record [RFC7672] is similar, [..]; the mechanism
> described here instead relies on certificate authorities (CAs) and
> does not require DNSSEC, at a cost of risking malicious downgrades. > For a thorough discussion of this trade-off, see Section 9, "Secu= rity
> Considerations".
Section 9 _does_ include the security considerations relating to
downgrades. It _does not_ make explicit the considerations for choice,
which is what I expected to find after reading this paragraph. On the
other hand, these are partly, and /implicitly/ covered two paragraphs
later in Section 2:

> The primary motivation of MTA-STS is to provide a mechanism for
> domains to upgrade their transport security even when deploying
> DNSSEC is undesirable or impractical. However, MTA-STS is designed
> not to interfere with DANE deployments when the two overlap; in
> particular, senders who implement MTA-STS validation MUST NOT allow > "valid" or "report-only" MTA-STS validation to ove= rride a failing
> DANE validation.
This paragraph seems to imply that DANE TLSA takes priority over
MTA-STS. This assumption is never explicitly stated in the document.

I would argue to explicitly include guidance on the choice implementors
face. This is important in a world where it is likely that large
receivers will only support MTA-STS due to their preference not to
implement DNSSEC. The tendency to go along with large organisations
should be offset by being crystal clear about the differences between
DANE TLSA and MTA-STS with respect to their ability to meet stated
security goals.

To this end, I would propose adding: "and are therefor RECOMMENDED to<= br> perform this validation prior to MTA-STS validation. To avoid risking
malicious downgrades, receivers that deploy DNSSEC are RECOMMENDED to
maintain DANE TLSA records for MX hosts."

Relevant inspiration for this proposal came from earlier conversation
between Jim Fenton and Viktor Dukhovni quoted below. For brevity, I have not included the "local policy" angle", but this may well be= worth doing.

best regards, Maarten

On 12-11-2017 19:48, Viktor Dukhovni wrote:
> On Nov 12, 2017, at 6:01 AM, Jim Fenton <fenton@bluepopcorn.net>
> wrote: >> - Section 4 "enforce" prohibits delivering w= hen things fail
>> mta-sts, but Section 2 says, "MTA-STS is designed not to inte= rfere
>> with DANE deployments where the two overlap". Doesn't thi= s
>> requirement constitute that sort of interference? >
> I would read that as "STS is entirely out of scope when DANE poli= cy
> is in effect". Of course sending machines get to decide whether D= ANE
> policy is in effect or not, by choosing to enable DANE or STS in the > first place, and potentially choose one or the other explicitly for > some domains.
>
> Thus, for example, while DANE policy is generally driven by the
> remote domain's publishing of TLSA records, a sending Postfix MTA = can
> be configured to *require* DANE for some set of destinations, in
> which case delivery will only happen when the destinations publish
> ("secure" DNSSEC) DANE TLSA records, and not otherwise.
>
> Similarly, a sending system might *require* STS for some set of
> destinations, and refuse to send in the absence of a cached policy. >
> So, the way I would read and implement this would be to prefer DANE > over STS barring local policy that prefers one over the other for
> some destinations or perhaps suppressed both.


_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
--94eb2c0ef650a8f5e3055e6cd924-- --94eb2c0ef650b4af0b055e6cd906 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMYvQlQqbPmlmUoZynMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODE4NDIxNloXDTE4MDMx NzE4NDIxNlowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDI3sfyM5pHCY0cDNbbiDAn17uPa3PG0G98FftCEkej/WTh RcWVnnX7STqcEnQwK7z8r8SckwfHWqDMNnb6PMXVZUOCv9iewPrxXlQfmFvDQQnRXbUKp7WgUjzm 5v1BIs/mIvqkrBsiPJLvNbO8b7BxewUnTP24wHaCYvlVFXd/A+hbq5CJciR230oH0bmB6zMlpxQe 45PlPkEkLb2cUaad14IV2ulfK8pcsLLM+NntC9jxKVAp3GCSAp6gjOmCJdCB4YlyC943ej9IoryJ fOVpmm6IOchzDTJH/rgPUWbQnZFhVw4V1EkHfrYugci2Up30l4SsMieOPgfd6oAwDzlbAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFFQQtjTE3yoZgnE8infGLj+S7TiRMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQBpExGZx6F4 zM7Y/n7mnIsXl81PZas0VWUjE0MMdlX+FBxLg6+tSAZL+pi0i/iRb9bNg3KLqo0mpN2cnHa0Cyeo 9+DUJYdHtitY7O0oDfN6qsTLKkI2ff4VhVRahJMa9RlBHuiJa09Tlu/d1BqqjF8Vlf+1ygExN6dx PL95kbdwYM+0GILX+rt4okmVWgj4ol9JgBcQG6MA6rQvuoJHpfxv0I6yNXMMe3R86vfnz5XFHrX1 RfudaTWxM29kR44KxN19+TtVs2HTb/YAgGyyI3sxsX/keInYwKOZEpX3PwXn30CjjzPDjXR9+Zye K9iJUpsLFz8YJkPSc2e90JrrGAFuMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM YvQlQqbPmlmUoZynMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCChspSOitZQyMqA mPP678XDuF9j9WxqU2DMuvewIbbaFzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzExMjAxNjQ4MDVaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAe+6ysdbeHIeWaUFbproafdxpp247IEnX PuvIDdZ7VZ3AocW7ukcM6pg2aBv411lwO9SAIl7aeWa2HYI9FKmb0VXfX94Fw+gX3kzawl782/Rf /3ITYq0ZfZRSUIeHEOd78PiEGMuY74Idljwf74BPGbavqQc5VcXkUy3wYJ/E+amo12qq/DuDgA5I UXo3BMOTUUAI1k+B+ekbzv7DfCegSHc8yYGvBBA1zayDE6UO0QxCmPLSIc/KImMLSo9HqBQb08/d vhbu2eOjZV+Dm7k+IWqQfNFG4IrepKfpCCCg8BzX1JnJYkSK6cfp1pe0FOsmNu4/LTxf5gWkgsUG dg4srA== --94eb2c0ef650b4af0b055e6cd906-- From nobody Tue Nov 21 00:05: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 6CA4D12922E for ; Tue, 21 Nov 2017 00:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.071 X-Spam-Level: *** X-Spam-Status: No, score=3.071 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=0.922, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_CR_SURBL=1.263, URIBL_RED=0.001] 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 gqwXL79Z0tky for ; Tue, 21 Nov 2017 00:04:59 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C7EC1293D6 for ; Tue, 21 Nov 2017 00:04:58 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 5C6707A3309 for ; Tue, 21 Nov 2017 08:04:57 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Viktor Dukhovni In-Reply-To: <10BCA440-D21C-4061-9DD5-796449F1BB6E@treenet.co.nz> Date: Tue, 21 Nov 2017 03:04:54 -0500 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: <34CF68C8-1E86-4BEF-94F2-DB7004EC71D4@dukhovni.org> References: <10BCA440-D21C-4061-9DD5-796449F1BB6E@treenet.co.nz> To: uta@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [Uta] =?utf-8?q?=28Forgery=2C_clearly_not_the_real_Stephen_Farrel?= =?utf-8?q?l=29_Re=3A__=E2=98=80Re=3A_yahoo!_miserable_but_true?= X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 08:05:00 -0000 With only a bit of luck nobody will be fooled by this forgery. No idea what the link points to, best to not go there. > On Nov 21, 2017, at 2:45 AM, Stephen Farrell = wrote: >=20 > Dear,=20 >=20 >=20 > I've been looking for a few products when by chance I came across = that! It's so unfortunate, please read ant notify me what you think = http://www.moldremovaloakville.ca/concert.php?UE91dGFAaWV0Zi5vcmc- >=20 > Thanks for your consideration, Stephen Farrell --=20 Viktor. From nobody Sat Nov 25 18:56:40 2017 Return-Path: X-Original-To: uta@ietf.org Delivered-To: uta@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE1F1241FC; Sat, 25 Nov 2017 18:56:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: uta@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151166499392.16232.6735628437827584333@ietfa.amsl.com> Date: Sat, 25 Nov 2017 18:56:33 -0800 Archived-At: Subject: [Uta] I-D Action: draft-ietf-uta-email-deep-11.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Nov 2017 02:56:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Using TLS in Applications WG of the IETF. Title : Cleartext Considered Obsolete: Use of TLS for Email Submission and Access Authors : Keith Moore Chris Newman Filename : draft-ietf-uta-email-deep-11.txt Pages : 30 Date : 2017-11-25 Abstract: This specification outlines current recommendations for the use of Transport Layer Security (TLS) to provide confidentiality of email traffic between a mail user agent (MUA) and a mail submission or mail access server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-uta-email-deep/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-uta-email-deep-11 https://datatracker.ietf.org/doc/html/draft-ietf-uta-email-deep-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-email-deep-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/