Subject: [DNSOP] draft-zhang-dnsop-weak-trust-anchor.txt

From: "[email-masked]" <[email-masked]>
Date: Fri, 30 May 2014 15:40:07 +0800

Hi everybody here,
A new version of I-D, draft-zhang-dnsop-weak-trust-anchor-00.txthas been successfully submitted and posted to the?IETF repository.?Name:	 draft-zhang-dnsop-weak-trust-anchorRevision:	00Title:	 Weak Trust Anchor IntroductionDocument date:	2014-05-30Group:	 Individual SubmissionPages:	 7URL:?http://www.ietf.org/internet-drafts/draft-zhang-dnsop-weak-trust-anchor-00.txtStatus:?https://datatracker.ietf.org/doc/draft-zhang-dnsop-weak-trust-anchor/Htmlized:?http://tools.ietf.org/html/draft-zhang-dnsop-weak-trust-anchor-00??Abstract:?? DNS Security Extensions (DNSSEC) is an effective method to provide?? security protection for resolvers and end users in the DNS protocols.?? But the DNSSEC is too aggressive for the DNS service in the poor?? network infrastructure, because the domain name will be invisible?? when large DNSSEC messages were dropped by some other network?? equipments, like the routers which have MTU problem or the old?? firewalls which do not support ENDS0.? This document defines a new?? concept weak trust anchor which can be used on a security-aware?? resolver to get rid of the above problem.?
I am looking for feedback for this draft, feel free to comment.
Best regards
Haikuo

Haikuo ZhangCNNICcell phone:(+86)13910920813email: [email-masked]

---

From: Matthäus Wander <[email-masked]>
Date: Fri, 30 May 2014 15:05:32 +0200

Hi,

Section 4:
>    If the resolver was
>    configured with a weak trust anchor and got nothing after sending a
>    request with DO bit set, then it should clear DO bit in the EDNS0 in
>    the query message and query again to the authoritative name server.
>    So it could receive a normal DNS message (with no DNSSEC information,
>    if the previous packet loss was caused by large size) and continue
>    its DNS query process, then return the result as an insecure message.

The concept is vulnerable to downgrade attacks:
- An on-path MITM attacker can drop DNSSEC messages to force insecure
DNS and then spoof bogus DNS responses.
- An off-path attacker can saturate links to delay/drop DNSSEC messages
to force insecure DNS and then spoof bogus DNS responses.

The interoperability problems can be solved without degrading security,
e.g. fall back to TCP.

Regards,
Matt

-- 
Universität Duisburg-Essen
Verteilte Systeme
Bismarckstr. 90 / BC 316
47057 Duisburg

---

From: Mark Andrews <[email-masked]>
Date: Fri, 30 May 2014 23:56:56 +1000

In message <[email-masked]>, =?ISO-8859-1?Q?Matth=E4us_Wander?= wr
> The interoperability problems can be solved without degrading security,

And by sending EDNS packets with EDNS UDP size of 512.  If EDNS
@512 gets through DNSSEC will work.  It may not work as efficiently
as with a larger sizes but it will work unless you have .

> Regards,
> Matt
> 
> --=20
> Universit=E4t Duisburg-Essen
> Verteilte Systeme
> Bismarckstr. 90 / BC 316
> 47057 Duisburg
> 
> 
> --------------ms060506050302010200000506
> Content-Type: application/pkcs7-signature; name="smime.p7s"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment; filename="smime.p7s"
> Content-Description: S/MIME Cryptographic Signature
> 
> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPojCC
> BHQwggNcoAMCAQICCQCJkBEVWD6HmzANBgkqhkiG9w0BAQsFADBxMQswCQYDVQQGEwJERTEc
> MBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0
> IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMTQwMjEx
> MTMxMTQ1WhcNMTkwNzA5MjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZl
> cmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFs
> IC0gRzAxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1
> PWLpbkztlNcAW5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXst
> kEXQ7aAAeny/Sg4bAMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QP
> wQmi9mvOvdPNFDBP9eXjpMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz
> 2w/FEcKKg6GUXUFr2NIQ9Uz9ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXF
> bOqnC5j5IZ0nrz6jOTlIaoytyZn7wxLyvQIDAQABo4IBJDCCASAwDgYDVR0PAQH/BAQDAgEG
> MB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAWgBQxw3kbuvVT1xfg
> iXotF2wKsyudMzASBgNVHRMBAf8ECDAGAQH/AgECMD8GA1UdHwQ4MDYwNKAyoDCGLmh0dHA6
> Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL3JsL0RUX1JPT1RfQ0FfMi5jcmwweQYIKwYBBQUHAQEE
> bTBrMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcDAzMzYudGVsZXNlYy5kZS9vY3NwcjA7Bggr
> BgEFBQcwAoYvaHR0cDovL29jc3AwMzM2LnRlbGVzZWMuZGUvY3J0L0RUX1JPT1RfQ0FfMi5j
> ZXIwDQYJKoZIhvcNAQELBQADggEBACwvqeBeQy8FcNxRlXVdgI47DMFjWFSBMIOcXalRh8m2
> 1w8runhIJGBCzPGi4jPhMh4ym1ETlXnGtazQJO0YFLwvKuovq7ITrEkdXgALBBhqmmXU6Ec1
> vK7t33S22PGAUGWgxtojm41TR8psu0DJlV1OYHor5LtmQFWvtjPB6iMhbvxUnd0zQm5Ma9Xk
> w/LqBrdaMmoyRXS2tW/+6v8cY6q7iNH4WK8gfo+///b3OHeLGrZQP609R3lGw1e0F2KHvZ6j
> NiUHaCSqIvL2rynsN6UUma66AWCGdS1hFbp4loe1ks/hUJGeWToV7J5axob8KD5mutTZNa+t
> PEkihYfub48wggVgMIIESKADAgECAgQMGu+IMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYT
> AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE
> Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMDgwNDA4MTMyNDEwWhcNMTkwNjMwMDAw
> MDAwWjCBxjELMAkGA1UEBhMCREUxJDAiBgNVBAoTG1VuaXZlcnNpdGFldCBEdWlzYnVyZy1F
> c3NlbjE1MDMGA1UECxMsWmVudHJ1bSBmdWVyIEluZm9ybWF0aW9ucy0gdW5kIE1lZGllbmRp
> ZW5zdGUxLDAqBgNVBAMTI1VuaXZlcnNpdGFldCBEdWlzYnVyZy1Fc3NlbiBDQSAtRzAxMSww
> KgYJKoZIhvcNAQkBFh1jYWFkbWluQHVuaS1kdWlzYnVyZy1lc3Nlbi5kZTCCASIwDQYJKoZI
> hvcNAQEBBQADggEPADCCAQoCggEBAKuV6yZOaIyQrM+4cgkNSnGmOIKQ8vXx+ikL0K57ifXF
> EHE+dISywj/ZcBviQdasmaU+N3bbzU/YeYhCRqP6Y87DTEaTNhqf+spFvyC/Bvi/9wmELtMi
> Kg9NDs1+98yDmGg1hbuZzKQARjR4WU7zR0sc0ssxRCbxVHE8NL2wOUeAhRp2YzVg2SAnc8HR
> /QOpHtaIujKCAt2/EhkOQKdwWmSFuu99dTSRBVRyPyQw0bkXkSA1Rr/WROmp85T7eMCKRgw+
> U+F9bg28ptKmbynkFtEclCW17bSlN5YUYBq2/pGM7XR5Yeg/zyVL2qI6Yf6ST9yqo/a3M+jh
> oTrYGIaLg4kCAwEAAaOCAb8wggG7MBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEG
> MB0GA1UdDgQWBBRmZryWm0hN6N28IqemW9WoQZ+V7jAfBgNVHSMEGDAWgBRJt8bP6D0ff+pE
> exMp9/EKcD7eZDAoBgNVHREEITAfgR1jYWFkbWluQHVuaS1kdWlzYnVyZy1lc3Nlbi5kZTCB
> iAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3Qt
> Y2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xv
> YmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgaIGCCsGAQUFBwEBBIGVMIGSMEcGCCsG
> AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNl
> cnQvY2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9i
> YWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQADggEBAI5l
> i++72KyjuHfz41mQ72nFXkHsio661WPRTdzVvhYOBwY74UibrWTi4VOvwUyHYIJliXqaEkSK
> ZIgcyfktQYCC4uHsOui511s+IdN+5LmhtgTB/6C53MW61cUMP4PfMppATz6BlTMhZlAI/VnD
> 2vTZfQrs3zLeXdxBHKyHXe8YB0rQNBKG5FggRo9+mSol0Ei8/4rMyO8Ci8R6Du/t6awaBlqR
> UquCGaXMSIjFwRRjlcqE9lFJi841M47+sVDbybqZ+Y7yY8pJieLns8bbp403JFAlcw7yWh1d
> MiXDrBRK6dwxJ3QivAMtwsDprLG5BoXMKFIgdpOfB2m8C/1AS7gwggXCMIIEqqADAgECAgcU
> BUqoUjzGMA0GCSqGSIb3DQEBBQUAMIHGMQswCQYDVQQGEwJERTEkMCIGA1UEChMbVW5pdmVy
> c2l0YWV0IER1aXNidXJnLUVzc2VuMTUwMwYDVQQLEyxaZW50cnVtIGZ1ZXIgSW5mb3JtYXRp
> b25zLSB1bmQgTWVkaWVuZGllbnN0ZTEsMCoGA1UEAxMjVW5pdmVyc2l0YWV0IER1aXNidXJn
> LUVzc2VuIENBIC1HMDExLDAqBgkqhkiG9w0BCQEWHWNhYWRtaW5AdW5pLWR1aXNidXJnLWVz
> c2VuLmRlMB4XDTEyMDYyMzE0MDUxMloXDTE1MDYyMzE0MDUxMlowajELMAkGA1UEBhMCREUx
> JDAiBgNVBAoTG1VuaXZlcnNpdGFldCBEdWlzYnVyZy1Fc3NlbjEaMBgGA1UECxMRVmVydGVp
> bHRlIFN5c3RlbWUxGTAXBgNVBAMTEE1hdHRoYWV1cyBXYW5kZXIwggEiMA0GCSqGSIb3DQEB
> AQUAA4IBDwAwggEKAoIBAQCdvebzOQgKxEVxdvIOIyHq7kTrxRyCUJeDRnXSeauKlTkMImpa
> c8CJoW3XgYvdL1KCieCbXPeVLzyttcm//FbXIqFFxNsEJTHzT4J3P4lCzHalBZVJj7QXBjga
> wwWZk6BkA5smRwo/8u0bJCUsiieTwLE207kEzpDHyHsihgNukps+c97wfGBAV1UdKuOzL+Ez
> SCqyRrGi2yIM13ZnXJ6iVhirAmzdDYUdxBy28JOgPrqEKAn8HXDrGqtWweXSkrOsaxUdbMn/
> j4F7J9TW+mox92d8Y3y6ciWkCHlI/tfVrJFj4WBSxVWhv74pAy0FZGst5WKIXT5dGj0ruTYa
> EgclAgMBAAGjggIOMIICCjAcBgNVHSAEFTATMBEGDysGAQQBga0hgiwBAQQCAjAJBgNVHRME
> AjAAMAsGA1UdDwQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0O
> BBYEFNoA+aB85/Iq0n0Wh4a88PbxS6fzMB8GA1UdIwQYMBaAFGZmvJabSE3o3bwip6Zb1ahB
> n5XuMCYGA1UdEQQfMB2BG21hdHRoYWV1cy53YW5kZXJAdW5pLWR1ZS5kZTCBlwYDVR0fBIGP
> MIGMMESgQqBAhj5odHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1kdWlzYnVyZy1lc3Nlbi1j
> YS9wdWIvY3JsL2NhY3JsLmNybDBEoEKgQIY+aHR0cDovL2NkcDIucGNhLmRmbi5kZS91bmkt
> ZHVpc2J1cmctZXNzZW4tY2EvcHViL2NybC9jYWNybC5jcmwwgbAGCCsGAQUFBwEBBIGjMIGg
> ME4GCCsGAQUFBzAChkJodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1kdWlzYnVyZy1lc3Nl
> bi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwTgYIKwYBBQUHMAKGQmh0dHA6Ly9jZHAyLnBj
> YS5kZm4uZGUvdW5pLWR1aXNidXJnLWVzc2VuLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDAN
> BgkqhkiG9w0BAQUFAAOCAQEAAC2lYcZl901vzBN0O5ivksC1xI65dafiXRkd4iF3LXeQgDeb
> 1g38TgPPZROSfRzKKEMBfks5IvNy98ziqYbkDuLNPybbZ++PZQrFjeqfOgQZmqYZ+Tyi2PXb
> VJrXQqjr0zKyl7CmpWQ58akDlUIX3Zy5jqYeaccdYRfvkaCpHBLBgma+Cz6MLrD2sUDYCuEy
> PrvU8yut3YRuIf02+avlsRX5qW6aHmKyYHW6ObbjDVnPYB04oafJow0Xfs7JUDOaTUVON+RW
> BK6aFrbDftAKYgnhafRcq5iEl+g5tudoj9UdI7wk+nygsnbPdzlxveJJaRaMZBqrFLG1yvh1
> J1UNUjGCBJcwggSTAgEBMIHSMIHGMQswCQYDVQQGEwJERTEkMCIGA1UEChMbVW5pdmVyc2l0
> YWV0IER1aXNidXJnLUVzc2VuMTUwMwYDVQQLEyxaZW50cnVtIGZ1ZXIgSW5mb3JtYXRpb25z
> LSB1bmQgTWVkaWVuZGllbnN0ZTEsMCoGA1UEAxMjVW5pdmVyc2l0YWV0IER1aXNidXJnLUVz
> c2VuIENBIC1HMDExLDAqBgkqhkiG9w0BCQEWHWNhYWRtaW5AdW5pLWR1aXNidXJnLWVzc2Vu
> LmRlAgcUBUqoUjzGMAkGBSsOAwIaBQCgggKZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw
> HAYJKoZIhvcNAQkFMQ8XDTE0MDUzMDEzMDUzMlowIwYJKoZIhvcNAQkEMRYEFJxtpolH4Xgi
> WvzLvWoKpntteoaNMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB
> AjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw
> DQYIKoZIhvcNAwICASgwgeMGCSsGAQQBgjcQBDGB1TCB0jCBxjELMAkGA1UEBhMCREUxJDAi
> BgNVBAoTG1VuaXZlcnNpdGFldCBEdWlzYnVyZy1Fc3NlbjE1MDMGA1UECxMsWmVudHJ1bSBm
> dWVyIEluZm9ybWF0aW9ucy0gdW5kIE1lZGllbmRpZW5zdGUxLDAqBgNVBAMTI1VuaXZlcnNp
> dGFldCBEdWlzYnVyZy1Fc3NlbiBDQSAtRzAxMSwwKgYJKoZIhvcNAQkBFh1jYWFkbWluQHVu
> aS1kdWlzYnVyZy1lc3Nlbi5kZQIHFAVKqFI8xjCB5QYLKoZIhvcNAQkQAgsxgdWggdIwgcYx
> CzAJBgNVBAYTAkRFMSQwIgYDVQQKExtVbml2ZXJzaXRhZXQgRHVpc2J1cmctRXNzZW4xNTAz
> BgNVBAsTLFplbnRydW0gZnVlciBJbmZvcm1hdGlvbnMtIHVuZCBNZWRpZW5kaWVuc3RlMSww
> KgYDVQQDEyNVbml2ZXJzaXRhZXQgRHVpc2J1cmctRXNzZW4gQ0EgLUcwMTEsMCoGCSqGSIb3
> DQEJARYdY2FhZG1pbkB1bmktZHVpc2J1cmctZXNzZW4uZGUCBxQFSqhSPMYwDQYJKoZIhvcN
> AQEBBQAEggEAcY/Yc/bjfgHEvaccGhgop4qWNQm7NWMaPF791EURXahKcaS2e5N21yFA72xf
> yHiSN99H7RLMdMhWfq/2udaVKwI9Zg/9gnKbMwK+36IXr0SmfUXaSvvwq3R2EGrz9dyzz0gB
> 36kIha7csv7a03YYwkbLnaTiMb9jEv2gMOq3yorz5Dp2YDkYtrZHsCS5TY0BM/Y21D5d/4TF
> MV34szNSWrpY/5vOVMhnBmQoSQgP2rIseCRT3U5zyEjtI0uFQ+BQsR1D1quMQ8XusB3vHhAm
> 3E59s/ojdW9nDO9xJUfFT4WX9hBFkYbUTOAjMfg0KNADPS59Pq9McIKMKnVt3TsB0wAAAAAA
> AA==
> --------------ms060506050302010200000506--
> 
> 
> --===============3145706613823098466==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> --===============3145706613823098466==--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Fri, 30 May 2014 14:11:45 -0400 (EDT)

On Fri, 30 May 2014, [email-masked] wrote:

> Name: draft-zhang-dnsop-weak-trust-anchor

> URL: http://www.ietf.org/internet-drafts/draft-zhang-dnsop-weak-trust-anchor-00.txt
> Status: https://datatracker.ietf.org/doc/draft-zhang-dnsop-weak-trust-anchor/
> Htmlized: http://tools.ietf.org/html/draft-zhang-dnsop-weak-trust-anchor-00
>  
>  
> Abstract:
>    DNS Security Extensions (DNSSEC) is an effective method to provide
>    security protection for resolvers and end users in the DNS protocols.
>    But the DNSSEC is too aggressive for the DNS service in the poor
>    network infrastructure, because the domain name will be invisible
>    when large DNSSEC messages were dropped by some other network
>    equipments, like the routers which have MTU problem or the old
>    firewalls which do not support ENDS0.  This document defines a new
>    concept weak trust anchor which can be used on a security-aware
>    resolver to get rid of the above problem.
>  
> 

A very skeptical person would describe this draft as a protocol backdoor
to disable DNSSEC to faciliate DNS spoofing to unwitting victims.

The draft claims to address two problems:

1 MTU issues with DNSSEC by misconfigured firewalls dropping
   large (and/or fragmented?) UDP.

2 old firewalls dropping EDNS0 packets by not recognising these as valid
  DNS packets.

The first issue is not a problem, the DNS software could request smaller
UDP packets using EDNS0, or it could fall back to TCP. No protocol
modifications are required for this to work.

The second issue is about broken software for a standard released in
August 1999 (RFC 2671), and assumes that the end hosts will actually
timely update by implementing this new 2014 document???

And to accomodate such broken software, it would requires the client to
completely disable DNSSEC when the network filters out expected DNSSEC
responses to queries it sent, without being able to tell this packet
drop was due to "old firewalls" or a MITM attack.

If this document is really meant to assist newer endnodes from operating
in old broken networks, you should find a way to accomplish this that
does not require disabling DNSSEC and does not require any DNS protocol
change.

Note also that for this problem, there is already a commonly deployed
solution at the application level that addresses this situation, such
as https://www.nlnetlabs.nl/projects/dnssec-trigger/ which will inform
the user the network is severely broken or the user is under attack,
and gives the user the option to disable DNSSEC and go "insecure".
Contrary to the proposed draft, the user is informed and consent is
requested before disabling a security control the user has activated
for good reasons on their system.

I do not believe your stated problem is one that needs addressing.

I do not believe the Security Considerations section of your draft
even remotely begins to address the problems of completely disabling
DNSSEC transparently without user consent.

Paul

---

From: Evan Hunt <[email-masked]>
Date: Fri, 30 May 2014 18:32:34 +0000

> and gives the user the option to disable DNSSEC and go "insecure".

Also negative trust anchors, which seems to have stalled in the IETF
(http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-06)
but has been implemented in some validators (and will be in BIND in
a future release).

> I do not believe your stated problem is one that needs addressing.

+1

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Ralf Weber <[email-masked]>
Date: Sat, 31 May 2014 00:16:07 +0000

Moin!

> but has been implemented in some validators (and will be in BIND in
Oh good, so now that everybody has/will implemented it can we maybe work on that draft again.

>> I do not believe your stated problem is one that needs addressing.
+1. I think that the problem has been addressed already as others have stated.

So long
-Ralf
---
Ralf Weber
Senior Infrastructure Architect
Nominum Inc.
2000 Seaport Blvd. Suite 400 
Redwood City, California 94063
[email-masked]