From lutz@iks-jena.de Fri Jul 1 00:25:55 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77F521F862B for ; Fri, 1 Jul 2011 00:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90S5GDIll8Ls for ; Fri, 1 Jul 2011 00:25:55 -0700 (PDT) Received: from annwfn.iks-jena.de (annwfn-eth.iks-jena.de [IPv6:2001:4bd8:0:104:20a:e4ff:fe80:3138]) by ietfa.amsl.com (Postfix) with ESMTP id B406B21F852B for ; Fri, 1 Jul 2011 00:25:53 -0700 (PDT) X-SMTP-Sender: IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f Received: from belenus.iks-jena.de (belenus.iks-jena.de [IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f]) by annwfn.iks-jena.de (8.14.3/8.14.1) with ESMTP id p617PmgA004667 for ; Fri, 1 Jul 2011 09:25:50 +0200 X-MSA-Host: belenus.iks-jena.de Received: (from lutz@localhost) by belenus.iks-jena.de (8.14.3/8.14.1/Submit) id p617PjlP026449; Fri, 1 Jul 2011 09:25:45 +0200 From: Lutz Donnerhacke Message-Id: <201107010725.p617PjlP026449@belenus.iks-jena.de> To: dnsext@ietf.org In-Reply-To: Date: Fri, 1 Jul 2011 09:25:45 +0200 User-Agent: slrn/pre0.9.9-77 (Linux) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Insecure Delegation Proofs X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 07:25:55 -0000 You wrote: > Since the insecure NS records are not signed (at all!), they can be spoofed. > (IMHO, the lack of signature on NS (without DS) is uncool in the > extreme. Having NS RRSIGs, even though they are not authoritative, > would still have been compatible with opt-out. But that ship has > sailed, as they say.) Glue is never signed, because it's impossible to distinguish algorithmically between an answer from the zone or its parent zone. It is possible to copy the glue records from the authoritive servers and include those (deeper) signed records as glue, but the validator can't really make benefit from. That's why the key material is distributed in two record types: DNSKEY contained by the zone DS containted by the parent zone A zone is not allowed to sign or respond with its own DS records and a parent zone is not allowed to sign or respond with the child DNSKEY records. Moving a special record of the zone into the parent allows the resolver to distinguish the various delegation levels and complete the delegation chain by asking for DS records explicitly (to overcome the grandparent problem). Consequently the RRSIG of a response from the parent zone can only cover the DS (because it's authoritive) and not the NS (because it's glue). OTOH the RRSIG of a response from the child zone has to cover at least the DNSKEY, NS, and SOA records (because they are authoritive and needed for a correct setup) and never DS (because it's not in scope). For the usual historical remarks, let me point out, that the early DNSSEC idea was to put the whole key material into the parent zone (KEY with SEP bit) and the client zone (KEY without SEP bit). > The attack is, to over-write a *signed* NS (with DS), by an unsigned > NS (with no DS or any other DNSSEC record). Sorry, I do not get it. Why should an unsigned NS record be accepted at all? If the zone y.z is signed, there is either an signed DS for x.y.z or an NSEC(3) record covering x.y.z. Only in this case the response from the parent is correct. And even in this case the attacker can simply modify the NS (glue) entries on the fly. > The defense is, to check the hash of any unsigned NS, and if it > matches an NSEC3 with opt-out, it clearly is a forgery and should be > discarded. Why? That's a legitim response from a parent zone. > To prevent this NS hijacking, the NS has to be hashed. There is no way to prevent glue modifications at all. From davidb@verisign.com Fri Jul 1 06:28:42 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD1011E80CF for ; Fri, 1 Jul 2011 06:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1oxDp+8dZk6 for ; Fri, 1 Jul 2011 06:28:41 -0700 (PDT) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id 926A711E80CA for ; Fri, 1 Jul 2011 06:28:40 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKTg3LhvZrlDZi7RI/npXeyITIXHCZ7ghQ@postini.com; Fri, 01 Jul 2011 06:28:40 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p61DSbG9011325; Fri, 1 Jul 2011 09:28:37 -0400 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jul 2011 09:28:37 -0400 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.205]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jul 2011 09:28:36 -0400 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com (10.173.152.206) by brn1wnexcas01.vcorp.ad.vrsn.com (10.173.152.205) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 1 Jul 2011 09:28:36 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0289.001; Fri, 1 Jul 2011 09:28:35 -0400 From: "Blacka, David" To: Sean Wells Thread-Topic: [dnsext] Insecure Delegation Proofs Thread-Index: AQHMN1qUpwJKDDaAkEemA95misk0TZTXueeA Date: Fri, 1 Jul 2011 13:28:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail-36-507233839"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-OriginalArrivalTime: 01 Jul 2011 13:28:36.0786 (UTC) FILETIME=[C83B8920:01CC37F2] Cc: "" Subject: Re: [dnsext] Insecure Delegation Proofs X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 13:28:42 -0000 --Apple-Mail-36-507233839 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 30, 2011, at 3:18 PM, Sean Wells wrote: > Hi, >=20 > DNSSEC bis updates document states: >=20 > [RFC4035] Section > = 5.2specifies > that a validator, when proving a >=20 > delegation is not secure, needs to check for the absence of the DS > and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also > needs to check for the presence of the NS bit in the matching NSEC > (or NSEC3) RR (proving that there is, indeed, a delegation), or > alternately make sure that the delegation is covered by an NSEC3 RR > with the Opt-Out flag set. If this is not checked, spoofed unsigned > delegations might be used to claim that an existing signed record is > not signed. >=20 >=20 > The last sentence is confusing: what is a "spoofed unsigned > delegation" ? Let us say that there are two delegations one of which > is secure. A spoofed unsigned delegation is a spoofed response in the form of a = referral ("delegation" basically means referral here) without a DS = RRset. > a.com is secure, so there is a DS record in com >=20 > b.com is insecure, so there is a NSEC record for b.com in com with DS, > SOA bits not set but the NS bit set. >=20 >=20 > I am looking up the DS record for "a.com". The attacker is responding > the NSEC record for b.com (or it was already in my cache). In this > case, the owner name does not match the SNAME (a.com). I thought we > checked the bitmap of the NSEC only if the owner name matches. This > NSEC record might still be accepted depending on what is there in the > "Next domain field". Is this the attack that is being described ? No. This attack is about obscuring non-delegation names (i.e., and = "existing signed record") with the spoofed delegation. So, imagine you = have a signed zone, foo.example. In that zone, you have an RRset that = an attacker wants to change: secure.foo.example/A. Now, there exists an = NSEC record for secure.foo.example: =20 secure.foo.example NSEC secure2.foo.example A NSEC RRSIG So, when a client asks for secure.foo.example/A, the attacker spoofs a = response that looks like this: secure.foo.example NS bad-ns1.attacker.example. secure.foo.example NS bad-ns2.attacker.example. secure.foo.example NSEC secure2.foo.example A NSEC RRSIG secure.foo.example RRSIG NSEC ... That is, the attacker uses the existing NSEC for secure.foo.example. = Note however, that this NSEC record's type map does not have the DS bit = set. So, if you are a naive validator, you might just follow the = referral, noting it is insecure (because the DS bit isn't set), but fail = to notice that it shouldn't have been a delegation at all. Hence the = advice. -- David Blacka =20 Principal Engineer Verisign Infrastructure Engineering --Apple-Mail-36-507233839 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMpzCCBhow ggUCoAMCAQICEBc0Avppt6vT9KJWAKLsKTAwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDMwMzAwMDAwMFoXDTE5MDMwMjIzNTk1OVowgbAxCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWdu LmNvbS9ycGEgKGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBH MzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZBVVIHbQdG81jb1cp+jOE4D5vUIaST JqKfkRcKNC8Q7l/sEuBplO3NRos9MRwdagtQtfeTiZC8NwQ1IfbPIAtd3BO4u5WRzWdD2G4BRTbK C/nkXDtJYGVgFD2m+OXsS31p4ryXlZo2OhbKQvXZof0qUWI/79smv37sOG9jRsPHUPVeMVtqtuHf YoG0PBNOfyu0Qq2W4a2RzYToKLekE4cJejlMLIsq8fk5J3Vb/hicWuNA9nVS8K5OZJ7dmNVxiqA6 yvWTt5u0lDLCRjYBUWuQ95AIG3yyTnCP8A39k3jlP24fYcIe1r1By2Fk7uzH/L9sOnrSFL8Aq9WS zws+u0UCAwEAAaOCAhIwggIOMBIGA1UdEwEB/wQIMAYBAf8CAQAwNAYDVR0fBC0wKzApoCegJYYj aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMHAGA1Ud IARpMGcwZQYLYIZIAYb4RQEHFwIwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTA3MB0GA1UdDgQWBBTVH5Sm O27W26S0sXCieoiKViFvFTCB8AYDVR0jBIHoMIHloYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IQYXDLSYxfmEUp57Cm2VBbejANBgkqhkiG9w0BAQUFAAOCAQEAFTXCpaBB Rq5kc0XwUen7u5EsOzy7iiwvAHrsd7PKLCHg0NSbZKWg4Tzk/Yl5HRl59esmG7e6avTxiEaDG7OV 2+BX5sEfFvKQmtTFyiI3sozDNs+nCFQ+ksSzNVS0msKRSX22qik6AH6diXmQvcb0PIM4QuZadhb+ qwxac5AvA8IKgfPkaXdnIpcotuqtKaqHe60qUw7hnCpN9gamcUoNDVx0Gu1nObq2usSjCVvXWiYY ohDin9MHLkmJ1uYOoRzsQA4WXVAa11UpMXsnd6JotLVKLnrjgZEdK0id0RTBpVbcI9VgxP1LCEaw rYgwfjsT08wUtdampqUUPcljHG4SzDCCBoUwggVtoAMCAQICECvwr+5g4ykMmRdZyEk9APUwDQYJ KoZIhvcNAQEFBQAwgbAxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNz IDIgRW1wbG95ZWUgQ0EgLSBHMzAeFw0xMTA1MTEwMDAwMDBaFw0xMjA1MTAwMDAwMDBaMGsxaTAQ BgNVBAsUCVZDT1JQIFVBUzAUBgNVBAMTDUJsYWNrYSwgRGF2aWQwHQYDVQQKFBZWZXJpU2lnbiBJ bmMuIFZDT1JQVUFTMCAGCSqGSIb3DQEJARYTZGF2aWRiQHZlcmlzaWduLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOFr4D6qtYX78Fwj5I+EKxkemPlg5PON2FAMElOxon6vuLv7 yRUPr7FdNu1RDd0QYni5EMQ/2cNpjQVRSrfrCNqoWkJ9y3iUHnQH+/29uOuafcxjZ11BaUo1AwpB ifMJD4PgPv4aP3kuusxY0lI3rVXJKnezejgRRGO+6n68VYQnbunJ0P0cdJvU+ZNpOkKj9y8eTG0h ynFnBP0UAgQ2f+E0c3u67ie54rHbdDNVMGECvjXjWs5KhXMR68tGCE2K7roer2v27N8VIWq5jrIU q9PLx8zjI6FThbu9ZzQCoToc7UGmeHV/oUiWKheAavj/D4iVupdZ07SPYUEnGGd5wYsCAwEAAaOC At0wggLZMAkGA1UdEwQCMAAwSAYDVR0RBEEwP4ETZGF2aWRiQHZlcmlzaWduLmNvbaAoBgorBgEE AYI3FAIDoBoMGGRhdmlkYkB2Y29ycC5hZC52cnNuLmNvbTAmBgkrBgEEAYI3FQcEGTAXBg9ghkgB hvhFAQ0EiGeB6AUCAWQCAQMwYQYDVR0fBFowWDBWoFSgUoZQaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vY2FfMzBlMmNkOGJhMjkzMDljYTAyMDJkMTVkNGJjZGYzZjAvTGF0ZXN0Q1JMLmNy bAAwggEGBgNVHSMEgf4wgfuAFNUflKY7btbbpLSxcKJ6iIpWIW8VoYHQpIHNMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQFzQC+mm3q9P0olYAouwpMDBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBxcCMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYD VR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDB7BgkqhkiG9w0BCQ8EbjBs MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAHBgUrDgMCGjAKBggqhkiG9w0C AjAKBggqhkiG9w0CBDAKBggqhkiG9w0CBTALBgkqhkiG9w0BAQUwCwYJKoZIhvcNAQEEMA0GCSqG SIb3DQEBBQUAA4IBAQBFpX/mFvxKbdeTruA4rSlIv9JREutn5/MiOpRqhvuuAEnei3ltZ2AdURZ/ 2dvNTfEeQphSCD/l9+rVxbZKEcaKxBYeV3sSAEsOVhsc+ruZKFLnwAzEm7u/rTfkyO+qYV2zWjqA Bq9UoIDTQ9ogjYZ7A0JWnYwj8VpTA2gqBqe6ya+k9/l/GuWyVm2PW/b8OGBzi4VsQYy2WE8KGHr1 nn5znY3KZswuyRQLnzlhSdwowUFDg/yaqolSWgP1HyJGs4Ek1ZL/9DGyH/QmfxCURP2Q7CIJSUYn yDNus5pZbifQbIOBA399fc0ASqM5lKbmIrAln3FQNIoX2P0RB+Hqg1HvMYIEAjCCA/4CAQEwgcUw gbAxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUg Q0EgLSBHMwIQK/Cv7mDjKQyZF1nIST0A9TAJBgUrDgMCGgUAoIICETAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA3MDExMzI4MzVaMCMGCSqGSIb3DQEJBDEWBBTP vEYk5NoZNJk+1dY4g5bUBRYRlTCB1gYJKwYBBAGCNxAEMYHIMIHFMIGwMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MSowKAYDVQQDEyFWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBIC0gRzMCECvwr+5g4ykM mRdZyEk9APUwgdgGCyqGSIb3DQEJEAILMYHIoIHFMIGwMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MSowKAYD VQQDEyFWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBIC0gRzMCECvwr+5g4ykMmRdZyEk9APUw DQYJKoZIhvcNAQEBBQAEggEAtaNSyR0aCBcGQTVOrYqsWwDMLrrWFkmPFBeqo8mgpb0RlRgMcU+P tDbIEv/LUfGGBiT/LBiUD/ac1y10otRcln8a8Fx4zGP7cXwPF0Fm7MdmpERxuZz+6YS588D9eoVM RwsqQlwgxq5aHsdWpphJiITYfLb8jhevxly8l37BZXyh7QujR5AzKpLyUkt4jlJyjyPYw6JEFK6M LYxBQQP1pa4J0BGZI83XYluYRZq8BB5IifFfQDcPaLaBQq4JJzwmyCrzRNtsoa53j7VrBAsziqaP jEkBoFltyzEhyj90emTIotErsb6dVq3QxfKUDA9NwHdMBE473ElBrsPJKLBsUwAAAAAAAA== --Apple-Mail-36-507233839-- From marka@isc.org Thu Jun 30 17:58:43 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4F911E8090 for ; Thu, 30 Jun 2011 17:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.667 X-Spam-Level: X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xu5HqunC7rW1 for ; Thu, 30 Jun 2011 17:58:43 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id F009E11E8085 for ; Thu, 30 Jun 2011 17:58:42 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 6FF03C942B for ; Fri, 1 Jul 2011 00:58:31 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 0C148216C7B for ; Fri, 1 Jul 2011 00:58:31 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 137A4115480D for ; Fri, 1 Jul 2011 10:58:29 +1000 (EST) Date: Fri, 01 Jul 2011 10:58:29 +1000 Message-Id: <20110701005829.137A4115480D@drugs.dv.isc.org> From: marka@isc.org To: undisclosed-recipients:; X-Mailman-Approved-At: Fri, 01 Jul 2011 08:54:13 -0700 Subject: Re: [dnsext] DNAME? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 00:58:43 -0000 ------- Blind-Carbon-Copy To: "Jon F." Cc: Timothe Litt , bind-users@isc.org From: Mark Andrews References: <45336A86FEAC4E029843F665D31B588A@sb.litts.net> Subject: Re: DNAME? In-reply-to: Your message of "Thu, 30 Jun 2011 15:10:38 EST." Date: Fri, 01 Jul 2011 10:58:29 +1000 In message , "Jon F." write s: > I have a similar set up to that and it works. Have you checked the logs to > make sure the zone properly loaded? I'm assuming the zone data you posted > below is from the example.us zone but your first question makes it sound > like you put it in a seperate zone. That would explain the SERVFAIL if the > zone data never loaded but the server was authoritative. It does need to be > in the .us. > > > ;; ANSWER SECTION: > example.com. 60 IN DNAME example.net. > test.example.com. 60 IN CNAME test.example.net. > test.example.net. 60 IN A 127.0.0.1 > > > > And that's with zone data like this: > example.com. IN NS ns1.example.net. > example.com. IN NS ns2.example.net. > example.com. IN A 10.0.0.1 > example.com. IN DNAME example.net. > > > Truthfully I haven't looked at DNAME's in a long time so I'm unsure how to > do it fully for a domain without adding an A record as well. But what your > doing works, it's just not very pretty. Someone may have a better way. There is an outstanding proposals for BNAME. This would be added to the parent zone instead of NS records and would synthesis CNAMEs records for the domain and its children. This has got bogged down in IETF politics over how to fix idn rather that be allowed to stand on its own merits. Mark - -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org ------- End of Blind-Carbon-Copy From snwells82@gmail.com Fri Jul 1 09:49:21 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D481F0C95 for ; Fri, 1 Jul 2011 09:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.531 X-Spam-Level: X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7Z4I4ajt7XX for ; Fri, 1 Jul 2011 09:49:21 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B63C11F0C92 for ; Fri, 1 Jul 2011 09:49:20 -0700 (PDT) Received: by vws12 with SMTP id 12so3058611vws.31 for ; Fri, 01 Jul 2011 09:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AdPzzg0/7YrdMRN8WsBqhFbCXw13WQknz6/TsTQmjVo=; b=YUwZcYt+KtgQ/zoWLm00qME0Ny5BFU02jQ079xKQP6w66kPonPmkBHtWMcsxhofyeN ZyNbR8eTjBYs8dS+59TxSm90QKyTro3o6OJZ/hvmdY2iyCKKZF/pfO2IV4edYs6PTiq9 4dTKOCucKYqSztb2lP0a9d4e9n4sqS5IkKsNo= MIME-Version: 1.0 Received: by 10.220.213.202 with SMTP id gx10mr1359123vcb.77.1309538959946; Fri, 01 Jul 2011 09:49:19 -0700 (PDT) Received: by 10.220.198.200 with HTTP; Fri, 1 Jul 2011 09:49:19 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Jul 2011 09:49:19 -0700 Message-ID: From: Sean Wells To: "Blacka, David" Content-Type: multipart/alternative; boundary=bcaec54eef9a86f4e404a704cce8 Cc: "" Subject: Re: [dnsext] Insecure Delegation Proofs X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 16:49:21 -0000 --bcaec54eef9a86f4e404a704cce8 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 1, 2011 at 6:28 AM, Blacka, David wrote: > > On Jun 30, 2011, at 3:18 PM, Sean Wells wrote: > > > Hi, > > > > DNSSEC bis updates document states: > > > > [RFC4035] Section > > 5.2< > http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-12#section-5.2 > >specifies > > that a validator, when proving a > > > > delegation is not secure, needs to check for the absence of the DS > > and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also > > needs to check for the presence of the NS bit in the matching NSEC > > (or NSEC3) RR (proving that there is, indeed, a delegation), or > > alternately make sure that the delegation is covered by an NSEC3 RR > > with the Opt-Out flag set. If this is not checked, spoofed unsigned > > delegations might be used to claim that an existing signed record is > > not signed. > > > > > > The last sentence is confusing: what is a "spoofed unsigned > > delegation" ? Let us say that there are two delegations one of which > > is secure. > > A spoofed unsigned delegation is a spoofed response in the form of a > referral ("delegation" basically means referral here) without a DS RRset. > > > a.com is secure, so there is a DS record in com > > > > b.com is insecure, so there is a NSEC record for b.com in com with DS, > > SOA bits not set but the NS bit set. > > > > > > I am looking up the DS record for "a.com". The attacker is responding > > the NSEC record for b.com (or it was already in my cache). In this > > case, the owner name does not match the SNAME (a.com). I thought we > > checked the bitmap of the NSEC only if the owner name matches. This > > NSEC record might still be accepted depending on what is there in the > > "Next domain field". Is this the attack that is being described ? > > No. This attack is about obscuring non-delegation names (i.e., and > "existing signed record") with the spoofed delegation. So, imagine you have > a signed zone, foo.example. In that zone, you have an RRset that an > attacker wants to change: secure.foo.example/A. Now, there exists an NSEC > record for secure.foo.example: > > secure.foo.example NSEC secure2.foo.example A NSEC RRSIG > > So, when a client asks for secure.foo.example/A, the attacker spoofs a > response that looks like this: > > secure.foo.example NS bad-ns1.attacker.example. > secure.foo.example NS bad-ns2.attacker.example. > secure.foo.example NSEC secure2.foo.example A NSEC RRSIG > secure.foo.example RRSIG NSEC ... > > That is, the attacker uses the existing NSEC for secure.foo.example. Note > however, that this NSEC record's type map does not have the DS bit set. So, > if you are a naive validator, you might just follow the referral, noting it > is insecure (because the DS bit isn't set), but fail to notice that it > shouldn't have been a delegation at all. Hence the advice. > > Ah! got it. An example always makes it much clearer. This is not even an attack. I could have looked up a name (that does not exist) earlier that resulted in the NSEC record in my cache and later when I look up the DS record, this would answer it. I suggest we reword the last sentence to make it clearer. Something like: As every authoritative name in the zone has a valid NSEC record, it could potentially answer a question that is looking for a DS record for any such name. Checking the NS bit makes sure that this NSEC record will not be mistaken for a unsigned delegation. does that sound right ? I wouldn't even call it an attack. The best way is to show the above example in the appendix. thanks Sean -- > David Blacka > Principal Engineer Verisign Infrastructure Engineering > > -- Sean --bcaec54eef9a86f4e404a704cce8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jul 1, 2011 at 6:28 AM, Blacka, = David <davidb@v= erisign.com> wrote:

On Jun 30, 2011, at 3:18 PM, Sean Wells wrote:

> Hi,
>
> DNSSEC bis updates document states:
>
> [RFC4035] Section
> 5.2<http://tools.ietf.org/h= tml/draft-ietf-dnsext-dnssec-bis-updates-12#section-5.2>specifies
> that a validator, when proving a
>
> =A0 delegation is not secure, needs to check for the absence of the DS=
> =A0 and SOA bits in the NSEC (or NSEC3) type bitmap. =A0The validator = also
> =A0 needs to check for the presence of the NS bit in the matching NSEC=
> =A0 (or NSEC3) RR (proving that there is, indeed, a delegation), or > =A0 alternately make sure that the delegation is covered by an NSEC3 R= R
> =A0 with the Opt-Out flag set. =A0If this is not checked, spoofed unsi= gned
> =A0 delegations might be used to claim that an existing signed record = is
> =A0 not signed.
>
>
> The last sentence is confusing: what is a "spoofed unsigned
> delegation" ? Let us say that there are two delegations one of wh= ich
> is secure.

A spoofed unsigned delegation is a spoofed response in the form of a = referral ("delegation" basically means referral here) without a D= S RRset.

> a.com is secure, so the= re is a DS record in com
>
> b.com is insecure, so t= here is a NSEC record for b.com<= /a> in com with DS,
> SOA bits not set but the NS bit set.
>
>
> I am looking up the DS record for "a.com". The attacker is responding
> the NSEC record for b.com (or it was already in my cache). In this
> case, the owner name does not match the SNAME (a.com). I thought we
> checked the bitmap of the NSEC only if the owner name matches. This > NSEC record might still be accepted depending on what is there in the<= br> > "Next domain field". Is this the attack that is being descri= bed ?

No. =A0This attack is about obscuring non-delegation names (i.e., and= "existing signed record") with the spoofed delegation. =A0So, im= agine you have a signed zone, foo.example. =A0In that zone, you have an RRs= et that an attacker wants to change: secure.foo.example/A. =A0Now, there ex= ists an NSEC record for secure.foo.example:

=A0secure.foo.example NSEC secure2.foo.example A NSEC RRSIG

So, when a client asks for secure.foo.example/A, the attacker spoofs a resp= onse that looks like this:

=A0secure.foo.example NS bad-ns1.attacker.example.
=A0secure.foo.example NS bad-ns2.attacker.example.
=A0secure.foo.example NSEC secure2.foo.example A NSEC RRSIG
=A0secure.foo.example RRSIG NSEC ...

That is, the attacker uses the existing NSEC for secure.foo.example. =A0Not= e however, that this NSEC record's type map does not have the DS bit se= t. =A0So, if you are a naive validator, you might just follow the referral,= noting it is insecure (because the DS bit isn't set), but fail to noti= ce that it shouldn't have been a delegation at all. =A0Hence the advice= .

Ah! got it. An example= always makes it much clearer. This is not even an attack. I could have loo= ked up a name (that does not exist) earlier that resulted in the NSEC recor= d in my cache and later when I look up the DS record, this would answer it.= =A0I suggest we reword the last sentence to make it clearer. =A0Something = like:

=A0 =A0 =A0 =A0As every authoritative name in the zone = has a valid NSEC record, it could potentially answer a question
= =A0 =A0 =A0 =A0that is looking for a DS record for any such name.=A0Checkin= g the NS bit makes sure=A0that this NSEC record
=A0 =A0 =A0 =A0will not be mistaken for a unsigned delegation.

does that sound right ? I wouldn't even call it an at= tack. The best way is to show the above example in the appendix.=A0

thanks
Sean

--
David Blacka =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<davidb@verisign.com>
Principal Engineer =A0 =A0 =A0Verisign Infrastructure Engineering




--
Sean
--bcaec54eef9a86f4e404a704cce8-- From davidb@verisign.com Fri Jul 1 10:53:07 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2B711E809F for ; Fri, 1 Jul 2011 10:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxffgeRLz8UY for ; Fri, 1 Jul 2011 10:53:07 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 6984011E8078 for ; Fri, 1 Jul 2011 10:53:06 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKTg4JgHu2KrX8timwAfIBsACgcwk0j94q@postini.com; Fri, 01 Jul 2011 10:53:06 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p61Hr4Mo030522; Fri, 1 Jul 2011 13:53:04 -0400 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jul 2011 13:53:03 -0400 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.205]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jul 2011 13:53:03 -0400 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com (10.173.152.206) by brn1wnexcas01.vcorp.ad.vrsn.com (10.173.152.205) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 1 Jul 2011 13:53:03 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0289.001; Fri, 1 Jul 2011 13:53:02 -0400 From: "Blacka, David" To: Sean Wells Thread-Topic: [dnsext] Insecure Delegation Proofs Thread-Index: AQHMN1qUpwJKDDaAkEemA95misk0TZTXueeAgAA4FYCAABHOAA== Date: Fri, 1 Jul 2011 17:53:02 +0000 Message-ID: <3294DE6F-0618-4083-8AE8-254EF8618087@verisign.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail-38-523100696"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-OriginalArrivalTime: 01 Jul 2011 17:53:03.0730 (UTC) FILETIME=[B9AB0D20:01CC3817] Cc: "" Subject: Re: [dnsext] Insecure Delegation Proofs X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 17:53:07 -0000 --Apple-Mail-38-523100696 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 1, 2011, at 12:49 PM, Sean Wells wrote: > On Fri, Jul 1, 2011 at 6:28 AM, Blacka, David = wrote: >=20 >>=20 >> On Jun 30, 2011, at 3:18 PM, Sean Wells wrote: >>=20 >>> Hi, >>>=20 >>> DNSSEC bis updates document states: >>>=20 >>> [RFC4035] Section >>> 5.2< >> = http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-12#section= -5.2 >>> specifies >>> that a validator, when proving a >>>=20 >>> delegation is not secure, needs to check for the absence of the DS >>> and SOA bits in the NSEC (or NSEC3) type bitmap. The validator = also >>> needs to check for the presence of the NS bit in the matching NSEC >>> (or NSEC3) RR (proving that there is, indeed, a delegation), or >>> alternately make sure that the delegation is covered by an NSEC3 RR >>> with the Opt-Out flag set. If this is not checked, spoofed = unsigned >>> delegations might be used to claim that an existing signed record = is >>> not signed. >>>=20 >>>=20 >>> The last sentence is confusing: what is a "spoofed unsigned >>> delegation" ? Let us say that there are two delegations one of which >>> is secure. >>=20 >> A spoofed unsigned delegation is a spoofed response in the form of a >> referral ("delegation" basically means referral here) without a DS = RRset. >>=20 >>> a.com is secure, so there is a DS record in com >>>=20 >>> b.com is insecure, so there is a NSEC record for b.com in com with = DS, >>> SOA bits not set but the NS bit set. >>>=20 >>>=20 >>> I am looking up the DS record for "a.com". The attacker is = responding >>> the NSEC record for b.com (or it was already in my cache). In this >>> case, the owner name does not match the SNAME (a.com). I thought we >>> checked the bitmap of the NSEC only if the owner name matches. This >>> NSEC record might still be accepted depending on what is there in = the >>> "Next domain field". Is this the attack that is being described ? >>=20 >> No. This attack is about obscuring non-delegation names (i.e., and >> "existing signed record") with the spoofed delegation. So, imagine = you have >> a signed zone, foo.example. In that zone, you have an RRset that an >> attacker wants to change: secure.foo.example/A. Now, there exists an = NSEC >> record for secure.foo.example: >>=20 >> secure.foo.example NSEC secure2.foo.example A NSEC RRSIG >>=20 >> So, when a client asks for secure.foo.example/A, the attacker spoofs = a >> response that looks like this: >>=20 >> secure.foo.example NS bad-ns1.attacker.example. >> secure.foo.example NS bad-ns2.attacker.example. >> secure.foo.example NSEC secure2.foo.example A NSEC RRSIG >> secure.foo.example RRSIG NSEC ... >>=20 >> That is, the attacker uses the existing NSEC for secure.foo.example. = Note >> however, that this NSEC record's type map does not have the DS bit = set. So, >> if you are a naive validator, you might just follow the referral, = noting it >> is insecure (because the DS bit isn't set), but fail to notice that = it >> shouldn't have been a delegation at all. Hence the advice. >> Ah! got it. An example always makes it much clearer. This is not even = an > attack. I could have looked up a name (that does not exist) earlier = that > resulted in the NSEC record in my cache and later when I look up the = DS > record, this would answer it. =20 This is an attack. The attack is where the bogus NS records come from. > I suggest we reword the last sentence to make > it clearer. Something like: >=20 > As every authoritative name in the zone has a valid NSEC record, = it > could potentially answer a question > that is looking for a DS record for any such name. Checking the = NS > bit makes sure that this NSEC record > will not be mistaken for a unsigned delegation. >=20 > does that sound right ? I wouldn't even call it an attack. The best = way is > to show the above example in the appendix. No, it doesn't sound quite correct. "it could potentially answer a = question that is looking for a DS..." is true, but irrelevant to this = case. The case that this advice is guarding against isn't that specific = to qtype. I'm not going to claim that the current language is as clear = as it could be, but this replacement text doesn't quite work, either. -- David Blacka =20 Principal Engineer Verisign Infrastructure Engineering --Apple-Mail-38-523100696 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMpzCCBhow ggUCoAMCAQICEBc0Avppt6vT9KJWAKLsKTAwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDMwMzAwMDAwMFoXDTE5MDMwMjIzNTk1OVowgbAxCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWdu LmNvbS9ycGEgKGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBH MzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZBVVIHbQdG81jb1cp+jOE4D5vUIaST JqKfkRcKNC8Q7l/sEuBplO3NRos9MRwdagtQtfeTiZC8NwQ1IfbPIAtd3BO4u5WRzWdD2G4BRTbK C/nkXDtJYGVgFD2m+OXsS31p4ryXlZo2OhbKQvXZof0qUWI/79smv37sOG9jRsPHUPVeMVtqtuHf YoG0PBNOfyu0Qq2W4a2RzYToKLekE4cJejlMLIsq8fk5J3Vb/hicWuNA9nVS8K5OZJ7dmNVxiqA6 yvWTt5u0lDLCRjYBUWuQ95AIG3yyTnCP8A39k3jlP24fYcIe1r1By2Fk7uzH/L9sOnrSFL8Aq9WS zws+u0UCAwEAAaOCAhIwggIOMBIGA1UdEwEB/wQIMAYBAf8CAQAwNAYDVR0fBC0wKzApoCegJYYj aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMHAGA1Ud IARpMGcwZQYLYIZIAYb4RQEHFwIwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTA3MB0GA1UdDgQWBBTVH5Sm O27W26S0sXCieoiKViFvFTCB8AYDVR0jBIHoMIHloYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IQYXDLSYxfmEUp57Cm2VBbejANBgkqhkiG9w0BAQUFAAOCAQEAFTXCpaBB Rq5kc0XwUen7u5EsOzy7iiwvAHrsd7PKLCHg0NSbZKWg4Tzk/Yl5HRl59esmG7e6avTxiEaDG7OV 2+BX5sEfFvKQmtTFyiI3sozDNs+nCFQ+ksSzNVS0msKRSX22qik6AH6diXmQvcb0PIM4QuZadhb+ qwxac5AvA8IKgfPkaXdnIpcotuqtKaqHe60qUw7hnCpN9gamcUoNDVx0Gu1nObq2usSjCVvXWiYY ohDin9MHLkmJ1uYOoRzsQA4WXVAa11UpMXsnd6JotLVKLnrjgZEdK0id0RTBpVbcI9VgxP1LCEaw rYgwfjsT08wUtdampqUUPcljHG4SzDCCBoUwggVtoAMCAQICECvwr+5g4ykMmRdZyEk9APUwDQYJ KoZIhvcNAQEFBQAwgbAxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNz IDIgRW1wbG95ZWUgQ0EgLSBHMzAeFw0xMTA1MTEwMDAwMDBaFw0xMjA1MTAwMDAwMDBaMGsxaTAQ BgNVBAsUCVZDT1JQIFVBUzAUBgNVBAMTDUJsYWNrYSwgRGF2aWQwHQYDVQQKFBZWZXJpU2lnbiBJ bmMuIFZDT1JQVUFTMCAGCSqGSIb3DQEJARYTZGF2aWRiQHZlcmlzaWduLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOFr4D6qtYX78Fwj5I+EKxkemPlg5PON2FAMElOxon6vuLv7 yRUPr7FdNu1RDd0QYni5EMQ/2cNpjQVRSrfrCNqoWkJ9y3iUHnQH+/29uOuafcxjZ11BaUo1AwpB ifMJD4PgPv4aP3kuusxY0lI3rVXJKnezejgRRGO+6n68VYQnbunJ0P0cdJvU+ZNpOkKj9y8eTG0h ynFnBP0UAgQ2f+E0c3u67ie54rHbdDNVMGECvjXjWs5KhXMR68tGCE2K7roer2v27N8VIWq5jrIU q9PLx8zjI6FThbu9ZzQCoToc7UGmeHV/oUiWKheAavj/D4iVupdZ07SPYUEnGGd5wYsCAwEAAaOC At0wggLZMAkGA1UdEwQCMAAwSAYDVR0RBEEwP4ETZGF2aWRiQHZlcmlzaWduLmNvbaAoBgorBgEE AYI3FAIDoBoMGGRhdmlkYkB2Y29ycC5hZC52cnNuLmNvbTAmBgkrBgEEAYI3FQcEGTAXBg9ghkgB hvhFAQ0EiGeB6AUCAWQCAQMwYQYDVR0fBFowWDBWoFSgUoZQaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vY2FfMzBlMmNkOGJhMjkzMDljYTAyMDJkMTVkNGJjZGYzZjAvTGF0ZXN0Q1JMLmNy bAAwggEGBgNVHSMEgf4wgfuAFNUflKY7btbbpLSxcKJ6iIpWIW8VoYHQpIHNMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQFzQC+mm3q9P0olYAouwpMDBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBxcCMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYD VR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDB7BgkqhkiG9w0BCQ8EbjBs MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAHBgUrDgMCGjAKBggqhkiG9w0C AjAKBggqhkiG9w0CBDAKBggqhkiG9w0CBTALBgkqhkiG9w0BAQUwCwYJKoZIhvcNAQEEMA0GCSqG SIb3DQEBBQUAA4IBAQBFpX/mFvxKbdeTruA4rSlIv9JREutn5/MiOpRqhvuuAEnei3ltZ2AdURZ/ 2dvNTfEeQphSCD/l9+rVxbZKEcaKxBYeV3sSAEsOVhsc+ruZKFLnwAzEm7u/rTfkyO+qYV2zWjqA Bq9UoIDTQ9ogjYZ7A0JWnYwj8VpTA2gqBqe6ya+k9/l/GuWyVm2PW/b8OGBzi4VsQYy2WE8KGHr1 nn5znY3KZswuyRQLnzlhSdwowUFDg/yaqolSWgP1HyJGs4Ek1ZL/9DGyH/QmfxCURP2Q7CIJSUYn yDNus5pZbifQbIOBA399fc0ASqM5lKbmIrAln3FQNIoX2P0RB+Hqg1HvMYIEAjCCA/4CAQEwgcUw gbAxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDkxKjAoBgNVBAMTIVZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUg Q0EgLSBHMwIQK/Cv7mDjKQyZF1nIST0A9TAJBgUrDgMCGgUAoIICETAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA3MDExNzUzMDJaMCMGCSqGSIb3DQEJBDEWBBRx 0Qa8YT29jn/yXIs4+FWbcoW4/zCB1gYJKwYBBAGCNxAEMYHIMIHFMIGwMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MSowKAYDVQQDEyFWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBIC0gRzMCECvwr+5g4ykM mRdZyEk9APUwgdgGCyqGSIb3DQEJEAILMYHIoIHFMIGwMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MSowKAYD VQQDEyFWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBIC0gRzMCECvwr+5g4ykMmRdZyEk9APUw DQYJKoZIhvcNAQEBBQAEggEAVI7eB8rbOPds0gmix5dty8ObH0dcx6ugdB6cLB25U5yOCEDqHloh eGEAA7giK8vr4HgNQCI8CYo7yoBNPul9W/g2SMjEwNyJumH6rd8pk+VEBbhwyxEuIO2wbHzOXJ8M hdqRZpJaAk3vVcMM9Ig20san8D/x3L9zJnjWNXOPHgD9hsOcyISAbNLF9Gs75wTwwTyMhDRNFLtV MFsUlu54COc+ow7CdATairbBGFRsCcZSaIsNi2bZ6JHDvD3hV2DzGgopb/Ozfax+IkZsThS+7TFq h0H3lkXflFRMWJMKnwLjHmEVGSiNl+YT7kv32Abp0L7QcHbYjovQaGfttYbe6QAAAAAAAA== --Apple-Mail-38-523100696-- From snwells82@gmail.com Fri Jul 1 11:33:07 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B19B11E8080 for ; Fri, 1 Jul 2011 11:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsnYhgfmJUkG for ; Fri, 1 Jul 2011 11:33:06 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1915811E8126 for ; Fri, 1 Jul 2011 11:33:06 -0700 (PDT) Received: by vxi40 with SMTP id 40so3139196vxi.31 for ; Fri, 01 Jul 2011 11:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bMzCRDJ/dnOyqmV5pmsMFfuuEHKoHtF0BJfS5FO+Dy8=; b=GPG/9xMRhNOngtb3p3elP3JSeLkp2/sLOEutb93zqII4MYnwvT1pRNIS8PvGh0s2n0 G0Ur0TUnPbDQO1LU52w9k9dm96SMgDDC1Qs+bK+oow+9SWNvU7scmo0hyw7zrXOu+a9t u4V94LtCpJw/G406T8vkHTxaz5u+er9H0VTBo= MIME-Version: 1.0 Received: by 10.220.118.195 with SMTP id w3mr1229811vcq.112.1309545185247; Fri, 01 Jul 2011 11:33:05 -0700 (PDT) Received: by 10.220.198.200 with HTTP; Fri, 1 Jul 2011 11:33:05 -0700 (PDT) In-Reply-To: <3294DE6F-0618-4083-8AE8-254EF8618087@verisign.com> References: <3294DE6F-0618-4083-8AE8-254EF8618087@verisign.com> Date: Fri, 1 Jul 2011 11:33:05 -0700 Message-ID: From: Sean Wells To: "Blacka, David" Content-Type: multipart/alternative; boundary=00032555853e9580a804a7063f8a Cc: "" Subject: Re: [dnsext] Insecure Delegation Proofs X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 18:33:07 -0000 --00032555853e9580a804a7063f8a Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 1, 2011 at 10:53 AM, Blacka, David wrote: > > On Jul 1, 2011, at 12:49 PM, Sean Wells wrote: > > > On Fri, Jul 1, 2011 at 6:28 AM, Blacka, David > wrote: > > > >> > >> On Jun 30, 2011, at 3:18 PM, Sean Wells wrote: > >> > >>> Hi, > >>> > >>> DNSSEC bis updates document states: > >>> > >>> [RFC4035] Section > >>> 5.2< > >> > http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-12#section-5.2 > >>> specifies > >>> that a validator, when proving a > >>> > >>> delegation is not secure, needs to check for the absence of the DS > >>> and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also > >>> needs to check for the presence of the NS bit in the matching NSEC > >>> (or NSEC3) RR (proving that there is, indeed, a delegation), or > >>> alternately make sure that the delegation is covered by an NSEC3 RR > >>> with the Opt-Out flag set. If this is not checked, spoofed unsigned > >>> delegations might be used to claim that an existing signed record is > >>> not signed. > >>> > >>> > >>> The last sentence is confusing: what is a "spoofed unsigned > >>> delegation" ? Let us say that there are two delegations one of which > >>> is secure. > >> > >> A spoofed unsigned delegation is a spoofed response in the form of a > >> referral ("delegation" basically means referral here) without a DS > RRset. > >> > >>> a.com is secure, so there is a DS record in com > >>> > >>> b.com is insecure, so there is a NSEC record for b.com in com with DS, > >>> SOA bits not set but the NS bit set. > >>> > >>> > >>> I am looking up the DS record for "a.com". The attacker is responding > >>> the NSEC record for b.com (or it was already in my cache). In this > >>> case, the owner name does not match the SNAME (a.com). I thought we > >>> checked the bitmap of the NSEC only if the owner name matches. This > >>> NSEC record might still be accepted depending on what is there in the > >>> "Next domain field". Is this the attack that is being described ? > >> > >> No. This attack is about obscuring non-delegation names (i.e., and > >> "existing signed record") with the spoofed delegation. So, imagine you > have > >> a signed zone, foo.example. In that zone, you have an RRset that an > >> attacker wants to change: secure.foo.example/A. Now, there exists an > NSEC > >> record for secure.foo.example: > >> > >> secure.foo.example NSEC secure2.foo.example A NSEC RRSIG > >> > >> So, when a client asks for secure.foo.example/A, the attacker spoofs a > >> response that looks like this: > >> > >> secure.foo.example NS bad-ns1.attacker.example. > >> secure.foo.example NS bad-ns2.attacker.example. > >> secure.foo.example NSEC secure2.foo.example A NSEC RRSIG > >> secure.foo.example RRSIG NSEC ... > >> > >> That is, the attacker uses the existing NSEC for secure.foo.example. > Note > >> however, that this NSEC record's type map does not have the DS bit set. > So, > >> if you are a naive validator, you might just follow the referral, noting > it > >> is insecure (because the DS bit isn't set), but fail to notice that it > >> shouldn't have been a delegation at all. Hence the advice. > > > >> Ah! got it. An example always makes it much clearer. This is not even an > > attack. I could have looked up a name (that does not exist) earlier that > > resulted in the NSEC record in my cache and later when I look up the DS > > record, this would answer it. > > This is an attack. The attack is where the bogus NS records come from. > > Hmm.. perhaps i am misunderstanding something then. Is it possible for this to happen even without an attack ? Just by merely using the NSEC record to answer the question (wrongly) ? > > I suggest we reword the last sentence to make > > it clearer. Something like: > > > > As every authoritative name in the zone has a valid NSEC record, it > > could potentially answer a question > > that is looking for a DS record for any such name. Checking the NS > > bit makes sure that this NSEC record > > will not be mistaken for a unsigned delegation. > > > > does that sound right ? I wouldn't even call it an attack. The best way > is > > to show the above example in the appendix. > > No, it doesn't sound quite correct. "it could potentially answer a > question that is looking for a DS..." is true, but irrelevant to this case. > The case that this advice is guarding against isn't that specific to qtype. > I'm not going to claim that the current language is as clear as it could > be, but this replacement text doesn't quite work, either. > > Section 5.2 in RFC 4035 is about authenticating referrals where the DS RRSets are being looked up. Why is this irrelevant to this case ? Perhaps, this section is more than 5.2 and i am not reading it properly. > -- > David Blacka > Principal Engineer Verisign Infrastructure Engineering > > Sean --00032555853e9580a804a7063f8a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jul 1, 2011 at 10:53 AM, Blacka,= David <davidb@= verisign.com> wrote:

On Jul 1, 2011, at 12:49 PM, Sean Wells wrote:

> On Fri, Jul 1, 2011 at 6:28 AM, Blacka, David <davidb@verisign.com> wrote:
>
>>
>> On Jun 30, 2011, at 3:18 PM, Sean Wells wrote:
>>
>>> Hi,
>>>
>>> DNSSEC bis updates document states:
>>>
>>> [RFC4035] Section
>>> 5.2<
>> http://tools.ietf.org/html/draft= -ietf-dnsext-dnssec-bis-updates-12#section-5.2
>>> specifies
>>> that a validator, when proving a
>>>
>>> =A0delegation is not secure, needs to check for the absence of= the DS
>>> =A0and SOA bits in the NSEC (or NSEC3) type bitmap. =A0The val= idator also
>>> =A0needs to check for the presence of the NS bit in the matchi= ng NSEC
>>> =A0(or NSEC3) RR (proving that there is, indeed, a delegation)= , or
>>> =A0alternately make sure that the delegation is covered by an = NSEC3 RR
>>> =A0with the Opt-Out flag set. =A0If this is not checked, spoof= ed unsigned
>>> =A0delegations might be used to claim that an existing signed = record is
>>> =A0not signed.
>>>
>>>
>>> The last sentence is confusing: what is a "spoofed unsign= ed
>>> delegation" ? Let us say that there are two delegations o= ne of which
>>> is secure.
>>
>> A spoofed unsigned delegation is a spoofed response in the form of= a
>> referral ("delegation" basically means referral here) wi= thout a DS RRset.
>>
>>> a.com is secure= , so there is a DS record in com
>>>
>>> b.com is insecu= re, so there is a NSEC record for b.com in com with DS,
>>> SOA bits not set but the NS bit set.
>>>
>>>
>>> I am looking up the DS record for "a.com". The attacker is responding
>>> the NSEC record for b.com (or it was already in my cache). In this
>>> case, the owner name does not match the SNAME (a.com). I thought we
>>> checked the bitmap of the NSEC only if the owner name matches.= This
>>> NSEC record might still be accepted depending on what is there= in the
>>> "Next domain field". Is this the attack that is bein= g described ?
>>
>> No. =A0This attack is about obscuring non-delegation names (i.e., = and
>> "existing signed record") with the spoofed delegation. = =A0So, imagine you have
>> a signed zone, foo.example. =A0In that zone, you have an RRset tha= t an
>> attacker wants to change: secure.foo.example/A. =A0Now, there exis= ts an NSEC
>> record for secure.foo.example:
>>
>> secure.foo.example NSEC secure2.foo.example A NSEC RRSIG
>>
>> So, when a client asks for secure.foo.example/A, the attacker spoo= fs a
>> response that looks like this:
>>
>> secure.foo.example NS bad-ns1.attacker.example.
>> secure.foo.example NS bad-ns2.attacker.example.
>> secure.foo.example NSEC secure2.foo.example A NSEC RRSIG
>> secure.foo.example RRSIG NSEC ...
>>
>> That is, the attacker uses the existing NSEC for secure.foo.exampl= e. =A0Note
>> however, that this NSEC record's type map does not have the DS= bit set. =A0So,
>> if you are a naive validator, you might just follow the referral, = noting it
>> is insecure (because the DS bit isn't set), but fail to notice= that it
>> shouldn't have been a delegation at all. =A0Hence the advice.<= br>

>> Ah! got it. An example always makes it much clearer. This is not e= ven an
> attack. I could have looked up a name (that does not exist) earlier th= at
> resulted in the NSEC record in my cache and later when I look up the D= S
> record, this would answer it.

This is an attack. =A0The attack is where the bogus NS records = come from.

Hmm.. perhaps i am misunderst= anding something then. Is it possible for this to happen even without an at= tack ? Just by merely using the NSEC record to answer the question (wrongly= ) ?
=A0
> I suggest we reword the last sentence to make
> it clearer. =A0Something like:
>
> =A0 =A0 =A0 As every authoritative name in the zone has a valid NSEC r= ecord, it
> could potentially answer a question
> =A0 =A0 =A0 that is looking for a DS record for any such name. Checkin= g the NS
> bit makes sure that this NSEC record
> =A0 =A0 =A0 will not be mistaken for a unsigned delegation.
>
> does that sound right ? I wouldn't even call it an attack. The bes= t way is
> to show the above example in the appendix.

No, it doesn't sound quite correct. =A0"it could potentially= answer a question that is looking for a DS..." is true, but irrelevan= t to this case. =A0The case that this advice is guarding against isn't = that specific to qtype. =A0I'm not going to claim that the current lang= uage is as clear as it could be, but this replacement text doesn't quit= e work, either.

Section= 5.2 in RFC 4035 is about authenticating referrals where the DS RRSets are = being looked up. Why is this irrelevant to this case ? Perhaps, this sectio= n is more than 5.2 and i am not reading it properly.


=A0
--
David Blacka =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<davidb@verisign.com>
Principal Engineer =A0 =A0 =A0Verisign Infrastructure Engineering


Sean=A0

--00032555853e9580a804a7063f8a-- From internet-drafts@ietf.org Tue Jul 5 09:11:03 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1D721F85D2; Tue, 5 Jul 2011 09:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcnMPYEB-JrY; Tue, 5 Jul 2011 09:11:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53DF21F85CC; Tue, 5 Jul 2011 09:11:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110705161101.23937.25957.idtracker@ietfa.amsl.com> Date: Tue, 05 Jul 2011 09:11:01 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-ecdsa-01.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 16:11:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the I= ETF. Title : Elliptic Curve DSA for DNSSEC Author(s) : Paul Hoffman Wouter Wijngaards Filename : draft-ietf-dnsext-ecdsa-01.txt Pages : 8 Date : 2011-07-05 This document describes how to specify Elliptic Curve DSA keys and signatures in DNSSEC. It lists curves of different sizes, and uses the SHA-2 family of hashes for signatures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecdsa-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-ecdsa-01.txt From internet-drafts@ietf.org Wed Jul 6 06:50:13 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB6021F872E; Wed, 6 Jul 2011 06:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btb+Hi8u5ruH; Wed, 6 Jul 2011 06:50:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8438321F863E; Wed, 6 Jul 2011 06:50:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110706135012.13666.6167.idtracker@ietfa.amsl.com> Date: Wed, 06 Jul 2011 06:50:12 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-02.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 13:50:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the I= ETF. Title : Signaling Cryptographic Algorithm Understanding in DNSSEC Author(s) : Steve Crocker Scott Rose Filename : draft-ietf-dnsext-dnssec-algo-signal-02.txt Pages : 8 Date : 2011-07-06 The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This draft sets out to specify a way for validating end-system resolvers to signal to a server which cryptographic algorithms they support. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-02= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-02.= txt From scottr.nist@gmail.com Wed Jul 6 07:01:08 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC9D21F84E3 for ; Wed, 6 Jul 2011 07:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80C+AjxBuzKs for ; Wed, 6 Jul 2011 07:01:08 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1776621F84E2 for ; Wed, 6 Jul 2011 07:01:05 -0700 (PDT) Received: from 107-140.antd.nist.gov (107-140.antd.nist.gov [129.6.140.107]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p66E0lrM009650 for ; Wed, 6 Jul 2011 10:00:49 -0400 From: Scott Rose Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Jul 2011 10:00:47 -0400 References: <20110706135012.13666.6167.idtracker@ietfa.amsl.com> To: dnsext@ietf.org Message-Id: <4158B8A7-7773-4819-90F4-BF6F7973B1C7@gmail.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr.nist@gmail.com Subject: [dnsext] Fwd: I-D Action: draft-ietf-dnsext-dnssec-algo-signal-02.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 14:01:08 -0000 An updated version of the algo-signal draft to address the issues in = WGLC. Specific changes: 1. Changed the wording in 3.4.1 to remove the RFC2119 wording on = setting the DO bit. =20 2. Changed section 4 wording to indicate DNS proxy systems and added a = ref to RFC 5625. 3. fixed some typos and minor wording changes to stress that the DAU = option is for signaling only and does not specify any change to how = servers construct a response. Scott Begin forwarded message: > From: internet-drafts@ietf.org > Date: July 6, 2011 9:50:12 AM EDT > To: i-d-announce@ietf.org > Cc: dnsext@ietf.org > Subject: [dnsext] I-D Action: = draft-ietf-dnsext-dnssec-algo-signal-02.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the DNS Extensions Working = Group of the IETF. >=20 > Title : Signaling Cryptographic Algorithm = Understanding in DNSSEC > Author(s) : Steve Crocker > Scott Rose > Filename : draft-ietf-dnsext-dnssec-algo-signal-02.txt > Pages : 8 > Date : 2011-07-06 >=20 > The DNS Security Extensions (DNSSEC) were developed to provide = origin > authentication and integrity protection for DNS data by using = digital > signatures. These digital signatures can be generated using > different algorithms. This draft sets out to specify a way for > validating end-system resolvers to signal to a server which > cryptographic algorithms they support. >=20 >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-0= 2.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-02= .txt > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From ogud@ogud.com Wed Jul 6 14:17:55 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E2421F8A8A for ; Wed, 6 Jul 2011 14:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.392 X-Spam-Level: X-Spam-Status: No, score=-106.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzp0Q3fQn-Kh for ; Wed, 6 Jul 2011 14:17:55 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1441B21F8A8B for ; Wed, 6 Jul 2011 14:17:54 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p66LHr8P031561 for ; Wed, 6 Jul 2011 17:17:54 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4E14D100.5010705@ogud.com> Date: Wed, 06 Jul 2011 17:17:52 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: dnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dnsext] WGLC: Elliptic Curve DSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 21:17:55 -0000 Dear Colleagues This message starts a Working Group Last Call for "Elliptic Curve DSA for DNSSEC" located at http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecdsa-01.txt This document is on Standards track. This WGLC will conclude on midnight on July 21'th UTC. Please review the document and sent a statement that you reviewed the document. If the review raises any issues, please note what they are. Remember that we need a minimum of 5 reviewers. Olafur & Andrew From Ed.Lewis@neustar.biz Thu Jul 7 08:13:54 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB81521F885E for ; Thu, 7 Jul 2011 08:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.932 X-Spam-Level: X-Spam-Status: No, score=-107.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RnbC3aSy3Qx for ; Thu, 7 Jul 2011 08:13:53 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2624921F885D for ; Thu, 7 Jul 2011 08:13:51 -0700 (PDT) Received: from tkel-lt61.cis.neustar.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p67FDnbP037529; Thu, 7 Jul 2011 11:13:49 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.129.195] by tkel-lt61.cis.neustar.com (PGP Universal service); Thu, 07 Jul 2011 11:13:50 -0400 X-PGP-Universal: processed; by tkel-lt61.cis.neustar.com on Thu, 07 Jul 2011 11:13:50 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4E14D100.5010705@ogud.com> References: <4E14D100.5010705@ogud.com> Date: Thu, 7 Jul 2011 11:13:28 -0400 To: Olafur Gudmundsson From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] WGLC: Elliptic Curve DSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 15:13:55 -0000 At 17:17 -0400 7/6/11, Olafur Gudmundsson wrote: >This message starts a Working Group Last Call for >"Elliptic Curve DSA for DNSSEC" located at >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecdsa-01.txt >This document is on Standards track. I have some minor comments and some questions. First, and this may fall into "style", "ECDSA" is not expanded in the Introduction (but it is in the abstract). My preference has been to expand letters the first use in the main body of the document. A more significant comment is that there is no reference defining ECDSA. In particular, this paragraph: # This document defines the DNSKEY and RRSIG resource records (RRs) of # two new signing algorithms: ECDSA with curve P-256 and SHA-256, and # ECDSA with curve P-384 and SHA-384. This document also defines the # DS RR for the SHA-384 one-way hash algorithm; the associated DS RR # for SHA-256 is already defined in RFC 4509 [RFC4509]. Lacks any document defining ECDSA. In the references there are two FIPS listed. (Mind you, I am not well read in cryptography. For the most part I don't care for the details. I'm just asking for a pointer where I could go read more if I cared.) And my question. When I saw the dreaded "DSA" I immediately harked back to the fact that is slower where it matters - verfication - than RSA. And the draft does address this: # However, validating RSA signatures is significantly faster than validating # ECDSA signatures (about 5 times faster in some implementations). From what I gather, the case for ECDSA is that the keys and signatures is that they are shorter. # ECDSA keys are much shorter than RSA keys; at this size, the difference is 256 # versus 3072 bits. Similarly, ECDSA signatures are much shorter than RSA signatures. Caveats I cut out here, because I'm no cryptogeek, is that the "shorter" is within the same "strengths" (whatever "strength" means) of protection. I'm taking for granted, this is a pound of oranges vs. a pound of apples comparison. What is set up here is the classic - "Space vs. Time" tradeoff. So here's the question to the authors/experts on this. Is the tradeoff worth it? Is the extra slowness in validation worth the savings in bytes? I haven't seen much evidence that larger DNSSEC responses are killing us - and I don't mean to say that there isn't a problem looming, but I don't see any evidence. So I wonder about the value of the lost time (which is something DNS gets hammered with by web site operators). This isn't a situation in which I can contribute text, but I would like to see a paragraph or two at least hypothesizing on the tradeoff and why ECDSA might be better than the current state of operations. Switching to ECDSA for the current 60+ signed TLDs and root would take some effort, would it be worth it? (Yeah, the latter question is one for operators. I'm asking for the experts prognostication if they are willing.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. From paul.hoffman@vpnc.org Thu Jul 7 08:47:22 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C076A21F88EF for ; Thu, 7 Jul 2011 08:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.737 X-Spam-Level: X-Spam-Status: No, score=-103.737 tagged_above=-999 required=5 tests=[AWL=0.862, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pt+Ye2ystKjv for ; Thu, 7 Jul 2011 08:47:22 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC1921F88E8 for ; Thu, 7 Jul 2011 08:47:21 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p67FlBfY092636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Jul 2011 08:47:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 7 Jul 2011 08:47:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E14D100.5010705@ogud.com> To: Edward Lewis X-Mailer: Apple Mail (2.1084) Cc: DNSEXT Working Group Subject: Re: [dnsext] WGLC: Elliptic Curve DSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 15:47:22 -0000 On Jul 7, 2011, at 8:13 AM, Edward Lewis wrote: > At 17:17 -0400 7/6/11, Olafur Gudmundsson wrote: >=20 >> This message starts a Working Group Last Call for >> "Elliptic Curve DSA for DNSSEC" located at >> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecdsa-01.txt >> This document is on Standards track. >=20 > I have some minor comments and some questions. >=20 > First, and this may fall into "style", "ECDSA" is not expanded in the = Introduction (but it is in the abstract). My preference has been to = expand letters the first use in the main body of the document. Good catch, will do. > A more significant comment is that there is no reference defining = ECDSA. In particular, this paragraph: >=20 > # This document defines the DNSKEY and RRSIG resource records (RRs) = of > # two new signing algorithms: ECDSA with curve P-256 and SHA-256, = and > # ECDSA with curve P-384 and SHA-384. This document also defines = the > # DS RR for the SHA-384 one-way hash algorithm; the associated DS RR > # for SHA-256 is already defined in RFC 4509 [RFC4509]. >=20 > Lacks any document defining ECDSA. In the references there are two = FIPS listed. It is not just in the references: Section 3 points directly to the FIPS = document that defines the curves used in ECDSA. > (Mind you, I am not well read in cryptography. For the most part I = don't care for the details. I'm just asking for a pointer where I could = go read more if I cared.) FIPS 186-3, as listed in Section 3. Not that I'm recommending it, mind = you. > And my question. >=20 > When I saw the dreaded "DSA" I immediately harked back to the fact = that is slower where it matters - verfication - than RSA. And the draft = does address this: >=20 > # However, validating RSA signatures is significantly faster than = validating > # ECDSA signatures (about 5 times faster in some implementations). >=20 > =46rom what I gather, the case for ECDSA is that the keys and = signatures is that they are shorter. >=20 > # ECDSA keys are much shorter than RSA keys; at this size, the = difference is 256 > # versus 3072 bits. Similarly, ECDSA signatures are much shorter = than RSA signatures. >=20 > Caveats I cut out here, because I'm no cryptogeek, is that the = "shorter" is within the same "strengths" (whatever "strength" means) of = protection. I'm taking for granted, this is a pound of oranges vs. a = pound of apples comparison. >=20 > What is set up here is the classic - "Space vs. Time" tradeoff. >=20 > So here's the question to the authors/experts on this. Is the = tradeoff worth it? =20 Yes. > Is the extra slowness in validation worth the savings in bytes? =20 That is not the only tradeoff. The strength of RSA keys goes down year = after year, but the strength of ECDSA keys hasn't declined at all. For = sites that require a certain strength and want that strength year after = year, they have to increase the length of their RSA keys. > I haven't seen much evidence that larger DNSSEC responses are killing = us - and I don't mean to say that there isn't a problem looming, but I = don't see any evidence. So I wonder about the value of the lost time = (which is something DNS gets hammered with by web site operators). That is going to depend on the preferences of who is doing the = measurements. ECDSA allows the hosts who have a particular set of = priorities to use smaller keys that don't degrade; RSA allows hosts who = don't feel the need for as much security to use keys that will validate = somewhat faster. > This isn't a situation in which I can contribute text, but I would = like to see a paragraph or two at least hypothesizing on the tradeoff = and why ECDSA might be better than the current state of operations. = Switching to ECDSA for the current 60+ signed TLDs and root would take = some effort, would it be worth it? Please, no. That kind of pie-in-the-sky speculation does not belong in a = technical document such as this. If you feel like writing such a = document in DNSOP, great, but it really doesn't belong here.=20 > (Yeah, the latter question is one for operators. I'm asking for the = experts prognostication if they are willing.) Not willing. --Paul Hoffman From Ed.Lewis@neustar.biz Thu Jul 7 10:39:08 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8162D1F0C49 for ; Thu, 7 Jul 2011 10:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.099 X-Spam-Level: X-Spam-Status: No, score=-107.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MG-K6X9-lM8F for ; Thu, 7 Jul 2011 10:39:08 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 92CE31F0C44 for ; Thu, 7 Jul 2011 10:39:05 -0700 (PDT) Received: from tkel-lt61.cis.neustar.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p67Hd3eq038457; Thu, 7 Jul 2011 13:39:03 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.129.195] by tkel-lt61.cis.neustar.com (PGP Universal service); Thu, 07 Jul 2011 13:39:04 -0400 X-PGP-Universal: processed; by tkel-lt61.cis.neustar.com on Thu, 07 Jul 2011 13:39:04 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4E14D100.5010705@ogud.com> Date: Thu, 7 Jul 2011 13:32:08 -0400 To: Paul Hoffman From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis , DNSEXT Working Group Subject: Re: [dnsext] WGLC: Elliptic Curve DSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 17:39:08 -0000 At 8:47 -0700 7/7/11, Paul Hoffman wrote: >It is not just in the references: Section 3 points directly to the >FIPS document that defines the curves used in ECDSA. Then the nit - please add the refernce earlier. >> Is the extra slowness in validation worth the savings in bytes? >That is not the only tradeoff. The strength of RSA keys goes down year >after year, but the strength of ECDSA keys hasn't declined at all. For >sites that require a certain strength and want that strength year after >year, they have to increase the length of their RSA keys. >That is going to depend on the preferences of who is doing the measurements. >ECDSA allows the hosts who have a particular set of priorities to use >smaller keys that don't degrade; RSA allows hosts who don't feel the need >for as much security to use keys that will validate somewhat faster. I'd like to see those words in the doc. >Please, no. That kind of pie-in-the-sky speculation does not belong >in a technical document such as this. Ok, I get that. >> asking for the experts prognostication if they are willing. >Not willing. Chicken ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. From paul.hoffman@vpnc.org Thu Jul 7 10:54:19 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76291F0C68 for ; Thu, 7 Jul 2011 10:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVrNC2DjknXT for ; Thu, 7 Jul 2011 10:54:19 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 347A61F0C61 for ; Thu, 7 Jul 2011 10:54:19 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p67Hs8Y7099043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Jul 2011 10:54:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 7 Jul 2011 10:54:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <851F09C9-78CE-4F56-8F25-5806C8979BB9@vpnc.org> References: <4E14D100.5010705@ogud.com> To: Edward Lewis X-Mailer: Apple Mail (2.1084) Cc: DNSEXT Working Group Subject: Re: [dnsext] WGLC: Elliptic Curve DSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 17:54:20 -0000 On Jul 7, 2011, at 10:32 AM, Edward Lewis wrote: > At 8:47 -0700 7/7/11, Paul Hoffman wrote: >> It is not just in the references: Section 3 points directly to the = FIPS document that defines the curves used in ECDSA. >=20 > Then the nit - please add the refernce earlier. Will do. >>> Is the extra slowness in validation worth the savings in bytes? >=20 >> That is not the only tradeoff. The strength of RSA keys goes down = year >> after year, but the strength of ECDSA keys hasn't declined at all. = For >> sites that require a certain strength and want that strength year = after >> year, they have to increase the length of their RSA keys. >=20 >> That is going to depend on the preferences of who is doing the = measurements. >> ECDSA allows the hosts who have a particular set of priorities to use >> smaller keys that don't degrade; RSA allows hosts who don't feel the = need >> for as much security to use keys that will validate somewhat faster. >=20 > I'd like to see those words in the doc. Not unless others in the WG really want this. Other docs that have = described different crypto algorithms (such as different hash functions) = haven't had such descriptions, and I think that's a good thing. Crypto = protocol descriptions should not be telling people how to consider them. --Paul Hoffman From Ed.Lewis@neustar.biz Thu Jul 7 11:05:20 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EEB1F0C82 for ; Thu, 7 Jul 2011 11:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.999 X-Spam-Level: X-Spam-Status: No, score=-106.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9wE03S0IJ37 for ; Thu, 7 Jul 2011 11:05:19 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id CFAF41F0C81 for ; Thu, 7 Jul 2011 11:05:18 -0700 (PDT) Received: from tkel-lt61.cis.neustar.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p67I5Gbx038691; Thu, 7 Jul 2011 14:05:17 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.129.195] by tkel-lt61.cis.neustar.com (PGP Universal service); Thu, 07 Jul 2011 14:05:17 -0400 X-PGP-Universal: processed; by tkel-lt61.cis.neustar.com on Thu, 07 Jul 2011 14:05:17 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <851F09C9-78CE-4F56-8F25-5806C8979BB9@vpnc.org> References: <4E14D100.5010705@ogud.com> <851F09C9-78CE-4F56-8F25-5806C8979BB9@vpnc.org> Date: Thu, 7 Jul 2011 14:05:14 -0400 To: Paul Hoffman From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis , DNSEXT Working Group Subject: Re: [dnsext] WGLC: Elliptic Curve DSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 18:05:20 -0000 At 10:54 -0700 7/7/11, Paul Hoffman wrote: >Not unless others in the WG really want this. Other docs that have >described different crypto algorithms (such as different hash functions) >haven't had such descriptions, and I think that's a good thing. Crypto >protocol descriptions should not be telling people how to consider them. But this is a DNS document and we need all the help we can get when it comes to understanding crypto, at least as far as it's role in DNSSEC deployments. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. From ogud@ogud.com Thu Jul 7 11:18:06 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B15A1F0C85 for ; Thu, 7 Jul 2011 11:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.496 X-Spam-Level: X-Spam-Status: No, score=-106.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrR+GFoODkQT for ; Thu, 7 Jul 2011 11:18:05 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7D73D1F0C81 for ; Thu, 7 Jul 2011 11:18:05 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p67II442038800 for ; Thu, 7 Jul 2011 14:18:04 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4E15F85A.5090905@ogud.com> Date: Thu, 07 Jul 2011 14:18:02 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: dnsext@ietf.org References: <4E14D100.5010705@ogud.com> <851F09C9-78CE-4F56-8F25-5806C8979BB9@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: Re: [dnsext] WGLC: Elliptic Curve DSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 18:18:06 -0000 On 07/07/2011 2:05 PM, Edward Lewis wrote: > At 10:54 -0700 7/7/11, Paul Hoffman wrote: > >> Not unless others in the WG really want this. Other docs that have >> described different crypto algorithms (such as different hash functions) >> haven't had such descriptions, and I think that's a good thing. Crypto >> protocol descriptions should not be telling people how to consider them. > > But this is a DNS document and we need all the help we can get when it > comes to understanding crypto, at least as far as it's role in DNSSEC > deployments. I tend to agree with Paul on this one, this is not appropriate content for a code allocation document. I think something like this might be published as BCP in a separate document. Olafur From scottr.nist@gmail.com Thu Jul 7 11:23:21 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373161F0C67 for ; Thu, 7 Jul 2011 11:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fvf80tr4F610 for ; Thu, 7 Jul 2011 11:23:20 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5E321F85A6 for ; Thu, 7 Jul 2011 11:23:20 -0700 (PDT) Received: from h222003.nist.gov (h222003.nist.gov [129.6.222.3]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p67IN3pO022800 for ; Thu, 7 Jul 2011 14:23:09 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Scott Rose In-Reply-To: <851F09C9-78CE-4F56-8F25-5806C8979BB9@vpnc.org> Date: Thu, 7 Jul 2011 14:23:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E14D100.5010705@ogud.com> <851F09C9-78CE-4F56-8F25-5806C8979BB9@vpnc.org> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1084) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr.nist@gmail.com Subject: Re: [dnsext] WGLC: Elliptic Curve DSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 18:23:21 -0000 On Jul 7, 2011, at 1:54 PM, Paul Hoffman wrote: >>>> Is the extra slowness in validation worth the savings in bytes? >>=20 >>> That is not the only tradeoff. The strength of RSA keys goes down = year >>> after year, but the strength of ECDSA keys hasn't declined at all. = For >>> sites that require a certain strength and want that strength year = after >>> year, they have to increase the length of their RSA keys. >>=20 >>> That is going to depend on the preferences of who is doing the = measurements. >>> ECDSA allows the hosts who have a particular set of priorities to = use >>> smaller keys that don't degrade; RSA allows hosts who don't feel the = need >>> for as much security to use keys that will validate somewhat faster. >>=20 >> I'd like to see those words in the doc. >=20 > Not unless others in the WG really want this. Other docs that have = described different crypto algorithms (such as different hash functions) = haven't had such descriptions, and I think that's a good thing. Crypto = protocol descriptions should not be telling people how to consider them. >=20 I don't think it is needed in this doc, since it was never considered to = be needed in any other algorithm spec doc. Sounds like something like = that would belong in a larger DNSSEC crypto considerations document = since similar text would be desired for other algorithms and not just = ECDSA. Scott > --Paul Hoffman >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From hallam@gmail.com Thu Jul 7 16:36:07 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377DA21F86FC for ; Thu, 7 Jul 2011 16:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.705 X-Spam-Level: X-Spam-Status: No, score=-2.705 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAiLcC68K-Kw for ; Thu, 7 Jul 2011 16:36:06 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBF721F86F5 for ; Thu, 7 Jul 2011 16:36:06 -0700 (PDT) Received: by gwb20 with SMTP id 20so703406gwb.31 for ; Thu, 07 Jul 2011 16:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JnRnHC0KAhHDXcXVoYJyhxFG1ATet8TC+/jeNn9eVto=; b=X4GOxxeM1me14NwrvE/c9iyNo9YtNEeJaYrYNpP2nOyKlsYMA49RTUzNfrM38t9FxZ UFoJV9UZ/MqI+sLvX0VuPoTy9Fcz9QIb2LWmTJkkHhuJ6/pssHIvrwPeOkbhEV2u4LM7 4u9p1+r9R1ORjWwOXuYVdBWenewGkM5TBMGQI= MIME-Version: 1.0 Received: by 10.100.249.8 with SMTP id w8mr1230183anh.168.1310081765857; Thu, 07 Jul 2011 16:36:05 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Thu, 7 Jul 2011 16:36:05 -0700 (PDT) In-Reply-To: <4E14D100.5010705@ogud.com> References: <4E14D100.5010705@ogud.com> Date: Thu, 7 Jul 2011 19:36:05 -0400 Message-ID: From: Phillip Hallam-Baker To: Olafur Gudmundsson Content-Type: multipart/alternative; boundary=00163691ff4c47da3504a7832e86 Cc: dnsext@ietf.org Subject: Re: [dnsext] WGLC: Elliptic Curve DSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 23:36:07 -0000 --00163691ff4c47da3504a7832e86 Content-Type: text/plain; charset=ISO-8859-1 Section 8: "The cryptographic strength of ECDSA with curve P-256 or P-384 is generally considered to be equivalent to half the size of the key, or 128 bits and 192 bits, respectively. " This should be 'Work Factor' Whit Diffie corrected me on this while I was speaking at a conference. Work factor is the way to think about it. 128 bits does not in itself imply a difficulty, the difficulty of 128 bit RSA being rather different to 128 bit AES. On Wed, Jul 6, 2011 at 5:17 PM, Olafur Gudmundsson wrote: > Dear Colleagues > > This message starts a Working Group Last Call for > "Elliptic Curve DSA for DNSSEC" located at > http://www.ietf.org/internet-**drafts/draft-ietf-dnsext-**ecdsa-01.txt > This document is on Standards track. > > This WGLC will conclude on midnight on July 21'th UTC. > > Please review the document and sent a statement that you reviewed the > document. If the review raises any issues, please note what they are. > Remember that we need a minimum of 5 reviewers. > > > Olafur & Andrew > ______________________________**_________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/**listinfo/dnsext > -- Website: http://hallambaker.com/ --00163691ff4c47da3504a7832e86 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Section 8:

"The cryptographic stren= gth of ECDSA with curve P-256 or P-384 is
=A0 =A0generally consid= ered to be equivalent to half the size of the key, or
=A0 =A0128 = bits and 192 bits, respectively. "


This should be 'Work Factor'

Whit Diffie corrected me on this while I was sp= eaking at a conference. Work factor is the way to think about it. 128 bits = does not in itself imply a difficulty, the difficulty of 128 bit RSA being = rather different to 128 bit AES.


On Wed, Jul 6, 2011 at 5:17 P= M, Olafur Gudmundsson <ogud@ogud.com> wrote:
Dear Colleagues

This message starts a Working Group Last Call for
"Elliptic Curve DSA for DNSSEC" located at
http://www.ietf.org/internet-drafts/draft-ietf= -dnsext-ecdsa-01.txt
This document is on Standards track.

This WGLC will conclude on midnight on July 21'th UTC.

Please review the document and sent a statement that you reviewed the
document. =A0If the review raises any issues, please note what they are. Remember that we need a minimum of 5 reviewers.


=A0 =A0Olafur & Andrew
_______________________________________________
dnsext mailing list
dnsext@ietf.org = https://www.ietf.org/mailman/listinfo/dnsext



--
Website: http://hallambaker.com/

--00163691ff4c47da3504a7832e86-- From paul.hoffman@vpnc.org Thu Jul 7 17:47:27 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F294721F8A05 for ; Thu, 7 Jul 2011 17:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.73 X-Spam-Level: X-Spam-Status: No, score=-102.73 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YC5-tRhwT1Qm for ; Thu, 7 Jul 2011 17:47:26 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id F16D221F89C1 for ; Thu, 7 Jul 2011 17:47:25 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p680lDSf016971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Jul 2011 17:47:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 7 Jul 2011 17:47:21 -0700 Content-Transfer-Encoding: 7bit Message-Id: <08FA6A18-9737-4A50-B3EB-7B731D98A36A@vpnc.org> References: <4E14D100.5010705@ogud.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org, Olafur Gudmundsson Subject: Re: [dnsext] WGLC: Elliptic Curve DSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 00:47:27 -0000 On Jul 7, 2011, at 4:36 PM, Phillip Hallam-Baker wrote: > Section 8: > > "The cryptographic strength of ECDSA with curve P-256 or P-384 is > generally considered to be equivalent to half the size of the key, or > 128 bits and 192 bits, respectively. " > > > This should be 'Work Factor' Sounds fine. --Paul Hoffman From johnl@iecc.com Thu Jul 7 18:37:26 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5728B21F89B1 for ; Thu, 7 Jul 2011 18:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.22 X-Spam-Level: X-Spam-Status: No, score=-110.22 tagged_above=-999 required=5 tests=[AWL=0.979, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T440AqwgvjYD for ; Thu, 7 Jul 2011 18:37:25 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 9A63421F89AC for ; Thu, 7 Jul 2011 18:37:25 -0700 (PDT) Received: (qmail 64865 invoked from network); 8 Jul 2011 01:37:24 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 8 Jul 2011 01:37:24 -0000 Received: (qmail 51583 invoked from network); 8 Jul 2011 01:37:24 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 8 Jul 2011 01:37:24 -0000 Date: 8 Jul 2011 01:37:02 -0000 Message-ID: <20110708013702.4496.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: Ed.Lewis@neustar.biz Subject: Re: [dnsext] WGLC: Elliptic Curve DSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 01:37:26 -0000 >But this is a DNS document and we need all the help we can get when >it comes to understanding crypto, at least as far as it's role in >DNSSEC deployments. I'd rather keep the documents that describe the bits on the wire separate from the documents that opine about how one should choose what bits to send. The former should be highly stable, the latter can evolve somewhat as we understand better what the deployment issues are. It's not exactly a BCP, since I gather there isn't a whole lot of practice with new algs in DNSSEC. It's more of a BHP or BPP (Hypothetical or Proposed). R's, John From matthijs@nlnetlabs.nl Thu Jul 7 23:30:48 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7054A21F892D for ; Thu, 7 Jul 2011 23:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3lrZkDj3OeI for ; Thu, 7 Jul 2011 23:30:47 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBB521F8922 for ; Thu, 7 Jul 2011 23:30:44 -0700 (PDT) Received: from [192.168.1.13] (ip123-112-174-82.adsl2.static.versatel.nl [82.174.112.123]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p686UfpE045519 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 8 Jul 2011 08:30:42 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4E16A411.8080802@nlnetlabs.nl> Date: Fri, 08 Jul 2011 08:30:41 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: dnsext@ietf.org References: <4E14D100.5010705@ogud.com> In-Reply-To: <4E14D100.5010705@ogud.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Fri, 08 Jul 2011 08:30:42 +0200 (CEST) Subject: Re: [dnsext] WGLC: Elliptic Curve DSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 06:30:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have read this document and have no further comments. Best regards, Matthijs On 07/06/2011 11:17 PM, Olafur Gudmundsson wrote: > Dear Colleagues > > This message starts a Working Group Last Call for > "Elliptic Curve DSA for DNSSEC" located at > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecdsa-01.txt > This document is on Standards track. > > This WGLC will conclude on midnight on July 21'th UTC. > > Please review the document and sent a statement that you reviewed the > document. If the review raises any issues, please note what they are. > Remember that we need a minimum of 5 reviewers. > > > Olafur & Andrew > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOFqQRAAoJEA8yVCPsQCW5G5gH/jx+OOdBOLJPKegAfFdItqLH nhiPkPKg6HgkBdeuv8KwyAv0bYLbdy/XiR/ib3IMDsgZGJX+uH99cX9v1H+BmvHk jCKPYfDvWFCiKcmoT8YaKYqKl4MqVTSRKXS6e3Dy4ONVCwtfu6x08gXDGb0++ICk g5WqWTBXIcyF4ZgG4AbP92uuLlZE+wCMwFIoxXR55FUpftJ+c9P+ucCfhefwuEUy /XGJl1sD6cOQGXHcXOfevFDBKH1Wtq/qxMupPxHcUWSANS+tOtW8Z1jKEi4oZFti /4a3/+CJJUsMmJgAqgCy4tyLp/LwvDkzYSHDmZVj50lIv+0M791P0E542hm0uzk= =P6SP -----END PGP SIGNATURE----- From bert.hubert@netherlabs.nl Fri Jul 8 03:57:19 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0F521F86B1 for ; Fri, 8 Jul 2011 03:57:19 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam_report: ...that system for details.\n \n Content previ[...] X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPMhW+YBwRnU for ; Fri, 8 Jul 2011 03:57:18 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id E9EF821F856E for ; Fri, 8 Jul 2011 03:57:09 -0700 (PDT) Received: from mail-fx0-f54.google.com ([209.85.161.54]) by xs.powerdns.com with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1Qf8k5-0006eU-IM for dnsext@ietf.org; Fri, 08 Jul 2011 12:57:07 +0200 Received: by fxe4 with SMTP id 4so2452556fxe.27 for ; Fri, 08 Jul 2011 03:57:00 -0700 (PDT) Received: by 10.223.65.197 with SMTP id k5mr2893666fai.26.1310122620128; Fri, 08 Jul 2011 03:57:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.124.209 with HTTP; Fri, 8 Jul 2011 03:56:40 -0700 (PDT) In-Reply-To: <4E14D100.5010705@ogud.com> References: <4E14D100.5010705@ogud.com> From: bert hubert Date: Fri, 8 Jul 2011 12:56:40 +0200 Message-ID: To: Olafur Gudmundsson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam_report: Spam detection software, running on the system "xs.powerdns.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Wed, Jul 6, 2011 at 11:17 PM, Olafur Gudmundsson wrote: > Please review the document and sent a statement that you reviewed the > document. If the review raises any issues, please note what they are. > Remember that we need a minimum of 5 reviewers. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: dnsext@ietf.org Subject: Re: [dnsext] WGLC: Elliptic Curve DSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 10:57:19 -0000 On Wed, Jul 6, 2011 at 11:17 PM, Olafur Gudmundsson wrote: > Please review the document and sent a statement that you reviewed the > document. =A0If the review raises any issues, please note what they are. > Remember that we need a minimum of 5 reviewers. I have read this document and also the other reviews. I think this document should go ahead, with two clarifications, one of which is new. The first clarification is moving up the definition of ECDSA, but this has been noted already and Paul is going to fix it. The second one is that the document describes a signature as 'r|s'. In such cases, an implementor is always left wondering where r ends and s begins. In the case of 'r' and 's' both needing their full amount of bits, this is easy - the '|' goes exactly down the middle. But it is possible that either r or s fits in one octet less (or more even!). The same goes for x and y. It is helpful therefore to add a sentence that r and s are both left-padded to their full length or, alternatively, that r and s occupy the same number of octets in an answer (and the same goes for x and y). PowerDNS already includes support for ECDSA in the 3.0 prereleases, and we use the 'cut down the middle' rule. http://wiki.powerdns.com/trac/browser/trunk/pdns/pdns/cryptoppsigners.cc#L1= 19 But I'd love to see some text that makes it official. A suggestion might be as the new third paragraph of section 4: "Implementations will ensure that when concatenating the halves of a coordinate, each half takes up the same amount of octets, allowing for the unambiguous reconstruction of the coordinate on reception". Bert From ahu@xs.powerdns.com Fri Jul 8 04:08:30 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A0621F8870 for ; Fri, 8 Jul 2011 04:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.588 X-Spam-Level: X-Spam-Status: No, score=-0.588 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FAKE_REPLY_C=2.012, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Kai1jGlsiLD for ; Fri, 8 Jul 2011 04:08:29 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8A18521F87ED for ; Fri, 8 Jul 2011 04:08:29 -0700 (PDT) Received: from ahu by xs.powerdns.com with local (Exim 4.71) (envelope-from ) id 1Qf8v6-000754-Nk for dnsext@ietf.org; Fri, 08 Jul 2011 13:08:28 +0200 Date: Fri, 8 Jul 2011 13:08:28 +0200 From: bert hubert To: dnsext@ietf.org Message-ID: <20110708110828.GA15836@xs.powerdns.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [dnsext] WGLC: Elliptic Curve DSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 11:08:30 -0000 On Wed, Jul 6, 2011 at 11:17 PM, Olafur Gudmundsson wrote: > Please review the document and sent a statement that you reviewed the > document. =A0If the review raises any issues, please note what they are. > Remember that we need a minimum of 5 reviewers. I have read this document and also the other reviews. I think this document should go ahead, with two clarifications, one of which is new. The first clarification is moving up the definition of ECDSA, but this has been noted already and Paul is going to fix it. The second one is that the document describes a signature as 'r|s'. In such cases, an implementor is always left wondering where r ends and s begins. In the case of 'r' and 's' both needing their full amount of bits, this is easy - the '|' goes exactly down the middle. But it is possible that either r or s fits in one octet less (or more even!). The same goes for x and y. It is helpful therefore to add a sentence that r and s are both left-padded to their full length or, alternatively, that r and s occupy the same number of octets in an answer (and the same goes for x and y). PowerDNS already includes support for ECDSA in the 3.0 prereleases, and we use the 'cut down the middle' rule. http://wiki.powerdns.com/trac/browser/trunk/pdns/pdns/cryptoppsigners.cc#L1= 19 But I'd love to see some text that makes it official. A suggestion might be as the new third paragraph of section 4: "Implementations will ensure that when concatenating the halves of a coordinate, each half takes up the same amount of octets, allowing for the unambiguous reconstruction of the coordinate on reception". Bert From scottr.nist@gmail.com Fri Jul 8 05:26:47 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B18F21F8998 for ; Fri, 8 Jul 2011 05:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7sCZjTWXrdb for ; Fri, 8 Jul 2011 05:26:47 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by ietfa.amsl.com (Postfix) with ESMTP id DD84821F8991 for ; Fri, 8 Jul 2011 05:26:46 -0700 (PDT) Received: from 107-140.antd.nist.gov (107-140.antd.nist.gov [129.6.140.107]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p68CQZUK027854 for ; Fri, 8 Jul 2011 08:26:37 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Scott Rose In-Reply-To: <4E14D100.5010705@ogud.com> Date: Fri, 8 Jul 2011 08:26:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <564B3EB6-8E63-4CF2-AB5D-143124ACDF1C@gmail.com> References: <4E14D100.5010705@ogud.com> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1084) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr.nist@gmail.com Subject: Re: [dnsext] WGLC: Elliptic Curve DSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 12:26:47 -0000 I have read the draft and have no additional comments. I support it = going forward. Scott On Jul 6, 2011, at 5:17 PM, Olafur Gudmundsson wrote: > Dear Colleagues >=20 > This message starts a Working Group Last Call for > "Elliptic Curve DSA for DNSSEC" located at > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecdsa-01.txt > This document is on Standards track. >=20 > This WGLC will conclude on midnight on July 21'th UTC. >=20 > Please review the document and sent a statement that you reviewed the > document. If the review raises any issues, please note what they are. > Remember that we need a minimum of 5 reviewers. >=20 >=20 > Olafur & Andrew > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From miekg@atoom.net Fri Jul 8 05:27:29 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52A721F88A7 for ; Fri, 8 Jul 2011 05:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8RxJN4Acjfd for ; Fri, 8 Jul 2011 05:27:29 -0700 (PDT) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD5B21F8681 for ; Fri, 8 Jul 2011 05:27:29 -0700 (PDT) Received: by elektron.atoom.net (Postfix, from userid 1000) id 5C9203FFF3; Fri, 8 Jul 2011 14:27:27 +0200 (CEST) Date: Fri, 8 Jul 2011 14:27:27 +0200 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20110708122727.GA2845@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <20110708110828.GA15836@xs.powerdns.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline In-Reply-To: <20110708110828.GA15836@xs.powerdns.com> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl Subject: Re: [dnsext] WGLC: Elliptic Curve DSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 12:27:29 -0000 --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [ Quoting bert hubert at 13:08 on July 8 in "Re: [dnsext] WGLC: Elliptic Curve D"... ] > On Wed, Jul 6, 2011 at 11:17 PM, Olafur Gudmundsson wrote: > > Please review the document and sent a statement that you reviewed the > > document. =A0If the review raises any issues, please note what they are. > > Remember that we need a minimum of 5 reviewers. > But I'd love to see some text that makes it official. A suggestion > might be as the new third paragraph of section 4: > "Implementations will ensure that when concatenating the halves of a > coordinate, each half takes up the same amount of octets, allowing for > the unambiguous reconstruction of the coordinate on reception". I've read the draft and support its publication, but I also like to see the text propposed by Bert to be included. Regards, Miek --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4W968ACgkQJYuFzziA0PZStgCffpLoJuzJ/bs+XwHqFAUKHsYS clQAoOIYipiAOuHVRefzbKiLHHRXqK7q =hVar -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- From wouter@nlnetlabs.nl Sat Jul 9 03:34:28 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F78921F8752 for ; Sat, 9 Jul 2011 03:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSRm4zxkBHZ1 for ; Sat, 9 Jul 2011 03:34:26 -0700 (PDT) Received: from spalding.dds.nl (spalding.dds.nl [85.17.178.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2E63521F8751 for ; Sat, 9 Jul 2011 03:34:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by spalding.dds.nl (Postfix) with ESMTP id 58C1362806E for ; Sat, 9 Jul 2011 12:34:24 +0200 (CEST) Received: from [192.168.254.2] (195-241-9-117.adsl.dds.nl [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by spalding.dds.nl (Postfix) with ESMTPSA id 60A87628075 for ; Sat, 9 Jul 2011 12:34:18 +0200 (CEST) Message-ID: <4E182EAB.9080803@nlnetlabs.nl> Date: Sat, 09 Jul 2011 12:34:19 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110616 SUSE/3.1.11 Thunderbird/3.1.11 MIME-Version: 1.0 To: dnsext@ietf.org References: <20110708110828.GA15836@xs.powerdns.com> <20110708122727.GA2845@miek.nl> In-Reply-To: <20110708122727.GA2845@miek.nl> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at spalding X-Virus-Status: Clean Subject: Re: [dnsext] WGLC: Elliptic Curve DSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 10:34:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/08/2011 02:27 PM, Miek Gieben wrote: > [ Quoting bert hubert at 13:08 on July 8 in "Re: [dnsext] WGLC: Elliptic Curve D"... ] >> On Wed, Jul 6, 2011 at 11:17 PM, Olafur Gudmundsson wrote: >>> Please review the document and sent a statement that you reviewed the >>> document. =A0If the review raises any issues, please note what they are. >>> Remember that we need a minimum of 5 reviewers. > >> But I'd love to see some text that makes it official. A suggestion >> might be as the new third paragraph of section 4: >> "Implementations will ensure that when concatenating the halves of a >> coordinate, each half takes up the same amount of octets, allowing for >> the unambiguous reconstruction of the coordinate on reception". > > I've read the draft and support its publication, but I also like to > see the text propposed by Bert to be included. I have not actually checked this, but the bit length of P256 and P384 are divisible by 8 (divisible by 64 even). Hence the width of these variables in octets is a whole number of octets? Are you proposing some sort of variable length encoding? I would prefer simplicity. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOGC6rAAoJEJ9vHC1+BF+Na+UP/1U6khsc7UYfKWJLRDcEaNUM FIJ4o9iDv+lcz4oC4japjDCF9rrXGh9Um5L9Y3ME2A79m/RFUFb2ZbuqmkHxQ8H2 I/eo3SNGaUoLG44k8ET6x7yK86co7P7fjalsNi++BveZE5+fOzJ6wBen6OcEyCrz VKytsQtK5b4Pgr1i22Udjcm/ZnWJvYrfoZ87P0agcFLmbRd+E3BRtCl1KqyV0F3A XhQFnUAFM8jotyysqCtWJpvw/yULrsJ6H3yvJxBv2qvBwSfRDvQI3vZV6fYoK8Pm vDuXssJ3FB5QdOR2kcGFjnQ4qOd/i0HOCeqctfMvW+jtB+Oxt4Ceiui0snYXBbCO ci1fFxJP3yvreXkgW6ylzCn/afYgIZePa6GOmFHxZf1edxgg0NmEt/N38UE7aGJG SjCRHU0FUXJkI14EhJiIPC+rpWKzx6PCpTHYOmbMn3+pE0ppJ3lXUYcv91Ys5qQK JZ/XzUxyIQrVOWfS3tS5qsh6ZsHeXgBAqDu8efNG2qQ/yEziI2neQC0WYMCl3Qz8 2LkNEgVZ+lfk4hrOUf+CtY8btysFf3S5OLRoEXkguUaEXNFALDzYag6pxyx+RzyI Ao6gJOvXV9E1YszETApSFBzLv9iqABpefAmb7Q/GrWG7z+VAFwSD4N1L1LzH5yKp HiIdaGT3ItCG8H11I4pU =pFTk -----END PGP SIGNATURE----- From mstjohns@comcast.net Sat Jul 9 08:01:15 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D989B21F87C6 for ; Sat, 9 Jul 2011 08:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twmF0LN71VdQ for ; Sat, 9 Jul 2011 08:01:15 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4A37221F87C5 for ; Sat, 9 Jul 2011 08:01:15 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta06.westchester.pa.mail.comcast.net with comcast id 5qip1h0051c6gX856r1FCr; Sat, 09 Jul 2011 15:01:15 +0000 Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta23.westchester.pa.mail.comcast.net with comcast id 5r1E1h00r1EtFYL3jr1EVq; Sat, 09 Jul 2011 15:01:15 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 09 Jul 2011 11:01:10 -0400 To: "W.C.A. Wijngaards" ,dnsext@ietf.org From: Michael StJohns In-Reply-To: <4E182EAB.9080803@nlnetlabs.nl> References: <20110708110828.GA15836@xs.powerdns.com> <20110708122727.GA2845@miek.nl> <4E182EAB.9080803@nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20110709150115.4A37221F87C5@ietfa.amsl.com> Subject: Re: [dnsext] WGLC: Elliptic Curve DSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 15:01:16 -0000 Note below. At 06:34 AM 7/9/2011, W.C.A. Wijngaards wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 >>> But I'd love to see some text that makes it official. A suggestion >>> might be as the new third paragraph of section 4: >>> "Implementations will ensure that when concatenating the halves of a >>> coordinate, each half takes up the same amount of octets, allowing for >>> the unambiguous reconstruction of the coordinate on reception". >> >> I've read the draft and support its publication, but I also like to >> see the text propposed by Bert to be included. > >I have not actually checked this, but the bit length of P256 and P384 >are divisible by 8 (divisible by 64 even). Hence the width of these >variables in octets is a whole number of octets? > >Are you proposing some sort of variable length encoding? I would prefer >simplicity. I'm pretty sure what Olafur is saying is that one possible encoding for an integer is no leading zeros, or additional leading zeros if the high bit is set. e.g. 00000056abcd1234.... 56abcd1234). You want to be clear that the point is encoded as 2N octets, where N is 16 for P256 and 24 for P384. I'm coming to this late, otherwise I would have strongly recommended using the well-defined point encoding from X9.6 - of 2N+1 where the first octet is 04 to indicate uncompressed. The saving of one byte seems to be short-sighted as this is yet another form of public key that tools will have to understand - pretty much every tool/library I know of will require the "04" be prepended to the key bytes before the key can be loaded for verification. (See RFC 5480, section 2.2 for better text on how to do the encoding) Mike From miekg@atoom.net Sat Jul 9 10:07:35 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23D221F87C7 for ; Sat, 9 Jul 2011 10:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yU4-dbL2Jcng for ; Sat, 9 Jul 2011 10:07:35 -0700 (PDT) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB9821F877B for ; Sat, 9 Jul 2011 10:07:35 -0700 (PDT) Received: by elektron.atoom.net (Postfix, from userid 1000) id 1A1A13FFCA; Sat, 9 Jul 2011 19:07:29 +0200 (CEST) Date: Sat, 9 Jul 2011 19:07:29 +0200 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20110709170729.GA7877@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <20110708110828.GA15836@xs.powerdns.com> <20110708122727.GA2845@miek.nl> <4E182EAB.9080803@nlnetlabs.nl> <20110709150115.4A37221F87C5@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline In-Reply-To: <20110709150115.4A37221F87C5@ietfa.amsl.com> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl Subject: Re: [dnsext] WGLC: Elliptic Curve DSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 17:07:35 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [ Quoting Michael StJohns at 11:01 on July 9 in "Re: [dnsext] WGLC: Elliptic Curve D"... ] > I'm coming to this late, otherwise I would have strongly recommended > using the well-defined point encoding from X9.6 - of 2N+1 where the > first octet is 04 to indicate uncompressed. The saving of one byte > seems to be short-sighted as this is yet another form of public key > that tools will have to understand - pretty much every tool/library > I know of will require the "04" be prepended to the key bytes before > the key can be loaded for verification. (See RFC 5480, section 2.2 > for better text on how to do the encoding) +1 I now understand why my ecdsa library has Marshal/Unmarshal functions, and why I could not use them in this case. Regards, Miek --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4YitEACgkQJYuFzziA0PberwCfdvm6PNZHntsAID2W2Z5o7Rx8 Z5AAnAgbZgqPYiJVVzAxYL31IoXbZ0fD =Wsbs -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- From internet-drafts@ietf.org Mon Jul 11 09:04:25 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB5221F8C71; Mon, 11 Jul 2011 09:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAoZZRX-z8HY; Mon, 11 Jul 2011 09:04:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4543D21F8E7B; Mon, 11 Jul 2011 09:04:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711160424.4108.54615.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 09:04:24 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-bis-updates-13.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 16:04:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the I= ETF. Title : Clarifications and Implementation Notes for DNSSECbis Author(s) : Samuel Weiler David Blacka Filename : draft-ietf-dnsext-dnssec-bis-updates-13.txt Pages : 15 Date : 2011-07-11 This document is a collection of technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as a repository of DNSSECbis errata. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-13= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-13.= txt From weiler@tislabs.com Mon Jul 11 09:20:11 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD1E21F8E36 for ; Mon, 11 Jul 2011 09:20:11 -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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4Cimo1O4XZG for ; Mon, 11 Jul 2011 09:20:11 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDAB11E8088 for ; Mon, 11 Jul 2011 09:20:03 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id EBD7928B003C; Mon, 11 Jul 2011 12:20:02 -0400 (EDT) Received: from nova.tislabs.com (nova.tislabs.com [10.66.1.77]) by nova.tislabs.com (Postfix) with ESMTP id D11A71F8032; Mon, 11 Jul 2011 12:20:02 -0400 (EDT) Date: Mon, 11 Jul 2011 12:20:02 -0400 (EDT) From: weiler@tislabs.com To: Matthijs Mekking In-Reply-To: <4D938CC3.1020103@nlnetlabs.nl> Message-ID: References: <4CE51293.5040605@nlnetlabs.nl> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> <20110314213319.A2799C8CA0B@drugs.dv.isc.org> <4D938CC3.1020103@nlnetlabs.nl> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] Clarifying the mandatory algorithm rules X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 16:20:11 -0000 On Wed, 30 Mar 2011, Matthijs Mekking wrote: > Ok, so let's try to come to a reasonable clarifying text: Many thanks to both Matthijs and Ed for proposing clarifying text. I just added this to dnssec-bis-updates, using a mix of text from Matthijs, Ed, and myself. -- Sam From weiler@tislabs.com Mon Jul 11 09:24:24 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D7E11E8088 for ; Mon, 11 Jul 2011 09: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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOb9vVgiOXbp for ; Mon, 11 Jul 2011 09:24:23 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8002511E80B1 for ; Mon, 11 Jul 2011 09:24:02 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 38CB328B0048; Mon, 11 Jul 2011 12:24:02 -0400 (EDT) Received: from nova.tislabs.com (nova.tislabs.com [10.66.1.77]) by nova.tislabs.com (Postfix) with ESMTP id 291201F8033; Mon, 11 Jul 2011 12:24:02 -0400 (EDT) Date: Mon, 11 Jul 2011 12:24:02 -0400 (EDT) From: weiler@tislabs.com To: "W.C.A. Wijngaards" In-Reply-To: <4C5986E7.4020400@nlnetlabs.nl> Message-ID: References: <4C5986E7.4020400@nlnetlabs.nl> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] algorithm rollover X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 16:24:24 -0000 While this dicussion (on this list) seemed to conclude that most of these changes belong in other docs, I did add one piece from it to dnssec-bis-updates: > In dnssecbis-updates, ...a zone MAY contain RRSIG's for an DNSKEY > that does not exist in the DNSKEY RRset. -- Sam From warren@kumari.net Wed Jul 13 12:54:00 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E11811E808C for ; Wed, 13 Jul 2011 12:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGnvHk-vs+Wu for ; Wed, 13 Jul 2011 12:54:00 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id D01A111E8135 for ; Wed, 13 Jul 2011 12:53:56 -0700 (PDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id 4D95E1B409DA; Wed, 13 Jul 2011 15:53:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <4158B8A7-7773-4819-90F4-BF6F7973B1C7@gmail.com> Date: Wed, 13 Jul 2011 15:53:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4EE862D0-592A-420C-BECA-66B9B53A9B72@kumari.net> References: <20110706135012.13666.6167.idtracker@ietfa.amsl.com> <4158B8A7-7773-4819-90F4-BF6F7973B1C7@gmail.com> To: Scott Rose X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: I-D Action: draft-ietf-dnsext-dnssec-algo-signal-02.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 19:54:00 -0000 On Jul 6, 2011, at 10:00 AM, Scott Rose wrote: > An updated version of the algo-signal draft to address the issues in = WGLC. Specific changes: >=20 > 1. Changed the wording in 3.4.1 to remove the RFC2119 wording on = setting the DO bit. =20 >=20 > 2. Changed section 4 wording to indicate DNS proxy systems and added a = ref to RFC 5625. >=20 > 3. fixed some typos and minor wording changes to stress that the DAU = option is for signaling only and does not specify any change to how = servers construct a response. >=20 > Scott Oooh, I like this version.... Some simple nits: Section1: Introduction: O: "for use with DNSSEC (see . " C: Somethings missing here :-P O: "by which a client query can signal a set of algorithms it = implements." P: "by which a client query can signal a set of algorithms which it = implements. C: or "that" or something ? Section 2 O: "for the DNSSEC Algorithm Understood (DAU)" P: for the DNSSEC Algorithms Understood (DAU)" C: Plural? O: "DNSSEC algorithm codes are 1 octet long so this value is the number = of octets." P: "" C: Is this sentence needed? I don't have proposed text, but I found it = broke the flow of the text... Section 3.1: O: "So optimal setting of the DAU" P: "Optimal setting of the DAU" Section 3.2: O: "This way thee validating stub resolver" P: "This way the validating stub resolver" C: 'thee" is *so* last century... Section 3.4.1: O: "A validating recursive resolver sets..." C: It *might* be interesting to somewhere also include a flag saying if = the DAU was included because the client did so, or if the recursive did = so because of local policy...=20 Section 6: O: "Zone administrators that are planning" P: "Zone administrators who are planning" C: Just sounds better (IMO). W >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Date: July 6, 2011 9:50:12 AM EDT >> To: i-d-announce@ietf.org >> Cc: dnsext@ietf.org >> Subject: [dnsext] I-D Action: = draft-ietf-dnsext-dnssec-algo-signal-02.txt >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the DNS Extensions Working = Group of the IETF. >>=20 >> Title : Signaling Cryptographic Algorithm = Understanding in DNSSEC >> Author(s) : Steve Crocker >> Scott Rose >> Filename : draft-ietf-dnsext-dnssec-algo-signal-02.txt >> Pages : 8 >> Date : 2011-07-06 >>=20 >> The DNS Security Extensions (DNSSEC) were developed to provide = origin >> authentication and integrity protection for DNS data by using = digital >> signatures. These digital signatures can be generated using >> different algorithms. This draft sets out to specify a way for >> validating end-system resolvers to signal to a server which >> cryptographic algorithms they support. >>=20 >>=20 >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-0= 2.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-02= .txt >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext >=20 From rwfranks@gmail.com Thu Jul 14 12:01:08 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5E721F87C3 for ; Thu, 14 Jul 2011 12:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWvgQZ4UmqXF for ; Thu, 14 Jul 2011 12:01:08 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id C84A411E81EC for ; Thu, 14 Jul 2011 12:00:21 -0700 (PDT) Received: by qwc23 with SMTP id 23so364013qwc.31 for ; Thu, 14 Jul 2011 12:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=V8bqRgRGWX5Wdt3w7i300CaVu1LlqmaQSw9QUkqbuV0=; b=k8C4JhVYcHgIsHZL+HMsxTb+LXH7eNn/8DCCzDYb3jFlvgOr1w5Mt3clDMsHjWC9Jk 0ywXa39a8W6q64tOygSRf/nO0EYbYrrxjeCCGtubfd46sKYfbGwK4wQodLDvV900S2Vj xnS5DOaCdDI2UALIpYiW9XCR41UnozhYRoFuc= Received: by 10.229.251.70 with SMTP id mr6mr1779569qcb.276.1310670021119; Thu, 14 Jul 2011 12:00:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.245.136 with HTTP; Thu, 14 Jul 2011 11:59:59 -0700 (PDT) In-Reply-To: <4158B8A7-7773-4819-90F4-BF6F7973B1C7@gmail.com> References: <20110706135012.13666.6167.idtracker@ietfa.amsl.com> <4158B8A7-7773-4819-90F4-BF6F7973B1C7@gmail.com> From: Dick Franks Date: Thu, 14 Jul 2011 19:59:59 +0100 Message-ID: To: Scott Rose , =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 14 Jul 2011 12:32:45 -0700 Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-02.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 19:23:41 -0000 Scott, Patrik, I find myself roused from dnsext lurking mode by what appears to be a conflict between draft02 of this proposal and the requirements of RFC2671, which has somehow slipped through review. RFC2671 defines OPT record wire-format to be a list of elements of the form: [
   A security-aware resolver SHOULD cache each response as a single
   atomic entry containing the entire answer, including the named RRset
   and any associated DNSSEC RRs.  The resolver SHOULD discard the
   entire atomic entry when any of the RRs contained in it expire.


DNSSEC =A0RRs here includes NSECs also. For example, when = processing a wildcard answer response, NSEC also should be taken into consi= deration when determining the TTL of the "atomic" entry. In secti= on 5.3.3, the discussion about setting the TTL does not explicitly mention = this case (or other cases where the response contains NSEC). I guess this i= s just a trivial omission. Can someone clarify ?

-regards=A0
Sean
--bcaec54ee67c96d2ba04a9670906--