Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA14D3A6BCE for ; Thu, 31 Mar 2011 20:13:46 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUWNKBSgM2CV for ; Thu, 31 Mar 2011 20:13:45 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 875BC3A6BCC for ; Thu, 31 Mar 2011 20:13:45 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 294582CE005; Fri, 1 Apr 2011 16:15:28 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80lnpOBbeslL; Fri, 1 Apr 2011 16:15:28 +1300 (NZDT) Received: from [192.168.1.6] (121-73-171-124.dsl.telstraclear.net [121.73.171.124]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 91BB72CE004; Fri, 1 Apr 2011 16:15:27 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <3DCDB1C2-A372-43F0-A87A-AC97D1FEA8A8@bbn.com> Date: Fri, 1 Apr 2011 16:15:22 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <05F78A16-9DC8-4412-9F18-8976928BE8C4@nzrs.net.nz> References: <4F5CBD0D-E9D4-4042-B082-B15D3D509A37@edvina.net> <57F0D906-4EF8-4628-AAE0-34C661A7184E@bbn.com> <3DCDB1C2-A372-43F0-A87A-AC97D1FEA8A8@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1084) Cc: keyassure@ietf.org Subject: Re: [keyassure] The draft and subj alt names X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 03:13:47 -0000 On 1/04/2011, at 3:06 PM, Richard L. Barnes wrote: > The only choice that avoids updating several RFCs is 5. Is that your only reason for not wanting to tackle this? Do you have = any view on the nature of trust that DNSSEC provides to applications or = not? > Just leave it alone! No. warmest regards Jay > --Richard >=20 >=20 > On Mar 31, 2011, at 10:41 PM, Jay Daley wrote: >=20 >> On 1/04/2011, at 12:12 AM, Richard L. Barnes wrote: >>=20 >>> As I've said in other threads, this WG should be silent on = requirements for certificate names, since different applications use TLS = certificate names in different ways. See for example the difference = between RFC 2818 and RFC 6125. The text you reference in the draft is = technically harmless ("must" not "MUST"), but should probably be deleted = anyway. >>=20 >> There are two separate issues here: >> a) whether we think name matching is still needed with DANE >> b) what the draft should say about that >>=20 >> On a) I would make the case that name matching is should not be done = because >> - DNSSEC provides sufficient trust >> - name matching forces certain operational decisions onto end user = (e.g. multiple certs, cert reuse) that are unreasonable >>=20 >> On b) There are six options for the draft: >>=20 >> 1. State that name matching must be done >> 2. State that name matching must not be done >> 3. Leave it to applications with a recommendation to match >> 4. Leave it to applications with a recommendation not to match >> 5. Leave it to applications with no recommendation >> 6. Add a flag into TLSA that specifies whether name matching is to = be done or not >>=20 >> My choice, in order of preference would be 2, 6, 4. =20 >>=20 >> Jay >>=20 >>>=20 >>> --Richard >>>=20 >>>=20 >>>=20 >>> On Mar 31, 2011, at 12:05 PM, Olle E. Johansson wrote: >>>=20 >>>> I have read the draft and reacted to one thing. Sorry if this = already have been discussed on the list. >>>>=20 >>>> The draft -06 says >>>> "The end entity certificate from TLS, regardless of whether it was >>>> matched with a TLSA type 1 certificate or chained to a TLSA type 2 = CA >>>> certificate, must have at least one identifier in the subject or >>>> subjectAltName field of the matched certificates matches the = expected >>>> identifier for the TLS server. " >>>>=20 >>>> The new RFC 6125 tells us that we should: >>>> "Move toward including and checking even more specific >>>> subjectAlternativeName extensions where appropriate for using the >>>> protocol (e.g., uniformResourceIdentifier and the otherName form >>>> SRVName)." >>>>=20 >>>> I feel we need to be more specific in the draft. What type of = subjectAltName should we match with? >>>> dnsName? >>>>=20 >>>> And if we're using SIP, and have URI's in the certificate - should = that be part of this draft >>>> or should we open for protocol-specific specifications for other = types of subject Alt Names? >>>>=20 >>>> /O >>>> _______________________________________________ >>>> keyassure mailing list >>>> keyassure@ietf.org >>>> https://www.ietf.org/mailman/listinfo/keyassure >>>=20 >>> _______________________________________________ >>> keyassure mailing list >>> keyassure@ietf.org >>> https://www.ietf.org/mailman/listinfo/keyassure >>=20 >>=20 >> --=20 >> Jay Daley >> Chief Executive >> .nz Registry Services (New Zealand Domain Name Registry Limited) >> desk: +64 4 931 6977 >> mobile: +64 21 678840 >>=20 >=20 --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D645F3A6AC1 for ; Thu, 31 Mar 2011 19:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnjjzBl9FJPf for ; Thu, 31 Mar 2011 19:05:20 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id BAEFE3A6AD2 for ; Thu, 31 Mar 2011 19:05:20 -0700 (PDT) Received: from [128.89.255.112] (port=56884 helo=dhcp-415b.meeting.ietf.org) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q5TlL-000Ez1-Si; Thu, 31 Mar 2011 22:07:00 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Fri, 1 Apr 2011 04:06:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3DCDB1C2-A372-43F0-A87A-AC97D1FEA8A8@bbn.com> References: <4F5CBD0D-E9D4-4042-B082-B15D3D509A37@edvina.net> <57F0D906-4EF8-4628-AAE0-34C661A7184E@bbn.com> To: Jay Daley X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] The draft and subj alt names X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 02:05:22 -0000 The only choice that avoids updating several RFCs is 5. Just leave it = alone! --Richard On Mar 31, 2011, at 10:41 PM, Jay Daley wrote: > On 1/04/2011, at 12:12 AM, Richard L. Barnes wrote: >=20 >> As I've said in other threads, this WG should be silent on = requirements for certificate names, since different applications use TLS = certificate names in different ways. See for example the difference = between RFC 2818 and RFC 6125. The text you reference in the draft is = technically harmless ("must" not "MUST"), but should probably be deleted = anyway. >=20 > There are two separate issues here: > a) whether we think name matching is still needed with DANE > b) what the draft should say about that >=20 > On a) I would make the case that name matching is should not be done = because > - DNSSEC provides sufficient trust > - name matching forces certain operational decisions onto end user = (e.g. multiple certs, cert reuse) that are unreasonable >=20 > On b) There are six options for the draft: >=20 > 1. State that name matching must be done > 2. State that name matching must not be done > 3. Leave it to applications with a recommendation to match > 4. Leave it to applications with a recommendation not to match > 5. Leave it to applications with no recommendation > 6. Add a flag into TLSA that specifies whether name matching is to be = done or not >=20 > My choice, in order of preference would be 2, 6, 4. =20 >=20 > Jay >=20 >>=20 >> --Richard >>=20 >>=20 >>=20 >> On Mar 31, 2011, at 12:05 PM, Olle E. Johansson wrote: >>=20 >>> I have read the draft and reacted to one thing. Sorry if this = already have been discussed on the list. >>>=20 >>> The draft -06 says >>> "The end entity certificate from TLS, regardless of whether it was >>> matched with a TLSA type 1 certificate or chained to a TLSA type 2 = CA >>> certificate, must have at least one identifier in the subject or >>> subjectAltName field of the matched certificates matches the = expected >>> identifier for the TLS server. " >>>=20 >>> The new RFC 6125 tells us that we should: >>> "Move toward including and checking even more specific >>> subjectAlternativeName extensions where appropriate for using the >>> protocol (e.g., uniformResourceIdentifier and the otherName form >>> SRVName)." >>>=20 >>> I feel we need to be more specific in the draft. What type of = subjectAltName should we match with? >>> dnsName? >>>=20 >>> And if we're using SIP, and have URI's in the certificate - should = that be part of this draft >>> or should we open for protocol-specific specifications for other = types of subject Alt Names? >>>=20 >>> /O >>> _______________________________________________ >>> keyassure mailing list >>> keyassure@ietf.org >>> https://www.ietf.org/mailman/listinfo/keyassure >>=20 >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >=20 >=20 > --=20 > Jay Daley > Chief Executive > .nz Registry Services (New Zealand Domain Name Registry Limited) > desk: +64 4 931 6977 > mobile: +64 21 678840 >=20 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F7FF3A6BAF for ; Thu, 31 Mar 2011 13:39:49 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkwhViRfWP-E for ; Thu, 31 Mar 2011 13:39:48 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 0CE453A6BA1 for ; Thu, 31 Mar 2011 13:39:47 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 1F5C62CE005; Fri, 1 Apr 2011 09:41:30 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onlp7ZrYFh4U; Fri, 1 Apr 2011 09:41:30 +1300 (NZDT) Received: from [192.168.1.4] (121-73-166-144.dsl.telstraclear.net [121.73.166.144]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 8B5392CE004; Fri, 1 Apr 2011 09:41:29 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <57F0D906-4EF8-4628-AAE0-34C661A7184E@bbn.com> Date: Fri, 1 Apr 2011 09:41:24 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F5CBD0D-E9D4-4042-B082-B15D3D509A37@edvina.net> <57F0D906-4EF8-4628-AAE0-34C661A7184E@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1084) Cc: keyassure@ietf.org Subject: Re: [keyassure] The draft and subj alt names X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 20:39:49 -0000 On 1/04/2011, at 12:12 AM, Richard L. Barnes wrote: > As I've said in other threads, this WG should be silent on = requirements for certificate names, since different applications use TLS = certificate names in different ways. See for example the difference = between RFC 2818 and RFC 6125. The text you reference in the draft is = technically harmless ("must" not "MUST"), but should probably be deleted = anyway. There are two separate issues here: a) whether we think name matching is still needed with DANE b) what the draft should say about that On a) I would make the case that name matching is should not be done = because - DNSSEC provides sufficient trust - name matching forces certain operational decisions onto end user (e.g. = multiple certs, cert reuse) that are unreasonable On b) There are six options for the draft: 1. State that name matching must be done 2. State that name matching must not be done 3. Leave it to applications with a recommendation to match 4. Leave it to applications with a recommendation not to match 5. Leave it to applications with no recommendation 6. Add a flag into TLSA that specifies whether name matching is to be = done or not My choice, in order of preference would be 2, 6, 4. =20 Jay >=20 > --Richard >=20 >=20 >=20 > On Mar 31, 2011, at 12:05 PM, Olle E. Johansson wrote: >=20 >> I have read the draft and reacted to one thing. Sorry if this already = have been discussed on the list. >>=20 >> The draft -06 says >> "The end entity certificate from TLS, regardless of whether it was >> matched with a TLSA type 1 certificate or chained to a TLSA type 2 = CA >> certificate, must have at least one identifier in the subject or >> subjectAltName field of the matched certificates matches the = expected >> identifier for the TLS server. " >>=20 >> The new RFC 6125 tells us that we should: >> "Move toward including and checking even more specific >> subjectAlternativeName extensions where appropriate for using the >> protocol (e.g., uniformResourceIdentifier and the otherName form >> SRVName)." >>=20 >> I feel we need to be more specific in the draft. What type of = subjectAltName should we match with? >> dnsName? >>=20 >> And if we're using SIP, and have URI's in the certificate - should = that be part of this draft >> or should we open for protocol-specific specifications for other = types of subject Alt Names? >>=20 >> /O >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >=20 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A50E3A6A63 for ; Thu, 31 Mar 2011 10:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mNQoQ94t72F for ; Thu, 31 Mar 2011 10:06:56 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 7875D3A6A33 for ; Thu, 31 Mar 2011 10:06:56 -0700 (PDT) Received: from [IPv6:2001:df8:0:96:221:6aff:fe5b:b80] (unknown [IPv6:2001:df8:0:96:221:6aff:fe5b:b80]) by mail.nic.cz (Postfix) with ESMTPSA id E014F2A29DA for ; Thu, 31 Mar 2011 19:08:33 +0200 (CEST) Message-ID: <4D94B511.3080803@nic.cz> Date: Thu, 31 Mar 2011 19:08:33 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Thunderbird/3.1.9 MIME-Version: 1.0 To: keyassure@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [keyassure] Mis-issued certs for Google / Yahoo / Skype, etc. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 17:06:58 -0000 On 24.3.2011 09:17, Warren Kumari wrote: > I'm assuming everyone has already seen this, but on the off-chance that you haven't: > > http://threatpost.com/en_us/blogs/phony-web-certificates-issued-google-yahoo-skype-others-032311# > > Being able to state "That ain't my cert" is one of the drivers for this work.... And there is a follow-up: http://www.h-online.com/security/news/item/Comodo-two-more-resellers-were-compromised-1218517.html O. -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- LaboratoÅ™e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E68F28C106 for ; Thu, 31 Mar 2011 07:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.06 X-Spam-Level: X-Spam-Status: No, score=-2.06 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhvBi34Q0udd for ; Thu, 31 Mar 2011 07:11:52 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id 641D73A69BD for ; Thu, 31 Mar 2011 07:11:52 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 6F13B400FA; Thu, 31 Mar 2011 14:13:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1301580810; bh=3kfvi4PVxaL71ErYV76GmG724Sqh6JUblMnbuPZvDYA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=P/x0Z5Kfgaot2g53RdCUYcDSeI99bUuDTWpgFd51dvn5l5Nlvv17eiCViG8muMj79 OgxHvDGDxrIBD95kpi8c/NzVRwRkB1ueF+qXXA5k3BQgcWH2XXlU6cQfTX9tKT5Nnr 4BFKvgg3d25XMgMavoUlCWpifO1OBW3XcxidUAw0= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 0B63A260042; Thu, 31 Mar 2011 14:02:48 +0000 (UTC) From: James Cloos To: mrex@sap.com In-Reply-To: <201103311302.p2VD2AWx020816@fs4113.wdf.sap.corp> (Martin Rex's message of "Thu, 31 Mar 2011 15:02:10 +0200 (MEST)") References: <201103311302.p2VD2AWx020816@fs4113.wdf.sap.corp> User-Agent: Gnus/5.110014 (No Gnus v0.14) Emacs/24.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2011 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 31 Mar 2011 10:02:48 -0400 Message-ID: Lines: 25 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:110331:mrex@sap.com::zJsh2sZglS5jmL5M:0000avsl4 X-Hashcash: 1:30:110331:ekr@rtfm.com::CEoyFTDH1WtYcXvQ:0000uu9zV X-Hashcash: 1:30:110331:keyassure@ietf.org::unrpzcZDCJvQwMzI:000000000000000000000000000000000000000000RJuCM Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:11:54 -0000 >>>>> "MR" == Martin Rex writes: MR> In a first round of attack, the attacker inserts a fake unsigned MR> TLSA record (DNS poisoning) that the victim is accessing with TLS MR> frequently and where the DNS admin is not using DNSSEC. Why would an attacker insert a fake tlsa w/o a matching fake a or aaaa? More likely they inject both and send the user off to a fake site with matching fake credentials. The client software might notice that the creds have changed since the last time it visited (/if/ it has ever visited), but how many do that for longer than a "session"? Any? Without dane the attacker just does the fake a/aaaa, fake server and fake cert an still wins. So it isn't a regression. But dtls w/o dnssec doesn't actually help either. Injecting a dtls w/o also injecting other fake RRs might get done as a lark, but any real attacks will be more sophisticated. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9054028C168 for ; Thu, 31 Mar 2011 06:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.221 X-Spam-Level: X-Spam-Status: No, score=-10.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Es1MGVJF9GAf for ; Thu, 31 Mar 2011 06:35:19 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 94C7928C153 for ; Thu, 31 Mar 2011 06:35:19 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p2VDafXL020422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Mar 2011 15:36:46 +0200 (MEST) From: Martin Rex Message-Id: <201103311336.p2VDafum022751@fs4113.wdf.sap.corp> To: rbarnes@bbn.com (Richard L. Barnes) Date: Thu, 31 Mar 2011 15:36:41 +0200 (MEST) In-Reply-To: from "Richard L. Barnes" at Mar 31, 11 03:29:18 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 13:35:20 -0000 Richard L. Barnes wrote: > > So it's a social engineering attack? Might as well just send an email trojan. > > This is the same result as > -- Hijacking the TCP session and feeding in a fake cert > -- Spoofing the A record and sending the client to the wrong host (like ekr said) > > --Richard To me, processing unsigned TLSA records is similar to processing unsigned OCSP responses or unsigned CRLs. I would not do the latter, and I'm in doubt that the former is a good idea. -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90D8228C170 for ; Thu, 31 Mar 2011 06:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0E6xlpD7GGxV for ; Thu, 31 Mar 2011 06:27:48 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 7255828C16E for ; Thu, 31 Mar 2011 06:27:47 -0700 (PDT) Received: from [128.89.255.156] (port=49970 helo=[130.129.71.95]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q5HwD-00037C-3M; Thu, 31 Mar 2011 09:29:25 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <201103311302.p2VD2AWx020816@fs4113.wdf.sap.corp> Date: Thu, 31 Mar 2011 15:29:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201103311302.p2VD2AWx020816@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 13:27:50 -0000 So it's a social engineering attack? Might as well just send an email = trojan. This is the same result as -- Hijacking the TCP session and feeding in a fake cert=20 -- Spoofing the A record and sending the client to the wrong host (like = ekr said) --Richard On Mar 31, 2011, at 3:02 PM, Martin Rex wrote: > Eric Rescorla wrote: >>=20 >> On Thu, Mar 31, 2011 at 2:38 AM, Martin Rex wrote: >>> Martin Rex wrote: >>>>=20 >>>>>=20 >>>>> I think this is an important consideration. However a relevant >>>>> question for a 2119-level MUST seems to be whether we wish to have >>>>> this data rejected if not DNSSEC signed. >>>>> What's your view on that? >>>>=20 >>>> I'm much less worried about false positives resulting in DoS, which >>>> can be more easily achieved attacking at the network layer (IP, = TCP). >>>=20 >>> Actually, a DoS based on spoofing an DANE TLSA record with incorrect >>> data and a long TTL into a DNS cache might turn out to be = devastatingly >>> effective when unsiged TLSA records are accepted. >>=20 >> How is this different from a spoofed A record with a long TTL? >=20 > In a first round of attack, the attacker inserts a fake unsigned > TLSA record (DNS poisoning) that the victim is accessing with TLS > frequently and where the DNS admin is not using DNSSEC. >=20 > After constantly running into validation failures although one is > connecting to the correct server and gets presented the correct > TLS server cert, either his help desk or the victim will disable DANE > or switch to a browser that doesn't have it yet. At that point > the victim becomes vulnerable to mis-issued certs even for sites > where the DNS admin uses DANE with DNSSEC. >=20 > -Martin >=20 >=20 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78A1328C155 for ; Thu, 31 Mar 2011 06:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.551 X-Spam-Level: X-Spam-Status: No, score=-10.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iixfsmiY-mCa for ; Thu, 31 Mar 2011 06:27:19 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 380FE28C141 for ; Thu, 31 Mar 2011 06:27:18 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p2VDSvFo014321; Thu, 31 Mar 2011 15:28:57 +0200 X-CheckPoint: {4D948106-13-1B221DC2-FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 31 Mar 2011 15:28:57 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 31 Mar 2011 15:28:56 +0200 From: Yoav Nir To: "mrex@sap.com" Date: Thu, 31 Mar 2011 15:28:54 +0200 Thread-Topic: [keyassure] Objective: Restrictive versus Supplementary Models Thread-Index: Acvvp5W1yDUfQJWyTmuIwei/6DbbJQ== Message-ID: <8BBFC78B-96FB-428B-9BB0-26F1431E63EF@checkpoint.com> References: <201103311309.p2VD9UwK021068@fs4113.wdf.sap.corp> In-Reply-To: <201103311309.p2VD9UwK021068@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 13:27:20 -0000 On Mar 31, 2011, at 3:09 PM, Martin Rex wrote: > Yoav Nir wrote: >>=20 >> On Mar 31, 2011, at 2:38 PM, Michael Richardson wrote: >>>=20 >>> Yoav> Cert-lock (and CA-lock) are what EKR calls supplementary, >>> Yoav> while the others are the restrictive. While the sever (and >>> Yoav> domain owner) can't dictate client policy, they should be able >>> Yoav> to indicate whether the Certificate (TA or EE) that's in the >>> Yoav> TLSA record is supposed to be validatable or not. The client >>> Yoav> (relying party) may have a policy to ignore records that push >>> Yoav> a non-valid certificate, but if you're going to publish a >>> Yoav> record with a certificate that you have just issued using >>> Yoav> openssl on your laptop and expires in 1975, the TLSA record >>> Yoav> had better reflect that this certificate is just a container >>> Yoav> for a public key, not something you can chain and validate.=20 >>>=20 >>> So, you are arguing that the protocol must signal the intent. >>=20 >> It's not strictly speaking "intent". It's more of an attribute. >> Either "this certificate of mine, you can use your regular validation >> techniques" or "this certificate of mine, just make sure you get this on= e." >=20 > I also think that leaving it up to the client to make assumptions > about what type of TLS Server cert validation scheme should be used > is likely going to result in a lot of bad decisions among the > implementors. >=20 > If the TLSA record includes the information on the intended validation > scheme for this information, then there is going to be more consistency > among the implementations. >=20 > When a particular HTML page renders without apparent problems in > one particular web browser, this is no proof that the page is correctly > formed and can be expected to render without problems in other > browsers as well. Just as long as we avoid the rat-hole of calling it "policy" Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E16613A6A1B for ; Thu, 31 Mar 2011 06:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.221 X-Spam-Level: X-Spam-Status: No, score=-10.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YGdsrfk976e for ; Thu, 31 Mar 2011 06:07:59 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id D7E0B3A67E9 for ; Thu, 31 Mar 2011 06:07:58 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p2VD9UOl013574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Mar 2011 15:09:30 +0200 (MEST) From: Martin Rex Message-Id: <201103311309.p2VD9UwK021068@fs4113.wdf.sap.corp> To: ynir@checkpoint.com (Yoav Nir) Date: Thu, 31 Mar 2011 15:09:30 +0200 (MEST) In-Reply-To: <8FA34510-B4BA-4DD2-B1D3-49D7100D7F62@checkpoint.com> from "Yoav Nir" at Mar 31, 11 03:01:19 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 13:08:00 -0000 Yoav Nir wrote: > > On Mar 31, 2011, at 2:38 PM, Michael Richardson wrote: > > > > Yoav> Cert-lock (and CA-lock) are what EKR calls supplementary, > > Yoav> while the others are the restrictive. While the sever (and > > Yoav> domain owner) can't dictate client policy, they should be able > > Yoav> to indicate whether the Certificate (TA or EE) that's in the > > Yoav> TLSA record is supposed to be validatable or not. The client > > Yoav> (relying party) may have a policy to ignore records that push > > Yoav> a non-valid certificate, but if you're going to publish a > > Yoav> record with a certificate that you have just issued using > > Yoav> openssl on your laptop and expires in 1975, the TLSA record > > Yoav> had better reflect that this certificate is just a container > > Yoav> for a public key, not something you can chain and validate. > > > > So, you are arguing that the protocol must signal the intent. > > It's not strictly speaking "intent". It's more of an attribute. > Either "this certificate of mine, you can use your regular validation > techniques" or "this certificate of mine, just make sure you get this one." I also think that leaving it up to the client to make assumptions about what type of TLS Server cert validation scheme should be used is likely going to result in a lot of bad decisions among the implementors. If the TLSA record includes the information on the intended validation scheme for this information, then there is going to be more consistency among the implementations. When a particular HTML page renders without apparent problems in one particular web browser, this is no proof that the page is correctly formed and can be expected to render without problems in other browsers as well. -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E43128C16A for ; Thu, 31 Mar 2011 06:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.22 X-Spam-Level: X-Spam-Status: No, score=-10.22 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvPe-9IawU3l for ; Thu, 31 Mar 2011 06:00:38 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id BC5F63A6B12 for ; Thu, 31 Mar 2011 06:00:37 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p2VD2AEO011624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Mar 2011 15:02:15 +0200 (MEST) From: Martin Rex Message-Id: <201103311302.p2VD2AWx020816@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Thu, 31 Mar 2011 15:02:10 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at Mar 31, 11 07:07:33 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 13:00:39 -0000 Eric Rescorla wrote: > > On Thu, Mar 31, 2011 at 2:38 AM, Martin Rex wrote: > > Martin Rex wrote: > >> > >> > > >> > I think this is an important consideration. However a relevant > >> > question for a 2119-level MUST seems to be whether we wish to have > >> > this data rejected if not DNSSEC signed. > >> > What's your view on that? > >> > >> I'm much less worried about false positives resulting in DoS, which > >> can be more easily achieved attacking at the network layer (IP, TCP). > > > > Actually, a DoS based on spoofing an DANE TLSA record with incorrect > > data and a long TTL into a DNS cache might turn out to be devastatingly > > effective when unsiged TLSA records are accepted. > > How is this different from a spoofed A record with a long TTL? In a first round of attack, the attacker inserts a fake unsigned TLSA record (DNS poisoning) that the victim is accessing with TLS frequently and where the DNS admin is not using DNSSEC. After constantly running into validation failures although one is connecting to the correct server and gets presented the correct TLS server cert, either his help desk or the victim will disable DANE or switch to a browser that doesn't have it yet. At that point the victim becomes vulnerable to mis-issued certs even for sites where the DNS admin uses DANE with DNSSEC. -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DB863A6B13 for ; Thu, 31 Mar 2011 05:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.55 X-Spam-Level: X-Spam-Status: No, score=-10.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOtJC8qhhD8Y for ; Thu, 31 Mar 2011 05:59:43 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id F0D1F28C14A for ; Thu, 31 Mar 2011 05:59:42 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p2VD1LGS005926; Thu, 31 Mar 2011 15:01:21 +0200 X-CheckPoint: {4D947A8E-18-1B221DC2-FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 31 Mar 2011 15:01:20 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 31 Mar 2011 15:01:20 +0200 From: Yoav Nir To: Michael Richardson Date: Thu, 31 Mar 2011 15:01:19 +0200 Thread-Topic: [keyassure] Objective: Restrictive versus Supplementary Models Thread-Index: Acvvo7qeNsIwLu4IRxSz9iwEVvanxw== Message-ID: <8FA34510-B4BA-4DD2-B1D3-49D7100D7F62@checkpoint.com> References: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> <7629D2C2-16DC-4ED8-B1AE-14900891448B@checkpoint.com> <14529.1301575096@marajade.sandelman.ca> In-Reply-To: <14529.1301575096@marajade.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 12:59:44 -0000 On Mar 31, 2011, at 2:38 PM, Michael Richardson wrote: >=20 > Yoav> Cert-lock (and CA-lock) are what EKR calls supplementary, > Yoav> while the others are the restrictive. While the sever (and > Yoav> domain owner) can't dictate client policy, they should be able > Yoav> to indicate whether the Certificate (TA or EE) that's in the > Yoav> TLSA record is supposed to be validatable or not. The client > Yoav> (relying party) may have a policy to ignore records that push > Yoav> a non-valid certificate, but if you're going to publish a > Yoav> record with a certificate that you have just issued using > Yoav> openssl on your laptop and expires in 1975, the TLSA record > Yoav> had better reflect that this certificate is just a container > Yoav> for a public key, not something you can chain and validate.=20 >=20 > So, you are arguing that the protocol must signal the intent. It's not strictly speaking "intent". It's more of an attribute. Either "thi= s certificate of mine, you can use your regular validation techniques" or "= this certificate of mine, just make sure you get this one." Yoav Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A359E3A6B13 for ; Thu, 31 Mar 2011 05:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohtRfzAoHApR for ; Thu, 31 Mar 2011 05:35:40 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id B9AA73A6767 for ; Thu, 31 Mar 2011 05:35:40 -0700 (PDT) Received: from marajade.sandelman.ca (dhcp-164d.meeting.ietf.org [130.129.22.77]) by relay.sandelman.ca (Postfix) with ESMTPS id 2D81B98039; Thu, 31 Mar 2011 08:37:20 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 80AD998B17; Thu, 31 Mar 2011 14:38:16 +0200 (CEST) From: Michael Richardson To: "keyassure@ietf.org" In-Reply-To: <7629D2C2-16DC-4ED8-B1AE-14900891448B@checkpoint.com> References: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> <7629D2C2-16DC-4ED8-B1AE-14900891448B@checkpoint.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 22) Date: Thu, 31 Mar 2011 14:38:16 +0200 Message-ID: <14529.1301575096@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 12:35:41 -0000 >>>>> "Yoav" == Yoav Nir writes: Yoav> So it's really down to 4 cases: Yoav> - CA-lock (I only use Verisign) Yoav> - Cert-lock (I only use this cert) Yoav> - This CA (This is the CA cert that issues my certificate, and Yoav> it may not be in your TAS) Yoav> - This Cert (this is the cert I'll be using, and I'm not Yoav> promising that you can validate it) Yoav> While I see some value in cert-lock, I don't see much value in Yoav> CA-lock. It would solve Comodogate if I was a customer of Yoav> another CA, but not if I was a customer of Comodo. Presumably, if you were a customer, they would never issue two certs for the same DN to different customers. Yoav> Cert-lock (and CA-lock) are what EKR calls supplementary, Yoav> while the others are the restrictive. While the sever (and Yoav> domain owner) can't dictate client policy, they should be able Yoav> to indicate whether the Certificate (TA or EE) that's in the Yoav> TLSA record is supposed to be validatable or not. The client Yoav> (relying party) may have a policy to ignore records that push Yoav> a non-valid certificate, but if you're going to publish a Yoav> record with a certificate that you have just issued using Yoav> openssl on your laptop and expires in 1975, the TLSA record Yoav> had better reflect that this certificate is just a container Yoav> for a public key, not something you can chain and validate. So, you are arguing that the protocol must signal the intent. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E93033A6B3C for ; Thu, 31 Mar 2011 04:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7tJws-6+++Y for ; Thu, 31 Mar 2011 04:11:05 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id ADDE13A6B3B for ; Thu, 31 Mar 2011 04:11:04 -0700 (PDT) Received: from [128.89.255.164] (port=49214 helo=[130.129.71.95]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q5Fnv-0005AB-Ih; Thu, 31 Mar 2011 07:12:43 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4F5CBD0D-E9D4-4042-B082-B15D3D509A37@edvina.net> Date: Thu, 31 Mar 2011 13:12:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <57F0D906-4EF8-4628-AAE0-34C661A7184E@bbn.com> References: <4F5CBD0D-E9D4-4042-B082-B15D3D509A37@edvina.net> To: "Olle E. Johansson" X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] The draft and subj alt names X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 11:11:07 -0000 As I've said in other threads, this WG should be silent on requirements = for certificate names, since different applications use TLS certificate = names in different ways. See for example the difference between RFC = 2818 and RFC 6125. The text you reference in the draft is technically = harmless ("must" not "MUST"), but should probably be deleted anyway. --Richard On Mar 31, 2011, at 12:05 PM, Olle E. Johansson wrote: > I have read the draft and reacted to one thing. Sorry if this already = have been discussed on the list. >=20 > The draft -06 says > "The end entity certificate from TLS, regardless of whether it was > matched with a TLSA type 1 certificate or chained to a TLSA type 2 = CA > certificate, must have at least one identifier in the subject or > subjectAltName field of the matched certificates matches the = expected > identifier for the TLS server. " >=20 > The new RFC 6125 tells us that we should: > "Move toward including and checking even more specific > subjectAlternativeName extensions where appropriate for using the > protocol (e.g., uniformResourceIdentifier and the otherName form > SRVName)." >=20 > I feel we need to be more specific in the draft. What type of = subjectAltName should we match with? > dnsName? >=20 > And if we're using SIP, and have URI's in the certificate - should = that be part of this draft > or should we open for protocol-specific specifications for other types = of subject Alt Names? >=20 > /O > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 402453A6A4D for ; Thu, 31 Mar 2011 03:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBhKIzKnXoHA for ; Thu, 31 Mar 2011 03:04:11 -0700 (PDT) Received: from smtp6.webway.se (smtp2.webway.se [87.96.134.128]) by core3.amsl.com (Postfix) with ESMTP id 56C303A6919 for ; Thu, 31 Mar 2011 03:04:10 -0700 (PDT) Received: from [10.1.27.91] (unknown [94.127.50.104]) by smtp6.webway.se (Postfix) with ESMTPA id 951F2552C41; Thu, 31 Mar 2011 10:05:48 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 31 Mar 2011 12:05:48 +0200 To: keyassure@ietf.org Message-Id: <4F5CBD0D-E9D4-4042-B082-B15D3D509A37@edvina.net> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [keyassure] The draft and subj alt names X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 10:04:12 -0000 I have read the draft and reacted to one thing. Sorry if this already = have been discussed on the list. The draft -06 says "The end entity certificate from TLS, regardless of whether it was matched with a TLSA type 1 certificate or chained to a TLSA type 2 CA certificate, must have at least one identifier in the subject or subjectAltName field of the matched certificates matches the expected identifier for the TLS server. " The new RFC 6125 tells us that we should: "Move toward including and checking even more specific subjectAlternativeName extensions where appropriate for using the protocol (e.g., uniformResourceIdentifier and the otherName form SRVName)." I feel we need to be more specific in the draft. What type of = subjectAltName should we match with? dnsName? And if we're using SIP, and have URI's in the certificate - should that = be part of this draft or should we open for protocol-specific specifications for other types = of subject Alt Names? /O= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9261A28C204 for ; Thu, 31 Mar 2011 02:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NAj9iGQUlNu for ; Thu, 31 Mar 2011 02:38:56 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 0CDB828C216 for ; Thu, 31 Mar 2011 02:38:31 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p2V9cPcu014825; Thu, 31 Mar 2011 11:39:57 +0200 X-CheckPoint: {4D944AFF-5-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 31 Mar 2011 11:39:24 +0200 From: Yoav Nir To: "Richard L. Barnes" Date: Thu, 31 Mar 2011 11:39:22 +0200 Thread-Topic: [keyassure] Objective: Restrictive versus Supplementary Models Thread-Index: Acvvh4RvDhWjW2aiR+69y9QbXi8Fxw== Message-ID: <7629D2C2-16DC-4ED8-B1AE-14900891448B@checkpoint.com> References: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 09:38:57 -0000 On Mar 31, 2011, at 11:15 AM, Richard L. Barnes wrote: >>>> If the attacker injects fake dns records pointing to a fake server, th= ey >>>> can include a dane rr. It only makes the attack slightly harder, does= n't it? >>>=20 >>> Yes, but as ekr pointed out, injecting fake DANE RRs can only cause the= connection to fail, it won't result in the client connecting to a bogus se= rver. That's why it's RECOMMENDED instead of REQUIRED. >>=20 >> Not if you are a MITM on the wire as well (more star bucks wifi use case= s) and >> you're directing the user to your own website with a dane rr matching pu= blic key. >=20 > You're confusing the "Cert Lock" and "Install TA" use cases. If all the = server doing is "Cert Lock", then the bogus DANE record will simply cause t= he client to reject the server's cert and the connection to fail. In the "= Install TA" case, DNSSEC would be REQUIRED, for exactly the reason you note= . So it's really down to 4 cases: - CA-lock (I only use Verisign) - Cert-lock (I only use this cert) - This CA (This is the CA cert that issues my certificate, and it may not b= e in your TAS) - This Cert (this is the cert I'll be using, and I'm not promising that you= can validate it) While I see some value in cert-lock, I don't see much value in CA-lock. It = would solve Comodogate if I was a customer of another CA, but not if I was = a customer of Comodo. Cert-lock (and CA-lock) are what EKR calls supplementary, while the others = are the restrictive. While the sever (and domain owner) can't dictate clien= t policy, they should be able to indicate whether the Certificate (TA or EE= ) that's in the TLSA record is supposed to be validatable or not. The clien= t (relying party) may have a policy to ignore records that push a non-valid= certificate, but if you're going to publish a record with a certificate th= at you have just issued using openssl on your laptop and expires in 1975, t= he TLSA record had better reflect that this certificate is just a container= for a public key, not something you can chain and validate. So I think the requirements document should describe EKR's use cases, and r= equire that the TLSA record be able to differentiate between records that a= re appropriate for the two use cases. And yes, a certificate from a known CA can be appropriate for both use case= s, and I expect that at least initially those would be more popular, as the= y work with "legacy" relying parties. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21E7C3A6919 for ; Thu, 31 Mar 2011 02:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9307jSi6KA77 for ; Thu, 31 Mar 2011 02:13:57 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 2F01D28C1A7 for ; Thu, 31 Mar 2011 02:13:57 -0700 (PDT) Received: from [128.89.255.123] (port=65125 helo=[130.129.17.55]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q5DyZ-0000Dg-9y; Thu, 31 Mar 2011 05:15:35 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Thu, 31 Mar 2011 11:15:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> To: Paul Wouters X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 09:13:58 -0000 >>> If the attacker injects fake dns records pointing to a fake server, = they >>> can include a dane rr. It only makes the attack slightly harder, = doesn't it? >>=20 >> Yes, but as ekr pointed out, injecting fake DANE RRs can only cause = the connection to fail, it won't result in the client connecting to a = bogus server. That's why it's RECOMMENDED instead of REQUIRED. >=20 > Not if you are a MITM on the wire as well (more star bucks wifi use = cases) and > you're directing the user to your own website with a dane rr matching = public key. You're confusing the "Cert Lock" and "Install TA" use cases. If all the = server doing is "Cert Lock", then the bogus DANE record will simply = cause the client to reject the server's cert and the connection to fail. = In the "Install TA" case, DNSSEC would be REQUIRED, for exactly the = reason you note. --Richard= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB1773A6B22 for ; Thu, 31 Mar 2011 01:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3jKCDHB3XTA for ; Thu, 31 Mar 2011 01:14:02 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 9316D3A69B7 for ; Thu, 31 Mar 2011 01:14:02 -0700 (PDT) Received: from marajade.sandelman.ca (dhcp-164d.meeting.ietf.org [130.129.22.77]) by relay.sandelman.ca (Postfix) with ESMTPS id 4FB5E98028 for ; Thu, 31 Mar 2011 04:15:40 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 3B11698B17 for ; Thu, 31 Mar 2011 10:16:37 +0200 (CEST) From: Michael Richardson To: keyassure@ietf.org In-Reply-To: <56573629-C534-4EE7-8546-4E97AF4BFDCD@kumari.net> References: <201103302155.p2ULtaUI028846@fs4113.wdf.sap.corp> <56573629-C534-4EE7-8546-4E97AF4BFDCD@kumari.net> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 22) Date: Thu, 31 Mar 2011 10:16:37 +0200 Message-ID: <17554.1301559397@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 08:14:03 -0000 >>>>> "Warren" == Warren Kumari writes: Warren> In Eric's Case / Objective 1 (where DNSSEC might not be Warren> needed): Scenario 1: If I am the operator of example.com and Warren> Mallory manages to trick EzCerts into issuing him a cert for Warren> example.com. Let's say that Mallory is powerful, and can Warren> monkey with DNS traffic for users behind ISP Foo (and only Warren> behind ISP Foo). If we allow TLSA without DNSSEC to say Warren> "Cert X must appear in the path" Malloy can do bad things to Warren> users of ISP Foo (by stripping the record, changing it to Warren> his, etc). BUT all users NOT behind ISP Foo (and all users Warren> of ISP Foo who do DNSSEC validation) will know not to accept Warren> Mallory's cert for example.com. As the operator of Warren> example.com, I am unhappy, but I have at least limited the Warren> scope of the attack.... There is an assumption here that the days of widespread DNS cache poisioning are over. That Mallory essentially can now only do an on-path attack on DNS. I'm not claiming this isn't true, but just stating this assumption. There are still lots of open recursive resolvers. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 299773A6AD5 for ; Thu, 31 Mar 2011 00:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.947 X-Spam-Level: X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjA4oRamvXXN for ; Thu, 31 Mar 2011 00:48:29 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 629E83A6826 for ; Thu, 31 Mar 2011 00:48:29 -0700 (PDT) Received: by iwn39 with SMTP id 39so2421843iwn.31 for ; Thu, 31 Mar 2011 00:50:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.131.7 with SMTP id ho7mr2791037icc.171.1301557808851; Thu, 31 Mar 2011 00:50:08 -0700 (PDT) Received: by 10.42.217.2 with HTTP; Thu, 31 Mar 2011 00:50:08 -0700 (PDT) In-Reply-To: References: <201103301818.p2UIIbcA016146@fs4113.wdf.sap.corp> Date: Thu, 31 Mar 2011 09:50:08 +0200 Message-ID: From: Eric Rescorla To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 07:48:30 -0000 On Thu, Mar 31, 2011 at 9:40 AM, Paul Wouters wrote: > On Wed, 30 Mar 2011, Eric Rescorla wrote: > >> It's obviously better if DANE is DNSSEC secured, but it's not dangerous >> if they aren't signed, since that just brings you back to where you were >> without DANE. > > That assumes DANE is an addition to PKIX. Once you assume it is a > replacement > for PKIX, you can't have DNSSEC being optional. (If you don't agree, let's > have coffee at starbucks and use their wifi :) The context has been lost here, but I was talking about the cert lock application, not the alternate CA application. -Ekr Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05E3428C222 for ; Thu, 31 Mar 2011 00:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAZU-+UDb49s for ; Thu, 31 Mar 2011 00:40:27 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 0CF773A6B16 for ; Thu, 31 Mar 2011 00:40:27 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 2D6DAC5A0; Thu, 31 Mar 2011 03:42:06 -0400 (EDT) Date: Thu, 31 Mar 2011 03:42:05 -0400 (EDT) From: Paul Wouters To: "Richard L. Barnes" In-Reply-To: Message-ID: References: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 07:40:28 -0000 On Wed, 30 Mar 2011, Richard L. Barnes wrote: >> If the attacker injects fake dns records pointing to a fake server, they >> can include a dane rr. It only makes the attack slightly harder, doesn't it? > > Yes, but as ekr pointed out, injecting fake DANE RRs can only cause the connection to fail, it won't result in the client connecting to a bogus server. That's why it's RECOMMENDED instead of REQUIRED. Not if you are a MITM on the wire as well (more star bucks wifi use cases) and you're directing the user to your own website with a dane rr matching public key. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6C6E3A6B0A for ; Thu, 31 Mar 2011 00:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FgVHDgmbQSZ for ; Thu, 31 Mar 2011 00:38:54 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 8B0943A6A8C for ; Thu, 31 Mar 2011 00:38:53 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 2A9EEC5A0; Thu, 31 Mar 2011 03:40:30 -0400 (EDT) Date: Thu, 31 Mar 2011 03:40:29 -0400 (EDT) From: Paul Wouters To: Eric Rescorla In-Reply-To: Message-ID: References: <201103301818.p2UIIbcA016146@fs4113.wdf.sap.corp> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 07:38:55 -0000 On Wed, 30 Mar 2011, Eric Rescorla wrote: > It's obviously better if DANE is DNSSEC secured, but it's not dangerous > if they aren't signed, since that just brings you back to where you were > without DANE. That assumes DANE is an addition to PKIX. Once you assume it is a replacement for PKIX, you can't have DNSSEC being optional. (If you don't agree, let's have coffee at starbucks and use their wifi :) Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9133D3A6C05 for ; Wed, 30 Mar 2011 22:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.947 X-Spam-Level: X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjQwEwUjIrNI for ; Wed, 30 Mar 2011 22:05:54 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4DC483A6BFA for ; Wed, 30 Mar 2011 22:05:54 -0700 (PDT) Received: by iwn39 with SMTP id 39so2278777iwn.31 for ; Wed, 30 Mar 2011 22:07:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.156.131 with SMTP id z3mr2428270icw.305.1301548053623; Wed, 30 Mar 2011 22:07:33 -0700 (PDT) Received: by 10.42.217.2 with HTTP; Wed, 30 Mar 2011 22:07:33 -0700 (PDT) In-Reply-To: <201103310038.p2V0cx49008399@fs4113.wdf.sap.corp> References: <201103310026.p2V0QLQO007637@fs4113.wdf.sap.corp> <201103310038.p2V0cx49008399@fs4113.wdf.sap.corp> Date: Thu, 31 Mar 2011 07:07:33 +0200 Message-ID: From: Eric Rescorla To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 05:05:55 -0000 On Thu, Mar 31, 2011 at 2:38 AM, Martin Rex wrote: > Martin Rex wrote: >> >> > >> > I think this is an important consideration. However a relevant >> > question for a 2119-level MUST seems to be whether we wish to have >> > this data rejected if not DNSSEC signed. >> > What's your view on that? >> >> I'm much less worried about false positives resulting in DoS, which >> can be more easily achieved attacking at the network layer (IP, TCP). > > Actually, a DoS based on spoofing an DANE TLSA record with incorrect > data and a long TTL into a DNS cache might turn out to be devastatingly > effective when unsiged TLSA records are accepted. How is this different from a spoofed A record with a long TTL? -Ekr Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE5083A6AAE for ; Wed, 30 Mar 2011 18:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.22 X-Spam-Level: X-Spam-Status: No, score=-10.22 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-25gi2gUAvn for ; Wed, 30 Mar 2011 18:03:43 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 6E6433A692C for ; Wed, 30 Mar 2011 18:03:43 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p2V15KhN000391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Mar 2011 03:05:21 +0200 (MEST) From: Martin Rex Message-Id: <201103310105.p2V15KtX009924@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Thu, 31 Mar 2011 03:05:20 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at Mar 30, 11 10:20:21 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: peter@palfrader.org, keyassure@ietf.org, paul.hoffman@vpnc.org Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 01:03:45 -0000 Eric Rescorla wrote: > > Jay Daley wrote: > > > > Richard L. Barnes wrote: > > > > > > Nope, it's up to applications.  If you want SN/CAN *not* to be > > > checked for HTTPS, then you need to go revise RFC 2818; for SMTP, > > > RFC 3207; for IMAP/POP3, RFC 2595. > > > > Indeed. > > > > I assumed we were updating RFC 2818. > > In that case, this document will need to be dual last called in the > TLS WG, since 2818 was a TLS product. While it doesn't call itself an update to rfc2818 by its document header, I always assumed it wanted to be this update. http://tools.ietf.org/html/rfc6125 The question is more about "if the creator of the certificate placed attributes in that certificates that are traditionally considered "constraints" or "usage restrictions", should these be still be honoured, even if there is no PKIX cert path validation performed on the certificate. This is why personally, I have a preference to use X.509v1 certs as self-signed TLS server certs -- there are significantly less attributes to get wrong by accident. But the real issue is more about determining intent. Maybe the DANE TLSA record should also carry a hint whether or not the cert attributes (anything besides the public key) should be ignored (= not checked, not seen as usage limitations). There may be clients in the installed base that have certain checks or assumptions about presence of specific attributes in a certificate hardcoded, and the TLS server admin may want to provide the attributes only/specifically for those old clients in the installed base -- not for DANE-aware new clients. -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13F4A3A6BE9 for ; Wed, 30 Mar 2011 17:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.22 X-Spam-Level: X-Spam-Status: No, score=-10.22 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsZmu3LpgCaK for ; Wed, 30 Mar 2011 17:37:23 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 9C7CF3A67D3 for ; Wed, 30 Mar 2011 17:37:22 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p2V0cxSH019228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Mar 2011 02:39:00 +0200 (MEST) From: Martin Rex Message-Id: <201103310038.p2V0cx49008399@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Thu, 31 Mar 2011 02:38:59 +0200 (MEST) In-Reply-To: <201103310026.p2V0QLQO007637@fs4113.wdf.sap.corp> from "Martin Rex" at Mar 31, 11 02:26:21 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 00:37:24 -0000 Martin Rex wrote: > > > > > I think this is an important consideration. However a relevant > > question for a 2119-level MUST seems to be whether we wish to have > > this data rejected if not DNSSEC signed. > > What's your view on that? > > I'm much less worried about false positives resulting in DoS, which > can be more easily achieved attacking at the network layer (IP, TCP). Actually, a DoS based on spoofing an DANE TLSA record with incorrect data and a long TTL into a DNS cache might turn out to be devastatingly effective when unsiged TLSA records are accepted. -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA7063A69AF for ; Wed, 30 Mar 2011 17:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.22 X-Spam-Level: X-Spam-Status: No, score=-10.22 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hNL6dPXmJ87 for ; Wed, 30 Mar 2011 17:24:49 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id D03963A67D3 for ; Wed, 30 Mar 2011 17:24:48 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p2V0QLgp023492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Mar 2011 02:26:26 +0200 (MEST) From: Martin Rex Message-Id: <201103310026.p2V0QLQO007637@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Thu, 31 Mar 2011 02:26:21 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at Mar 30, 11 10:17:47 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 00:24:50 -0000 Eric Rescorla wrote: > > Jay Daley wrote: > > > > Richard L. Barnes wrote: > > > > > > Yes, but as ekr pointed out, injecting fake DANE RRs can only > > > cause the connection to fail, it won't result in the client > > > connecting to a bogus server.   That's why it's RECOMMENDED > > > instead of REQUIRED. > > > > That's still potentially a devastating DOS attack if done well and > > against an important target.  Worthy of a REQUIRED for that alone. > > > > There is also the layer 9 interpretation issue here - if we say that > > DANE in its entirety requires DNSSEC then that message can be shouted > > loud and clear, reinforced and hopefully entrenched.  If we say that > > only some parts need it then people, for entirely fallible reasons, > > get confused, doubt DANE, can use this to attack DANE and so on. > > I think this is an important consideration. However a relevant > question for a 2119-level MUST seems to be whether we wish to have > this data rejected if not DNSSEC signed. > What's your view on that? I'm much less worried about false positives resulting in DoS, which can be more easily achieved attacking at the network layer (IP, TCP). What worries me is the false negatives resulting from a "successful verification" of an unsigned DANE RR. The prerequisite for a "successful DANE validation" is that the DANE TLSA record has been DNSSEC validated. And my concern is that some GUIs might get that wrong unless the spec is crystal clear what constitutes a successful DANE validation (DNSSEC required) and what not. I'm OK with interpreting even an unsigned TLSA validation failure as "something is goofy here, abort the connection", but that causes the DANE validation result to have 3-states "good/not-obviously-bad/bad" rather than a boolean "good/bad", and a 3-state may get mapped incorrectly to binary UI indicators (icon present/absent). -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28FB28C0F1 for ; Wed, 30 Mar 2011 16:12:40 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpZ9kbihcVaw for ; Wed, 30 Mar 2011 16:12:39 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id 5533A3A69AE for ; Wed, 30 Mar 2011 16:12:39 -0700 (PDT) Received: from [10.67.11.182] (dhcp-4798.meeting.ietf.org [130.129.71.152]) by vimes.kumari.net (Postfix) with ESMTPSA id B897E1B4123D; Wed, 30 Mar 2011 19:14:17 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <201103302155.p2ULtaUI028846@fs4113.wdf.sap.corp> Date: Thu, 31 Mar 2011 01:14:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <56573629-C534-4EE7-8546-4E97AF4BFDCD@kumari.net> References: <201103302155.p2ULtaUI028846@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1084) Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 23:12:40 -0000 On Mar 30, 2011, at 11:55 PM, Martin Rex wrote: > Eric Rescorla wrote: >>=20 >> Martin Rex wrote: >>>=20 >>> Maybe I'm dense at the moment, but I don't understand >>> "the DANE data need not be DNSSEC secured". >>>=20 >>> Without DNSSEC, you have a vulnerability, because you can not >>> enforce a CA or EE cert lock. An attacker can DNS-spoof DANE = records >>> for the mis-issued certs of his choice or DNS-spoof the absence >>> of DANE records (and the absence of DANE records will be quite >>> common for more than just a few days). >>=20 >> It's obviously better if DANE is DNSSEC secured, but it's not = dangerous >> if they aren't signed, since that just brings you back to where you = were >> without DANE. However, the DANE records can be set with fairly long >> expiries (like HSTS), thus providing a partial firewall against = comodo-type >> problems. >=20 > I still don't understand. >=20 > As Bruce Schneier says "security must be evaluated not based > on how it works, but on how it fails". >=20 > DANE without DNSSEC is a vulnerability by itself, because it can > be abused by an attacker to make things work that shouldn't work > (the trust rooted to DNS case) and can create a false impression > about security that is not provided (the cert/CA lock case). >=20 > Verification of unsigned DANE TLSA records may cause a warm > fuzzy feeling for some, but does not provide any security > against a determined and powerful attacker. I suspect think that you are talking past each other, so I'm going to = try provide scenarios (and also make sure I understand): In Eric's Case / Objective 1 (where DNSSEC might not be needed): Scenario 1: If I am the operator of example.com and Mallory manages to = trick EzCerts into issuing him a cert for example.com. Let's say that Mallory is powerful, and can monkey with DNS traffic for = users behind ISP Foo (and only behind ISP Foo). If we allow TLSA = without DNSSEC to say "Cert X must appear in the path" Malloy can do bad = things to users of ISP Foo (by stripping the record, changing it to his, = etc). BUT all users NOT behind ISP Foo (and all users of ISP Foo who do = DNSSEC validation) will know not to accept Mallory's cert for = example.com. As the operator of example.com, I am unhappy, but I have = at least limited the scope of the attack.... Scenario 2: I am the operator of example.com and Eve is has the ability = to spoof DNS. She wants to cause a DoS against example.com, so she = inserts a "false" TLSA record -- she does this so that users connecting = though that path will fail the DANE check and be unable to connect.... = This *is* a new DoS vulnerability, but if Eve is in a position to monkey = with the DNS / inject DNS she *already* has the ability to cause a DoS = by simply changing A / AAAA records, etc. In both of these (and all the scenarios I can come up with), TLSA = without DNSSEC validation doesn't make problems worse, but sometimes = makes things better... I think that Martin's concerns are all in Eric's Case / Objective 2, = where DNSSEC *is* required... >=20 > Commodogate may have been a government-backed hack. The may be > more such about which we don't know yet. They could prevent = OCSP-checks > by making the relevant requests fail at the network layer. > Similarly, they could prevent browser updates (with blacklists of > the mis-issued certs) at the network level. And they could spoof > DNS replies as well. Yes, but if we allow TLSA without DNSSEC *only for objective / case 1*, = "they" can still attack victims for whom they can spoof DNS replies, but = at least everyone else if better protected. Obviously TLSA with DNSSEC = is far better, but allowing it without does have some benefits (and can = be deployed much faster). W >=20 >=20 > -Martin > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure >=20 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBF963A67EE for ; Wed, 30 Mar 2011 15:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.946 X-Spam-Level: X-Spam-Status: No, score=-102.946 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4Agm+OsYTFQ for ; Wed, 30 Mar 2011 15:13:00 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id C836D3A6BDF for ; Wed, 30 Mar 2011 15:12:59 -0700 (PDT) Received: by iye19 with SMTP id 19so1962050iye.31 for ; Wed, 30 Mar 2011 15:14:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.131.7 with SMTP id ho7mr1961833icc.171.1301523278789; Wed, 30 Mar 2011 15:14:38 -0700 (PDT) Received: by 10.42.217.2 with HTTP; Wed, 30 Mar 2011 15:14:38 -0700 (PDT) In-Reply-To: <201103302155.p2ULtaUI028846@fs4113.wdf.sap.corp> References: <201103302155.p2ULtaUI028846@fs4113.wdf.sap.corp> Date: Thu, 31 Mar 2011 00:14:38 +0200 Message-ID: From: Eric Rescorla To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 22:13:01 -0000 On Wed, Mar 30, 2011 at 11:55 PM, Martin Rex wrote: > Eric Rescorla wrote: >> >> Martin Rex wrote: >> > >> > Maybe I'm dense at the moment, but I don't understand >> > "the DANE data need not be DNSSEC secured". >> > >> > Without DNSSEC, you have a vulnerability, because you can not >> > enforce a CA or EE cert lock. =A0An attacker can DNS-spoof DANE record= s >> > for the mis-issued certs of his choice or DNS-spoof the absence >> > of DANE records (and the absence of DANE records will be quite >> > common for more than just a few days). >> >> It's obviously better if DANE is DNSSEC secured, but it's not dangerous >> if they aren't signed, since that just brings you back to where you were >> without DANE. However, the DANE records can be set with fairly long >> expiries (like HSTS), thus providing a partial firewall against comodo-t= ype >> problems. > > I still don't understand. I don't disagree with you about the facts of the situation, merely about ho= w they should be interpreted.. Best -Ekr > As Bruce Schneier says "security must be evaluated not based > on how it works, but on how it fails". > > DANE without DNSSEC is a vulnerability by itself, because it can > be abused by an attacker to make things work that shouldn't work > (the trust rooted to DNS case) and can create a false impression > about security that is not provided (the cert/CA lock case). > > Verification of unsigned DANE TLSA records may cause a warm > fuzzy feeling for some, but does not provide any security > against a determined and powerful attacker. > > Commodogate may have been a government-backed hack. =A0The may be > more such about which we don't know yet. =A0They could prevent OCSP-check= s > by making the relevant requests fail at the network layer. > Similarly, they could prevent browser updates (with blacklists of > the mis-issued certs) at the network level. =A0And they could spoof > DNS replies as well. > > > -Martin > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB8673A6AC7 for ; Wed, 30 Mar 2011 15:01:57 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8WTs0Vjbxup for ; Wed, 30 Mar 2011 15:01:57 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id 0FDD73A6ACA for ; Wed, 30 Mar 2011 15:01:56 -0700 (PDT) Received: from [10.67.11.182] (dhcp-4798.meeting.ietf.org [130.129.71.152]) by vimes.kumari.net (Postfix) with ESMTPSA id BABB11B41028 for ; Wed, 30 Mar 2011 18:03:35 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 31 Mar 2011 00:03:33 +0200 Message-Id: <52E7B80E-D656-47A5-9581-37F64E8DCAC9@kumari.net> To: keyassure@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [keyassure] Use cases document. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 22:01:57 -0000 Hi there all, So it became (blindingly) clear during the meeting today that we need a = use-cases type document to clearly explain what we believe the actual = use cases are, what we think we can do, etc. This discussion has already progressed nicely on-list ("Objective: = Restrictive versus Supplementary Models"), but we would like to keep the = momentum going, strike while the iron is hot and various similar idioms, = so: 1: We are asking folk to please send any additional use cases to the = list by Thursday April 7th. 2: We are starting a consensus call to add a milestone for the use-case = document. =46rom the meeting it seems that there is likely to be strong consensus = for creating this, but please provide input on list.... I would like to apologize for not realizing earlier that the group = wanted this document -- it is very easy to get swept up in the "Let's = fix this thing" and assuming that everyone has the same idea of what the = "thing" actually is.... I thought that we had figured this out on-list = right back at the beginning of time, but a: not as clearly as I thought = and b: we didn't clearly capture this.... W= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E07A3A6AC8 for ; Wed, 30 Mar 2011 14:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.219 X-Spam-Level: X-Spam-Status: No, score=-10.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAi1ZQXtKaz3 for ; Wed, 30 Mar 2011 14:53:59 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 498D83A6ABD for ; Wed, 30 Mar 2011 14:53:59 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p2ULtbpb010065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Mar 2011 23:55:37 +0200 (MEST) From: Martin Rex Message-Id: <201103302155.p2ULtaUI028846@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Wed, 30 Mar 2011 23:55:36 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at Mar 30, 11 09:27:31 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 21:54:00 -0000 Eric Rescorla wrote: > > Martin Rex wrote: > > > > Maybe I'm dense at the moment, but I don't understand > > "the DANE data need not be DNSSEC secured". > > > > Without DNSSEC, you have a vulnerability, because you can not > > enforce a CA or EE cert lock.  An attacker can DNS-spoof DANE records > > for the mis-issued certs of his choice or DNS-spoof the absence > > of DANE records (and the absence of DANE records will be quite > > common for more than just a few days). > > It's obviously better if DANE is DNSSEC secured, but it's not dangerous > if they aren't signed, since that just brings you back to where you were > without DANE. However, the DANE records can be set with fairly long > expiries (like HSTS), thus providing a partial firewall against comodo-type > problems. I still don't understand. As Bruce Schneier says "security must be evaluated not based on how it works, but on how it fails". DANE without DNSSEC is a vulnerability by itself, because it can be abused by an attacker to make things work that shouldn't work (the trust rooted to DNS case) and can create a false impression about security that is not provided (the cert/CA lock case). Verification of unsigned DANE TLSA records may cause a warm fuzzy feeling for some, but does not provide any security against a determined and powerful attacker. Commodogate may have been a government-backed hack. The may be more such about which we don't know yet. They could prevent OCSP-checks by making the relevant requests fail at the network layer. Similarly, they could prevent browser updates (with blacklists of the mis-issued certs) at the network level. And they could spoof DNS replies as well. -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59C423A6BC7 for ; Wed, 30 Mar 2011 13:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQ+ocSVCLkUQ for ; Wed, 30 Mar 2011 13:38:29 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 83B523A6BC5 for ; Wed, 30 Mar 2011 13:38:29 -0700 (PDT) Received: from [128.89.255.154] (port=60612 helo=dhcp-436b.meeting.ietf.org) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q52BN-000JjQ-NT; Wed, 30 Mar 2011 16:40:02 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <04AAADD9-69E1-43E5-8957-E951C69B332B@nzrs.net.nz> Date: Wed, 30 Mar 2011 22:39:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1996B7AF-9711-48FD-92E1-BE8FC653E5BE@bbn.com> References: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> <04AAADD9-69E1-43E5-8957-E951C69B332B@nzrs.net.nz> To: Jay Daley X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 20:38:30 -0000 To re-focus this discussion, I would just like to point out that whether = DNSSEC is REQUIRED or RECOMMENDED is not material to the structure of = the use case. We can have that debate when it comes time to decide on = mechanism. --Richard On Mar 30, 2011, at 10:27 PM, Jay Daley wrote: >=20 > On 31/03/2011, at 9:17 AM, Eric Rescorla wrote: >=20 >>>>> RLB> 1. Cert-lock / CA-lock >>>>> RLB> 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only = cause connection failure >>>>>=20 >>>>> If the attacker injects fake dns records pointing to a fake = server, they >>>>> can include a dane rr. It only makes the attack slightly harder, = doesn't it? >>>>=20 >>>> Yes, but as ekr pointed out, injecting fake DANE RRs can only cause = the connection to fail, it won't result in the client connecting to a = bogus server. That's why it's RECOMMENDED instead of REQUIRED. >>>=20 >>> That's still potentially a devastating DOS attack if done well and = against an important target. Worthy of a REQUIRED for that alone. >>>=20 >>> There is also the layer 9 interpretation issue here - if we say that = DANE in its entirety requires DNSSEC then that message can be shouted = loud and clear, reinforced and hopefully entrenched. If we say that = only some parts need it then people, for entirely fallible reasons, get = confused, doubt DANE, can use this to attack DANE and so on. >>=20 >> I think this is an important consideration. However a relevant >> question for a 2119-level MUST seems >> to be whether we wish to have this data rejected if not DNSSEC = signed. >> What's your view on that? >=20 > If unsigned then the data should be ignored. That exactly maps to the = current situation, which gives a clean split between that or using DANE = as an all-or-nothing improvement on top of that. =20 >=20 > Jay=20 >=20 >>=20 >> -Ekr >=20 >=20 > --=20 > Jay Daley > Chief Executive > .nz Registry Services (New Zealand Domain Name Registry Limited) > desk: +64 4 931 6977 > mobile: +64 21 678840 >=20 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052A83A6BC5 for ; Wed, 30 Mar 2011 13:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vk95CRq9lwkP for ; Wed, 30 Mar 2011 13:35:19 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id AB9D63A6A64 for ; Wed, 30 Mar 2011 13:35:19 -0700 (PDT) Received: from [128.89.255.154] (port=60607 helo=dhcp-436b.meeting.ietf.org) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q528L-000Jgm-VE; Wed, 30 Mar 2011 16:36:54 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <72CD6385-5FBF-41FF-90D5-71B7A2A87BE1@nzrs.net.nz> Date: Wed, 30 Mar 2011 22:36:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D7BFB41.4000403@vpnc.org> <20110321092514.GE9247@anguilla.noreply.org> <20110321130430.GG9247@anguilla.noreply.org> <4BC9E139-CBC5-46EE-A18F-E8F16AE108D6@vpnc.org> <20110330091416.GI681@anguilla.noreply.org> <20EEA73E-9E5E-4D8F-B70C-BD6DF37F60E6@nzrs.net.nz> <0D12CEFF-68F5-49C1-B4A9-6A0572936B3C@bbn.com> <72CD6385-5FBF-41FF-90D5-71B7A2A87BE1@nzrs.net.nz> To: Jay Daley X-Mailer: Apple Mail (2.1082) Cc: Peter Palfrader , keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 20:35:21 -0000 The milestone reads: " April 2011 - First WG draft of standards-track protocol for using DNS to = associate hosts with keys for TLS and DTLS " So no, not updating 2818, 3207, etc. The upshot of this naming discussion is that nothing that touches names = is going to be general to TLS and DTLS. So if you want to update 2818 = to use DANE for name matching, you'll have to do it in a separate = document, either as a new DANE milestone or (more likely) in TLS. =20 --Richard On Mar 30, 2011, at 10:14 PM, Jay Daley wrote: >=20 > On 31/03/2011, at 9:03 AM, Richard L. Barnes wrote: >=20 >> Nope, it's up to applications. If you want SN/CAN *not* to be = checked for HTTPS, then you need to go revise RFC 2818; for SMTP, RFC = 3207; for IMAP/POP3, RFC 2595. >=20 > Indeed. >=20 > I assumed we were updating RFC 2818. >=20 > As for RFC 3207 that says this gem, which is as much use as a = chocolate teapot and so will need updating: >=20 > - A SMTP client would probably only want to authenticate an SMTP > server whose server certificate has a domain name that is the > domain name that the client thought it was connecting to." >=20 > And RFC 2595 is going to need updating because the name check is = specific: >=20 > - The client MUST use the server hostname it used to open the > connection as the value to compare against the server name as > expressed in the server certificate. The client MUST NOT use any > form of the server hostname derived from an insecure remote source > (e.g., insecure DNS lookup). CNAME canonicalization is not done. >=20 > Jay >=20 >>=20 >> --Richard >>=20 >>=20 >>=20 >> On Mar 30, 2011, at 9:45 PM, Jay Daley wrote: >>=20 >>> I would argue the complete opposite - that it is in scope for DANE = to state that names in certificates should not be checked because the = trust chain has been provided by DNSSEC. Doing that allows individuals = and organisations to reuse certificates as they need to for operational = reasons and not as dictated to by suppliers or paranoid protocol = developers. >>>=20 >>> Jay >>>=20 >>> On 31/03/2011, at 12:55 AM, Richard L. Barnes wrote: >>>=20 >>>> This is outside of DANE's scope. Checking of names in certificates = is up to the application that uses TLS. >>>> --Richard >>>>=20 >>>>=20 >>>> On Mar 30, 2011, at 1:19 PM, Stephen Kent wrote: >>>>=20 >>>>> At 11:14 AM +0200 3/30/11, Peter Palfrader wrote: >>>>>> On Mon, 21 Mar 2011, Paul Hoffman wrote: >>>>>>=20 >>>>>>> On Mar 21, 2011, at 6:04 AM, Peter Palfrader wrote: >>>>>>>> Why is it needed in the first place? >>>>>>>=20 >>>>>>> That's a very good question. I don't feel that it is a "need", = but it >>>>>>> "makes some sense". That is, if I want to go to www.example.com, = and I >>>>>>> get an A record for www.example.com, and I get a TLSA record for >>>>>>> _http._tcp.www.example.com, and I get a certificate that says = "this >>>>>>> key is associated with www.somethingelse.com", what does it = mean? >>>>>>>=20 >>>>>>> I can see both ways: "it doesn't matter what the cert says, we = are >>>>>>> trusting the binding from the DNS" vs. "the cert needs to mean >>>>>>> something"? Jakob and I have that text in because a number of = people >>>>>>> on the list were in the latter category, but it seems like a >>>>>>> reasonable question to ask separately. >>>>>>=20 >>>>>> I wonder if one approach here would be to require a match if, and = only >>>>>> if, any naming attributes (CN, SubjectAltName) are in the = certificate. >>>>>>=20 >>>>>> If there are no CN and no SAN attributes in the certificate then = that >>>>>> would be acceptable too. >>>>>>=20 >>>>>> Cheers, >>>>>> Peter >>>>>=20 >>>>> A CN is a type of attribute in the Subject DN. A SAN admits a = variety of name types, some of which can have attributes. Do you mean to = focus on DNS names as SANs or did you have a broader range of SANs in = mind? >>>>>=20 >>>>> Steve >>>>> _______________________________________________ >>>>> keyassure mailing list >>>>> keyassure@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/keyassure >>>>=20 >>>> _______________________________________________ >>>> keyassure mailing list >>>> keyassure@ietf.org >>>> https://www.ietf.org/mailman/listinfo/keyassure >>>=20 >>>=20 >>> --=20 >>> Jay Daley >>> Chief Executive >>> .nz Registry Services (New Zealand Domain Name Registry Limited) >>> desk: +64 4 931 6977 >>> mobile: +64 21 678840 >>>=20 >>=20 >=20 >=20 > --=20 > Jay Daley > Chief Executive > .nz Registry Services (New Zealand Domain Name Registry Limited) > desk: +64 4 931 6977 > mobile: +64 21 678840 >=20 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2425C3A69AB for ; Wed, 30 Mar 2011 13:25:59 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwYM+1L61C18 for ; Wed, 30 Mar 2011 13:25:58 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 3C4BC3A68F4 for ; Wed, 30 Mar 2011 13:25:58 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 107C32CE004; Thu, 31 Mar 2011 09:27:41 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ob4yOy5pMUg; Thu, 31 Mar 2011 09:27:41 +1300 (NZDT) Received: from [192.168.22.200] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id C42422DB35F; Thu, 31 Mar 2011 09:27:40 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: Date: Thu, 31 Mar 2011 09:27:36 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <04AAADD9-69E1-43E5-8957-E951C69B332B@nzrs.net.nz> References: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> To: Eric Rescorla X-Mailer: Apple Mail (2.1084) Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 20:25:59 -0000 On 31/03/2011, at 9:17 AM, Eric Rescorla wrote: >>>> RLB> 1. Cert-lock / CA-lock >>>> RLB> 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause = connection failure >>>>=20 >>>> If the attacker injects fake dns records pointing to a fake server, = they >>>> can include a dane rr. It only makes the attack slightly harder, = doesn't it? >>>=20 >>> Yes, but as ekr pointed out, injecting fake DANE RRs can only cause = the connection to fail, it won't result in the client connecting to a = bogus server. That's why it's RECOMMENDED instead of REQUIRED. >>=20 >> That's still potentially a devastating DOS attack if done well and = against an important target. Worthy of a REQUIRED for that alone. >>=20 >> There is also the layer 9 interpretation issue here - if we say that = DANE in its entirety requires DNSSEC then that message can be shouted = loud and clear, reinforced and hopefully entrenched. If we say that = only some parts need it then people, for entirely fallible reasons, get = confused, doubt DANE, can use this to attack DANE and so on. >=20 > I think this is an important consideration. However a relevant > question for a 2119-level MUST seems > to be whether we wish to have this data rejected if not DNSSEC signed. > What's your view on that? If unsigned then the data should be ignored. That exactly maps to the = current situation, which gives a clean split between that or using DANE = as an all-or-nothing improvement on top of that. =20 Jay=20 >=20 > -Ekr --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4B113A6A2A for ; Wed, 30 Mar 2011 13:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.589, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CA7kuwF9ft1g for ; Wed, 30 Mar 2011 13:19:27 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id 3D3EB3A69AB for ; Wed, 30 Mar 2011 13:19:27 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 279B14067D; Wed, 30 Mar 2011 20:20:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1301516460; bh=B+6WySojQpuQvWDg5VVW5Jge7+JngaTV20B8GJDiVMM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=NbL72cIMcVkHp99yy8wX20InK45cIjDzVPPEJp/AGHUbhxUPizPut2K2xFb8/Rapc HEBuFN726U6yL3kHOftkNnN5gOGPka2qmkfxlnMGfcCywGvb9Cb4xbCREYZG80zz0T 2oNfij9pm4CjCUmS9j/QpuGXNGtePtCz6f5cvwik= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 879D126004B; Wed, 30 Mar 2011 20:13:14 +0000 (UTC) From: James Cloos To: "Richard L. Barnes" In-Reply-To: (Richard L. Barnes's message of "Wed, 30 Mar 2011 21:32:40 +0200") References: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> User-Agent: Gnus/5.110014 (No Gnus v0.14) Emacs/24.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2011 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 30 Mar 2011 16:13:14 -0400 Message-ID: Lines: 20 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:110330:rbarnes@bbn.com::NZNb1tK+U2nFVX/p:0DK+Fq X-Hashcash: 1:30:110330:ekr@rtfm.com::IQeQusEZxTGHxslt:0000PM27E X-Hashcash: 1:30:110330:keyassure@ietf.org::j4qF6r3/jPOYlzby:0000000000000000000000000000000000000000004kdr2 Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 20:19:28 -0000 >>>>> "RLB" == Richard L Barnes writes: JC> If the attacker injects fake dns records pointing to a fake server, they JC> can include a dane rr. It only makes the attack slightly harder, doesn't it? RLB> Yes, but as ekr pointed out, injecting fake DANE RRs can only cause RLB> the connection to fail, it won't result in the client connecting to a RLB> bogus server. That's why it's RECOMMENDED instead of REQUIRED. If an attacker is going to inject fake RRs, they will inject fake A and/or AAAA RRs too, not only fake dane RRs. So the attacker will direct the victem to its fake site with its fake cert tree which matches the fake dane rr. I don't see how that is any different than the (non-dnssec) status quo. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBB333A6A2A for ; Wed, 30 Mar 2011 13:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.945 X-Spam-Level: X-Spam-Status: No, score=-102.945 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXl87G1UFPlf for ; Wed, 30 Mar 2011 13:18:43 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4F1303A69AB for ; Wed, 30 Mar 2011 13:18:42 -0700 (PDT) Received: by iwn39 with SMTP id 39so1858612iwn.31 for ; Wed, 30 Mar 2011 13:20:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.62.10 with SMTP id wy10mr1675769icb.37.1301516421416; Wed, 30 Mar 2011 13:20:21 -0700 (PDT) Received: by 10.42.217.2 with HTTP; Wed, 30 Mar 2011 13:20:21 -0700 (PDT) In-Reply-To: <72CD6385-5FBF-41FF-90D5-71B7A2A87BE1@nzrs.net.nz> References: <4D7BFB41.4000403@vpnc.org> <20110321092514.GE9247@anguilla.noreply.org> <20110321130430.GG9247@anguilla.noreply.org> <4BC9E139-CBC5-46EE-A18F-E8F16AE108D6@vpnc.org> <20110330091416.GI681@anguilla.noreply.org> <20EEA73E-9E5E-4D8F-B70C-BD6DF37F60E6@nzrs.net.nz> <0D12CEFF-68F5-49C1-B4A9-6A0572936B3C@bbn.com> <72CD6385-5FBF-41FF-90D5-71B7A2A87BE1@nzrs.net.nz> Date: Wed, 30 Mar 2011 22:20:21 +0200 Message-ID: From: Eric Rescorla To: Jay Daley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Peter Palfrader , keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 20:18:43 -0000 On Wed, Mar 30, 2011 at 10:14 PM, Jay Daley wrote: > > On 31/03/2011, at 9:03 AM, Richard L. Barnes wrote: > >> Nope, it's up to applications. =A0If you want SN/CAN *not* to be checked= for HTTPS, then you need to go revise RFC 2818; for SMTP, RFC 3207; for IM= AP/POP3, RFC 2595. > > Indeed. > > I assumed we were updating RFC 2818. In that case, this document will need to be dual last called in the TLS WG, since 2818 was a TLS product. -Ekr Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D44C33A6A2A for ; Wed, 30 Mar 2011 13:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.945 X-Spam-Level: X-Spam-Status: No, score=-102.945 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IylpXaWbpgU3 for ; Wed, 30 Mar 2011 13:16:08 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 0B8553A69AB for ; Wed, 30 Mar 2011 13:16:07 -0700 (PDT) Received: by iye19 with SMTP id 19so1854604iye.31 for ; Wed, 30 Mar 2011 13:17:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.62.10 with SMTP id wy10mr1671207icb.37.1301516267070; Wed, 30 Mar 2011 13:17:47 -0700 (PDT) Received: by 10.42.217.2 with HTTP; Wed, 30 Mar 2011 13:17:47 -0700 (PDT) In-Reply-To: References: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> Date: Wed, 30 Mar 2011 22:17:47 +0200 Message-ID: From: Eric Rescorla To: Jay Daley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 20:16:08 -0000 On Wed, Mar 30, 2011 at 10:06 PM, Jay Daley wrote: > > On 31/03/2011, at 8:32 AM, Richard L. Barnes wrote: > >>>>>>>> "RLB" =3D=3D Richard L Barnes writes: >>> >>> RLB> 1. Cert-lock / CA-lock >>> RLB> 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause con= nection failure >>> >>> If the attacker injects fake dns records pointing to a fake server, the= y >>> can include a dane rr. =A0It only makes the attack slightly harder, doe= sn't it? >> >> Yes, but as ekr pointed out, injecting fake DANE RRs can only cause the = connection to fail, it won't result in the client connecting to a bogus ser= ver. =A0 That's why it's RECOMMENDED instead of REQUIRED. > > That's still potentially a devastating DOS attack if done well and agains= t an important target. =A0Worthy of a REQUIRED for that alone. > > There is also the layer 9 interpretation issue here - if we say that DANE= in its entirety requires DNSSEC then that message can be shouted loud and = clear, reinforced and hopefully entrenched. =A0If we say that only some par= ts need it then people, for entirely fallible reasons, get confused, doubt = DANE, can use this to attack DANE and so on. I think this is an important consideration. However a relevant question for a 2119-level MUST seems to be whether we wish to have this data rejected if not DNSSEC signed. What's your view on that? -Ekr Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60CD728C1AA for ; Wed, 30 Mar 2011 13:12:48 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HwVw03VitNg for ; Wed, 30 Mar 2011 13:12:47 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id E907F28C0DE for ; Wed, 30 Mar 2011 13:12:46 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 495122CE004; Thu, 31 Mar 2011 09:14:29 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjNXX9k5ZSnd; Thu, 31 Mar 2011 09:14:29 +1300 (NZDT) Received: from [192.168.22.200] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id DFAAD2DB66F; Thu, 31 Mar 2011 09:14:28 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <0D12CEFF-68F5-49C1-B4A9-6A0572936B3C@bbn.com> Date: Thu, 31 Mar 2011 09:14:24 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <72CD6385-5FBF-41FF-90D5-71B7A2A87BE1@nzrs.net.nz> References: <4D7BFB41.4000403@vpnc.org> <20110321092514.GE9247@anguilla.noreply.org> <20110321130430.GG9247@anguilla.noreply.org> <4BC9E139-CBC5-46EE-A18F-E8F16AE108D6@vpnc.org> <20110330091416.GI681@anguilla.noreply.org> <20EEA73E-9E5E-4D8F-B70C-BD6DF37F60E6@nzrs.net.nz> <0D12CEFF-68F5-49C1-B4A9-6A0572936B3C@bbn.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1084) Cc: Peter Palfrader , keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 20:12:48 -0000 On 31/03/2011, at 9:03 AM, Richard L. Barnes wrote: > Nope, it's up to applications. If you want SN/CAN *not* to be checked = for HTTPS, then you need to go revise RFC 2818; for SMTP, RFC 3207; for = IMAP/POP3, RFC 2595. Indeed. I assumed we were updating RFC 2818. As for RFC 3207 that says this gem, which is as much use as a chocolate = teapot and so will need updating: - A SMTP client would probably only want to authenticate an SMTP server whose server certificate has a domain name that is the domain name that the client thought it was connecting to." And RFC 2595 is going to need updating because the name check is = specific: - The client MUST use the server hostname it used to open the connection as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done. Jay >=20 > --Richard >=20 >=20 >=20 > On Mar 30, 2011, at 9:45 PM, Jay Daley wrote: >=20 >> I would argue the complete opposite - that it is in scope for DANE to = state that names in certificates should not be checked because the trust = chain has been provided by DNSSEC. Doing that allows individuals and = organisations to reuse certificates as they need to for operational = reasons and not as dictated to by suppliers or paranoid protocol = developers. >>=20 >> Jay >>=20 >> On 31/03/2011, at 12:55 AM, Richard L. Barnes wrote: >>=20 >>> This is outside of DANE's scope. Checking of names in certificates = is up to the application that uses TLS. >>> --Richard >>>=20 >>>=20 >>> On Mar 30, 2011, at 1:19 PM, Stephen Kent wrote: >>>=20 >>>> At 11:14 AM +0200 3/30/11, Peter Palfrader wrote: >>>>> On Mon, 21 Mar 2011, Paul Hoffman wrote: >>>>>=20 >>>>>> On Mar 21, 2011, at 6:04 AM, Peter Palfrader wrote: >>>>>>> Why is it needed in the first place? >>>>>>=20 >>>>>> That's a very good question. I don't feel that it is a "need", = but it >>>>>> "makes some sense". That is, if I want to go to www.example.com, = and I >>>>>> get an A record for www.example.com, and I get a TLSA record for >>>>>> _http._tcp.www.example.com, and I get a certificate that says = "this >>>>>> key is associated with www.somethingelse.com", what does it mean? >>>>>>=20 >>>>>> I can see both ways: "it doesn't matter what the cert says, we = are >>>>>> trusting the binding from the DNS" vs. "the cert needs to mean >>>>>> something"? Jakob and I have that text in because a number of = people >>>>>> on the list were in the latter category, but it seems like a >>>>>> reasonable question to ask separately. >>>>>=20 >>>>> I wonder if one approach here would be to require a match if, and = only >>>>> if, any naming attributes (CN, SubjectAltName) are in the = certificate. >>>>>=20 >>>>> If there are no CN and no SAN attributes in the certificate then = that >>>>> would be acceptable too. >>>>>=20 >>>>> Cheers, >>>>> Peter >>>>=20 >>>> A CN is a type of attribute in the Subject DN. A SAN admits a = variety of name types, some of which can have attributes. Do you mean to = focus on DNS names as SANs or did you have a broader range of SANs in = mind? >>>>=20 >>>> Steve >>>> _______________________________________________ >>>> keyassure mailing list >>>> keyassure@ietf.org >>>> https://www.ietf.org/mailman/listinfo/keyassure >>>=20 >>> _______________________________________________ >>> keyassure mailing list >>> keyassure@ietf.org >>> https://www.ietf.org/mailman/listinfo/keyassure >>=20 >>=20 >> --=20 >> Jay Daley >> Chief Executive >> .nz Registry Services (New Zealand Domain Name Registry Limited) >> desk: +64 4 931 6977 >> mobile: +64 21 678840 >>=20 >=20 --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9879C28C0DE for ; Wed, 30 Mar 2011 13:05:10 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxRRX4pC51dj for ; Wed, 30 Mar 2011 13:05:09 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 9A96328C18B for ; Wed, 30 Mar 2011 13:05:09 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 930C42CE008; Thu, 31 Mar 2011 09:06:51 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37HeI7V8lf2d; Thu, 31 Mar 2011 09:06:51 +1300 (NZDT) Received: from [192.168.22.200] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 40F382DA3F3; Thu, 31 Mar 2011 09:06:51 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: Date: Thu, 31 Mar 2011 09:06:46 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1084) Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 20:05:10 -0000 On 31/03/2011, at 8:32 AM, Richard L. Barnes wrote: >>>>>>> "RLB" =3D=3D Richard L Barnes writes: >>=20 >> RLB> 1. Cert-lock / CA-lock >> RLB> 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause = connection failure >>=20 >> If the attacker injects fake dns records pointing to a fake server, = they >> can include a dane rr. It only makes the attack slightly harder, = doesn't it? >=20 > Yes, but as ekr pointed out, injecting fake DANE RRs can only cause = the connection to fail, it won't result in the client connecting to a = bogus server. That's why it's RECOMMENDED instead of REQUIRED. That's still potentially a devastating DOS attack if done well and = against an important target. Worthy of a REQUIRED for that alone. There is also the layer 9 interpretation issue here - if we say that = DANE in its entirety requires DNSSEC then that message can be shouted = loud and clear, reinforced and hopefully entrenched. If we say that = only some parts need it then people, for entirely fallible reasons, get = confused, doubt DANE, can use this to attack DANE and so on. Jay > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6296428C18B for ; Wed, 30 Mar 2011 13:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usMCjJD-7T9J for ; Wed, 30 Mar 2011 13:02:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 35BAB3A6BC1 for ; Wed, 30 Mar 2011 13:02:00 -0700 (PDT) Received: from [128.89.255.132] (port=60049 helo=[130.129.71.95]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q51c5-000JC3-Uh; Wed, 30 Mar 2011 16:03:34 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <20EEA73E-9E5E-4D8F-B70C-BD6DF37F60E6@nzrs.net.nz> Date: Wed, 30 Mar 2011 22:03:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0D12CEFF-68F5-49C1-B4A9-6A0572936B3C@bbn.com> References: <4D7BFB41.4000403@vpnc.org> <20110321092514.GE9247@anguilla.noreply.org> <20110321130430.GG9247@anguilla.noreply.org> <4BC9E139-CBC5-46EE-A18F-E8F16AE108D6@vpnc.org> <20110330091416.GI681@anguilla.noreply.org> <20EEA73E-9E5E-4D8F-B70C-BD6DF37F60E6@nzrs.net.nz> To: Jay Daley X-Mailer: Apple Mail (2.1082) Cc: Peter Palfrader , keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 20:02:01 -0000 Nope, it's up to applications. If you want SN/CAN *not* to be checked = for HTTPS, then you need to go revise RFC 2818; for SMTP, RFC 3207; for = IMAP/POP3, RFC 2595. --Richard On Mar 30, 2011, at 9:45 PM, Jay Daley wrote: > I would argue the complete opposite - that it is in scope for DANE to = state that names in certificates should not be checked because the trust = chain has been provided by DNSSEC. Doing that allows individuals and = organisations to reuse certificates as they need to for operational = reasons and not as dictated to by suppliers or paranoid protocol = developers. >=20 > Jay >=20 > On 31/03/2011, at 12:55 AM, Richard L. Barnes wrote: >=20 >> This is outside of DANE's scope. Checking of names in certificates = is up to the application that uses TLS. >> --Richard >>=20 >>=20 >> On Mar 30, 2011, at 1:19 PM, Stephen Kent wrote: >>=20 >>> At 11:14 AM +0200 3/30/11, Peter Palfrader wrote: >>>> On Mon, 21 Mar 2011, Paul Hoffman wrote: >>>>=20 >>>>> On Mar 21, 2011, at 6:04 AM, Peter Palfrader wrote: >>>>>> Why is it needed in the first place? >>>>>=20 >>>>> That's a very good question. I don't feel that it is a "need", but = it >>>>> "makes some sense". That is, if I want to go to www.example.com, = and I >>>>> get an A record for www.example.com, and I get a TLSA record for >>>>> _http._tcp.www.example.com, and I get a certificate that says = "this >>>>> key is associated with www.somethingelse.com", what does it mean? >>>>>=20 >>>>> I can see both ways: "it doesn't matter what the cert says, we are >>>>> trusting the binding from the DNS" vs. "the cert needs to mean >>>>> something"? Jakob and I have that text in because a number of = people >>>>> on the list were in the latter category, but it seems like a >>>>> reasonable question to ask separately. >>>>=20 >>>> I wonder if one approach here would be to require a match if, and = only >>>> if, any naming attributes (CN, SubjectAltName) are in the = certificate. >>>>=20 >>>> If there are no CN and no SAN attributes in the certificate then = that >>>> would be acceptable too. >>>>=20 >>>> Cheers, >>>> Peter >>>=20 >>> A CN is a type of attribute in the Subject DN. A SAN admits a = variety of name types, some of which can have attributes. Do you mean to = focus on DNS names as SANs or did you have a broader range of SANs in = mind? >>>=20 >>> Steve >>> _______________________________________________ >>> keyassure mailing list >>> keyassure@ietf.org >>> https://www.ietf.org/mailman/listinfo/keyassure >>=20 >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >=20 >=20 > --=20 > Jay Daley > Chief Executive > .nz Registry Services (New Zealand Domain Name Registry Limited) > desk: +64 4 931 6977 > mobile: +64 21 678840 >=20 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC5D33A6BBE for ; Wed, 30 Mar 2011 12:44:01 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X13r96SqRLR2 for ; Wed, 30 Mar 2011 12:44:00 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id F34AC3A6A7F for ; Wed, 30 Mar 2011 12:43:59 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id ADCE52CE004; Thu, 31 Mar 2011 08:45:41 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ok9tcMdjgn7A; Thu, 31 Mar 2011 08:45:41 +1300 (NZDT) Received: from [192.168.22.200] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 62FB12DB66F; Thu, 31 Mar 2011 08:45:41 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: Date: Thu, 31 Mar 2011 08:45:36 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <20EEA73E-9E5E-4D8F-B70C-BD6DF37F60E6@nzrs.net.nz> References: <4D7BFB41.4000403@vpnc.org> <20110321092514.GE9247@anguilla.noreply.org> <20110321130430.GG9247@anguilla.noreply.org> <4BC9E139-CBC5-46EE-A18F-E8F16AE108D6@vpnc.org> <20110330091416.GI681@anguilla.noreply.org> To: Richard L. Barnes X-Mailer: Apple Mail (2.1084) Cc: Peter Palfrader , keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 19:44:01 -0000 I would argue the complete opposite - that it is in scope for DANE to = state that names in certificates should not be checked because the trust = chain has been provided by DNSSEC. Doing that allows individuals and = organisations to reuse certificates as they need to for operational = reasons and not as dictated to by suppliers or paranoid protocol = developers. Jay On 31/03/2011, at 12:55 AM, Richard L. Barnes wrote: > This is outside of DANE's scope. Checking of names in certificates is = up to the application that uses TLS. > --Richard >=20 >=20 > On Mar 30, 2011, at 1:19 PM, Stephen Kent wrote: >=20 >> At 11:14 AM +0200 3/30/11, Peter Palfrader wrote: >>> On Mon, 21 Mar 2011, Paul Hoffman wrote: >>>=20 >>>> On Mar 21, 2011, at 6:04 AM, Peter Palfrader wrote: >>>>> Why is it needed in the first place? >>>>=20 >>>> That's a very good question. I don't feel that it is a "need", but = it >>>> "makes some sense". That is, if I want to go to www.example.com, = and I >>>> get an A record for www.example.com, and I get a TLSA record for >>>> _http._tcp.www.example.com, and I get a certificate that says "this >>>> key is associated with www.somethingelse.com", what does it mean? >>>>=20 >>>> I can see both ways: "it doesn't matter what the cert says, we are >>>> trusting the binding from the DNS" vs. "the cert needs to mean >>>> something"? Jakob and I have that text in because a number of = people >>>> on the list were in the latter category, but it seems like a >>>> reasonable question to ask separately. >>>=20 >>> I wonder if one approach here would be to require a match if, and = only >>> if, any naming attributes (CN, SubjectAltName) are in the = certificate. >>>=20 >>> If there are no CN and no SAN attributes in the certificate then = that >>> would be acceptable too. >>>=20 >>> Cheers, >>> Peter >>=20 >> A CN is a type of attribute in the Subject DN. A SAN admits a = variety of name types, some of which can have attributes. Do you mean to = focus on DNS names as SANs or did you have a broader range of SANs in = mind? >>=20 >> Steve >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >=20 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7766C3A6BB3 for ; Wed, 30 Mar 2011 12:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dV2xNo2lPID for ; Wed, 30 Mar 2011 12:31:12 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 9D2D73A68E0 for ; Wed, 30 Mar 2011 12:31:12 -0700 (PDT) Received: from [128.89.255.132] (port=59747 helo=[130.129.71.95]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q518M-000Iba-LG; Wed, 30 Mar 2011 15:32:50 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 30 Mar 2011 21:32:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> To: James Cloos X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 19:31:13 -0000 >>>>>> "RLB" =3D=3D Richard L Barnes writes: >=20 > RLB> 1. Cert-lock / CA-lock > RLB> 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause = connection failure >=20 > If the attacker injects fake dns records pointing to a fake server, = they > can include a dane rr. It only makes the attack slightly harder, = doesn't it? Yes, but as ekr pointed out, injecting fake DANE RRs can only cause the = connection to fail, it won't result in the client connecting to a bogus = server. That's why it's RECOMMENDED instead of REQUIRED.= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A2D328C18B for ; Wed, 30 Mar 2011 12:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.944 X-Spam-Level: X-Spam-Status: No, score=-102.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szaerreFabhk for ; Wed, 30 Mar 2011 12:25:53 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 911B928C12E for ; Wed, 30 Mar 2011 12:25:53 -0700 (PDT) Received: by iye19 with SMTP id 19so1805685iye.31 for ; Wed, 30 Mar 2011 12:27:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.226.135 with SMTP id iw7mr1461972icb.238.1301513252430; Wed, 30 Mar 2011 12:27:32 -0700 (PDT) Received: by 10.42.217.2 with HTTP; Wed, 30 Mar 2011 12:27:31 -0700 (PDT) In-Reply-To: <201103301818.p2UIIbcA016146@fs4113.wdf.sap.corp> References: <201103301818.p2UIIbcA016146@fs4113.wdf.sap.corp> Date: Wed, 30 Mar 2011 21:27:31 +0200 Message-ID: From: Eric Rescorla To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 19:25:54 -0000 On Wed, Mar 30, 2011 at 8:18 PM, Martin Rex wrote: > Eric Rescorla wrote: >> >> 1. Protecting against CA mis-issue (as in CA/cert lock). >> >> In the first case, the idea would be that the relying party would go >> through its ordinary validation logic and if that failed, would reject >> the certificate. However, if the validation succeeded, >> it would check DNS and if that check failed, would then reject the >> certificate. Only if both checks succeeded would the certificate >> be accepted. [0] The objective of this type of mechanism would be >> simply to defend against unauthorized certificate issuance. >> Note that in this case, the DANE data need not be DNSSEC secured, >> because an attacker who tampers with it will solely be able to >> cause a connection failure, and in many cases (TLS, SSH, etc.) >> an attacker with those capabilities can tamper with >> the A record and block the connection that way. > > Maybe I'm dense at the moment, but I don't understand > "the DANE data need not be DNSSEC secured". > > Without DNSSEC, you have a vulnerability, because you can not > enforce a CA or EE cert lock. =A0An attacker can DNS-spoof DANE records > for the mis-issued certs of his choice or DNS-spoof the absence > of DANE records (and the absence of DANE records will be quite > common for more than just a few days). It's obviously better if DANE is DNSSEC secured, but it's not dangerous if they aren't signed, since that just brings you back to where you were without DANE. However, the DANE records can be set with fairly long expiries (like HSTS), thus providing a partial firewall against comodo-type problems. -Ekr Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0791628C190 for ; Wed, 30 Mar 2011 11:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.219 X-Spam-Level: X-Spam-Status: No, score=-10.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNwuLHC19IlE for ; Wed, 30 Mar 2011 11:42:24 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id F1FD328C18B for ; Wed, 30 Mar 2011 11:42:23 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p2UIhlGn024399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Mar 2011 20:43:47 +0200 (MEST) From: Martin Rex Message-Id: <201103301843.p2UIhlYk017803@fs4113.wdf.sap.corp> To: rbarnes@bbn.com (Richard L. Barnes) Date: Wed, 30 Mar 2011 20:43:46 +0200 (MEST) In-Reply-To: <9F44BE94-7AC3-48F4-8A42-0748CA40A29D@bbn.com> from "Richard L. Barnes" at Mar 30, 11 01:54:48 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 18:42:25 -0000 Richard L. Barnes wrote: > > >> To follow up on my comments at the microphone, there are two potential > >> objectives for > >> technology of this type: > >> > >> 1. Protecting against CA mis-issue (as in CA/cert lock). > >> 2. Allowing TLS to work without getting a certificate from one of the > >> established trust > >> anchors. > > > > 3. Enhancing privacy by reducing OCSP lookups to CA operators potentially > > keeping statistics on these (as proven recently with Comodogate) > > This is isomorphic to the use of domain-issued certs, case 2 above. > If the TLS server is using a CA-issued cert, the client *should* use > OCSP (or a CRL) to make sure it hasn't been revoked. With a > domain-issued cert, there's probably no place to go for OCSP. Looking at the recent rush of Browser patches to address Commodogate, I'm somewhat in doubt that certificate revocation ever really worked. A sufficiently powerful attacker might be able to interfere with OCSP lookups and CRL download attempts (making them fail at the network level). The necessesity to blacklist the mis-issued certs seems to indicate that most browser did not (and maybe still don't) check server certs for revocation when encountering a network error trying to access OCSP or CRL download URLs from the server's cert. -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E21428C19A for ; Wed, 30 Mar 2011 11:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.218 X-Spam-Level: X-Spam-Status: No, score=-10.218 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3hgO2yyR-AO for ; Wed, 30 Mar 2011 11:17:06 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 712E528C195 for ; Wed, 30 Mar 2011 11:17:06 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p2UIIcO8020868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Mar 2011 20:18:43 +0200 (MEST) From: Martin Rex Message-Id: <201103301818.p2UIIbcA016146@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Wed, 30 Mar 2011 20:18:37 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at Mar 30, 11 10:48:53 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 18:17:07 -0000 Eric Rescorla wrote: > > 1. Protecting against CA mis-issue (as in CA/cert lock). > > In the first case, the idea would be that the relying party would go > through its ordinary validation logic and if that failed, would reject > the certificate. However, if the validation succeeded, > it would check DNS and if that check failed, would then reject the > certificate. Only if both checks succeeded would the certificate > be accepted. [0] The objective of this type of mechanism would be > simply to defend against unauthorized certificate issuance. > Note that in this case, the DANE data need not be DNSSEC secured, > because an attacker who tampers with it will solely be able to > cause a connection failure, and in many cases (TLS, SSH, etc.) > an attacker with those capabilities can tamper with > the A record and block the connection that way. Maybe I'm dense at the moment, but I don't understand "the DANE data need not be DNSSEC secured". Without DNSSEC, you have a vulnerability, because you can not enforce a CA or EE cert lock. An attacker can DNS-spoof DANE records for the mis-issued certs of his choice or DNS-spoof the absence of DANE records (and the absence of DANE records will be quite common for more than just a few days). > > 2. Allowing TLS to work without getting a certificate from one of the > established trust anchors. > > [...] > > The draft to some extent conflates these two objectives, since it > *both* injects a new trust anchor and restricts the list of potential > certificates. It does not allow you to simply restrict > the list of CAs/certificates without also injecting a new trust point. Personally, I would also prefer if the information conveyed through DANE would include a tag that clearly distinguishes "CA/cert lock" (for a server cert issued under the traditional TLS X.509 PKI of browsers) from a certificate path validation based solely on DNSSEC trust. But ultimately, whoever gains control over the DNSSEC zone contents will be able to preempt the validation under the traditional TLS X.509 PKI for a server cert by supplying appropriately crafted DNSSEC-signed DANE records. Therefore, the existence of DANE will make DNS admins much more interesting targets for attacks (as an alternative to attacking issuing procedures of commercial CAs). -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC8E33A6B7C for ; Wed, 30 Mar 2011 09:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.648, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+JOZ6AmfNcp for ; Wed, 30 Mar 2011 09:02:06 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id 8C77A3A6B72 for ; Wed, 30 Mar 2011 09:02:06 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id A0AF64010B; Wed, 30 Mar 2011 16:03:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1301501024; bh=M5huYlXbhQA4TuZL9ynUeGwKaxjGJSuBfYHgpBi7xBQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=qOiB5Yp33ZJgKjZVTEm5ta6da8orlo2G1sUHGsoSOFUpoj/QhJ6NqFeyOViqUMQyw IlM0A5SZ4cEki/2nV3RMY2rUR6lAV2IuOx4OHTZOZpMIYo2EREF3KnBxrUwdEP/Drt sK/xVid0476KvpDvqSR4II/rFrHEeHvVgN6PANmw= Received: by carbon.jhcloos.org (Postfix, from userid 500) id C545B260070; Wed, 30 Mar 2011 15:56:40 +0000 (UTC) From: James Cloos To: "Richard L. Barnes" In-Reply-To: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> (Richard L. Barnes's message of "Wed, 30 Mar 2011 14:18:15 +0200") References: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> User-Agent: Gnus/5.110014 (No Gnus v0.14) Emacs/24.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2011 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 30 Mar 2011 11:56:36 -0400 Message-ID: Lines: 11 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:110330:rbarnes@bbn.com::jm+c5sAB3a0Vx8nu:0BIi3e X-Hashcash: 1:30:110330:ekr@rtfm.com::H5hjXdmnbKdL5UBD:0000IILXc X-Hashcash: 1:30:110330:keyassure@ietf.org::YF+AKZ0QGAudehn4:000000000000000000000000000000000000000000N5sek Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 16:02:07 -0000 >>>>> "RLB" == Richard L Barnes writes: RLB> 1. Cert-lock / CA-lock RLB> 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause connection failure If the attacker injects fake dns records pointing to a fake server, they can include a dane rr. It only makes the attack slightly harder, doesn't it? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 641203A6932 for ; Wed, 30 Mar 2011 08:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=0.720, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2bfKVnx86B4 for ; Wed, 30 Mar 2011 08:59:19 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id 15B2F3A6917 for ; Wed, 30 Mar 2011 08:59:19 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 401A84010B; Wed, 30 Mar 2011 16:00:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1301500856; bh=6d7mxX2Sd1i8s8OlKQwJGsuXWG3ba0TJL87PyIrqQ3g=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=dTIpNxKT4/MUI93GFsenfsaG5s22D86AxZcmb+41YRw5llITsgTBJJqmo20oCi4mn WKFmSbRMm3Mc53ClfSybabvA7KFnwQl74tx3v2Ck2jAYSjqwncHlTxDWdjXpqcFDaL o4JBrDuqTZlXnjVUFwohq3C3oA0JzWNomjkbrmJ8= Received: by carbon.jhcloos.org (Postfix, from userid 500) id B0296260042; Wed, 30 Mar 2011 15:52:41 +0000 (UTC) From: James Cloos To: keyassure@ietf.org In-Reply-To: (Eric Rescorla's message of "Wed, 30 Mar 2011 10:48:53 +0200") References: User-Agent: Gnus/5.110014 (No Gnus v0.14) Emacs/24.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2011 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 30 Mar 2011 11:52:41 -0400 Message-ID: Lines: 40 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:110330:keyassure@ietf.org::AkQGaJp043D3MBd8:000000000000000000000000000000000000000000HtjUo X-Hashcash: 1:30:110330:ekr@rtfm.com::zTFM4HI+8NXF4BSC:0000icCW4 Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 15:59:20 -0000 >>>>> "ER" == Eric Rescorla writes: ER> 1. Protecting against CA mis-issue (as in CA/cert lock). I hadn't though of doing this as Eric later describes (such that dnssec isn't required for this usage). I can understand how even an unsigned specification that a resource uses this-and-only-this CA might be an improvement over the status quo. But isn't false RR injection combined with a matching false cert chain still a relevant problem in that scenario? Perhaps the rfc should spec that, but with a threat analysis. ER> 2. Allowing TLS to work without getting a certificate from one ER> of the established trust anchors. The above said, this is my primary motivation. Commercial trust anchors provide little value and significant burden. It isn't just about "convenience". Obviously there is still a lot of third-party trust involved. You have to trust that the DS RRs are properly handled by the registrars, root & tld zone operators, et al. But we already have to trust them to do the same with the NS glue RRs. Ie, if the NS glue is mishandled the game is over anyway. So why not trust them correctly to handle the DS glue, too? The one thing that does become significantly more convenient, though, is more frequent rollover. Eric's second scenario should be DANE's primary mission. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFA833A6B61 for ; Wed, 30 Mar 2011 08:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLezSymxXAcn for ; Wed, 30 Mar 2011 08:41:21 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id DA0953A684E for ; Wed, 30 Mar 2011 08:41:20 -0700 (PDT) Received: from marajade.sandelman.ca (ip-85-160-190-55.eurotel.cz [85.160.190.55]) by relay.sandelman.ca (Postfix) with ESMTPS id CAF0D34117 for ; Wed, 30 Mar 2011 11:42:58 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 10D9E98B17 for ; Wed, 30 Mar 2011 17:28:22 +0200 (CEST) From: Michael Richardson To: keyassure@ietf.org In-Reply-To: <0374DFAB-AA4F-42DA-9792-71BCEFB4ABBF@bbn.com> References: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> <0374DFAB-AA4F-42DA-9792-71BCEFB4ABBF@bbn.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 22) Date: Wed, 30 Mar 2011 17:28:22 +0200 Message-ID: <8018.1301498902@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 15:41:21 -0000 >>>>> "Richard" == Richard L Barnes writes: Richard> Fair enough. Revised version below allows for the Richard> possibility of short-circuiting based on exact match with Richard> an EE cert. (Trying to maintain an integral version that Richard> can be called for consensus later.) okay, but is there a bit that tells the client which case they are trying to implement? Or do we even need such a thing? Paul and I were discussing things from the point of view that the client does one process only, and that it has to work for both cases. 1. client looks up A/AAAA record. DNSSEC recommended. If no DNSSEC, attacker can mis-direct connection. 2a. client initiates TCP socket to target. (Attacker may do IP-level redirection, even if A/AAAA is correct) 2b. client looks up DANE/TLSA record (if any). 3. If TLSA found, client adds DANE CA and/or EE certs to TA store, dropping all others (*) 4. Client performs normal TLS/PKIX checks. This is secure for domain-managed authentication if DNSSEC. This is is also secure for cert-lock even in the face of Comodogate. This may fail for some corporate environments where there is a forced proxy of all TLS connections to some auditing firewall device. Apparently some vendors let you force new sets of trust anchors to desktops so that the desktops will wind up trusting the official man-in-the-middle device. If in step 3, one drops that trust anchor, then the MitM is detected. This may be a feature or not. The question that we came up with was: is the act of dropping other trust anchors something that should be controlled by the owner the domain via the TLSA record, or is this a question of local policy? You *HAVE* to drop them to get the cert-lock to be effective. Richard> 1. Cert-lock / CA-lock Richard> 1.1. Use case: Richard> 1.1.1. Client initiates TLS connection and gets server cert chain Richard> 1.1.2. Client performs normal TLS/PKIX validation on cert chain Richard> 1.1.3. Client retrieves DANE records from DNS Richard> 1.1.4. DANE records specify EE or CA certs that MUST be present in cert chain Richard> 1.1.5. Client verifies that TLS cert chain meets DANE constraints Richard> 1.2. Security goal: Defend against issuance of other certs for this domain Richard> 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause connection failure Richard> 2. Domain-managed authentication Richard> 2.1. Use case: Richard> 2.1.1. Client retrieves DANE records from DNS Richard> 2.1.2. DANE records specify Trust Anchors for PKIX certificate validation Richard> 2.1.3. Client adds DANE CA certs to TA store (optionally, drops all others) Richard> 2.1.3. [TBD] If DANE provides EE cert, accept/reject based on exact match Richard> 2.1.4. Client initiates TLS connection and gets server cert chain Richard> 2.1.5. Client performs normal TLS/PKIX validation on cert chain Richard> 2.2. Security goal: Allow TLS to work without pre-configured TAs Richard> 2.3. DNSSEC REQUIRED; attacker can insert bogus TAs Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5317F28C12F for ; Wed, 30 Mar 2011 05:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eW+ZJCZ9sI5A for ; Wed, 30 Mar 2011 05:45:26 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id C3E0528C14E for ; Wed, 30 Mar 2011 05:45:25 -0700 (PDT) Received: from [128.89.255.137] (port=58514 helo=[130.129.17.55]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q4und-000AuN-Mt; Wed, 30 Mar 2011 08:47:01 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 30 Mar 2011 14:46:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1DDD3940-D481-44E8-B505-05F24E7B46AA@bbn.com> To: Eric Rescorla X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Musing on design based on proposed use cases X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:45:27 -0000 >> So the proposed validation algorithm would have roughly the following = form: >> A. Given a set of DANE records and a cert chain... >> B. Verify that all DANE certs with the "critical" flag set are = present in the cert chain >=20 > This seems problematic. Say what I'm trying to do is cert lock and I > have multiple servers, > each with its own cert. If I list all the certs, this will obvious = break. Fair enough. Could also be "Verify that at least one DANE CA cert with = the "critical" flag set is present in the cert chain". Assuming that = you never want to specify more than one cert in the chain (I don't see = why you would). --Richard= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A849E28C17F for ; Wed, 30 Mar 2011 05:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.943 X-Spam-Level: X-Spam-Status: No, score=-102.943 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBXugvg5v8eB for ; Wed, 30 Mar 2011 05:42:13 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 90CC328C14E for ; Wed, 30 Mar 2011 05:42:13 -0700 (PDT) Received: by iwn39 with SMTP id 39so1416996iwn.31 for ; Wed, 30 Mar 2011 05:43:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.226.135 with SMTP id iw7mr1112356icb.238.1301489032339; Wed, 30 Mar 2011 05:43:52 -0700 (PDT) Received: by 10.42.217.2 with HTTP; Wed, 30 Mar 2011 05:43:52 -0700 (PDT) In-Reply-To: <1DDD3940-D481-44E8-B505-05F24E7B46AA@bbn.com> References: <1DDD3940-D481-44E8-B505-05F24E7B46AA@bbn.com> Date: Wed, 30 Mar 2011 14:43:52 +0200 Message-ID: From: Eric Rescorla To: "Richard L. Barnes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Musing on design based on proposed use cases X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:42:18 -0000 Without endorsing this design overall... On Wed, Mar 30, 2011 at 2:40 PM, Richard L. Barnes wrote: > So I think the use cases EKR described are clear enough to design to -- a= nd they're not satisfied by the current design. =A0ISTM that there will pro= bably be a need for a couple of flags to distinguish the two semantics: > 1. "critical": MUST require that this cert be present in the chain > 2. "trusted": =A0MUST use this cert as a TA > 3. "exclusive": Trusted + MUST NOT use any other TAs. > > The latter two come with a caveat: Clearly, the relying party can choose = to ignore the DANE TAs, so the flag would be a recommendation from the doma= in owner to the relying party. =A0(There are clearly interactions between t= he flags, e.g., no "exclusive" without "trusted"; see table at the bottom. = =A0There are also potential interactions between records w.r.t. the "exclus= ive" flag.) > > So the proposed validation algorithm would have roughly the following for= m: > A. Given a set of DANE records and a cert chain... > B. Verify that all DANE certs with the "critical" flag set are present in= the cert chain This seems problematic. Say what I'm trying to do is cert lock and I have multiple servers, each with its own cert. If I list all the certs, this will obvious break. > C. [TBD-Consensus] If there is a "critical" EE cert, accept/reject based = on exact match > E. If any DANE record is flagged "exclusive", remove all TAs from the loc= al TA store > D. Add all DANE certs with the "trusted" flag set to the local TA store > F. Perform normal PKIX validation -Ekr Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DE7D28C14E for ; Wed, 30 Mar 2011 05:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVuXem92qPns for ; Wed, 30 Mar 2011 05:41:19 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id C1D473A67D4 for ; Wed, 30 Mar 2011 05:41:19 -0700 (PDT) Received: from [128.89.255.137] (port=58501 helo=[130.129.17.55]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q4ujc-000Ard-UK; Wed, 30 Mar 2011 08:42:53 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 30 Mar 2011 14:42:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0374DFAB-AA4F-42DA-9792-71BCEFB4ABBF@bbn.com> References: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> To: Eric Rescorla X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:41:21 -0000 Fair enough. Revised version below allows for the possibility of = short-circuiting based on exact match with an EE cert. (Trying to = maintain an integral version that can be called for consensus later.) 1. Cert-lock / CA-lock 1.1. Use case: 1.1.1. Client initiates TLS connection and gets server cert chain 1.1.2. Client performs normal TLS/PKIX validation on cert chain 1.1.3. Client retrieves DANE records from DNS 1.1.4. DANE records specify EE or CA certs that MUST be present in cert = chain 1.1.5. Client verifies that TLS cert chain meets DANE constraints 1.2. Security goal: Defend against issuance of other certs for this = domain 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause = connection failure 2. Domain-managed authentication 2.1. Use case: 2.1.1. Client retrieves DANE records from DNS 2.1.2. DANE records specify Trust Anchors for PKIX certificate = validation 2.1.3. Client adds DANE CA certs to TA store (optionally, drops all = others) 2.1.3. [TBD] If DANE provides EE cert, accept/reject based on exact = match 2.1.4. Client initiates TLS connection and gets server cert chain 2.1.5. Client performs normal TLS/PKIX validation on cert chain 2.2. Security goal: Allow TLS to work without pre-configured TAs 2.3. DNSSEC REQUIRED; attacker can insert bogus TAs On Mar 30, 2011, at 2:27 PM, Eric Rescorla wrote: > On Wed, Mar 30, 2011 at 2:18 PM, Richard L. Barnes = wrote: >> I agree with Ekr and Steve that these are the right goals. I don't = have any further goals to add. Just trying to re-state in bullet-point = form: >>=20 >> 1. Cert-lock / CA-lock >> 1.1. Use case: >> 1.1.1. Client initiates TLS connection and gets server cert chain >> 1.1.2. Client performs normal TLS/PKIX validation on cert chain >> 1.1.3. Client retrieves DANE records from DNS >> 1.1.4. DANE records specify EE or CA certs that MUST be present in = cert chain >> 1.1.5. Client verifies that TLS cert chain meets DANE constraints >> 1.2. Security goal: Defend against issuance of other certs for this = domain >> 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause = connection failure >>=20 >> 2. Domain-managed authentication >> 2.1. Use case: >> 2.1.1. Client retrieves DANE records from DNS >> 2.1.2. DANE records specify Trust Anchors for PKIX certificate = validation >> 2.1.3. Client adds DANE CA certs to TA store (optionally, drops all = others) >> 2.1.3. Client initiates TLS connection and gets server cert chain >> 2.1.4. Client performs normal TLS/PKIX validation on cert chain >=20 > I don't think this last point has consensus. Certainly, in the case = where the > certificate in question is the terminal certificate, I think at least > some people > don't care if it's invalid from a PKIX perspective. >=20 > -Ekr >=20 >> 2.2. Security goal: Allow TLS to work without pre-configured TAs >> 2.3. DNSSEC REQUIRED; attacker can insert bogus TAs >>=20 >>=20 >>=20 >>=20 >>=20 >> On Mar 30, 2011, at 10:48 AM, Eric Rescorla wrote: >>=20 >>> To follow up on my comments at the microphone, there are two = potential >>> objectives for >>> technology of this type: >>>=20 >>> 1. Protecting against CA mis-issue (as in CA/cert lock). >>> 2. Allowing TLS to work without getting a certificate from one of = the >>> established trust >>> anchors. >>>=20 >>> In the first case, the idea would be that the relying party would go >>> through its ordinary validation >>> logic and if that failed, would reject the certificate. However, if >>> the validation succeeded, >>> it would check DNS and if that check failed, would then reject the >>> certificate. Only if both >>> checks succeeded would the certificate be accepted. [0] The = objective >>> of this type of >>> mechanism would be simply to defend against unauthorized certificate = issuance. >>> Note that in this case, the DANE data need not be DNSSEC secured, >>> because an attacker >>> who tampers with it will solely be able to cause a connection = failure, >>> and in many cases >>> (TLS, SSH, etc.) an attacker with those capabilities can tamper with >>> the A record and >>> block the connection that way. >>>=20 >>> In the second case, the intention is to allow clients to effectively >>> bypass the existing trust >>> hierarchy by injecting a new trust point via the DNS. Thus, either = the >>> certificate validation >>> simply will not be used at all (in the case where a terminal >>> certificate is provided) or will be >>> used up to a newly inserted trust anchor. In either case, the >>> presumptive rationale here >>> is that it's too inconvenient to deal with the existing CAs and that >>> DANE will be easier. >>> This version of DANE *does* need to be protected via DNSSEC because = tampering >>> with these records allows the attacker to impersonate the >>> authenticating party to the >>> relying party. >>>=20 >>>=20 >>> The draft to some extent conflates these two objectives, since it >>> *both* injects a new trust >>> anchor and restricts the list of potential certificates. It does not >>> allow you to simply restrict >>> the list of CAs/certificates without also injecting a new trust = point. >>>=20 >>>=20 >>> Opinion follows: >>> For my money the most important driving use case for this work is = the >>> first case, for two >>> reasons. First, it's the more pressing problem since it's not really >>> *that* hard to get a >>> certificate from one of the existing CAs, but this also means that = we >>> have to worry about >>> mis-issue by misbehaving CAs, as we have recently seen. Second, the >>> incremental deployment >>> story is much easier, since clients which don't speak DANE will just >>> not be protected against >>> attack, whereas in the second case clients which don't speak DANE = will >>> experience certificate >>> errors when connecting to a DANE-only site. >>>=20 >>> -Ekr >>>=20 >>>=20 >>> [0] The checks can be done in either order. This is only for = clarity. >>> _______________________________________________ >>> keyassure mailing list >>> keyassure@ietf.org >>> https://www.ietf.org/mailman/listinfo/keyassure >>=20 >>=20 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ADBF3A67FC for ; Wed, 30 Mar 2011 05:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfdxWuBh62rj for ; Wed, 30 Mar 2011 05:38:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 5A3EC3A67D4 for ; Wed, 30 Mar 2011 05:38:55 -0700 (PDT) Received: from [128.89.255.137] (port=58496 helo=[130.129.17.55]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q4uhN-000AqB-Tx for keyassure@ietf.org; Wed, 30 Mar 2011 08:40:34 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Mar 2011 14:40:28 +0200 Message-Id: <1DDD3940-D481-44E8-B505-05F24E7B46AA@bbn.com> To: keyassure@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [keyassure] Musing on design based on proposed use cases X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:38:56 -0000 So I think the use cases EKR described are clear enough to design to -- = and they're not satisfied by the current design. ISTM that there will = probably be a need for a couple of flags to distinguish the two = semantics: 1. "critical": MUST require that this cert be present in the chain 2. "trusted": MUST use this cert as a TA 3. "exclusive": Trusted + MUST NOT use any other TAs. The latter two come with a caveat: Clearly, the relying party can choose = to ignore the DANE TAs, so the flag would be a recommendation from the = domain owner to the relying party. (There are clearly interactions = between the flags, e.g., no "exclusive" without "trusted"; see table at = the bottom. There are also potential interactions between records = w.r.t. the "exclusive" flag.) So the proposed validation algorithm would have roughly the following = form: A. Given a set of DANE records and a cert chain... B. Verify that all DANE certs with the "critical" flag set are present = in the cert chain C. [TBD-Consensus] If there is a "critical" EE cert, accept/reject based = on exact match E. If any DANE record is flagged "exclusive", remove all TAs from the = local TA store=20 D. Add all DANE certs with the "trusted" flag set to the local TA store F. Perform normal PKIX validation Submitted for consideration... --Richard CTE 000 [disallowed] 001 [disallowed] 010 MUST use as a TA 011 MUST NOT use any other TAs 100 MUST be present in cert chain 101 [disallowed] 110 MUST be present and used as a TA 111 MUST be present and used as only TA Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623A428C160 for ; Wed, 30 Mar 2011 05:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.942 X-Spam-Level: X-Spam-Status: No, score=-102.942 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHQnwx56uLN7 for ; Wed, 30 Mar 2011 05:25:57 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8E66128C121 for ; Wed, 30 Mar 2011 05:25:57 -0700 (PDT) Received: by iwn39 with SMTP id 39so1400016iwn.31 for ; Wed, 30 Mar 2011 05:27:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.75.196 with SMTP id b4mr1164242ick.372.1301488054709; Wed, 30 Mar 2011 05:27:34 -0700 (PDT) Received: by 10.42.217.2 with HTTP; Wed, 30 Mar 2011 05:27:34 -0700 (PDT) In-Reply-To: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> References: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> Date: Wed, 30 Mar 2011 14:27:34 +0200 Message-ID: From: Eric Rescorla To: "Richard L. Barnes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:26:01 -0000 On Wed, Mar 30, 2011 at 2:18 PM, Richard L. Barnes wrote: > I agree with Ekr and Steve that these are the right goals. =A0I don't hav= e any further goals to add. =A0Just trying to re-state in bullet-point form= : > > 1. Cert-lock / CA-lock > 1.1. Use case: > 1.1.1. Client initiates TLS connection and gets server cert chain > 1.1.2. Client performs normal TLS/PKIX validation on cert chain > 1.1.3. Client retrieves DANE records from DNS > 1.1.4. DANE records specify EE or CA certs that MUST be present in cert c= hain > 1.1.5. Client verifies that TLS cert chain meets DANE constraints > 1.2. Security goal: Defend against issuance of other certs for this domai= n > 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause connection= failure > > 2. Domain-managed authentication > 2.1. Use case: > 2.1.1. Client retrieves DANE records from DNS > 2.1.2. DANE records specify Trust Anchors for PKIX certificate validation > 2.1.3. Client adds DANE CA certs to TA store (optionally, drops all other= s) > 2.1.3. Client initiates TLS connection and gets server cert chain > 2.1.4. Client performs normal TLS/PKIX validation on cert chain I don't think this last point has consensus. Certainly, in the case where t= he certificate in question is the terminal certificate, I think at least some people don't care if it's invalid from a PKIX perspective. -Ekr > 2.2. Security goal: Allow TLS to work without pre-configured TAs > 2.3. DNSSEC REQUIRED; attacker can insert bogus TAs > > > > > > On Mar 30, 2011, at 10:48 AM, Eric Rescorla wrote: > >> To follow up on my comments at the microphone, there are two potential >> objectives for >> technology of this type: >> >> 1. Protecting against CA mis-issue (as in CA/cert lock). >> 2. Allowing TLS to work without getting a certificate from one of the >> established trust >> anchors. >> >> In the first case, the idea would be that the relying party would go >> through its ordinary validation >> logic and if that failed, would reject the certificate. However, if >> the validation succeeded, >> it would check DNS and if that check failed, would then reject the >> certificate. Only if both >> checks succeeded would the certificate be accepted. [0] The objective >> of this type of >> mechanism would be simply to defend against unauthorized certificate iss= uance. >> Note that in this case, the DANE data need not be DNSSEC secured, >> because an attacker >> who tampers with it will solely be able to cause a connection failure, >> and in many cases >> (TLS, SSH, etc.) an attacker with those capabilities can tamper with >> the A record and >> block the connection that way. >> >> In the second case, the intention is to allow clients to effectively >> bypass the existing trust >> hierarchy by injecting a new trust point via the DNS. Thus, either the >> certificate validation >> simply will not be used at all (in the case where a terminal >> certificate is provided) or will be >> used up to a newly inserted trust anchor. In either case, the >> presumptive rationale here >> is that it's too inconvenient to deal with the existing CAs and that >> DANE will be easier. >> This version of DANE *does* need to be protected via DNSSEC because tamp= ering >> with these records allows the attacker to impersonate the >> authenticating party to the >> relying party. >> >> >> The draft to some extent conflates these two objectives, since it >> *both* injects a new trust >> anchor and restricts the list of potential certificates. It does not >> allow you to simply restrict >> the list of CAs/certificates without also injecting a new trust point. >> >> >> Opinion follows: >> For my money the most important driving use case for this work is the >> first case, for two >> reasons. First, it's the more pressing problem since it's not really >> *that* hard to get a >> certificate from one of the existing CAs, but this also means that we >> have to worry about >> mis-issue by misbehaving CAs, as we have recently seen. Second, the >> incremental deployment >> story is much easier, since clients which don't speak DANE will just >> not be protected against >> attack, whereas in the second case clients which don't speak DANE will >> experience certificate >> errors when connecting to a DANE-only site. >> >> -Ekr >> >> >> [0] The checks can be done in either order. This is only for clarity. >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13BA428C108 for ; Wed, 30 Mar 2011 05:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIBACKLyOoRb for ; Wed, 30 Mar 2011 05:16:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 1FD2B3A6947 for ; Wed, 30 Mar 2011 05:16:42 -0700 (PDT) Received: from [128.89.255.137] (port=58478 helo=[130.129.17.55]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q4uLs-000IFJ-Ft; Wed, 30 Mar 2011 08:18:20 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 30 Mar 2011 14:18:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> References: To: Eric Rescorla X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:16:43 -0000 I agree with Ekr and Steve that these are the right goals. I don't have = any further goals to add. Just trying to re-state in bullet-point form: 1. Cert-lock / CA-lock 1.1. Use case: 1.1.1. Client initiates TLS connection and gets server cert chain 1.1.2. Client performs normal TLS/PKIX validation on cert chain 1.1.3. Client retrieves DANE records from DNS 1.1.4. DANE records specify EE or CA certs that MUST be present in cert = chain 1.1.5. Client verifies that TLS cert chain meets DANE constraints 1.2. Security goal: Defend against issuance of other certs for this = domain 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause = connection failure 2. Domain-managed authentication 2.1. Use case: 2.1.1. Client retrieves DANE records from DNS 2.1.2. DANE records specify Trust Anchors for PKIX certificate = validation 2.1.3. Client adds DANE CA certs to TA store (optionally, drops all = others) 2.1.3. Client initiates TLS connection and gets server cert chain 2.1.4. Client performs normal TLS/PKIX validation on cert chain 2.2. Security goal: Allow TLS to work without pre-configured TAs 2.3. DNSSEC REQUIRED; attacker can insert bogus TAs On Mar 30, 2011, at 10:48 AM, Eric Rescorla wrote: > To follow up on my comments at the microphone, there are two potential > objectives for > technology of this type: >=20 > 1. Protecting against CA mis-issue (as in CA/cert lock). > 2. Allowing TLS to work without getting a certificate from one of the > established trust > anchors. >=20 > In the first case, the idea would be that the relying party would go > through its ordinary validation > logic and if that failed, would reject the certificate. However, if > the validation succeeded, > it would check DNS and if that check failed, would then reject the > certificate. Only if both > checks succeeded would the certificate be accepted. [0] The objective > of this type of > mechanism would be simply to defend against unauthorized certificate = issuance. > Note that in this case, the DANE data need not be DNSSEC secured, > because an attacker > who tampers with it will solely be able to cause a connection failure, > and in many cases > (TLS, SSH, etc.) an attacker with those capabilities can tamper with > the A record and > block the connection that way. >=20 > In the second case, the intention is to allow clients to effectively > bypass the existing trust > hierarchy by injecting a new trust point via the DNS. Thus, either the > certificate validation > simply will not be used at all (in the case where a terminal > certificate is provided) or will be > used up to a newly inserted trust anchor. In either case, the > presumptive rationale here > is that it's too inconvenient to deal with the existing CAs and that > DANE will be easier. > This version of DANE *does* need to be protected via DNSSEC because = tampering > with these records allows the attacker to impersonate the > authenticating party to the > relying party. >=20 >=20 > The draft to some extent conflates these two objectives, since it > *both* injects a new trust > anchor and restricts the list of potential certificates. It does not > allow you to simply restrict > the list of CAs/certificates without also injecting a new trust point. >=20 >=20 > Opinion follows: > For my money the most important driving use case for this work is the > first case, for two > reasons. First, it's the more pressing problem since it's not really > *that* hard to get a > certificate from one of the existing CAs, but this also means that we > have to worry about > mis-issue by misbehaving CAs, as we have recently seen. Second, the > incremental deployment > story is much easier, since clients which don't speak DANE will just > not be protected against > attack, whereas in the second case clients which don't speak DANE will > experience certificate > errors when connecting to a DANE-only site. >=20 > -Ekr >=20 >=20 > [0] The checks can be done in either order. This is only for clarity. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74B9628C126 for ; Wed, 30 Mar 2011 04:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWPvXET4GYh6 for ; Wed, 30 Mar 2011 04:54:19 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 2589528C15F for ; Wed, 30 Mar 2011 04:54:19 -0700 (PDT) Received: from [128.89.255.137] (port=58399 helo=[130.129.17.55]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q4u08-000A8Z-7c; Wed, 30 Mar 2011 07:55:52 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 30 Mar 2011 13:55:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D7BFB41.4000403@vpnc.org> <20110321092514.GE9247@anguilla.noreply.org> <20110321130430.GG9247@anguilla.noreply.org> <4BC9E139-CBC5-46EE-A18F-E8F16AE108D6@vpnc.org> <20110330091416.GI681@anguilla.noreply.org> To: Stephen Kent X-Mailer: Apple Mail (2.1082) Cc: Peter Palfrader , keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 11:54:20 -0000 This is outside of DANE's scope. Checking of names in certificates is = up to the application that uses TLS. --Richard On Mar 30, 2011, at 1:19 PM, Stephen Kent wrote: > At 11:14 AM +0200 3/30/11, Peter Palfrader wrote: >> On Mon, 21 Mar 2011, Paul Hoffman wrote: >>=20 >>> On Mar 21, 2011, at 6:04 AM, Peter Palfrader wrote: >>> > Why is it needed in the first place? >>>=20 >>> That's a very good question. I don't feel that it is a "need", but = it >>> "makes some sense". That is, if I want to go to www.example.com, and = I >>> get an A record for www.example.com, and I get a TLSA record for >>> _http._tcp.www.example.com, and I get a certificate that says "this >>> key is associated with www.somethingelse.com", what does it mean? >>>=20 >>> I can see both ways: "it doesn't matter what the cert says, we are >>> trusting the binding from the DNS" vs. "the cert needs to mean >>> something"? Jakob and I have that text in because a number of people >>> on the list were in the latter category, but it seems like a >>> reasonable question to ask separately. >>=20 >> I wonder if one approach here would be to require a match if, and = only >> if, any naming attributes (CN, SubjectAltName) are in the = certificate. >>=20 >> If there are no CN and no SAN attributes in the certificate then that >> would be acceptable too. >>=20 >> Cheers, >> Peter >=20 > A CN is a type of attribute in the Subject DN. A SAN admits a variety = of name types, some of which can have attributes. Do you mean to focus = on DNS names as SANs or did you have a broader range of SANs in mind? >=20 > Steve > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2BB128C11A for ; Wed, 30 Mar 2011 04:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDDty+F3rx0L for ; Wed, 30 Mar 2011 04:53:16 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id B1F2328C134 for ; Wed, 30 Mar 2011 04:53:15 -0700 (PDT) Received: from [128.89.255.137] (port=58399 helo=[130.129.17.55]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q4tzB-000A8Z-L9; Wed, 30 Mar 2011 07:54:53 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 30 Mar 2011 13:54:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9F44BE94-7AC3-48F4-8A42-0748CA40A29D@bbn.com> References: To: Paul Wouters X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 11:53:16 -0000 >> To follow up on my comments at the microphone, there are two = potential >> objectives for >> technology of this type: >>=20 >> 1. Protecting against CA mis-issue (as in CA/cert lock). >> 2. Allowing TLS to work without getting a certificate from one of the >> established trust >> anchors. >=20 > 3. Enhancing privacy by reducing OCSP lookups to CA operators = potentially > keeping statistics on these (as proven recently with Comodogate) This is isomorphic to the use of domain-issued certs, case 2 above. If = the TLS server is using a CA-issued cert, the client *should* use OCSP = (or a CRL) to make sure it hasn't been revoked. With a domain-issued = cert, there's probably no place to go for OCSP. --Richard= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7E928C11A for ; Wed, 30 Mar 2011 04:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.941 X-Spam-Level: X-Spam-Status: No, score=-102.941 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEgzblaFqspU for ; Wed, 30 Mar 2011 04:52:13 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id EE2BE28C134 for ; Wed, 30 Mar 2011 04:52:12 -0700 (PDT) Received: by iwn39 with SMTP id 39so1365472iwn.31 for ; Wed, 30 Mar 2011 04:53:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.156.131 with SMTP id z3mr1151462icw.305.1301486031592; Wed, 30 Mar 2011 04:53:51 -0700 (PDT) Received: by 10.42.217.2 with HTTP; Wed, 30 Mar 2011 04:53:51 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Mar 2011 13:53:51 +0200 Message-ID: From: Eric Rescorla To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Another comment from the mic X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 11:52:14 -0000 On Wed, Mar 30, 2011 at 1:16 PM, Stephen Kent wrote: > At 10:57 AM +0200 3/30/11, Eric Rescorla wrote: >> >> As I said at the mic, the vast majority of the certificate warnings >> you see on the network >> are not because of attacks, but rather are due to: >> >> - Self-signed certs >> - Certificates from legitimate CAs which are uncompromised but invalid >> for some technical >> =A0 reason (expired certs, trivial name mismatches, etc.) >> >> One of the purposes of my "permissive" case-2 model in my previous >> email is to allow those >> self-signed certificate servers to have verifiable credentials. >> However, anything we do that >> has the consequence that certificates which should verify don't for >> mostly-irrelevant technical >> reasons (e.g., certs which are validated by DANE but are expired or >> have the wrong keyusage >> bits) will defeat this purpose to some extent. Perhaps that's worth >> doing in service of the correctness >> of the validation chain, but it does need to be considered. >> >> -Ekr > > I fully agree with the goal of avoiding error messages that confuse a use= r, > especially ones that make it hard to tell the difference between a sloppy > admin and an attacker. =A0But, it may be hard to tell the difference in s= ome > cases :-). Maybe we can reduce the incidence of bad self-signed certs by > providing better tools to generate these certs, and including defaults to > make it easy to avoid the typical errors. This seems like a very worthy goal. -Ekr Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB03F28C174 for ; Wed, 30 Mar 2011 04:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0Oq7+VaRc1h for ; Wed, 30 Mar 2011 04:40:07 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 3CAE628C114 for ; Wed, 30 Mar 2011 04:40:07 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:58034 helo=[130.129.71.125]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q4tmS-000A36-Sd; Wed, 30 Mar 2011 07:41:45 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110330091416.GI681@anguilla.noreply.org> References: <4D7BFB41.4000403@vpnc.org> <20110321092514.GE9247@anguilla.noreply.org> <20110321130430.GG9247@anguilla.noreply.org> <4BC9E139-CBC5-46EE-A18F-E8F16AE108D6@vpnc.org> <20110330091416.GI681@anguilla.noreply.org> Date: Wed, 30 Mar 2011 07:19:39 -0400 To: Peter Palfrader From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 11:40:09 -0000 At 11:14 AM +0200 3/30/11, Peter Palfrader wrote: >On Mon, 21 Mar 2011, Paul Hoffman wrote: > >> On Mar 21, 2011, at 6:04 AM, Peter Palfrader wrote: >> > Why is it needed in the first place? >> >> That's a very good question. I don't feel that it is a "need", but it >> "makes some sense". That is, if I want to go to www.example.com, and I >> get an A record for www.example.com, and I get a TLSA record for >> _http._tcp.www.example.com, and I get a certificate that says "this >> key is associated with www.somethingelse.com", what does it mean? >> >> I can see both ways: "it doesn't matter what the cert says, we are >> trusting the binding from the DNS" vs. "the cert needs to mean >> something"? Jakob and I have that text in because a number of people >> on the list were in the latter category, but it seems like a >> reasonable question to ask separately. > >I wonder if one approach here would be to require a match if, and only >if, any naming attributes (CN, SubjectAltName) are in the certificate. > >If there are no CN and no SAN attributes in the certificate then that >would be acceptable too. > >Cheers, >Peter A CN is a type of attribute in the Subject DN. A SAN admits a variety of name types, some of which can have attributes. Do you mean to focus on DNS names as SANs or did you have a broader range of SANs in mind? Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C933E28C157 for ; Wed, 30 Mar 2011 04:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8Sx6SJqbaqN for ; Wed, 30 Mar 2011 04:40:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 087BE28C0DB for ; Wed, 30 Mar 2011 04:40:00 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:58034 helo=[130.129.71.125]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q4tmL-000A36-GJ; Wed, 30 Mar 2011 07:41:37 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 30 Mar 2011 07:13:08 -0400 To: Paul Wouters , Eric Rescorla From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 11:40:01 -0000 At 4:51 AM -0400 3/30/11, Paul Wouters wrote: >On Wed, 30 Mar 2011, Eric Rescorla wrote: > >> To follow up on my comments at the microphone, there are two potential >> objectives for >> technology of this type: >> >> 1. Protecting against CA mis-issue (as in CA/cert lock). Eric's text provide a good rationale for this, and I think a solid rationale is an important part of the requirements spec. I would be a bit more precise, and note that the CAs that pose a threat are the TAs configured into the system, any CAs below those TAs, and any other CAs that have been accepted by the client as TAs. > > 2. Allowing TLS to work without getting a certificate from one of the >> established trust >> anchors. right. also, don't we want the TAs acquired via DANE to be treated, for the session in question, to be as god as the configured TAs, i.e., yield no error messages/ (I'll duck for the moment the issue of EV certs and whether we ought to have a DANE-validated icon, and what color it should be :-).) >3. Enhancing privacy by reducing OCSP lookups to CA operators potentially >keeping statistics on these (as proven recently with Comodogate) > >Paul Presumably #3 applies only to the configured TAs (and their offspring), right? Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFFFA28C0DB for ; Wed, 30 Mar 2011 04:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-DQAt-XY2uQ for ; Wed, 30 Mar 2011 04:40:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 088B228C0F9 for ; Wed, 30 Mar 2011 04:40:00 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:58034 helo=[130.129.71.125]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q4tmM-000A36-Ep; Wed, 30 Mar 2011 07:41:38 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 30 Mar 2011 07:16:15 -0400 To: Eric Rescorla From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Another comment from the mic X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 11:40:01 -0000 At 10:57 AM +0200 3/30/11, Eric Rescorla wrote: >As I said at the mic, the vast majority of the certificate warnings >you see on the network >are not because of attacks, but rather are due to: > >- Self-signed certs >- Certificates from legitimate CAs which are uncompromised but invalid >for some technical > reason (expired certs, trivial name mismatches, etc.) > >One of the purposes of my "permissive" case-2 model in my previous >email is to allow those >self-signed certificate servers to have verifiable credentials. >However, anything we do that >has the consequence that certificates which should verify don't for >mostly-irrelevant technical >reasons (e.g., certs which are validated by DANE but are expired or >have the wrong keyusage >bits) will defeat this purpose to some extent. Perhaps that's worth >doing in service of the correctness >of the validation chain, but it does need to be considered. > >-Ekr I fully agree with the goal of avoiding error messages that confuse a user, especially ones that make it hard to tell the difference between a sloppy admin and an attacker. But, it may be hard to tell the difference in some cases :-). Maybe we can reduce the incidence of bad self-signed certs by providing better tools to generate these certs, and including defaults to make it easy to avoid the typical errors. Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DEC13A697A for ; Wed, 30 Mar 2011 02:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.545 X-Spam-Level: X-Spam-Status: No, score=-10.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKF52zJl8Ynr for ; Wed, 30 Mar 2011 02:13:47 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 245BF3A6875 for ; Wed, 30 Mar 2011 02:13:46 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p2U9FOA9027704; Wed, 30 Mar 2011 11:15:24 +0200 X-CheckPoint: {4D92F420-F-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 30 Mar 2011 11:15:24 +0200 From: Yoav Nir To: Eric Rescorla Date: Wed, 30 Mar 2011 11:15:23 +0200 Thread-Topic: [keyassure] Objective: Restrictive versus Supplementary Models Thread-Index: AcvuuwBcEyTzZ+JoQ9yLPapZRJKGaQ== Message-ID: <5B5DFBAB-9705-4C81-A5B4-EC77EAA56385@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 09:13:48 -0000 On Mar 30, 2011, at 10:48 AM, Eric Rescorla wrote: > To follow up on my comments at the microphone, there are two potential > objectives for > technology of this type: >=20 > 1. Protecting against CA mis-issue (as in CA/cert lock). > 2. Allowing TLS to work without getting a certificate from one of the > established trust > anchors. I think the current draft is mostly focused on the second objective. Unless= we declare #2 to be a non-goal, a (web) client cannot do the regular PKIX = validation of the certificate. More specifically, with a type-2 certificate (CA cert in the record) you an= yway have to validate the EE certificate using regular PKIX procedure, exce= pt that you replace the trust anchor store with the CA certificate in the D= NS record. This makes sense for the 2nd objective, but not for the first (y= ou could put the Verisign root certificate in the DNS record, but then you'= re protected from mis-issue only by the other CAs). So with a type #2 recor= d, you get both objectives With a type-1 certificate (EE cert in the record) you get objective #1, but= how is a client to know whether it is intended to just compare bits or als= o to validate the certificate? As long as objective #2 is not a non-goal, t= he client can't rely on such a record containing a certificate that can be = validated. Maybe we need three types of records: CA certificate, untrusted = EE certificate, and PKIX EE certificate. In that case, I don't the what adv= antage an "untrusted EE certificate" has over bare keys. So maybe it should= be: CA certificate, PKIX certificate (that needs to be validated) and bare= keys.=20 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 186FC28C119 for ; Wed, 30 Mar 2011 02:12:40 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUQzeDXa6T21 for ; Wed, 30 Mar 2011 02:12:39 -0700 (PDT) Received: from anguilla.debian.or.at (anguilla.debian.or.at [IPv6:2001:858:10f:6::2]) by core3.amsl.com (Postfix) with ESMTP id B552A28C11E for ; Wed, 30 Mar 2011 02:12:38 -0700 (PDT) Received: by anguilla.debian.or.at (Postfix, from userid 1002) id 51AF210EBAF; Wed, 30 Mar 2011 11:14:16 +0200 (CEST) Date: Wed, 30 Mar 2011 11:14:16 +0200 From: Peter Palfrader To: Paul Hoffman Message-ID: <20110330091416.GI681@anguilla.noreply.org> References: <4D7BFB41.4000403@vpnc.org> <20110321092514.GE9247@anguilla.noreply.org> <20110321130430.GG9247@anguilla.noreply.org> <4BC9E139-CBC5-46EE-A18F-E8F16AE108D6@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <4BC9E139-CBC5-46EE-A18F-E8F16AE108D6@vpnc.org> X-PGP: 1024D/94C09C7F 5B00 C96D 5D54 AEE1 206B AF84 DE7A AF6E 94C0 9C7F X-Request-PGP: http://www.palfrader.org/keys/94C09C7F.asc X-Accept-Language: de, en User-Agent: Mutt/1.5.18 (2008-05-17) Cc: keyassure@ietf.org Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 09:12:40 -0000 On Mon, 21 Mar 2011, Paul Hoffman wrote: > On Mar 21, 2011, at 6:04 AM, Peter Palfrader wrote: > > Why is it needed in the first place? > > That's a very good question. I don't feel that it is a "need", but it > "makes some sense". That is, if I want to go to www.example.com, and I > get an A record for www.example.com, and I get a TLSA record for > _http._tcp.www.example.com, and I get a certificate that says "this > key is associated with www.somethingelse.com", what does it mean? > > I can see both ways: "it doesn't matter what the cert says, we are > trusting the binding from the DNS" vs. "the cert needs to mean > something"? Jakob and I have that text in because a number of people > on the list were in the latter category, but it seems like a > reasonable question to ask separately. I wonder if one approach here would be to require a match if, and only if, any naming attributes (CN, SubjectAltName) are in the certificate. If there are no CN and no SAN attributes in the certificate then that would be acceptable too. Cheers, Peter -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78BEE28C111 for ; Wed, 30 Mar 2011 01:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.941 X-Spam-Level: X-Spam-Status: No, score=-102.941 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rUeYo312ljR for ; Wed, 30 Mar 2011 01:55:59 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C0AB128C0F0 for ; Wed, 30 Mar 2011 01:55:59 -0700 (PDT) Received: by iwn39 with SMTP id 39so1184868iwn.31 for ; Wed, 30 Mar 2011 01:57:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.131.7 with SMTP id ho7mr963237icc.171.1301475458514; Wed, 30 Mar 2011 01:57:38 -0700 (PDT) Received: by 10.42.217.2 with HTTP; Wed, 30 Mar 2011 01:57:38 -0700 (PDT) Date: Wed, 30 Mar 2011 10:57:38 +0200 Message-ID: From: Eric Rescorla To: keyassure@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [keyassure] Another comment from the mic X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 08:56:00 -0000 As I said at the mic, the vast majority of the certificate warnings you see on the network are not because of attacks, but rather are due to: - Self-signed certs - Certificates from legitimate CAs which are uncompromised but invalid for some technical reason (expired certs, trivial name mismatches, etc.) One of the purposes of my "permissive" case-2 model in my previous email is to allow those self-signed certificate servers to have verifiable credentials. However, anything we do that has the consequence that certificates which should verify don't for mostly-irrelevant technical reasons (e.g., certs which are validated by DANE but are expired or have the wrong keyusage bits) will defeat this purpose to some extent. Perhaps that's worth doing in service of the correctness of the validation chain, but it does need to be considered. -Ekr Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E20373A6B34 for ; Wed, 30 Mar 2011 01:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4uI+OvjWVjY for ; Wed, 30 Mar 2011 01:50:17 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id EDF7B3A6919 for ; Wed, 30 Mar 2011 01:50:16 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 87F8AC4BA; Wed, 30 Mar 2011 04:51:54 -0400 (EDT) Date: Wed, 30 Mar 2011 04:51:54 -0400 (EDT) From: Paul Wouters To: Eric Rescorla In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: keyassure@ietf.org Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 08:50:18 -0000 On Wed, 30 Mar 2011, Eric Rescorla wrote: > To follow up on my comments at the microphone, there are two potential > objectives for > technology of this type: > > 1. Protecting against CA mis-issue (as in CA/cert lock). > 2. Allowing TLS to work without getting a certificate from one of the > established trust > anchors. 3. Enhancing privacy by reducing OCSP lookups to CA operators potentially keeping statistics on these (as proven recently with Comodogate) Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD05C28C101 for ; Wed, 30 Mar 2011 01:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.94 X-Spam-Level: X-Spam-Status: No, score=-102.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6nma9LpLK37 for ; Wed, 30 Mar 2011 01:47:14 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C134228C0CF for ; Wed, 30 Mar 2011 01:47:14 -0700 (PDT) Received: by mail-iw0-f172.google.com with SMTP id 39so1175530iwn.31 for ; Wed, 30 Mar 2011 01:48:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.136.138 with SMTP id u10mr916447ict.104.1301474933642; Wed, 30 Mar 2011 01:48:53 -0700 (PDT) Received: by 10.42.217.2 with HTTP; Wed, 30 Mar 2011 01:48:53 -0700 (PDT) Date: Wed, 30 Mar 2011 10:48:53 +0200 Message-ID: From: Eric Rescorla To: keyassure@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [keyassure] Objective: Restrictive versus Supplementary Models X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 08:47:15 -0000 To follow up on my comments at the microphone, there are two potential objectives for technology of this type: 1. Protecting against CA mis-issue (as in CA/cert lock). 2. Allowing TLS to work without getting a certificate from one of the established trust anchors. In the first case, the idea would be that the relying party would go through its ordinary validation logic and if that failed, would reject the certificate. However, if the validation succeeded, it would check DNS and if that check failed, would then reject the certificate. Only if both checks succeeded would the certificate be accepted. [0] The objective of this type of mechanism would be simply to defend against unauthorized certificate issuance. Note that in this case, the DANE data need not be DNSSEC secured, because an attacker who tampers with it will solely be able to cause a connection failure, and in many cases (TLS, SSH, etc.) an attacker with those capabilities can tamper with the A record and block the connection that way. In the second case, the intention is to allow clients to effectively bypass the existing trust hierarchy by injecting a new trust point via the DNS. Thus, either the certificate validation simply will not be used at all (in the case where a terminal certificate is provided) or will be used up to a newly inserted trust anchor. In either case, the presumptive rationale here is that it's too inconvenient to deal with the existing CAs and that DANE will be easier. This version of DANE *does* need to be protected via DNSSEC because tampering with these records allows the attacker to impersonate the authenticating party to the relying party. The draft to some extent conflates these two objectives, since it *both* injects a new trust anchor and restricts the list of potential certificates. It does not allow you to simply restrict the list of CAs/certificates without also injecting a new trust point. Opinion follows: For my money the most important driving use case for this work is the first case, for two reasons. First, it's the more pressing problem since it's not really *that* hard to get a certificate from one of the existing CAs, but this also means that we have to worry about mis-issue by misbehaving CAs, as we have recently seen. Second, the incremental deployment story is much easier, since clients which don't speak DANE will just not be protected against attack, whereas in the second case clients which don't speak DANE will experience certificate errors when connecting to a DANE-only site. -Ekr [0] The checks can be done in either order. This is only for clarity. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 608283A67F8 for ; Tue, 29 Mar 2011 23:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mwb-LQexpM+6 for ; Tue, 29 Mar 2011 23:52:25 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 247BE3A6B0D for ; Tue, 29 Mar 2011 23:52:25 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 5A7BDC59D; Wed, 30 Mar 2011 02:54:02 -0400 (EDT) Date: Wed, 30 Mar 2011 02:54:01 -0400 (EDT) From: Paul Wouters To: Zack Weinberg In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: keyassure@ietf.org Subject: Re: [keyassure] PROPOSAL: Revision of DANE client requirements X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 06:52:26 -0000 On Tue, 29 Mar 2011, Zack Weinberg wrote: [more later after the WG meeting] > Do you have a link to your proposal? ftp://ftp.xelerance.com/tls-oob/ Note that I have not finished it yet. Please consider it a pre-release Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA5F3A6AA2 for ; Tue, 29 Mar 2011 16:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2Ua8OV0vvGu for ; Tue, 29 Mar 2011 16:22:14 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 074C73A6992 for ; Tue, 29 Mar 2011 16:22:13 -0700 (PDT) Received: by vxg33 with SMTP id 33so693176vxg.31 for ; Tue, 29 Mar 2011 16:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=m0KTgvX4rocgm6+I0pNmJ+7cX0RzuxvQK+SWt4n9VfM=; b=QMHzMyef5eZMNa4Bd7PeVcRyqaak0S+0oLkSk8DzPqjkLhdCXe99DxP+7v8IJn0F4Z tpKEmTNW2z2Ug02oZaw7iyFlt9TgQhA1ecoOVMqBhhFiztToNG3pEAgX6oo47NLL/9C/ g96TUvno2qQLXAfCM82FVhsrAvDXmPA1Y5Cp8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=q4Tz5PGWI2jeFwM1Vy3WyccuH3vSZY/IeRsve6idCka1cWS/r5aZYZsBGjZzVAYB7J Q1XS0VyiBW8iaY1lGciEqdj79jPNRSALxV4XMB0XdBsd+ewA8uKYN/R83YHI66eyzkht b1fRElVtOX47vgT2HgskR0yhxufRH/bNCpUMk= MIME-Version: 1.0 Received: by 10.52.0.4 with SMTP id 4mr634505vda.104.1301441032075; Tue, 29 Mar 2011 16:23:52 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.52.166.34 with HTTP; Tue, 29 Mar 2011 16:23:52 -0700 (PDT) In-Reply-To: References: <4672.1301340852@marajade.sandelman.ca> Date: Tue, 29 Mar 2011 16:23:52 -0700 X-Google-Sender-Auth: XZwjQhx-r_xd3BJB5jx1hnPzOoQ Message-ID: From: Zack Weinberg To: Jay Daley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] TLSA record does not mandate the given certificate X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 23:22:15 -0000 On Mon, Mar 28, 2011 at 6:27 PM, Jay Daley wrote: >>> 1. =C2=A0How is the current text in 3. not good enough? >>> >>> "If a match between one of the certificate association(s) and the >>> =C2=A0 server's end entity certificate in TLS is found, the TLS client >>> =C2=A0 continues the TLS handshake. =C2=A0If no match between the usabl= e >>> =C2=A0 certificate association(s) and the server's end entity certifica= te in >>> =C2=A0 TLS is found, the TLS client MUST abort the handshake with an >>> =C2=A0 "access_denied" error." >> >> Only in being more confusing than I would like. =C2=A0I think it's vital= to >> be crystal clear how a client should behave in all cases. > > Sorry to be a pain, but I struggle to see how this is confusing. =C2=A0Ca= n you explain? Had to think about it for a while, but my big problem with it is the "match between one of the certificate associations and the end entity certificate" language. An _association_ is a weird thing to _match_. There is also a jumble of MUST-language and non-MUST language in here ("the TLS client continues" versus "the TLS client MUST abort". >>> "A DANE client must determine whether the certificate bundle provided i= n the TLS handshake from a server found at a domain name matches a trusted = TLSA record for that domain name. =C2=A0If it does not ..." >> >> I changed the terminology (see text above this), > > I'm not sure what you are referring to. =C2=A0Did I miss some text? The "definitions" section in my proposal. The way you'd say this in my language is ... must determine whether the server's certificate bundle ... can be associated with the server's domain name by at least one of the TLSA records for that domain name ... Note how the TLSA record is not itself an "association", it's just a "record", whose effect is to _match_ one of the certificates in the in-band bundle, and thus form an association between the bundle and the _name_. In my next draft, having taken on board some of Paul Wouters' comments, I think I'll say that the association is between the _server_ and the name. zw Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E7A73A6ACC for ; Tue, 29 Mar 2011 16:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rz7P4SbQCv3W for ; Tue, 29 Mar 2011 16:07:29 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 3BC033A6AA2 for ; Tue, 29 Mar 2011 16:07:29 -0700 (PDT) Received: by vxg33 with SMTP id 33so686045vxg.31 for ; Tue, 29 Mar 2011 16:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OivyaAwOqLXLaBgR0UFGroB7gncfJzufHyyBR/0AGQY=; b=bSjGWs22Zg59kWCSmMXwEE+KfWlhuJxDBDXgv7b0/+J/nxsONPuwohtOfXtJJoJVUl y11Ilw3Xop1og4MHtdMBBfS6REP2Spr7hjiuu225/LOWmP8Tt1tywLXH8ZkPNAYz7aVh wCBLoqCizmaWDIrYkUPJIGDjaZ0yq4mh9wxf8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=p8TbrnezG8ioTO9SLrErKEdIrw08ow9XAyzs+56uKF4Ca1lJTWTNpV0pJGnBt5nB2f NdxQiVc28a4/+BZnPfZXhGaqqy3xDToaVxvct7s8W5Q6e22+H+6bzKwcx93dOFCvxTWG 98IDGJsw6hwU/0Ex5Xto8BLbs5ro24NjE3Ol0= MIME-Version: 1.0 Received: by 10.52.168.8 with SMTP id zs8mr589657vdb.184.1301440147322; Tue, 29 Mar 2011 16:09:07 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.52.166.34 with HTTP; Tue, 29 Mar 2011 16:09:07 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Mar 2011 16:09:07 -0700 X-Google-Sender-Auth: _2sHpRliOtl2r7-CbET_cv0cnCE Message-ID: From: Zack Weinberg To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] PROPOSAL: Revision of DANE client requirements X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 23:07:31 -0000 On Tue, Mar 29, 2011 at 2:24 AM, Paul Wouters wrote: > > I think the client should decide which trust models (DANE, PKIX, others) > it intends to trust. I do not think these trust models should make > statements about the other models. The original section 3 starts out > with doing this ("MUST be marked as unusable." [Paul: by DANE]) > correctly, but then later on assumes DANE trumps everything ("MUST abort > the handshake ") We disagree so profoundly that I can only conclude you have an entirely different notion of what DANE is good for than I do. Here's how I see it: The gating audience for DANE is site admins, who must be persuaded that adding TLSA records (and DNSSEC signatures) to their zones is a valuable thing for them to do. Site admins are not going to go for this pitch: "If you put TLSA records in your zone and sign it, then DANE-compliant clients will do something with that information. We can't tell you what, because we thought that policy should be up to the client. Some of your users might get some sort of security benefit out of it. Others might find themselves unable to use your site." They are much more likely to go for this pitch: "If you put TLSA records in your zone and sign it, then all DANE-compliant clients will react to those records in this predictable fashion: [....] This protects those users from these actual security threats: [....] However, if your site is ever misconfigured in this specific way: [...] then it will become inaccessible to DANE-compliant clients, so you need to make sure that your operational procedures never let that happen." Therefore, I do not think the client should decide who to trust. I think DANE needs to decide and specify that decision with as little wiggle room as possible, and I think it *especially* needs to specify what to do when DANE disagrees with other trust models (PKIX being the only such at present). And that's what I've tried to do with my revisions. >> Second, I have added constraints on client behavior based on DNSSEC >> status alone. =C2=A0This is arguably out of scope for this standard, but >> I think the additions are necessary to preserve the security benefits >> of DANE in the presence of active tampering with the DNS. > > DNSSEC should be a requirement for DANE. I thought this was already in > the 06 draft? Ah, it is in Section 3. The new requirement I added is "MUST NOT proceed with a connection to a server if the DNSSEC validation status is 'bogus' for _any_ DNS records relating to that server". The old language could be read to say that TLSA records should be _ignored_ when DNSSEC validation came back "bogus", and did not state anything about what should happen if the TLSA record was properly signed but the A record was bogus. With my wording, the only way an attacker with the power to tamper with DNS responses can downgrade a client to backward-compatible PKIX-only mode (for a server that does provide signed TLSA records) is by suppressing _all_ DNSSEC information. I think this is a valuable property. >> Section 1.2: Delete the sentence "The DNSSEC signature MUST be >> validated on all responses in order to assure the proof of origin of >> the data" and the subsequent paragraph break. =C2=A0(An equivalent, but >> more specific, requirement will reappear in section 3.) > > I think it would be good to state the relationship between DNSSEC and TLS= A > at the beginning of the draft. I agree that this sentence is not the best= , > because it kind of implies the client has to do the validation itself fro= m > the root down, and not trust the AD bit on responses received from its > (secure) connection to a validating name server, which I think is not wha= t > the authors intended. Though it is clarified in the orignal section 3. The main reason I proposed modifications to sections 1 and 2 is to _consolidate_ all requirements upon the client in section 3, for clarity's sake. I'd be okay with leaving an informative sentence early in the document along the lines of "TLSA records are only useful for security when the DNS zone they appear in is protected from tampering by DNSSEC signatures", but I want that to be redundant to normative, MUST-requirement text in section 3. ... >> =C2=A0 =C2=A0If it is desired to use other certificate >> =C2=A0 formats with this specification in the future, those formats must >> =C2=A0 be assigned their own certificate type numbers, and the definitio= n >> =C2=A0 of "associated" in section 3.1 of this specification must be revi= sed >> =C2=A0 appropriately. > > I am not sure if this is required after the previous paragraph. I wouldn't especially miss it, but equivalent language was in the -06 draft and I didn't see any harm in preserving it. > Note also that in the future, there will be other type of TLSA records no= t > involving PKIX certificates, such as those containing just bare public ke= ys. > Ideally, I would like to see a different name for "certificate type" and > call it "identifier type" or something. Then part of this text should mov= e > to the section describing the type 1 and type 2 identifiers specifically. I would support that change. However, I feel it is off-topic for this change proposal, which I would prefer to keep focused on nailing down client behavior. >> =C2=A0 The primary purpose of TLSA records is security. =C2=A0However, T= LSA >> =C2=A0 information might also be useful for protocol optimizations that >> =C2=A0 require advance knowledge of what the server's end-entity >> =C2=A0 certificate should be. =C2=A0Clients that use TLSA information on= ly for >> =C2=A0 such optimizations, and not for security decisions, are exempt >> =C2=A0 from all other requirements in this section. > > I assume you are trying to say that client/servers supporting this could > skip the exchange of PKIX information in the TLS handshake. Sort of. I was specifically thinking of snap start [ http://tools.ietf.org/html/draft-agl-tls-snapstart-00 ] when I wrote that paragraph - that perhaps having the end-entity certificate out-of-band would allow a client to do snap start on the first connection to a previously unknown server. Having reread the snap start spec, it looks like that won't work (the client needs to know several other things) and even if it did, it would be a bad idea to do it on insecure/indeterminate data. And it's off topic anyway. I will drop this part of the proposal. >> =C2=A0 Clients that make security decisions based on TLSA information >> =C2=A0 MUST be, or have access to, security-aware DNS resolvers as >> =C2=A0 defined by RFC 4033. =C2=A0The rest of this section applies only = to >> =C2=A0 such clients, which will be referred to as "DANE clients". > > This is a DANE document, you cannot really say in the above paragraph tha= t > such a client using insecure TLSA from DNSSEC is not a "DANE client". > Clients > using this draft/rfc are "DANE clients". Dropping the optimization-only text would render this moot, I think? I could just say "Clients MUST themselves be, or have secure access to, security-aware DNS resolvers" and scrap the "DANE client" wording below. >> 3.1. Definitions >> >> =C2=A0 A certificate received in the TLS handshake is said to _match_ a >> =C2=A0 TLSA record if: >> >> =C2=A0 o =C2=A0The TLSA record has reference type 0 and the certificate = from >> =C2=A0 =C2=A0 =C2=A0the handshake is byte-for-byte identical to the cert= ificate for >> =C2=A0 =C2=A0 =C2=A0association; or >> >> =C2=A0 o =C2=A0The TLSA record has some other reference type, and the ha= sh of >> =C2=A0 =C2=A0 =C2=A0the certificate from the handshake (using the hash a= lgorithm >> =C2=A0 =C2=A0 =C2=A0specified by the reference type) is byte-for-byte id= entical to >> =C2=A0 =C2=A0 =C2=A0the certificate for association. > > With my proposed TLS extension, the whole PKIX transmission could be > suppressed, but this paragraph assumes it is always sent. Do you have a link to your proposal? I'm happy to adjust the wording appropriately - the intent is just to be clear about what exactly is being "matched". > I also get > nervous about terms lie "byte for byte" since we have things like network > ordered bytes. Fair point, but the comparison function needs to be specified precisely - "identical" is not precise in my book - and pace Peter Gutmann's complaints about "memcmp() is the only way to compare PKIX certificates", I don't know a better option than "byte-for-byte". Maybe the thing to do is nail down the byte order of the certificate for association in section 2. >> =C2=A0 A certificate bundle received in the TLS handshake is said to be >> =C2=A0 _associated_ with a domain name by DANE, if a TLSA record for the >> =C2=A0 host, protocol, and port exists, the end-entity certificate in th= e >> =C2=A0 bundle contains a name record that matches the host, and: > > I see more people using wildcard certs (*.xelerance.com) which would not > match "a name record".... I'm open to suggestions for better wording here. I don't have a lot of experience with DNS wildcards _or_ certificate wildcards. >> =C2=A0 DANE clients MUST NOT proceed with a connection to a server if th= e >> =C2=A0 DNSSEC validation status is "bogus" for _any_ DNS records relatin= g >> =C2=A0 to that server. > > Don't say "connection". Say that the "DANE trust path" must be aborted. T= he > client might still do PKIX or other methods. The DANE specification shoul= d > not forbid those so it should not dictate to close the connection. On the contrary. If DANE can't dictate a connection abort it is useless, and if DANE allows a client to proceed with a connection when DNSSEC signature checks have come back "bogus", a DNS-tampering attacker can subvert it. The DANE specification _absolutely must_ dictate a connection abort under these circumstances. If equivalent wording is not in the final draft I will raise a formal objection (or whatever the appropriate term is, sorry, I know W3C procedure a lot better than IETF procedure). >> =C2=A0 DANE clients MUST ignore TLSA records whose DNSSEC validation >> =C2=A0 status is "insecure" or "indeterminate" (however, such records MA= Y >> =C2=A0 be used for TLS handshake optimizations as mentioned above). > > See above. I still don't understand this "insecure use" of TLSA. Will drop the parenthetical. Do you agree that ignoring the record is the Right Thing when DNSSEC validation comes back insecure or indeterminate? >> =C2=A0 A TLSA record whose DNSSEC status is "secure", and whose >> =C2=A0 certificate and hash types are understood by the client processin= g >> =C2=A0 it, will henceforth be referred to as a _trusted_ TLSA record. > > Again, I don't agree with a "untrusted TLSA record" concept. This is just meant to make it unambiguous, below, that records that were ignored for lack of a zone signature, or because the client doesn't understand the type codes, do not count. Maybe I should replace "trusted" with "usable"? > I think we definitely need to discuss the "no others" part. I can see > its use to ignore any bogus PKIX issued certificates, but I don't think > this should be a zone administrator decision. It should probably be a cli= ent > decision to disable PKIX or disable PKIX in the precense of DANE records. It has to be a zone administrator decision, so that the zone administrator knows the consequences of adding TLSA records to their zone (see discussion way up top). Leaving this as an application decision will only ensure that nobody uses DANE. >> =C2=A0 However, if there is any _other_ reason why a server's end-entity >> =C2=A0 certificate would have been rejected in the absence of TLSA >> =C2=A0 information, a DANE client SHOULD still reject that certificate. ... > I would say if you store full PKIX into DNS then you should ensure that > both the DNS and the PKIX information is valid, and reject it if either > one fails. That was in fact the intent of my text. How was it unclear? > Especially if a method is available where you can store the > bare public key in DNS and avoid all these conflicts. I'm good with a bare-public-key option but I will not make this proposal depend on the addition of a bare-public-key option. The WG has been arguing over bare public keys for weeks now, and I've got plenty of potential for controversy in here already, thanks. >> =C2=A0 DANE associations provide a trust anchor _only_ for end-entity >> =C2=A0 certificates, even if the TLSA record has certificate type 2. >> =C2=A0 A DANE client MUST NOT allow any non-end-entity certificate in >> =C2=A0 a certificate bundle that is anchored by a DANE association to >> =C2=A0 become trusted for any domain name other than the one in the >> =C2=A0 original association. > > This might get complicated with wildcards, both in DNS as well as in > the CN=3D or SubjectAltname=3D The intent is to trust only the end-entity cert and only for the domain name that was *queried*. Please suggest wording improvements. >> =C2=A0 DANE does not assure any information in a certificate other than >> =C2=A0 the public key and its binding to host, protocol, and port. > > This is a real problem, as clients would have to store the certificate > in their certificate pool, yet mark it was obtained by DANE and/or what > parts were validated. I was told by at least one major browser vendor > that this is a serious problem. I would say that if the entire cert > was in DANE, then DANE assures ALL the information in that certificate. > After all, the RRSIG was over the entire certificate. What I'm really going after here is the DV/EV distinction; I want to specify that DANE does _not_ provide EV. However, EV is a marketing term rather than a technical term, so it doesn't belong in a spec like this. The _effect_ of EV is, if a certificate is signed by a particular CA certificate, then more of the name fields are considered trustworthy. So by saying "does not assure any information other than ..." I was trying to specify a similar effect (or rather, the absence of a similar effect). Again, I'm open to wording improvements. >> 3.5. User override >> >> =C2=A0 DANE clients SHOULD NOT allow their human users to force the >> =C2=A0 establishment of a connection that has been aborted for any of th= e >> =C2=A0 reasons listed in sections 3.2 or 3.3. > > That's not up to the network protocol to decide. That's why it's a SHOULD rather than a MUST (and why there is a specific example of an application that might ignore the recommendation). But I think it's important to have this advice to applications in the spec, again, so that the behavior of clients is predictable - in this case, so that site admins can assume fail-hard behavior. > Even if you state it here, it will get ignored. I will be making efforts to ensure it doesn't for HTTPS (by working with browser vendors). zw Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D0AE3A6940 for ; Tue, 29 Mar 2011 08:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGCm90E4cQlo for ; Tue, 29 Mar 2011 08:08:05 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 849D03A6917 for ; Tue, 29 Mar 2011 08:08:05 -0700 (PDT) Received: by vws12 with SMTP id 12so242189vws.31 for ; Tue, 29 Mar 2011 08:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ik8segDG3bxMSMnIIA7yVuIltnzYcn1jMTSSdb58wxw=; b=XzAKTwaO0NTdSVhqcej45kDpGySAOPPCZ5sFwdhBQCty3O/44D7BKoLbG6RsSk6Hpr hjv7J1IK8rsQyKH+dZ5YWzrUhV5/qkM614UIOuLzaC8kjnR3Jvebz2Y97iHrpiUa6ofO 2X7gjnw85RRegUACvV6VyvEDCsnbaqysyZYG4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Q1crxesgxMHJ6yfF20Uycue+uR6HClVEbTIuHFdvkhzukO/ZO4al2WQVs1+uWOASoH FnWH8mB4yTyFFwQNQP6tqOpRgUz6EOFxUUWLkfZ6UgUnMgJki46o+eQVWzKndlp3IhpI Wqgb0TIjcqpF0crwmRC9NAUNfH/3QhWAHra8c= MIME-Version: 1.0 Received: by 10.52.179.69 with SMTP id de5mr1275398vdc.304.1301411355649; Tue, 29 Mar 2011 08:09:15 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.52.166.34 with HTTP; Tue, 29 Mar 2011 08:09:15 -0700 (PDT) In-Reply-To: <6B7AD439-2F88-4D8B-A58D-A32552D1E846@bbn.com> References: <4672.1301340852@marajade.sandelman.ca> <6B7AD439-2F88-4D8B-A58D-A32552D1E846@bbn.com> Date: Tue, 29 Mar 2011 08:09:15 -0700 X-Google-Sender-Auth: j88kHBoOrBZ73XWDUXAVxdKiiUs Message-ID: From: Zack Weinberg To: "Richard L. Barnes" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] TLSA record does not mandate the given certificate X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 15:08:06 -0000 On Tue, Mar 29, 2011 at 1:43 AM, Richard L. Barnes wrote: > I actually really disagree with the idea that DANE would be some parallel= , alternative path to PKIX validation. =C2=A0If DANE is going to be meaning= ful, it needs to be able to cause the TLS handshake to fail -- this is the = correct behavior when the server says (through DANE) that things should be = one way and they aren't. I concur with this. I see this as possibly *the* security benefit relative to the status quo. zw Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11D6B3A68F5 for ; Tue, 29 Mar 2011 06:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eD9A6XYF02Vn for ; Tue, 29 Mar 2011 06:35:00 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id E9CFF3A6884 for ; Tue, 29 Mar 2011 06:34:56 -0700 (PDT) Received: from [IPv6:2001:df8:0:96:221:6aff:fe5b:b80] (unknown [IPv6:2001:df8:0:96:221:6aff:fe5b:b80]) by mail.nic.cz (Postfix) with ESMTPSA id C330D2A2B5B; Tue, 29 Mar 2011 15:36:33 +0200 (CEST) Message-ID: <4D91E061.9010600@nic.cz> Date: Tue, 29 Mar 2011 15:36:33 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4D481641.6090604@nic.cz> <4D91DC2B.8060203@nic.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: keyassure@ietf.org Subject: Re: [keyassure] Administrivia: Rename the mailing list to dane@ietf.org X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 13:35:02 -0000 Either he will, or I'll take care of it. O. On 29.3.2011 15:27, Richard L. Barnes wrote: > Is the listmaster moving everyone over, or do we have to re-subscribe? > --Richard > > On Mar 29, 2011, at 3:18 PM, OndÅ™ej Surý wrote: > >> Hi, >> >> this is a reminder, that the mailing list will be renamed to the dane@ietf.org after the IETF. I already spoke to listmaster and he needs just couple of days, so I thought it might be a good idea to do that while everybody is travelling home. >> >> So, if the keyassure@ietf.org starts bouncing, use dane@ietf.org. I'll try to make sure everything else works (aka the subscriber list is the same) and I will send the announce message after the move is done. >> >> If you adjust your filters before you will not probably notice the move at all :). >> >> O. >> >> On 1.2.2011 15:18, OndÅ™ej Surý wrote: >>> Hi, >>> >>> I would like to ask the listmaster to rename the mailing list to >>> dane@ietf.org to keep it with sync with the WG name. >>> >>> Any objections? >>> >>> I'll keep you posted on the dates, etc. when I know more details. >>> >>> Ondrej >> >> >> -- >> OndÅ™ej Surý >> vedoucí výzkumu/Head of R&D department >> ------------------------------------------- >> CZ.NIC, z.s.p.o. -- LaboratoÅ™e CZ.NIC >> Americka 23, 120 00 Praha 2, Czech Republic >> mailto:ondrej.sury@nic.cz http://nic.cz/ >> tel:+420.222745110 fax:+420.222745112 >> ------------------------------------------- >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- LaboratoÅ™e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4D83A6834 for ; Tue, 29 Mar 2011 06:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.099 X-Spam-Level: X-Spam-Status: No, score=-102.099 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkJcey9CyDWZ for ; Tue, 29 Mar 2011 06:25:58 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 4BEBD3A6824 for ; Tue, 29 Mar 2011 06:25:57 -0700 (PDT) Received: from [128.89.255.104] (port=54155 helo=[130.129.71.95]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q4YxK-0005e2-To; Tue, 29 Mar 2011 09:27:35 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=utf-8 From: "Richard L. Barnes" In-Reply-To: <4D91DC2B.8060203@nic.cz> Date: Tue, 29 Mar 2011 15:27:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D481641.6090604@nic.cz> <4D91DC2B.8060203@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Administrivia: Rename the mailing list to dane@ietf.org X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 13:25:59 -0000 Is the listmaster moving everyone over, or do we have to re-subscribe? --Richard On Mar 29, 2011, at 3:18 PM, Ond=C5=99ej Sur=C3=BD wrote: > Hi, >=20 > this is a reminder, that the mailing list will be renamed to the = dane@ietf.org after the IETF. I already spoke to listmaster and he = needs just couple of days, so I thought it might be a good idea to do = that while everybody is travelling home. >=20 > So, if the keyassure@ietf.org starts bouncing, use dane@ietf.org. = I'll try to make sure everything else works (aka the subscriber list is = the same) and I will send the announce message after the move is done. >=20 > If you adjust your filters before you will not probably notice the = move at all :). >=20 > O. >=20 > On 1.2.2011 15:18, Ond=C5=99ej Sur=C3=BD wrote: >> Hi, >>=20 >> I would like to ask the listmaster to rename the mailing list to >> dane@ietf.org to keep it with sync with the WG name. >>=20 >> Any objections? >>=20 >> I'll keep you posted on the dates, etc. when I know more details. >>=20 >> Ondrej >=20 >=20 > --=20 > Ond=C5=99ej Sur=C3=BD > vedouc=C3=AD v=C3=BDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FC2F3A67C3 for ; Tue, 29 Mar 2011 06:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhPRxsBaGqFf for ; Tue, 29 Mar 2011 06:16:58 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 0DF903A6784 for ; Tue, 29 Mar 2011 06:16:58 -0700 (PDT) Received: from [IPv6:2001:df8:0:96:221:6aff:fe5b:b80] (unknown [IPv6:2001:df8:0:96:221:6aff:fe5b:b80]) by mail.nic.cz (Postfix) with ESMTPSA id A47792A0AB4 for ; Tue, 29 Mar 2011 15:18:35 +0200 (CEST) Message-ID: <4D91DC2B.8060203@nic.cz> Date: Tue, 29 Mar 2011 15:18:35 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Thunderbird/3.1.9 MIME-Version: 1.0 To: keyassure@ietf.org References: <4D481641.6090604@nic.cz> In-Reply-To: <4D481641.6090604@nic.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [keyassure] Administrivia: Rename the mailing list to dane@ietf.org X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 13:16:59 -0000 Hi, this is a reminder, that the mailing list will be renamed to the dane@ietf.org after the IETF. I already spoke to listmaster and he needs just couple of days, so I thought it might be a good idea to do that while everybody is travelling home. So, if the keyassure@ietf.org starts bouncing, use dane@ietf.org. I'll try to make sure everything else works (aka the subscriber list is the same) and I will send the announce message after the move is done. If you adjust your filters before you will not probably notice the move at all :). O. On 1.2.2011 15:18, OndÅ™ej Surý wrote: > Hi, > > I would like to ask the listmaster to rename the mailing list to > dane@ietf.org to keep it with sync with the WG name. > > Any objections? > > I'll keep you posted on the dates, etc. when I know more details. > > Ondrej -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- LaboratoÅ™e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F81028C137 for ; Tue, 29 Mar 2011 02:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZNDIKm0RRT7 for ; Tue, 29 Mar 2011 02:22:33 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 3DF913A6947 for ; Tue, 29 Mar 2011 02:22:33 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 96024C5A0; Tue, 29 Mar 2011 05:24:10 -0400 (EDT) Date: Tue, 29 Mar 2011 05:24:09 -0400 (EDT) From: Paul Wouters To: Zack Weinberg In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] PROPOSAL: Revision of DANE client requirements X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 09:22:36 -0000 On Mon, 28 Mar 2011, Zack Weinberg wrote: > The exceptions are: First, it is not clear to me whether the present > intent of the spec is that a TLSA record for site S specifying > certificate X forbids a compliant client from proceeding with the > handshake if it receives certificate Y. I think the answer to this > question must be an unambiguous "yes", and I have made changes to that > effect in my edits. If the answer is meant to be "no", then I will > have to raise a formal objection, because that would IMHO mean that > DANE provided no improvements over the status quo. I think the client should decide which trust models (DANE, PKIX, others) it intends to trust. I do not think these trust models should make statements about the other models. The original section 3 starts out with doing this ("MUST be marked as unusable." [Paul: by DANE]) correctly, but then later on assumes DANE trumps everything ("MUST abort the handshake ") > Second, I have added constraints on client behavior based on DNSSEC > status alone. This is arguably out of scope for this standard, but > I think the additions are necessary to preserve the security benefits > of DANE in the presence of active tampering with the DNS. DNSSEC should be a requirement for DANE. I thought this was already in the 06 draft? Ah, it is in Section 3. > Third, I have added text about a potential non-security use of TLSA > records -- to enable TLS handshake optimizations -- and about user > override of TLSA-based rejection of a certificate. These were not > addressed in the current draft, but I believe they add value. > Section 1.2: Delete the sentence "The DNSSEC signature MUST be > validated on all responses in order to assure the proof of origin of > the data" and the subsequent paragraph break. (An equivalent, but > more specific, requirement will reappear in section 3.) I think it would be good to state the relationship between DNSSEC and TLSA at the beginning of the draft. I agree that this sentence is not the best, because it kind of implies the client has to do the validation itself from the root down, and not trust the AD bit on responses received from its (secure) connection to a validating name server, which I think is not what the authors intended. Though it is clarified in the orignal section 3. > Section 1.3: Delete the entire second paragraph. Agreed. My reasoning being that DANE should not exlucde PKIX (just like PKIX should not be allowed to exclude DANE). This should be a client choice. See above on the contraction in the original section 3. > Section 2.2: Replace the paragraph that begins "Both types are > structured ..." with this text: > > Certificates of type 1 and 2 MUST be in PKIX format: that is, they > must be structured according to the formatting rules in RFC 5280, > and encoded using ASN.1 DER. However, as described in section 3.4, > type 1 certificates do not need to adhere to all the semantic > rules in RFC 5280. This sounds okay. > If it is desired to use other certificate > formats with this specification in the future, those formats must > be assigned their own certificate type numbers, and the definition > of "associated" in section 3.1 of this specification must be revised > appropriately. I am not sure if this is required after the previous paragraph. Note also that in the future, there will be other type of TLSA records not involving PKIX certificates, such as those containing just bare public keys. Ideally, I would like to see a different name for "certificate type" and call it "identifier type" or something. Then part of this text should move to the section describing the type 1 and type 2 identifiers specifically. > Section 3: Replace entire section with this text: > > 3. Client application behavior in the presence of TLSA records > > The primary purpose of TLSA records is security. However, TLSA > information might also be useful for protocol optimizations that > require advance knowledge of what the server's end-entity > certificate should be. Clients that use TLSA information only for > such optimizations, and not for security decisions, are exempt > from all other requirements in this section. I assume you are trying to say that client/servers supporting this could skip the exchange of PKIX information in the TLS handshake. In fact, that is pretty much what my draft for "TLS Extensions for out of bound public key validation" adds an option for. However, the above paragraph stating something like "you can use this info but not treat it as secure" makes me very nervous. I would be uncomfortable introducing a concept of "insecurely obtaining TLS public keys from DNS". My TLS extension draft addresses this by saying the TLS client could have cached the TLS public key from a previous handshake or have obtained this via another secure(!) method like DANE or LDAP. > Clients that make security decisions based on TLSA information > MUST be, or have access to, security-aware DNS resolvers as > defined by RFC 4033. The rest of this section applies only to > such clients, which will be referred to as "DANE clients". This is a DANE document, you cannot really say in the above paragraph that such a client using insecure TLSA from DNSSEC is not a "DANE client". Clients using this draft/rfc are "DANE clients". > 3.1. Definitions > > A certificate received in the TLS handshake is said to _match_ a > TLSA record if: > > o The TLSA record has reference type 0 and the certificate from > the handshake is byte-for-byte identical to the certificate for > association; or > > o The TLSA record has some other reference type, and the hash of > the certificate from the handshake (using the hash algorithm > specified by the reference type) is byte-for-byte identical to > the certificate for association. With my proposed TLS extension, the whole PKIX transmission could be suppressed, but this paragraph assumes it is always sent. I also get nervous about terms lie "byte for byte" since we have things like network ordered bytes. > A certificate bundle received in the TLS handshake is said to be > _associated_ with a domain name by DANE, if a TLSA record for the > host, protocol, and port exists, the end-entity certificate in the > bundle contains a name record that matches the host, and: I see more people using wildcard certs (*.xelerance.com) which would not match "a name record".... > o The TLSA record has certificate type 1, and it matches the > end-entity certificate in the bundle; or > > o The TLSA record has certificate type 2, it matches one of the > non-end-entity certificates in the bundle, and the end-entity > certificate in the bundle has a valid chain to the certificate > that matched the TLSA record. > > 3.2. DNSSEC validation > > DANE clients MUST NOT proceed with a connection to a server if the > DNSSEC validation status is "bogus" for _any_ DNS records relating > to that server. Don't say "connection". Say that the "DANE trust path" must be aborted. The client might still do PKIX or other methods. The DANE specification should not forbid those so it should not dictate to close the connection. > DANE clients MUST ignore TLSA records whose DNSSEC validation > status is "insecure" or "indeterminate" (however, such records MAY > be used for TLS handshake optimizations as mentioned above). See above. I still don't understand this "insecure use" of TLSA. Either you obtained it securely outside of DANE to use, in which case DANE does not apply, or you only got it via DANE, in which case you should not use it if it was not secured. One DoS attack I could imagine here is spoofing bogus DANE records and the client trying to "optimise" to the server and botching the TLS handshake repeatedly. > DANE clients MUST also ignore TLSA records whose certificate type > or hash type they do not understand. > > A TLSA record whose DNSSEC status is "secure", and whose > certificate and hash types are understood by the client processing > it, will henceforth be referred to as a _trusted_ TLSA record. Again, I don't agree with a "untrusted TLSA record" concept. > 3.3. DANE validation > > The presence in the DNS of a trusted TLSA record is an assertion > by the zone administrator that the legitimate server(s) for that > host, protocol, and port will use certificate bundles that can be > associated with the domain name by that record (as defined in > section 3.1), and no others. I think we definitely need to discuss the "no others" part. I can see its use to ignore any bogus PKIX issued certificates, but I don't think this should be a zone administrator decision. It should probably be a client decision to disable PKIX or disable PKIX in the precense of DANE records. > However, if there is any _other_ reason why a server's end-entity > certificate would have been rejected in the absence of TLSA > information, a DANE client SHOULD still reject that certificate. This is the fundamental problem of storing things like "Validity" of the PKIX into a DNS record with a validatity based on TTL/RRSIG lifetimes. This is also why I am writing the DANE public key draft, which has as one of its goals not to add possibly contradicting information from PKIX into DNS. I would say if you store full PKIX into DNS then you should ensure that both the DNS and the PKIX information is valid, and reject it if either one fails. Especially if a method is available where you can store the bare public key in DNS and avoid all these conflicts. One of the advantages of DANE is you can put your public key in DNS and forget about things like re-signing your certificate and expiration. > For instance, if a certificate anywhere in the server's bundle has > expired or has been revoked by its issuing CA, a DANE client > SHOULD reject the end-entity certificate, even if the TLSA record > matches a point in the chain before the invalid certificate. Should it? I am not sure I agree (or disagree) If we have a bare public key option, then I can agree with this, as anyone who cares can then pub just the pubkey in DNS and then for compat reasons (or other) keep a valid PKIX on the server as well. > DANE associations provide a trust anchor _only_ for end-entity > certificates, even if the TLSA record has certificate type 2. > A DANE client MUST NOT allow any non-end-entity certificate in > a certificate bundle that is anchored by a DANE association to > become trusted for any domain name other than the one in the > original association. This might get complicated with wildcards, both in DNS as well as in the CN= or SubjectAltname= > DANE does not assure any information in a certificate other than > the public key and its binding to host, protocol, and port. This is a real problem, as clients would have to store the certificate in their certificate pool, yet mark it was obtained by DANE and/or what parts were validated. I was told by at least one major browser vendor that this is a serious problem. I would say that if the entire cert was in DANE, then DANE assures ALL the information in that certificate. After all, the RRSIG was over the entire certificate. And again, this assumes the alternative of bare public keys in DANE exist for those who only want to assure the port/transport/name and public key. > Most importantly, DANE does _not_ assure any non-DNS name records. How is an implementation supposed to keep track? I would strongly suggest people who desire this should use bare public keys in DANE instead. > 3.5. User override > > DANE clients SHOULD NOT allow their human users to force the > establishment of a connection that has been aborted for any of the > reasons listed in sections 3.2 or 3.3. That's not up to the network protocol to decide. Leave that up to the application developers to deal with. Even if you state it here, it will get ignored. But I don't think the protocol should tell me how much I should trust it. Just like I want to decide how much to trust (or not) PKIX, I will decide how much to trust DANE. That not every enduser can make an informative decision is something the application people are much better suited to address properly then network protocol engineers. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1C873A6ABE for ; Tue, 29 Mar 2011 01:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiXhGBPfbEpW for ; Tue, 29 Mar 2011 01:41:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 11DC23A6948 for ; Tue, 29 Mar 2011 01:41:43 -0700 (PDT) Received: from [128.89.255.146] (port=52765 helo=[130.129.17.55]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q4UWC-000H8I-0E; Tue, 29 Mar 2011 04:43:16 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Tue, 29 Mar 2011 10:43:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6B7AD439-2F88-4D8B-A58D-A32552D1E846@bbn.com> References: <4672.1301340852@marajade.sandelman.ca> To: Paul Wouters X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] TLSA record does not mandate the given certificate X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 08:41:44 -0000 I actually really disagree with the idea that DANE would be some = parallel, alternative path to PKIX validation. If DANE is going to be = meaningful, it needs to be able to cause the TLS handshake to fail -- = this is the correct behavior when the server says (through DANE) that = things should be one way and they aren't. The relationship between DANE and PKIX is one of the topics for = discussion at the DANE meeting tomorrow. As I'll present (in a = discussion too long for this email), they can actually work together = very naturally. --Richard On Mar 29, 2011, at 10:34 AM, Paul Wouters wrote: > On Tue, 29 Mar 2011, Jay Daley wrote: >=20 >> Two questions: >>=20 >> 1. How is the current text in 3. not good enough? >>=20 >> "If a match between one of the certificate association(s) and the >> server's end entity certificate in TLS is found, the TLS client >> continues the TLS handshake. If no match between the usable >> certificate association(s) and the server's end entity certificate = in >> TLS is found, the TLS client MUST abort the handshake with an >> "access_denied" error." >=20 > I am assuming we will see deployment of DANE and PKIX alongside, > where there might be contradictions or discrepancies between these two > (or even other methods of obtaining this information out of band). I > think what should be stated is that the "DANE validation path" should > be aborted. We should not dictate to abort the TLS handshake. It would > be up to a client/browser to implement one or more trust anchor = methods > (PKIX, DANE, LDAP, caching) and decide to abort the TLS handhshake = only > after all its trusted methods have failed. >=20 > Paul >=20 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17513A6948 for ; Tue, 29 Mar 2011 01:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xy0wC4LEil38 for ; Tue, 29 Mar 2011 01:33:13 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id AD7C83A6873 for ; Tue, 29 Mar 2011 01:33:13 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 5E36CC59D; Tue, 29 Mar 2011 04:34:49 -0400 (EDT) Date: Tue, 29 Mar 2011 04:34:49 -0400 (EDT) From: Paul Wouters To: Jay Daley In-Reply-To: Message-ID: References: <4672.1301340852@marajade.sandelman.ca> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] TLSA record does not mandate the given certificate X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 08:33:14 -0000 On Tue, 29 Mar 2011, Jay Daley wrote: > Two questions: > > 1. How is the current text in 3. not good enough? > > "If a match between one of the certificate association(s) and the > server's end entity certificate in TLS is found, the TLS client > continues the TLS handshake. If no match between the usable > certificate association(s) and the server's end entity certificate in > TLS is found, the TLS client MUST abort the handshake with an > "access_denied" error." I am assuming we will see deployment of DANE and PKIX alongside, where there might be contradictions or discrepancies between these two (or even other methods of obtaining this information out of band). I think what should be stated is that the "DANE validation path" should be aborted. We should not dictate to abort the TLS handshake. It would be up to a client/browser to implement one or more trust anchor methods (PKIX, DANE, LDAP, caching) and decide to abort the TLS handhshake only after all its trusted methods have failed. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB9F828C143 for ; Mon, 28 Mar 2011 18:26:21 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNqBytHCxEYh for ; Mon, 28 Mar 2011 18:26:20 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id A70AE28C142 for ; Mon, 28 Mar 2011 18:26:20 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id CA0082DAA91; Tue, 29 Mar 2011 14:28:01 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ria7SDW-zkMY; Tue, 29 Mar 2011 14:28:01 +1300 (NZDT) Received: from [192.168.22.200] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 981842DA68E; Tue, 29 Mar 2011 14:28:01 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: Date: Tue, 29 Mar 2011 14:27:57 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4672.1301340852@marajade.sandelman.ca> To: Zack Weinberg X-Mailer: Apple Mail (2.1084) Cc: keyassure@ietf.org Subject: Re: [keyassure] TLSA record does not mandate the given certificate X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 01:26:21 -0000 On 29/03/2011, at 2:02 PM, Zack Weinberg wrote: > On Mon, Mar 28, 2011 at 5:39 PM, Jay Daley wrote: >>=20 >> Two questions: >>=20 >> 1. How is the current text in 3. not good enough? >>=20 >> "If a match between one of the certificate association(s) and the >> server's end entity certificate in TLS is found, the TLS client >> continues the TLS handshake. If no match between the usable >> certificate association(s) and the server's end entity certificate = in >> TLS is found, the TLS client MUST abort the handshake with an >> "access_denied" error." >=20 > Only in being more confusing than I would like. I think it's vital to > be crystal clear how a client should behave in all cases. Sorry to be a pain, but I struggle to see how this is confusing. Can = you explain? > By highlighting this text you reassure me that my changes to emphasize > the exclusivity properties of TLSA really are editorial, though, so > that's a relief. Good. >> 2. Assuming there is a problem with that text and your replacement = text is needed, then shouldn't this be more explicit about multiple TLSA = records? (And also use correct terminology) >>=20 >> "A DANE client must determine whether the certificate bundle provided = in the TLS handshake from a server found at a domain name matches a = trusted TLSA record for that domain name. If it does not ..." >=20 > I changed the terminology (see text above this), I'm not sure what you are referring to. Did I miss some text? Jay > again, to reduce > confusion. An entire certificate bundle does not match anything > anymore, it can only be associated. Only single certificates match. >=20 > You're right, though, I forgot to consider the case of multiple TLSA > records. I'll need to tweak wording throughout to fix that, I think. >=20 > zw --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E2CC3A6AA9 for ; Mon, 28 Mar 2011 18:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.727 X-Spam-Level: X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esrfcfIUV413 for ; Mon, 28 Mar 2011 18:00:55 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 75E7128C0E7 for ; Mon, 28 Mar 2011 18:00:55 -0700 (PDT) Received: by vws12 with SMTP id 12so3230824vws.31 for ; Mon, 28 Mar 2011 18:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SCrbzeJH2NYFEILo2BiHHQCVLul4j4eiaVNVlVxd7N4=; b=VMhBcrp82X24ojOitA+9yfNwFRwa3rkNiah96rZ3xnfeItkIPVT0B9rqSaaolFhQTR csJC5Wwiidmmuy1wP4Z++QFBr6lln2KL+d74DmBVRCO6ZReTts4djotGYu/jvS13T1G3 oKv3hNMD9JaCCHRLXqqjFHsfKlq6FNB6QsPQ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=MP0vc33VWglLADE4fbgtsXM0JEzwwZ/FHfmm5xTB2XpIT29F0NdSm4ZmA1GfBqTm98 i6J9IAWQjyX8fR5Chg36Byv6FED+GxqAgVX4wo9OW5pvqlEUMIXx/qI8mB2fqDaCFf6w dI3ob/4R7nTt5YACumHBfBLpY2FSjrYuIoLKs= MIME-Version: 1.0 Received: by 10.52.18.102 with SMTP id v6mr5630657vdd.224.1301360550821; Mon, 28 Mar 2011 18:02:30 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.52.166.34 with HTTP; Mon, 28 Mar 2011 18:02:30 -0700 (PDT) In-Reply-To: References: <4672.1301340852@marajade.sandelman.ca> Date: Mon, 28 Mar 2011 18:02:30 -0700 X-Google-Sender-Auth: GyePyGpsYgLnzw4KZh-9CLsSnew Message-ID: From: Zack Weinberg To: Jay Daley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] TLSA record does not mandate the given certificate X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 01:00:56 -0000 On Mon, Mar 28, 2011 at 5:39 PM, Jay Daley wrote: > > Two questions: > > 1. =C2=A0How is the current text in 3. not good enough? > > "If a match between one of the certificate association(s) and the > =C2=A0 server's end entity certificate in TLS is found, the TLS client > =C2=A0 continues the TLS handshake. =C2=A0If no match between the usable > =C2=A0 certificate association(s) and the server's end entity certificate= in > =C2=A0 TLS is found, the TLS client MUST abort the handshake with an > =C2=A0 "access_denied" error." Only in being more confusing than I would like. I think it's vital to be crystal clear how a client should behave in all cases. By highlighting this text you reassure me that my changes to emphasize the exclusivity properties of TLSA really are editorial, though, so that's a relief. > 2. =C2=A0Assuming there is a problem with that text and your replacement = text is needed, then shouldn't this be more explicit about multiple TLSA re= cords? (And also use correct terminology) > > "A DANE client must determine whether the certificate bundle provided in = the TLS handshake from a server found at a domain name matches a trusted TL= SA record for that domain name. =C2=A0If it does not ..." I changed the terminology (see text above this), again, to reduce confusion. An entire certificate bundle does not match anything anymore, it can only be associated. Only single certificates match. You're right, though, I forgot to consider the case of multiple TLSA records. I'll need to tweak wording throughout to fix that, I think. zw Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E01E83A6A97 for ; Mon, 28 Mar 2011 17:38:17 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoxLzC5IKIv1 for ; Mon, 28 Mar 2011 17:38:17 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id E5C8A3A6A90 for ; Mon, 28 Mar 2011 17:38:16 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 7C1162DA68E; Tue, 29 Mar 2011 13:39:57 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOH4rgTJGq3b; Tue, 29 Mar 2011 13:39:57 +1300 (NZDT) Received: from [192.168.22.200] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 295962DA2EB; Tue, 29 Mar 2011 13:39:57 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: Date: Tue, 29 Mar 2011 13:39:52 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4672.1301340852@marajade.sandelman.ca> To: Zack Weinberg X-Mailer: Apple Mail (2.1084) Cc: keyassure@ietf.org Subject: Re: [keyassure] TLSA record does not mandate the given certificate X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 00:38:18 -0000 On 29/03/2011, at 10:01 AM, Zack Weinberg wrote: >> Zack> The presence in the DNS of a trusted TLSA record is an = assertion >> Zack> by the zone administrator that the legitimate server(s) for = that >> Zack> host, protocol, and port will use certificate bundles that = can be >> Zack> associated with the domain name by that record (as defined = in >> Zack> section 3.1), and no others. >>=20 >> Zack> Therefore, a DANE client in possession of a trusted TLSA = record >> Zack> for a server MUST determine whether that TLSA record = associates >> Zack> the server's domain name with the certificate bundle it = provides >> Zack> in the TLS handshake. If it does not, a DANE client MUST = reject >> Zack> the end-entity certificate and abort the TLS handshake with = an >> Zack> "access_denied" error. This rule applies even if the = end-entity >> Zack> certificate would have been trusted in the absence of the = TLSA >> Zack> record. >=20 > If it's not, please let me know how I could improve it. Two questions: 1. How is the current text in 3. not good enough? "If a match between one of the certificate association(s) and the server's end entity certificate in TLS is found, the TLS client continues the TLS handshake. If no match between the usable certificate association(s) and the server's end entity certificate in TLS is found, the TLS client MUST abort the handshake with an "access_denied" error." 2. Assuming there is a problem with that text and your replacement text = is needed, then shouldn't this be more explicit about multiple TLSA = records? (And also use correct terminology) "A DANE client must determine whether the certificate bundle provided in = the TLS handshake from a server found at a domain name matches a trusted = TLSA record for that domain name. If it does not ..." Jay >=20 > zw > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62DDF28C0F0 for ; Mon, 28 Mar 2011 13:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUUOXmFIksJA for ; Mon, 28 Mar 2011 13:59:49 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 6D8D43A693D for ; Mon, 28 Mar 2011 13:59:49 -0700 (PDT) Received: by vxg33 with SMTP id 33so3098644vxg.31 for ; Mon, 28 Mar 2011 14:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=O1W18n+OkWnwMCY0e2EwAUl1zuwTWaTHhLsJmRQ17VU=; b=fNmaZxJQuNaOCgBzL2Ds0um9cBj2ty+FSBkcp8F41XeratohSVoKEOI9K46Gvu0v72 xbcCdz3tELzmOAbIrKuVLt65VNtxmhem5R17Z64rJZTZTAJakB0Wd2uDKcdP072JJoh3 79J0DgJE8r8xHRlicoN821/CwUgxEn1REOYVo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=EqQQAy1s00uDPGGCjRovN3fdxIov/otS5vweGoU7FsmyXr9aKyIIWiQFzSQ8Luatrt MXFRpcJ/YpdnUVlZ3ac0wVCi5xJrBM/t7Tjc13j4queQccDzznFEN41LG/dW5Zk47nQ6 PhyKPRGE9v4eRrPprh/JEorjGwRftDC9hPIxk= MIME-Version: 1.0 Received: by 10.52.74.226 with SMTP id x2mr6231387vdv.264.1301346086795; Mon, 28 Mar 2011 14:01:26 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.52.166.34 with HTTP; Mon, 28 Mar 2011 14:01:26 -0700 (PDT) In-Reply-To: <4672.1301340852@marajade.sandelman.ca> References: <4672.1301340852@marajade.sandelman.ca> Date: Mon, 28 Mar 2011 14:01:26 -0700 X-Google-Sender-Auth: FjOp-KjJ7MkFzssRStlgu6gXyA8 Message-ID: From: Zack Weinberg To: Michael Richardson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] TLSA record does not mandate the given certificate X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 20:59:50 -0000 On Mon, Mar 28, 2011 at 12:34 PM, Michael Richardson wro= te: > > {I think you should start three threads for your three proposals} It is one proposal. I could split out the additional text about non-security use, but apart from that, it doesn't make sense to try to break up the changes. > I can't parse "yes"/"no" in the above sentence. > Do you mean: > > =C2=A0A TLSA record for site S specifying certificate X forbids a complia= nt > =C2=A0client from proceeding with the handshake if it receives certificat= e Y. > > or do you mean to object to this statement? =C2=A0I think you mean to sup= port > it but I couldn't tell from the overview, and only from the text you supp= lied. I mean to support it. This is meant to be clear from this text of the prop= osal: > =C2=A0 =C2=A0Zack> The presence in the DNS of a trusted TLSA record is an= assertion > =C2=A0 =C2=A0Zack> by the zone administrator that the legitimate server(s= ) for that > =C2=A0 =C2=A0Zack> host, protocol, and port will use certificate bundles = that can be > =C2=A0 =C2=A0Zack> associated with the domain name by that record (as def= ined in > =C2=A0 =C2=A0Zack> section 3.1), and no others. > > =C2=A0 =C2=A0Zack> Therefore, a DANE client in possession of a trusted TL= SA record > =C2=A0 =C2=A0Zack> for a server MUST determine whether that TLSA record a= ssociates > =C2=A0 =C2=A0Zack> the server's domain name with the certificate bundle i= t provides > =C2=A0 =C2=A0Zack> in the TLS handshake. =C2=A0If it does not, a DANE cli= ent MUST reject > =C2=A0 =C2=A0Zack> the end-entity certificate and abort the TLS handshake= with an > =C2=A0 =C2=A0Zack> "access_denied" error. =C2=A0This rule applies even if= the end-entity > =C2=A0 =C2=A0Zack> certificate would have been trusted in the absence of = the TLSA > =C2=A0 =C2=A0Zack> record. If it's not, please let me know how I could improve it. zw Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8938F3A68F2 for ; Mon, 28 Mar 2011 12:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.025 X-Spam-Level: X-Spam-Status: No, score=-1.025 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsEVRUrkR3RD for ; Mon, 28 Mar 2011 12:31:45 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 0BBF33A686E for ; Mon, 28 Mar 2011 12:31:44 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [85.162.122.65]) by relay.sandelman.ca (Postfix) with ESMTPS id 91E1E34074; Mon, 28 Mar 2011 15:33:21 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 62E3D98B18; Mon, 28 Mar 2011 21:34:12 +0200 (CEST) From: Michael Richardson To: keyassure@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 22) Date: Mon, 28 Mar 2011 21:34:12 +0200 Message-ID: <4672.1301340852@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [keyassure] TLSA record does not mandate the given certificate X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 19:31:46 -0000 {I think you should start three threads for your three proposals} >>>>> "Zack" == Zack Weinberg writes: Zack> The exceptions are: First, it is not clear to me whether the present Zack> intent of the spec is that a TLSA record for site S specifying Zack> certificate X forbids a compliant client from proceeding with the Zack> handshake if it receives certificate Y. I think the answer to this Zack> question must be an unambiguous "yes", and I have made changes Zack> to that effect in my edits. If the answer is meant to be Zack> "no", then I will have to raise a formal objection, because Zack> that would IMHO mean that Zack> DANE provided no improvements over the status quo. I can't parse "yes"/"no" in the above sentence. Do you mean: A TLSA record for site S specifying certificate X forbids a compliant client from proceeding with the handshake if it receives certificate Y. or do you mean to object to this statement? I think you mean to support it but I couldn't tell from the overview, and only from the text you supplied. Zack> o The TLSA record has certificate type 1, and it matches the Zack> end-entity certificate in the bundle; or Zack> o The TLSA record has certificate type 2, it matches one of the Zack> non-end-entity certificates in the bundle, and the end-entity Zack> certificate in the bundle has a valid chain to the certificate Zack> that matched the TLSA record. ... Zack> 3.3. DANE validation Zack> The presence in the DNS of a trusted TLSA record is an assertion Zack> by the zone administrator that the legitimate server(s) for that Zack> host, protocol, and port will use certificate bundles that can be Zack> associated with the domain name by that record (as defined in Zack> section 3.1), and no others. Zack> Therefore, a DANE client in possession of a trusted TLSA record Zack> for a server MUST determine whether that TLSA record associates Zack> the server's domain name with the certificate bundle it provides Zack> in the TLS handshake. If it does not, a DANE client MUST reject Zack> the end-entity certificate and abort the TLS handshake with an Zack> "access_denied" error. This rule applies even if the end-entity Zack> certificate would have been trusted in the absence of the TLSA Zack> record. Zack> Conversely, if the TLSA record _does_ associate the server's Zack> certificate bundle with its domain name, a DANE client MUST treat Zack> the end-entity certificate as possessing a valid chain to a trust Zack> anchor, until the TTL of the TLSA record expires. In other words, Zack> under these circumstances a DANE client MUST NOT reject a server's Zack> end-entity certificate solely for lack of a trust anchor. Zack> Furthermore, if the TLSA record providing the association has Zack> certificate type 1, a DANE client MUST NOT reject an end-entity Zack> certificate for violation of the PKIX rules that are relaxed by Zack> section 3.4 of this specification. Zack> However, if there is any _other_ reason why a server's end-entity Zack> certificate would have been rejected in the absence of TLSA Zack> information, a DANE client SHOULD still reject that certificate. Zack> For instance, if a certificate anywhere in the server's bundle has Zack> expired or has been revoked by its issuing CA, a DANE client Zack> SHOULD reject the end-entity certificate, even if the TLSA record Zack> matches a point in the chain before the invalid certificate. Zack> DANE associations provide a trust anchor _only_ for end-entity Zack> certificates, even if the TLSA record has certificate type 2. Zack> A DANE client MUST NOT allow any non-end-entity certificate in Zack> a certificate bundle that is anchored by a DANE association to Zack> become trusted for any domain name other than the one in the Zack> original association. Zack> DANE does not assure any information in a certificate other than Zack> the public key and its binding to host, protocol, and port. Most Zack> importantly, DANE does _not_ assure any non-DNS name records. I like your text. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 934E23A6842 for ; Mon, 28 Mar 2011 09:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZonjedNPsAC for ; Mon, 28 Mar 2011 09:45:22 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id EF2253A659C for ; Mon, 28 Mar 2011 09:45:21 -0700 (PDT) Received: by vws12 with SMTP id 12so2846213vws.31 for ; Mon, 28 Mar 2011 09:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=wjUxgsYqBt0IPfkMIfs9tmUCassioDJC9zRSwkV7V20=; b=NNmUT697g35fugaQ7QsHYvi3hHs8dr8cyVLCdOZeA8rK2MTCIbCyurxOz10PW/8Z57 YLm1+1Tdft3D/mUt8zSCmllPOWyUFSzyK0Qdw1a5u+2qQoq7WGyQOb1Ya3CFVHwZLkBG 1yZFVyKVSQ3x+tzJKXnYyb4CiHVAGp7X7tVWY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=RzGn7PXKILoqHT8e4JrOqZPHKvTfRcpylMz7kHwwunNa89dFiHd/LWAnZ923MfUrxZ tna63WaXMwJx34bk3DfkKwT18NBWPx7w0SlrQvMCd6DD4O1eqDDZ9eY0jwwPGlJPeRaS QR/WXX2xusj47HrBnFAKS38Lk3q0AuGRm0j/8= MIME-Version: 1.0 Received: by 10.52.18.103 with SMTP id v7mr5952516vdd.64.1301330810283; Mon, 28 Mar 2011 09:46:50 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.52.166.34 with HTTP; Mon, 28 Mar 2011 09:46:50 -0700 (PDT) Date: Mon, 28 Mar 2011 09:46:50 -0700 X-Google-Sender-Auth: MJ3fvkE7jFdy1zuvqj3XpFQEXQs Message-ID: From: Zack Weinberg To: keyassure@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [keyassure] PROPOSAL: Revision of DANE client requirements X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 16:45:23 -0000 I'd like to propose some revisions to the text of DANE. Specifically, I want to make the requirements upon TLS clients that implement the spec clearer, and I also want to consolidate them in one place. The current draft (http://tools.ietf.org/html/draft-ietf-dane-protocol-06) scatters client requirements all around the text, and it is IMO a bit too vague about exactly what *is* a requirement. I want to avoid a situation where not all clients interpret TLSA records the same way, and I also want to avoid a situation where a site administrator might be confused about the effects of adding TLSA records to their zones. With a few exceptions, I believe all my proposed changes are strictly editorial -- that is, I have not removed or added any requirements upon TLS clients, I have just made it clearer what they are. The exceptions are: First, it is not clear to me whether the present intent of the spec is that a TLSA record for site S specifying certificate X forbids a compliant client from proceeding with the handshake if it receives certificate Y. I think the answer to this question must be an unambiguous "yes", and I have made changes to that effect in my edits. If the answer is meant to be "no", then I will have to raise a formal objection, because that would IMHO mean that DANE provided no improvements over the status quo. Second, I have added constraints on client behavior based on DNSSEC status alone. This is arguably out of scope for this standard, but I think the additions are necessary to preserve the security benefits of DANE in the presence of active tampering with the DNS. Third, I have added text about a potential non-security use of TLSA records -- to enable TLS handshake optimizations -- and about user override of TLSA-based rejection of a certificate. These were not addressed in the current draft, but I believe they add value. I am speaking as a security researcher and as a Web browser implementor. I am not speaking on behalf of any other individual or organization; however, I have received positive feedback on earlier drafts of these edits from other browser implementors. Thanks for your attention, zw ---- proposal begins ---- Section 1.2: Delete the sentence "The DNSSEC signature MUST be validated on all responses in order to assure the proof of origin of the data" and the subsequent paragraph break. (An equivalent, but more specific, requirement will reappear in section 3.) Section 1.3: Delete the entire second paragraph. Section 2.2: Replace the paragraph that begins "Both types are structured ..." with this text: Certificates of type 1 and 2 MUST be in PKIX format: that is, they must be structured according to the formatting rules in RFC 5280, and encoded using ASN.1 DER. However, as described in section 3.4, type 1 certificates do not need to adhere to all the semantic rules in RFC 5280. If it is desired to use other certificate formats with this specification in the future, those formats must be assigned their own certificate type numbers, and the definition of "associated" in section 3.1 of this specification must be revised appropriately. Delete the paragraph that begins "Certificate types 1 and 2 explicitly only apply ..." (having been folded into the above). Section 2.3: Delete all text before the beginning of section 2.3.1. (Equivalent but clearer text will reappear in section 3.) Section 2.3.1: Move contents to section 3.4 (marked below). Section 3: Replace entire section with this text: 3. Client application behavior in the presence of TLSA records The primary purpose of TLSA records is security. However, TLSA information might also be useful for protocol optimizations that require advance knowledge of what the server's end-entity certificate should be. Clients that use TLSA information only for such optimizations, and not for security decisions, are exempt from all other requirements in this section. Clients that make security decisions based on TLSA information MUST be, or have access to, security-aware DNS resolvers as defined by RFC 4033. The rest of this section applies only to such clients, which will be referred to as "DANE clients". 3.1. Definitions A certificate received in the TLS handshake is said to _match_ a TLSA record if: o The TLSA record has reference type 0 and the certificate from the handshake is byte-for-byte identical to the certificate for association; or o The TLSA record has some other reference type, and the hash of the certificate from the handshake (using the hash algorithm specified by the reference type) is byte-for-byte identical to the certificate for association. A certificate bundle received in the TLS handshake is said to be _associated_ with a domain name by DANE, if a TLSA record for the host, protocol, and port exists, the end-entity certificate in the bundle contains a name record that matches the host, and: o The TLSA record has certificate type 1, and it matches the end-entity certificate in the bundle; or o The TLSA record has certificate type 2, it matches one of the non-end-entity certificates in the bundle, and the end-entity certificate in the bundle has a valid chain to the certificate that matched the TLSA record. 3.2. DNSSEC validation DANE clients MUST NOT proceed with a connection to a server if the DNSSEC validation status is "bogus" for _any_ DNS records relating to that server. DANE clients MUST ignore TLSA records whose DNSSEC validation status is "insecure" or "indeterminate" (however, such records MAY be used for TLS handshake optimizations as mentioned above). DANE clients MUST also ignore TLSA records whose certificate type or hash type they do not understand. A TLSA record whose DNSSEC status is "secure", and whose certificate and hash types are understood by the client processing it, will henceforth be referred to as a _trusted_ TLSA record. 3.3. DANE validation The presence in the DNS of a trusted TLSA record is an assertion by the zone administrator that the legitimate server(s) for that host, protocol, and port will use certificate bundles that can be associated with the domain name by that record (as defined in section 3.1), and no others. Therefore, a DANE client in possession of a trusted TLSA record for a server MUST determine whether that TLSA record associates the server's domain name with the certificate bundle it provides in the TLS handshake. If it does not, a DANE client MUST reject the end-entity certificate and abort the TLS handshake with an "access_denied" error. This rule applies even if the end-entity certificate would have been trusted in the absence of the TLSA record. Conversely, if the TLSA record _does_ associate the server's certificate bundle with its domain name, a DANE client MUST treat the end-entity certificate as possessing a valid chain to a trust anchor, until the TTL of the TLSA record expires. In other words, under these circumstances a DANE client MUST NOT reject a server's end-entity certificate solely for lack of a trust anchor. Furthermore, if the TLSA record providing the association has certificate type 1, a DANE client MUST NOT reject an end-entity certificate for violation of the PKIX rules that are relaxed by section 3.4 of this specification. However, if there is any _other_ reason why a server's end-entity certificate would have been rejected in the absence of TLSA information, a DANE client SHOULD still reject that certificate. For instance, if a certificate anywhere in the server's bundle has expired or has been revoked by its issuing CA, a DANE client SHOULD reject the end-entity certificate, even if the TLSA record matches a point in the chain before the invalid certificate. DANE associations provide a trust anchor _only_ for end-entity certificates, even if the TLSA record has certificate type 2. A DANE client MUST NOT allow any non-end-entity certificate in a certificate bundle that is anchored by a DANE association to become trusted for any domain name other than the one in the original association. DANE does not assure any information in a certificate other than the public key and its binding to host, protocol, and port. Most importantly, DANE does _not_ assure any non-DNS name records. 3.4. Relaxation of PKIX semantics for self-signed certificates (insert former contents of section 2.3.1 here) 3.5. User override DANE clients SHOULD NOT allow their human users to force the establishment of a connection that has been aborted for any of the reasons listed in sections 3.2 or 3.3. A client that has good reason not to comply with this requirement, such as a forensic tool, SHOULD assume that the other end of a forced connection is actively malicious. Therefore, the client SHOULD take precautions to avoid compromising the local computer or any of the user's data, such as: o Not transmitting "cookies" or any other information that should be confidential to the legitimate server; o Not executing any code (e.g. JavaScript) received over the connection; o Not triggering further network traffic based on the normal semantics of the data received (e.g. images referenced by an HTML page) without explicit user instructions to do so. ---- proposal ends ---- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 321673A6A76 for ; Mon, 28 Mar 2011 05:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjH0iBwFDIcb for ; Mon, 28 Mar 2011 05:55:11 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 87FCB3A6A81 for ; Mon, 28 Mar 2011 05:55:11 -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 p2SCulK7051231 for ; Mon, 28 Mar 2011 08:56:48 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4D908590.5020302@ogud.com> Date: Mon, 28 Mar 2011 08:56:48 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: keyassure@ietf.org References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> <1296657079.1889.8.camel@mattlaptop2.local> <1296688716.2621.20.camel@mattlaptop2.local> 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: [keyassure] Asserting DANE exclusivity for an entire domain X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:55:14 -0000 On 03/02/2011 11:45 AM, James Cloos wrote: >>>>>> "MM" == Matt McCutchen writes: > >>> Since we rely on DNSSEC anyway, DS records are the ideal way to >>> determine zone cut points. They are grabbed anyway as a matter >>> of course and provide all the clue required. > > MM> Right... but do DNSSEC client libraries make it easy to access this > MM> information without doing a separate query for the DS record? > > Even if they do not, the resolver had to grab the DS as part of the > validation, so the round trip for an extra DS lookup by the end client > is by definition local, often even same-process. > > -JimC Actually the RRSIG(DTLS) is an even better indicator the zone name == signer name, there is no need to look up the DS record from the client. Olafur Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49BE028C102 for ; Fri, 25 Mar 2011 18:01:51 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdlz8M17jauz for ; Fri, 25 Mar 2011 18:01:49 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id 9818E28C0CE for ; Fri, 25 Mar 2011 18:01:49 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id 3C4353BC069; Fri, 25 Mar 2011 18:03:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=AQIL7zPFj069w/6YZTd3deQbhAuZNEiPx9A3QgIpBbD Kq0Y++t+K6RQ6bxiKESbE/ClrO7Qwac6E8zjuBrRpWCM+JRpY8VgTIWkwk7ns/3w jU6GuEcJWAM9669myayIAejopy1BjCsm5tVJdywusXjWXwh38mJ+AI9u9j9O7ynM = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=eAaQuwoeM6c8agxEkb0bpIn/nWc=; b=YFgxKbSHCt WKaQvb4gbBef+YBD8F1QkELMIf0dAwxXkFP7W8IIxrLs7n+OQ5FykI9kBnpPqmsO UlyZayu1zbcwLRQPPinXWro37uTDuDr0io4FqiUgNHgkc4lNFA7kzfPazVWF/fYZ W15WARMLlkpuci10zvnhxhrqMwW/fJjvQ= Received: from [192.168.1.40] (pool-96-231-2-98.washdc.east.verizon.net [96.231.2.98]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTPA id BFE7D3BC062; Fri, 25 Mar 2011 18:03:24 -0700 (PDT) From: Matt McCutchen To: Paul Wouters In-Reply-To: References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> <1300739370.2117.40.camel@localhost> <4D8AAC8E.8040107@mail-abuse.org> <1301062867.11498.9.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Fri, 25 Mar 2011 21:03:23 -0400 Message-ID: <1301101403.24429.15.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 01:01:51 -0000 On Fri, 2011-03-25 at 19:36 -0400, Paul Wouters wrote: > On Fri, 25 Mar 2011, Matt McCutchen wrote: > > On Fri, 2011-03-25 at 05:03 -0400, Paul Wouters wrote: > >> I was also pretty disappointed to see that when you send a > >> trusted_ca_keys: pre_agreed value, that this is totally ignored on > >> servers, including openssl.org. > > > > What else would you have expected? That value is only meaningful in > > contexts where the server knows what set of trust anchors you are > > talking about. > > I would have expected to only get the EE cert, and no CA certs whatsoever. Why? The https://www.openssl.org server is not part of a deployment in which the pre_agreed value has a well-known meaning. I think you're still (willfully?) misreading RFC 6066. -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C643A6809 for ; Fri, 25 Mar 2011 16:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aCqnaFvM5QR for ; Fri, 25 Mar 2011 16:35:17 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 978123A6808 for ; Fri, 25 Mar 2011 16:35:17 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 04AAAC582; Fri, 25 Mar 2011 19:36:49 -0400 (EDT) Date: Fri, 25 Mar 2011 19:36:48 -0400 (EDT) From: Paul Wouters To: Matt McCutchen In-Reply-To: <1301062867.11498.9.camel@localhost> Message-ID: References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> <1300739370.2117.40.camel@localhost> <4D8AAC8E.8040107@mail-abuse.org> <1301062867.11498.9.camel@localhost> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 23:35:19 -0000 On Fri, 25 Mar 2011, Matt McCutchen wrote: > On Fri, 2011-03-25 at 05:03 -0400, Paul Wouters wrote: >> I was also pretty disappointed to see that when you send a >> trusted_ca_keys: pre_agreed value, that this is totally ignored on >> servers, including openssl.org. > > What else would you have expected? That value is only meaningful in > contexts where the server knows what set of trust anchors you are > talking about. I would have expected to only get the EE cert, and no CA certs whatsoever. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A74973A68B3 for ; Fri, 25 Mar 2011 07:20:16 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPBKSIH5jEM0 for ; Fri, 25 Mar 2011 07:20:15 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id C6A3F3A68BD for ; Fri, 25 Mar 2011 07:19:34 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id 6E2E610AFBC; Fri, 25 Mar 2011 07:21:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=Ha/XjO00Se6J8Zt7lOkNLRzM5TauuayzO0Cmu4LewtR TfDXxPxY6qkLNeWSMHTXAEWZygzAoJhj+S+QhVTsZREaW5RH39NX5tUYBOv+Ye46 4cgIh0J4QosAWytg+nmhD9Ppk4MLp5CP49qQEe6swJnKZjWZMkj04HjTBRgUMbqg = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=pHLlrOthD83z0XixP/CCXMWOYN0=; b=juKHqrClJo sAs0VHSABzZUjze0ZZXc6ZuOITqYrOAY6kzSEXV+Q3K81Ih64Yfkyi1SuWTSjf1V EXsHpXdy2TX9DxXB1TNKfH12qE4E2xUxQWUnJa2P0RN46SMxepCNUJ1n+FWYQBlA zSC9Y4vwD9KBLtlNwHc8NGdBWZ/xAfUOM= Received: from [192.168.1.40] (pool-96-231-2-98.washdc.east.verizon.net [96.231.2.98]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPA id E61DF10AFA1; Fri, 25 Mar 2011 07:21:08 -0700 (PDT) From: Matt McCutchen To: Paul Wouters In-Reply-To: References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> <1300739370.2117.40.camel@localhost> <4D8AAC8E.8040107@mail-abuse.org> Content-Type: text/plain; charset="UTF-8" Date: Fri, 25 Mar 2011 10:21:07 -0400 Message-ID: <1301062867.11498.9.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 14:20:16 -0000 On Fri, 2011-03-25 at 05:03 -0400, Paul Wouters wrote: > I was also pretty disappointed to see that when you send a > trusted_ca_keys: pre_agreed value, that this is totally ignored on > servers, including openssl.org. What else would you have expected? That value is only meaningful in contexts where the server knows what set of trust anchors you are talking about. -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73B9928C162 for ; Fri, 25 Mar 2011 03:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTR4v-G-MzDq for ; Fri, 25 Mar 2011 03:58:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A963728C163 for ; Fri, 25 Mar 2011 03:58:45 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q34ke-0004Im-Hy; Fri, 25 Mar 2011 04:00:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: henry.story@bblfish.net X-Trac-Project: dane Date: Fri, 25 Mar 2011 11:00:20 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/14#comment:3 Message-ID: <064.dd43277ffa7bbfd9cbd7800165dd923e@trac.tools.ietf.org> References: <055.52e849c52f563625a28428b98f4ca55c@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <055.52e849c52f563625a28428b98f4ca55c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henry.story@bblfish.net, keyassure@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: keyassure@ietf.org Subject: Re: [keyassure] [dane] #14: Bare Public Keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 10:58:46 -0000 #14: Bare Public Keys Comment(by henry.story@…): Paul Hoffman added in http://www.ietf.org/mail- archive/web/keyassure/current/msg02129.html "Those arguing against" had additional claims. The one I heard a few times was "there is no good reason to have bare keys in DANE if you cannot have them in TLS". That is, you can't do straight matching with a bare key because that is not a form that is allowed by TLS. If TLS is extended with a standards-track extension that adds bare keys, I would argue that TLSA should have it as well, but probably not until then. -- --------------------------------+------------------------------------------- Reporter: mlepinsk@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: protocol | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: dane Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 492B13A6990 for ; Fri, 25 Mar 2011 03:12:56 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fg6nUNfado9U for ; Fri, 25 Mar 2011 03:12:55 -0700 (PDT) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 317EE3A684D for ; Fri, 25 Mar 2011 03:12:55 -0700 (PDT) Received: from [10.0.2.202] ([212.47.23.197]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2PAEOqP044186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Mar 2011 03:14:27 -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: <1F4784C6-6ED2-4BA7-A2E4-A4296BFFFF4A@bblfish.net> Date: Fri, 25 Mar 2011 06:14:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <188FA2C8-E5A3-4EEF-9372-04D3346A5037@vpnc.org> References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> <1300739370.2117.40.camel@localhost> , <4003BE42-F5AA-4AD2-BF27-21891975F7CE@vpnc.org> <1F4784C6-6ED2-4BA7-A2E4-A4296BFFFF4A@bblfish.net> To: Henry Story X-Mailer: Apple Mail (2.1084) Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 10:12:56 -0000 > What was still open was why one should add bare public keys, other = than for reasons of elegance and bandwidth (which could be important, = tests needed) to the options specified in Dane. Those arguing against = claimed it could make things very difficult for a lot of software. "Those arguing against" had additional claims. The one I heard a few = times was "there is no good reason to have bare keys in DANE if you = cannot have them in TLS". That is, you can't do straight matching with a = bare key because that is not a form that is allowed by TLS. If TLS is = extended with a standards-track extension that adds bare keys, I would = argue that TLSA should have it as well, but probably not until then. --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B754B3A684A for ; Fri, 25 Mar 2011 03:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jvw8s-jDxPuN for ; Fri, 25 Mar 2011 03:12:10 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 42B693A67C3 for ; Fri, 25 Mar 2011 03:12:09 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p2PADfZW022521 for ; Fri, 25 Mar 2011 03:13:42 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301048024; bh=F8Mqp1i/6eo+N91qVM93GLojoyg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=OlPIyFc3EkwP/DZzBoAlq5McM5S4oRSI07zijQ6QOgJfS/FOcdxNcGM/UP8KnB4Fz rTUMFuV7H5d5eDHDdyZIw== Received: from vws13 (vws13.prod.google.com [10.241.21.141]) by wpaz24.hot.corp.google.com with ESMTP id p2PADeqK002462 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 25 Mar 2011 03:13:40 -0700 Received: by vws13 with SMTP id 13so229210vws.40 for ; Fri, 25 Mar 2011 03:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=M4FK/8s4nRRDaqEctRt33D/mIRDsdPdHbDM7b3M2PiM=; b=k1KERYoAMH+iv1P6PqJ3SyFE/dxWpXFI8VFX86Xy71U2NbAwJT+0xiZJjcCB4hmaiZ np+wR4zI2Y05IOH/c9SA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Tj+wdGJiWfrZHaREV1tGnT9ah8K+8/2uH25ClRpJK1Z80EgqXhnp024v0wSzxxO1hN hy7Eme6hFg+0n5y/atww== MIME-Version: 1.0 Received: by 10.220.125.102 with SMTP id x38mr144363vcr.260.1301048020098; Fri, 25 Mar 2011 03:13:40 -0700 (PDT) Received: by 10.220.88.137 with HTTP; Fri, 25 Mar 2011 03:13:39 -0700 (PDT) In-Reply-To: References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> <1300739370.2117.40.camel@localhost> <4D8AAC8E.8040107@mail-abuse.org> Date: Fri, 25 Mar 2011 10:13:39 +0000 Message-ID: From: Ben Laurie To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: keyassure@ietf.org Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 10:12:12 -0000 On 25 March 2011 09:03, Paul Wouters wrote: > On Wed, 23 Mar 2011, Douglas Otis wrote: > >>> >>> http://blog.torproject.org/blog/detecting-certificate-authority-comprom= ises-and-web-browser-collusion >>> This is another clear signal that DANE is needed, and the need for the >>> X509 storage format is unneccessary. So people can simply take control >>> of SSL for servers within their own DNS zones. >> >> Could this end the practice of stapling Certs to server responses that >> might be cached for weeks to support ultra-fast browsers? =A0Perfect Mit= M. =A0Do >> these browser insist on seeing valid nonce extensions, as this would hur= t >> performance? > > I was also pretty disappointed to see that when you send a > trusted_ca_keys: pre_agreed value, that this is totally ignored on > servers, including openssl.org. I have a rough patch for openssl I used > for testing, but not one that takes any of the other RFC 6066 options (ye= t) Happy to shepherd OpenSSL patches... > > In fact, if I understood the versioning right, basically no one is > running TLS v1.2 yet, and the comments in the openssl 1.0.1 snapshot > suggested it had only partially started on TLs v1.1. > > I did not expect this backlog on the TLS implementations. > > Paul > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB2F03A6984 for ; Fri, 25 Mar 2011 02:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqd2zc7hcUms for ; Fri, 25 Mar 2011 02:02:00 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 99B913A6989 for ; Fri, 25 Mar 2011 02:02:00 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id DCC58C582; Fri, 25 Mar 2011 05:03:32 -0400 (EDT) Date: Fri, 25 Mar 2011 05:03:32 -0400 (EDT) From: Paul Wouters To: Douglas Otis In-Reply-To: <4D8AAC8E.8040107@mail-abuse.org> Message-ID: References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> <1300739370.2117.40.camel@localhost> <4D8AAC8E.8040107@mail-abuse.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 09:02:02 -0000 On Wed, 23 Mar 2011, Douglas Otis wrote: >> http://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion >> >> This is another clear signal that DANE is needed, and the need for the >> X509 storage format is unneccessary. So people can simply take control >> of SSL for servers within their own DNS zones. > Could this end the practice of stapling Certs to server responses that might > be cached for weeks to support ultra-fast browsers? Perfect MitM. Do these > browser insist on seeing valid nonce extensions, as this would hurt > performance? I was also pretty disappointed to see that when you send a trusted_ca_keys: pre_agreed value, that this is totally ignored on servers, including openssl.org. I have a rough patch for openssl I used for testing, but not one that takes any of the other RFC 6066 options (yet) In fact, if I understood the versioning right, basically no one is running TLS v1.2 yet, and the comments in the openssl 1.0.1 snapshot suggested it had only partially started on TLs v1.1. I did not expect this backlog on the TLS implementations. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B51473A6964 for ; Thu, 24 Mar 2011 23:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.293 X-Spam-Level: X-Spam-Status: No, score=-3.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ec1lhsNFiNNT for ; Thu, 24 Mar 2011 23:53:57 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id A11A83A6811 for ; Thu, 24 Mar 2011 23:53:56 -0700 (PDT) Received: by bwz13 with SMTP id 13so727546bwz.31 for ; Thu, 24 Mar 2011 23:55:30 -0700 (PDT) Received: by 10.204.73.206 with SMTP id r14mr352980bkj.181.1301036129641; Thu, 24 Mar 2011 23:55:29 -0700 (PDT) Received: from [192.168.1.10] (ALagny-751-1-3-15.w86-218.abo.wanadoo.fr [86.218.42.15]) by mx.google.com with ESMTPS id w3sm473670bkt.17.2011.03.24.23.55.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Mar 2011 23:55:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: <4003BE42-F5AA-4AD2-BF27-21891975F7CE@vpnc.org> Date: Fri, 25 Mar 2011 07:55:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1F4784C6-6ED2-4BA7-A2E4-A4296BFFFF4A@bblfish.net> References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> <1300739370.2117.40.camel@localhost> , <4003BE42-F5AA-4AD2-BF27-21891975F7CE@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1082) Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 06:53:58 -0000 On 23 Mar 2011, at 16:19, Paul Hoffman wrote: > On Mar 23, 2011, at 7:15 AM, Jeff Schmidt wrote: >=20 >> I'm new here, so I please accept all relevant apologies and I ask for = all relevant leniance and guidance. >=20 > Guidance: read the list archives relevant to your concern. Search for = issue #14, which was finished some time ago, and "bare key". This = current thread is an attempt to re-open the issue. Just to make that simpler, you can find it here: http://trac.tools.ietf.org/wg/dane/trac/ticket/14 It was a long thread, so I added a pointer to one mail where I tried to = summarise the issues on that issue page. There is at least a reasonably = standard way to publish the keys, the one defined by X509 itself.=20 What was still open was why one should add bare public keys, other than = for reasons of elegance and bandwidth (which could be important, tests = needed) to the options specified in Dane. Those arguing against claimed = it could make things very difficult for a lot of software. Henry= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8CFD28C0EA for ; Thu, 24 Mar 2011 23:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 033+RWCNP0Yl for ; Thu, 24 Mar 2011 23:41:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3602C3A6962 for ; Thu, 24 Mar 2011 23:41:55 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q30k6-00077l-Sm; Thu, 24 Mar 2011 23:43:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: henry.story@bblfish.net X-Trac-Project: dane Date: Fri, 25 Mar 2011 06:43:30 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/14#comment:2 Message-ID: <064.fc0fed3acc190316c0e42591695670d4@trac.tools.ietf.org> References: <055.52e849c52f563625a28428b98f4ca55c@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <055.52e849c52f563625a28428b98f4ca55c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henry.story@bblfish.net, keyassure@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: keyassure@ietf.org Subject: Re: [keyassure] [dane] #14: Bare Public Keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 06:41:57 -0000 #14: Bare Public Keys Comment(by henry.story@…): That ended up being a long thread. One part of the discussion was on what the keys should look like. A simple and standard compliant bare public key format would be the one defined by X509 itself, namely the subset of X509 that defines. RSAPublicKey ::= SEQUENCE { modulus INTEGER, -- n publicExponent INTEGER -- e } More on this here: http://www.ietf.org/mail-archive/web/keyassure/current/msg01850.html The thread of February 14th is long, and one summary of the pros and cons can be found here, with pointers http://www.ietf.org/mail-archive/web/keyassure/current/msg01900.html -- --------------------------------+------------------------------------------- Reporter: mlepinsk@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: protocol | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: dane Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E486F28C10D for ; Thu, 24 Mar 2011 11:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.529 X-Spam-Level: X-Spam-Status: No, score=-106.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQRjLU0LFcdg for ; Thu, 24 Mar 2011 11:42:26 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id CCB6828C0F3 for ; Thu, 24 Mar 2011 11:42:26 -0700 (PDT) Received: from us-dougo-mac.us.trendnet.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 9B4E0A94451 for ; Thu, 24 Mar 2011 18:44:49 +0000 (UTC) Message-ID: <4D8B90E7.7030706@mail-abuse.org> Date: Thu, 24 Mar 2011 11:43:51 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: keyassure@ietf.org References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> <1300739370.2117.40.camel@localhost> <4D8AAC8E.8040107@mail-abuse.org> In-Reply-To: <4D8AAC8E.8040107@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 18:42:28 -0000 On 3/23/11 7:29 PM, Douglas Otis wrote: > On 3/23/11 3:30 AM, Paul Wouters wrote: >> On Mon, 21 Mar 2011, Paul Wouters wrote: >> >>>> Trying to use DANE as a means of eliminating X.509 from TLS is a >>>> non-starter as far as I am concerned. >>> >>> That has been loud and clear. However, it does not mean others >>> should stop trying to innovate and move forward. >> >> Especially considering the latest CA compromise where a CA issued a >> rogue >> certificate for addons.mozilla.org. And this is not some el cheapo CA, >> but one that is respected and has people very active within the IETF, >> the >> good guys.... >> >> http://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion >> >> >> This is another clear signal that DANE is needed, and the need for the >> X509 storage format is unneccessary. So people can simply take control >> of SSL for servers within their own DNS zones. > Could this end the practice of stapling Certs to server responses that > might be cached for weeks to support ultra-fast browsers? Perfect > MitM. Do these browser insist on seeing valid nonce extensions, as > this would hurt performance? It was a mistake referring to the stapling of Certs. The concern was in regard to stapling of OSCP-responses as defined in RFC4366. Unfortunately, this RFC did not establish a convention for NONCE tokens indicating it represented POSIX time where receivers could be required to reject any that were more than 1 hour old, for example. This would mean OSCP responses should never be more than 1 hour old. Otherwise, a response will always be delayed by an embedded OSCP response, which would also eliminates the speed advantage being sought. -Doug Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9C873A682C for ; Thu, 24 Mar 2011 01:16:20 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO+RcQQfNkIg for ; Thu, 24 Mar 2011 01:16:19 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id D52483A67CF for ; Thu, 24 Mar 2011 01:16:19 -0700 (PDT) Received: from [10.67.11.182] (unknown [212.47.23.197]) by vimes.kumari.net (Postfix) with ESMTPSA id B17431B401D8 for ; Thu, 24 Mar 2011 04:17:53 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Mar 2011 09:17:56 +0100 Message-Id: To: keyassure@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [keyassure] Mis-issued certs for Google / Yahoo / Skype, etc. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 08:16:20 -0000 I'm assuming everyone has already seen this, but on the off-chance that = you haven't: = http://threatpost.com/en_us/blogs/phony-web-certificates-issued-google-yah= oo-skype-others-032311# Being able to state "That ain't my cert" is one of the drivers for this = work.... W= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F72C3A67D9 for ; Wed, 23 Mar 2011 20:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZ6fADLdqSIx for ; Wed, 23 Mar 2011 20:17:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 945213A67D2 for ; Wed, 23 Mar 2011 20:17:42 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q2b4u-0000Ju-RE; Wed, 23 Mar 2011 20:19:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: matt@mattmccutchen.net X-Trac-Project: dane Date: Thu, 24 Mar 2011 03:19:15 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/dane/trac/ticket/22#comment:1 Message-ID: <070.75a9fc409a6e1b9ef399534b5ad414a3@trac.tools.ietf.org> References: <061.e0845de87f7a8d8d863b8ef546890255@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <061.e0845de87f7a8d8d863b8ef546890255@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: matt@mattmccutchen.net, keyassure@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: keyassure@ietf.org Subject: Re: [keyassure] [dane] #22: Provide the security of the strongest digest supported by both sides X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 03:17:43 -0000 #22: Provide the security of the strongest digest supported by both sides Comment(by matt@…): For the curious: [https://www.ietf.org/mail- archive/web/dnsext/current/msg11006.html George Barwood took my claim that the issue affects DNSSEC DS to the dnsext list] and discussion ensued. It turns out DNSSEC DS has a solution that I was unaware of: assume that the DS RRset is formed as a Cartesian product of DNSKEYs with digest algorithms, and then the client uses the strongest algorithm it supports that appears in the set. This makes three possible solutions: 1. Allow each RR to contain a set of (digest type, digest value) pairs for the same certificate. 1. Require the RRset to be a Cartesian product of certificates with digest algorithms. 1. Add an ID field to each RR to cross-reference all digests of the same object. IMO, solution 1 is the cleanest. -- ------------------------------------+--------------------------------------- Reporter: matt@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Ticket URL: dane Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0C7C3A67AB for ; Wed, 23 Mar 2011 19:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.521 X-Spam-Level: X-Spam-Status: No, score=-106.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pypSxyppdcPp for ; Wed, 23 Mar 2011 19:28:07 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id AF6EB3A67A6 for ; Wed, 23 Mar 2011 19:28:07 -0700 (PDT) Received: from us-dougo-mac.us.trendnet.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id CEDDAA9444A for ; Thu, 24 Mar 2011 02:30:32 +0000 (UTC) Message-ID: <4D8AAC8E.8040107@mail-abuse.org> Date: Wed, 23 Mar 2011 19:29:34 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: keyassure@ietf.org References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> <1300739370.2117.40.camel@localhost> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 02:28:09 -0000 On 3/23/11 3:30 AM, Paul Wouters wrote: > On Mon, 21 Mar 2011, Paul Wouters wrote: > >>> Trying to use DANE as a means of eliminating X.509 from TLS is a >>> non-starter as far as I am concerned. >> >> That has been loud and clear. However, it does not mean others should >> stop trying to innovate and move forward. > > Especially considering the latest CA compromise where a CA issued a rogue > certificate for addons.mozilla.org. And this is not some el cheapo CA, > but one that is respected and has people very active within the IETF, the > good guys.... > > http://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion > > > This is another clear signal that DANE is needed, and the need for the > X509 storage format is unneccessary. So people can simply take control > of SSL for servers within their own DNS zones. Could this end the practice of stapling Certs to server responses that might be cached for weeks to support ultra-fast browsers? Perfect MitM. Do these browser insist on seeing valid nonce extensions, as this would hurt performance? -Doug Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3739428C0F8 for ; Wed, 23 Mar 2011 08:24:57 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bv1MrUOlWEt for ; Wed, 23 Mar 2011 08:24:56 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by core3.amsl.com (Postfix) with ESMTP id 13B8428C0DF for ; Wed, 23 Mar 2011 08:24:56 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id B35A2598076 for ; Wed, 23 Mar 2011 08:26:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=XCPbEIpr6EjaH5p0f+oIXTABXyuhHD6QtzP+ul3nZ7p iKdA8qez076bR4YsGZcE6nLXhoSmDDTeZ7v1kNA+7ipWuWxRD9EANKn8NxZpjz7/ 17kx5ocrPk5QObRHVpIy0xYyCx1Mwvc9hQ0iGUV1k7PKYWC5gUIEnD1CQZmLLv5w = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=YPer1kn5wSgcDaQQ+45SnVihE4w=; b=bOJvNoe51D K9Q93NM+aZ4zuAtsOkcX/MX4K1CmvGZsNJyD3xOSGrxj4y5pMB1WsRDDBDxvlEWp 3IILur8ARaiPkrxYAEAKkCi3JjrwRQ8tcKae/U0EGzw9h8goQdiziHdkybKa0joi /ffACHAIDEunq7EOEpHB6tko0g868CVl0= Received: from [192.168.1.40] (pool-96-231-2-98.washdc.east.verizon.net [96.231.2.98]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPA id 620A6598074 for ; Wed, 23 Mar 2011 08:26:29 -0700 (PDT) From: Matt McCutchen To: keyassure In-Reply-To: References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> <1300739370.2117.40.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Wed, 23 Mar 2011 11:26:28 -0400 Message-ID: <1300893988.2117.179.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 15:24:57 -0000 On Wed, 2011-03-23 at 06:30 -0400, Paul Wouters wrote: > Especially considering the latest CA compromise where a CA issued a rogue > certificate for addons.mozilla.org. And this is not some el cheapo CA, > but one that is respected and has people very active within the IETF, the > good guys.... > > http://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion > > This is another clear signal that DANE is needed, Indeed. > and the need for the X509 storage format is unneccessary. Non sequitur. What does the compromise of a CA have to do with the use (or not) of X.509 as a container in DANE? -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5B933A692C for ; Wed, 23 Mar 2011 08:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.036 X-Spam-Level: X-Spam-Status: No, score=-102.036 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9X-5RLWi9mq3 for ; Wed, 23 Mar 2011 08:18:00 -0700 (PDT) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id AC5573A6914 for ; Wed, 23 Mar 2011 08:17:59 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2NFJWAd038056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Mar 2011 08:19:32 -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: Wed, 23 Mar 2011 08:19:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4003BE42-F5AA-4AD2-BF27-21891975F7CE@vpnc.org> References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> <1300739370.2117.40.camel@localhost> , To: Jeff Schmidt X-Mailer: Apple Mail (2.1084) Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 15:18:00 -0000 On Mar 23, 2011, at 7:15 AM, Jeff Schmidt wrote: > I'm new here, so I please accept all relevant apologies and I ask for = all relevant leniance and guidance. Guidance: read the list archives relevant to your concern. Search for = issue #14, which was finished some time ago, and "bare key". This = current thread is an attempt to re-open the issue. > If I'm not way off base here, I'd be happy to take a shot at some = edits to -06 if desired. Guidance: The WG already has draft authors (I'm one, Jakob Schlyter is = the other). We take direction from the WG chairs when issues are closed, = then put out a new draft. --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C2DC3A690C for ; Wed, 23 Mar 2011 07:13:59 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJxxe5KPhhzs for ; Wed, 23 Mar 2011 07:13:58 -0700 (PDT) Received: from relay-hub202.domainlocalhost.com (relay-hub202.domainlocalhost.com [74.115.204.52]) by core3.amsl.com (Postfix) with ESMTP id 2EB2B3A6869 for ; Wed, 23 Mar 2011 07:13:57 -0700 (PDT) Received: from MBX202.domain.local ([169.254.2.125]) by HUB202.domain.local ([74.115.204.52]) with mapi id 14.01.0255.000; Wed, 23 Mar 2011 10:15:31 -0400 From: Jeff Schmidt To: Paul Wouters , "keyassure@ietf.org" Thread-Topic: [keyassure] Bare keys again Thread-Index: AQHL51zGDvNhnuZrW0u0NF7HLeps2ZQ3NYOAgAAHOACAABQaAIABMNsAgAACqYCAAAL5gIAABGkAgAAICICAAmtBgP//8wT+ Date: Wed, 23 Mar 2011 14:15:33 +0000 Message-ID: References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> <1300739370.2117.40.camel@localhost> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.64.24] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 14:13:59 -0000 =0A= I'm new here, so I please accept all relevant apologies and I ask for all r= elevant leniance and guidance. =0A= =0A= On Mon, 21 Mar 2011, Paul Wouters wrote=0A= =0A= > http://blog.torproject.org/blog/detecting-certificate-authority-compromis= es-and-web-browser-collusion=0A= =0A= > This is another clear signal that DANE is needed, and the need for the=0A= > X509 storage format is unneccessary. So people can simply take control=0A= > of SSL for servers within their own DNS zones.=0A= =0A= I have been tracking this conversation with interest. I am of the opinion = that X.509 is an artifact of the past, when public keys were distributed ou= tside of any useful namespace, and we needed additional "stuff" to establis= h provenance, chain of trust, etc. X.509 is essentially a way to (1) map a= public key to a hostname/email address, and (2) establish a chain of trust= .=0A= =0A= Of course, we don't need (1) when the key is in DNS, and hopefully we're mo= ving away from practices that would need (2) for all the reasons the CA tru= st model is broken. So, X.509 brings a lot of overhead/baggage without pro= viding anything useful in return.(*) Thus, I agree that we should be desig= ning DANE (and other approaches) for the future, which will hopefully be a = post-X.509/CA world.=0A= =0A= The (*) is interoperability with TLS, which we obviously need. So, here's = the idea: why don't we design DANE to support both methods of operation: pu= blishing X.509 certs/hashes and bare keys. This gives us interoperability = in the near term and flexibility into the future (to combat the TXT approac= hes).=0A= =0A= As I see it, we could generalize the "TLSA Certificate Types" registry to s= upport several methods of operation - something like "TLSA Data Types" then= add to the initial registry:=0A= n: Bare public key to identify an end entity=0A= n: Bare public key trust anchor=0A= =0A= Hash types still applies as written; some other language would need smoothi= ng here and there, but it pretty much works.=0A= =0A= If I'm not way off base here, I'd be happy to take a shot at some edits to = -06 if desired.=0A= =0A= Thanks,=0A= Jeff=0A= =0A= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA963A6853 for ; Wed, 23 Mar 2011 04:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DjTKDDK56FZ for ; Wed, 23 Mar 2011 04:50:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 462DF3A684E for ; Wed, 23 Mar 2011 04:50:24 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q2MbW-0007XM-DT; Wed, 23 Mar 2011 04:51:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: ondrej.sury@nic.cz X-Trac-Project: dane Date: Wed, 23 Mar 2011 11:51:58 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/dane/trac/ticket/11#comment:2 Message-ID: <064.9b4db7ad4e952752909057a4a117cd86@trac.tools.ietf.org> References: <055.3d7dd0c7adb34161b2bdcc2e641d24ee@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <055.3d7dd0c7adb34161b2bdcc2e641d24ee@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: ondrej.sury@nic.cz, keyassure@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: keyassure@ietf.org Subject: Re: [keyassure] [dane] #11: Hash Function Strength X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 11:50:26 -0000 #11: Hash Function Strength Changes (by ondrej.sury@…): * status: new => closed * resolution: => fixed -- ------------------------------+--------------------------------------------- Reporter: mlepinsk@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: protocol | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Ticket URL: dane Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CF803A686C for ; Wed, 23 Mar 2011 04:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cU9rmIgt61VH for ; Wed, 23 Mar 2011 04:50:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C00923A6814 for ; Wed, 23 Mar 2011 04:50:02 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q2Mb7-0007GS-Mn; Wed, 23 Mar 2011 04:51:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: mlepinsk@bbn.com, ondrej.sury@nic.cz X-Trac-Project: dane Date: Wed, 23 Mar 2011 11:51:33 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/dane/trac/ticket/9#comment:2 Message-ID: <064.30225833ab32c3db368a5eb520cf596c@trac.tools.ietf.org> References: <055.445f568e999e5a1e5b8567f847ee98d6@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <055.445f568e999e5a1e5b8567f847ee98d6@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mlepinsk@bbn.com, ondrej.sury@nic.cz, keyassure@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: keyassure@ietf.org Subject: Re: [keyassure] [dane] #9: Self-Signed Certificates X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 11:50:19 -0000 #9: Self-Signed Certificates Changes (by ondrej.sury@…): * status: new => closed * resolution: => fixed Comment: Resolved in the current draft draft-ietf-dane-protocol-06. -- --------------------------------+------------------------------------------- Reporter: mlepinsk@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: protocol | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: dane Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3BC63A690C for ; Wed, 23 Mar 2011 04:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYkfzVf+bBeS for ; Wed, 23 Mar 2011 04:49:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1B11D3A6868 for ; Wed, 23 Mar 2011 04:49:19 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q2MaT-00068U-8S; Wed, 23 Mar 2011 04:50:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: ondrej.sury@nic.cz X-Trac-Project: dane Date: Wed, 23 Mar 2011 11:50:53 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/dane/trac/ticket/11#comment:1 Message-ID: <064.81be2aa86d69cd846c70091c91dd483f@trac.tools.ietf.org> References: <055.3d7dd0c7adb34161b2bdcc2e641d24ee@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <055.3d7dd0c7adb34161b2bdcc2e641d24ee@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: ondrej.sury@nic.cz, keyassure@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: keyassure@ietf.org Subject: Re: [keyassure] [dane] #11: Hash Function Strength X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 11:49:20 -0000 #11: Hash Function Strength Comment(by ondrej.sury@…): Resolved in the current draft draft-ietf-dane-protocol-06. -- ------------------------------+--------------------------------------------- Reporter: mlepinsk@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: protocol | Version: Severity: - | Keywords: ------------------------------+--------------------------------------------- Ticket URL: dane Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B2B83A6836 for ; Wed, 23 Mar 2011 04:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByXSF6GACi-j for ; Wed, 23 Mar 2011 04:48:50 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7436E3A682C for ; Wed, 23 Mar 2011 04:48:50 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q2MZz-0005HX-IB; Wed, 23 Mar 2011 04:50:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: ondrej.sury@nic.cz X-Trac-Project: dane Date: Wed, 23 Mar 2011 11:50:23 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/dane/trac/ticket/5#comment:1 Message-ID: <065.1a86693cb4c3c4552eb86acd47040c66@trac.tools.ietf.org> References: <056.f2d2010d4e1a25f586a1841967ceb73f@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <056.f2d2010d4e1a25f586a1841967ceb73f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: ondrej.sury@nic.cz, keyassure@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: keyassure@ietf.org Subject: Re: [keyassure] [dane] #5: Protocol support -- TLS / DTLS / IPsec or larger. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 11:48:51 -0000 #5: Protocol support -- TLS / DTLS / IPsec or larger. Changes (by ondrej.sury@…): * status: new => closed * resolution: => wontfix Comment: Out of scope for the current draft. We may reopen if needed for a new draft in the future. -- -------------------------------+-------------------------------------------- Reporter: warren@… | Owner: Type: task | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: wontfix Keywords: | -------------------------------+-------------------------------------------- Ticket URL: dane Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD4673A67F9 for ; Wed, 23 Mar 2011 03:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlGWnTMlfKt4 for ; Wed, 23 Mar 2011 03:29:05 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 6D5713A67F3 for ; Wed, 23 Mar 2011 03:29:05 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id DE68BC582 for ; Wed, 23 Mar 2011 06:30:35 -0400 (EDT) Date: Wed, 23 Mar 2011 06:30:35 -0400 (EDT) From: Paul Wouters To: keyassure@ietf.org In-Reply-To: Message-ID: References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> <1300739370.2117.40.camel@localhost> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 10:29:06 -0000 On Mon, 21 Mar 2011, Paul Wouters wrote: >> Trying to use DANE as a means of eliminating X.509 from TLS is a >> non-starter as far as I am concerned. > > That has been loud and clear. However, it does not mean others should stop > trying to innovate and move forward. Especially considering the latest CA compromise where a CA issued a rogue certificate for addons.mozilla.org. And this is not some el cheapo CA, but one that is respected and has people very active within the IETF, the good guys.... http://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion This is another clear signal that DANE is needed, and the need for the X509 storage format is unneccessary. So people can simply take control of SSL for servers within their own DNS zones. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6133A68ED for ; Mon, 21 Mar 2011 14:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiBCb8E28kdN for ; Mon, 21 Mar 2011 14:59:32 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id F1F9D3A68E4 for ; Mon, 21 Mar 2011 14:59:31 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p2LM13hQ022191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Mar 2011 23:01:04 +0100 (MET) From: Martin Rex Message-Id: <201103212201.p2LM13oI018636@fs4113.wdf.sap.corp> To: paul@xelerance.com (Paul Wouters) Date: Mon, 21 Mar 2011 23:01:03 +0100 (MET) In-Reply-To: from "Paul Wouters" at Mar 21, 11 05:40:52 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 21:59:38 -0000 Paul Wouters wrote: > > Thank you for pointing this out. Only now I understand what the objection > is. Rereading 6066, it does seem to indicate the EE cert was not meant > to be omitted, though the handshake diagram in 5246 seems to suggest it > can be omitted. I will do some more re-reading of 5246. The diagram http://tools.ietf.org/html/rfc5246#page-36 Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data Figure 1. Message flow for a full handshake * Indicates optional or situation-dependent messages that are not always sent. means that in some handshake the entire "Server Certificate" might be omitted, and the definition of the "Server Certificate" handshake message tells you, which handshakes or situations these are. http://tools.ietf.org/html/rfc5246#section-7.4.2 There is a proposal to omit a pre-agreed server certificate (chain) from the TLS handshake here: http://tools.ietf.org/html/draft-ietf-tls-cached-info-09 but the document got stuck on the algorithm agility discussions for this proposal a while ago... -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B5A53A68E1 for ; Mon, 21 Mar 2011 14:42:31 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYTUO-l3ttEN for ; Mon, 21 Mar 2011 14:42:24 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (mx1.spunky.mail.dreamhost.com [208.97.132.47]) by core3.amsl.com (Postfix) with ESMTP id 99ECF3A68E8 for ; Mon, 21 Mar 2011 14:42:24 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 4B009634079; Mon, 21 Mar 2011 14:43:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=Gh3TlGKuxOd4LlQ7nzrXUCkGEKR0LBucZ9QlsuhdpPZ ANvHSOTs2uYYpbwtcRfguFDHqgSy3ei2eNbCRjsiahrhZ/BtGD81jRNeTu0uyv+Y v100o7y77SlNKA9i0WeH+B+PVvI/3N7qqfCWhgnRHkN0gtgocbAJ5BFZo2rxdfHk = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=UhrdlWH94TC0/4lMJl+YjRozv8w=; b=Ty6TkPuKLW GnpxBDIQd9le+bsqw5qicbt9cf1wuJ0s7wLX1gtFd/5p12OvNzZlihJbQdzqiTYp 1hSKoct0YqaL498DoypTQquC8O3wW0w2uCwkp/39T3S/sP/Ln26T0wdRIQMnyEgb yNB18d57EN6+NoxUgcWT1oAC3QIVW7MjI= Received: from [192.168.1.40] (pool-96-231-2-98.washdc.east.verizon.net [96.231.2.98]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPA id CFEC4634075; Mon, 21 Mar 2011 14:43:56 -0700 (PDT) From: Matt McCutchen To: Paul Wouters In-Reply-To: References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> <1300739370.2117.40.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Mon, 21 Mar 2011 17:43:55 -0400 Message-ID: <1300743835.2117.67.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 21:42:31 -0000 On Mon, 2011-03-21 at 17:40 -0400, Paul Wouters wrote: > though the handshake diagram in 5246 seems to suggest [the EE cert] > can be omitted. http://www.ietf.org/mail-archive/web/keyassure/current/msg02102.html -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF27A3A68E1 for ; Mon, 21 Mar 2011 14:41:04 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlqOOxBthgzW for ; Mon, 21 Mar 2011 14:40:54 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id BEA2F3A68E4 for ; Mon, 21 Mar 2011 14:40:54 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id 7837F70406E; Mon, 21 Mar 2011 14:42:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=l0s20Tq400VF4YawwxRqP6koE2qtcrHJM0Tszp/iL0o WQ/SmzJcpuL4b3uKPrVChuapFXEPKrMWjm3r7FujmUEh7SzOwhBNKRjIOg0YJMsL 4+t/QZkkZpysMBXtq/yoQr6ZhT5ug0OiFRHMTNlioc//mEyEjyOMcRJH8MaIuplc = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=HshLO0b33BqgV5jl9OTpKMRE32I=; b=ZTTrhg6rFK pjukyS5x0lOE/57KJmgFym1RNBwzxVj1q/Sx2xFaMTXQK2DVQtKvDKvNvGnvOY5d eb3wM9g66ekRRV5Q8zM5VxmPxa3n+5avKoeXh90ZLC8G6MuIBv+tg5ceOurBO6FQ Qy7MGye3yKzerbiYbI8J0nvENtGKH6KvY= Received: from [192.168.1.40] (pool-96-231-2-98.washdc.east.verizon.net [96.231.2.98]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPA id 1AB8C70406A; Mon, 21 Mar 2011 14:42:26 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker In-Reply-To: References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> <1300739370.2117.40.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Mon, 21 Mar 2011 17:42:25 -0400 Message-ID: <1300743745.2117.66.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 21:41:04 -0000 On Mon, 2011-03-21 at 17:05 -0400, Phillip Hallam-Baker wrote: > Trying to use DANE as a means of eliminating X.509 from TLS is a > non-starter as far as I am concerned. If this group is not going to > listen to the TLS WG Agreed: we are targeting TLS. > or the PKIX WG there is not a lot of point in it being here. Digression (because this thread only pertains to the TLS WG): I would not agree that following PKIX methods is a requirement per se of the DANE WG. PKIX is relevant to us inasmuch as (1) the TLS protocol currently supports X.509 certificates, and we should not replace that format just for the sake of replacing it, and (2) people will want to use DANE in conjunction with PKIX CAs. > What might appear to be a minor change to the protocol can have > significant and unpredictable results throughout the system. > > The way we avoid such results is mostly to avoid changes that do not > have a very very good justification. This is true to a point, beyond which it is FUD. In all cases, the risks of a change are to be balanced against its benefits. > Not liking ASN.1 is not a justification in my view. Agreed. -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE3C53A68E4 for ; Mon, 21 Mar 2011 14:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.223 X-Spam-Level: X-Spam-Status: No, score=-10.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ub8x+n7zWOs for ; Mon, 21 Mar 2011 14:40:46 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 935543A68E8 for ; Mon, 21 Mar 2011 14:40:46 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p2LLgHL1021046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Mar 2011 22:42:17 +0100 (MET) From: Martin Rex Message-Id: <201103212142.p2LLgHQS017649@fs4113.wdf.sap.corp> To: paul@xelerance.com (Paul Wouters) Date: Mon, 21 Mar 2011 22:42:17 +0100 (MET) In-Reply-To: from "Paul Wouters" at Mar 21, 11 04:39:01 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 21:40:54 -0000 Paul Wouters wrote: > > On the contrary, that is *exactly* what the goal of 6066 is. It specifies as > reason "memory starved clients" and "reducing bandwidth", but why is that > list treated as an exclusive list? The real purpose of rfc6066 is really only what the last paragraph of the definition of this TLS extension says: http://tools.ietf.org/html/rfc6066#section-6 Servers that receive a client hello containing the "trusted_ca_keys" extension MAY use the information contained in the extension to guide their selection of an appropriate certificate chain to return to the client. In this event, the server SHALL include an extension of type "trusted_ca_keys" in the (extended) server hello. The "extension_data" field of this extension SHALL be empty. The semantics of a "Server Certificate" handshake message with no Certificates in it is UNDEFINED and therefore prohibited. The semantics of a "Client Certificate" handshake message with no Certificates is "NO client certificate" with _no_ slack. The TLS requirement for the Certificate handshake message says this: http://tools.ietf.org/html/rfc5246#section-7.4.2 Structure of this message: opaque ASN.1Cert<1..2^24-1>; struct { ASN.1Cert certificate_list<0..2^24-1>; } Certificate; certificate_list This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. There certainly are no "pre_agreed" semantics for the End-Entity(!) certificate in the TLS Certificate handshake message. What might be permissible (but is not an official part of the TLS spec) is to send the certificate chain only up to a signer known to the TLS peer. The CertificateRequest handshake message conveys the signer trusted by the Server to the client, so certificate path validation should be possible for a cert chain up to one of the announced trusted signers. If the client uses the TrustedAuthorities TLS extension, then personally, I would consider it permissible (but that is not officially part of the spec!) for the server to send his own cert chain only up to one of the trusted signers announced by the client through the TrustedAuthorities TLS extension. -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03F0E3A68E8 for ; Mon, 21 Mar 2011 14:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKJLNtYo3OCm for ; Mon, 21 Mar 2011 14:39:21 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 185AE3A68EB for ; Mon, 21 Mar 2011 14:39:21 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 50E46C57F; Mon, 21 Mar 2011 17:40:53 -0400 (EDT) Date: Mon, 21 Mar 2011 17:40:52 -0400 (EDT) From: Paul Wouters To: Eric Rescorla In-Reply-To: Message-ID: References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> <1300739370.2117.40.camel@localhost> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 21:39:22 -0000 On Mon, 21 Mar 2011, Eric Rescorla wrote: >> which is the case of the TLS client has gotten the public key from DNS using >> DANE. But it does not matter how the client obtained the trust. The client >> is telling the server it has all the required trust anchors, and that the >> server can ommit sending them over. > > There's a difference between end-entity certificates and trust anchors, and the > RFC 6066 text simply does not say that you can omit the EE cert. Thank you for pointing this out. Only now I understand what the objection is. Rereading 6066, it does seem to indicate the EE cert was not meant to be omitted, though the handshake diagram in 5246 seems to suggest it can be omitted. I will do some more re-reading of 5246. >> I can see how we would want the TLS client behaviour to be written down in a >> standards document, and I am more then happy to do so. > > In my opinion this is what would be required, and that document would need to > be standardized by the TLS WG. Okay. Thanks, Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3F6E3A68DA for ; Mon, 21 Mar 2011 14:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpJcIMK+gG7d for ; Mon, 21 Mar 2011 14:32:41 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id C8BCB3A63D2 for ; Mon, 21 Mar 2011 14:32:40 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id AD61CC57F; Mon, 21 Mar 2011 17:34:11 -0400 (EDT) Date: Mon, 21 Mar 2011 17:34:11 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> <1300739370.2117.40.camel@localhost> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 21:32:42 -0000 On Mon, 21 Mar 2011, Phillip Hallam-Baker wrote: > As a meta point here, the only point to doing work in IETF is to 1) get buy in from people in your working group and 2) > get buy in from people in other working groups. Which is why i'm here instead of jumping on the Kaminsky TXT band wagon. > Trying to use DANE as a means of eliminating X.509 from TLS is a non-starter as far as I am concerned. That has been loud and clear. However, it does not mean others should stop trying to innovate and move forward. [remainder vague generalities snipped] Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 394043A68CB for ; Mon, 21 Mar 2011 14:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8S558tUyv6BE for ; Mon, 21 Mar 2011 14:03:54 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 453E03A68BC for ; Mon, 21 Mar 2011 14:03:53 -0700 (PDT) Received: by qwg5 with SMTP id 5so5245369qwg.31 for ; Mon, 21 Mar 2011 14:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=abwdWT0oe9eCWWJAwBS7W9btQ/o91wOvTLvW0WyqcMQ=; b=S79Al1LCt+cqWB/vRsgON2lK+02qdzzx3LI9XxQw5ChiCmmVcsGqaQqZPxrwry+2wl VFAsbpTyRQCgkxIixGRx3cFjYMUxFFHtuLgc9ZjJeDwz5rlXeYZEvMt/O9GCGTs059uH yc6Kq4ZFVs/4ZozD6Cf6kGFb+3ELFsxaDtZ5Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PizphhhkCYjdgTo02N6HiSScKrhNBlKTWeDEgVRUAWeY6Y2qk7lPjX85BaiDc7lRzS eddMN2gPmqzziY4VBIk5zgknlUInEgS5RQl2pyk7eguc6quhLhJ3Nv1/F9na64v86eJU NF5jazyJEBBuk8IUqopM+v4jyQ5EZxDIxN/Eo= MIME-Version: 1.0 Received: by 10.224.173.79 with SMTP id o15mr3812778qaz.221.1300741526279; Mon, 21 Mar 2011 14:05:26 -0700 (PDT) Received: by 10.52.167.100 with HTTP; Mon, 21 Mar 2011 14:05:26 -0700 (PDT) In-Reply-To: References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> <1300739370.2117.40.camel@localhost> Date: Mon, 21 Mar 2011 17:05:26 -0400 Message-ID: From: Phillip Hallam-Baker To: Eric Rescorla Content-Type: multipart/alternative; boundary=20cf303343e99e548b049f047cb5 Cc: keyassure@ietf.org Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 21:03:55 -0000 --20cf303343e99e548b049f047cb5 Content-Type: text/plain; charset=ISO-8859-1 As a meta point here, the only point to doing work in IETF is to 1) get buy in from people in your working group and 2) get buy in from people in other working groups. Trying to use DANE as a means of eliminating X.509 from TLS is a non-starter as far as I am concerned. If this group is not going to listen to the TLS WG or the PKIX WG there is not a lot of point in it being here. Its like going to the Bayreuth festival and not wanting to go to opera. Trying to modify Internet protocols is like trying to change the wheels on a bike while the rider is still riding it (yeah, people really do that for a job). Trying to modify Internet security protocols is like playing a game of Jenga on the rider's helmet with the guy trying to change his wheel. What might appear to be a minor change to the protocol can have significant and unpredictable results throughout the system. The way we avoid such results is mostly to avoid changes that do not have a very very good justification. Not liking ASN.1 is not a justification in my view. --20cf303343e99e548b049f047cb5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As a meta point here, the only point to doing work in IETF is to 1) get buy= in from people in your working group and 2) get buy in from people in othe= r working groups.

Trying to use DANE as a means of eliminating X.509 from= TLS is a non-starter as far as I am concerned. If this group is not going = to listen to the TLS WG or the PKIX WG there is not a lot of point in it be= ing here. Its like going to the=A0Bayreuth festival=A0and not wanting to go= to opera.


Trying to modify Internet protocols is l= ike trying to change the wheels on a bike while the rider is still riding i= t (yeah, people really do that for a job).

Trying = to modify Internet security protocols is like playing a game of Jenga on th= e rider's helmet with the guy trying to change his wheel.


What might appear to be a minor change t= o the protocol can have significant and unpredictable results throughout th= e system.

The way we avoid such results is mostly = to avoid changes that do not have a very very good justification.


Not liking ASN.1 is not a justification = in my view.
--20cf303343e99e548b049f047cb5-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98B1728C172 for ; Mon, 21 Mar 2011 13:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.939 X-Spam-Level: X-Spam-Status: No, score=-102.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1flb6bsMsv3 for ; Mon, 21 Mar 2011 13:48:06 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id BF40928C17E for ; Mon, 21 Mar 2011 13:48:06 -0700 (PDT) Received: by iyi12 with SMTP id 12so7902216iyi.31 for ; Mon, 21 Mar 2011 13:49:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.117.8 with SMTP id r8mr1677817icq.37.1300740579422; Mon, 21 Mar 2011 13:49:39 -0700 (PDT) Received: by 10.42.217.2 with HTTP; Mon, 21 Mar 2011 13:49:39 -0700 (PDT) In-Reply-To: References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> <1300739370.2117.40.camel@localhost> Date: Mon, 21 Mar 2011 13:49:39 -0700 Message-ID: From: Eric Rescorla To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 20:48:07 -0000 On Mon, Mar 21, 2011 at 1:39 PM, Paul Wouters wrote: > On Mon, 21 Mar 2011, Matt McCutchen wrote: > >>> =A0 =A0- =A0"pre_agreed": no CA root key identity supplied. >> >> "pre_agreed" stands for a set of one or more trust anchors that is >> already known to the other side in the context of a particular >> deployment. =A0Hence, bandwidth is saved by not sending identifiers for >> the trust anchors. > > which is the case of the TLS client has gotten the public key from DNS us= ing > DANE. But it does not matter how the client obtained the trust. The clien= t > is telling the server it has all the required trust anchors, and that the > server can ommit sending them over. There's a difference between end-entity certificates and trust anchors, and= the RFC 6066 text simply does not say that you can omit the EE cert. > That is exactly what the option is meant > to do. I'm not sure it makes sense to get into questions of textual hermeneutics h= ere, but I don't recall anyone suggesting the omission of the EE cert while this draft was under discussion, so I don't think this assertion is very convinc= ing. > I can see how we would want the TLS client behaviour to be written down i= n a > standards document, and I am more then happy to do so. In my opinion this is what would be required, and that document would need = to be standardized by the TLS WG. > But adding a new > TLS client/server extension is silly. it would have the exact same semant= ics > as "pre_agreed", as I don't think we would want to state that the "new > pre-agreed" > can only be used if the client has used DANE to validate the key. This is > like > writing separate laws for email spam and fax spam.... That's for the TLS WG to decide. >> Using "pre_agreed" to tell the server it can skip >> sending a certificate chain is not envisioned by RFC 6066. > > On the contrary, that is *exactly* what the goal of 6066 is. It specifies= as > reason "memory starved clients" and "reducing bandwidth", but why is that > list treated as an exclusive list? See above. -Ekr Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57FFC28C175 for ; Mon, 21 Mar 2011 13:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSKE+-eWzZW7 for ; Mon, 21 Mar 2011 13:37:30 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 1E9443A6886 for ; Mon, 21 Mar 2011 13:37:30 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 2D284C5CA; Mon, 21 Mar 2011 16:39:02 -0400 (EDT) Date: Mon, 21 Mar 2011 16:39:01 -0400 (EDT) From: Paul Wouters To: Matt McCutchen In-Reply-To: <1300739370.2117.40.camel@localhost> Message-ID: References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> <1300739370.2117.40.camel@localhost> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 20:37:31 -0000 On Mon, 21 Mar 2011, Matt McCutchen wrote: >> - "pre_agreed": no CA root key identity supplied. > > "pre_agreed" stands for a set of one or more trust anchors that is > already known to the other side in the context of a particular > deployment. Hence, bandwidth is saved by not sending identifiers for > the trust anchors. which is the case of the TLS client has gotten the public key from DNS using DANE. But it does not matter how the client obtained the trust. The client is telling the server it has all the required trust anchors, and that the server can ommit sending them over. That is exactly what the option is meant to do. I can see how we would want the TLS client behaviour to be written down in a standards document, and I am more then happy to do so. But adding a new TLS client/server extension is silly. it would have the exact same semantics as "pre_agreed", as I don't think we would want to state that the "new pre-agreed" can only be used if the client has used DANE to validate the key. This is like writing separate laws for email spam and fax spam.... > Using "pre_agreed" to tell the server it can skip > sending a certificate chain is not envisioned by RFC 6066. On the contrary, that is *exactly* what the goal of 6066 is. It specifies as reason "memory starved clients" and "reducing bandwidth", but why is that list treated as an exclusive list? >> The only thing that is different here is that I am using a client contraint >> that is different from the examples listed at the start of section 6. > > What is different is that the server does not send a certificate chain. Which is exactly what happens on a TLS client preloaded with the root CA of the server, in a low memory or low bandwidth situation sending the "pre_agreed" option. Just because for bare public keys the client has a different format (or method) of getting that information should be irrelevant to 6066. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1630828C174 for ; Mon, 21 Mar 2011 13:28:09 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FybAO5emfC4O for ; Mon, 21 Mar 2011 13:28:00 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id 81B1528C16C for ; Mon, 21 Mar 2011 13:27:59 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id 5F95451C08B; Mon, 21 Mar 2011 13:29:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=bS5+9ikWm2+NW5hZKqTddlNJ6sYDcfPQdjBZWXAYqrQ x//TiIpE8YK9Zo3LKA5o2jQEbnPdjiX6xYP4R2ir51ivqSbAUCW0pE49K5jNxhge StS30jsM6j61tckmUPLPX2rKtLkfXUwS+xaIEc2dZW/cMrjOVnt0iflw1/cCTpIM = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=+5chxKb1mL4gxk/80z+pCnD+Wog=; b=eg7VHUp6Ck QM3BOCKXbWmg/QrvN9w+HRCmH94eLlnpJzHkxtnTD8NHzD3HOWOJW/8RYQEoIfz5 teLaw01UYkElYfBA1icQ4QEWEzhY0YlOfTfteXjug9YCi5yitZ6sJalSDtK72m9o Thk6rvOQs5hTBDBauXY1EV8CICyHu1z2o= Received: from [192.168.1.40] (pool-96-231-2-98.washdc.east.verizon.net [96.231.2.98]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPA id E6E3051C07C; Mon, 21 Mar 2011 13:29:31 -0700 (PDT) From: Matt McCutchen To: Paul Wouters In-Reply-To: References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Mon, 21 Mar 2011 16:29:30 -0400 Message-ID: <1300739370.2117.40.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 20:28:09 -0000 For completeness (I think the main points have been also made elsewhere): On Sun, 2011-03-20 at 22:18 -0400, Paul Wouters wrote: > On Sun, 20 Mar 2011, Matt McCutchen wrote: > > >> The client sends its hello message saying "I have all the CA root trust > >> anchors I need from pre-agreement". Whether that means it got information > >> from DNSSEC/DANE or elsewhere does not matter. What matters is, is that > >> the client can start the TLS handshake without the server sending any > >> PKIX certs. > > > > How does this look at the message level? The server sends a Certificate > > message containing a zero-length sequence of certificates? > > No, it sends an Hello TLS extension of type "trusted_ca_keys" containing > in its "extension_data" a 'struct' TrustedAuthorities containing one > "TrustedAuthority" that has an "IdentifierType" of "agreed" which is > 'struct {}' I understand that part. I was asking about the "without the server sending any PKIX certs" part. > > This is not > > at all what is envisioned by RFC 6066. To say that your scheme involves > > no TLS protocol changes is a little misleading: you are using existing > > messages but dramatically repurposing them. > > Not at all! According to 6066: > > 6. Trusted CA Indication > > > Constrained clients that, due to memory limitations, possess only a > small number of CA root keys may wish to indicate to servers which > root keys they possess, in order to avoid repeated handshake > failures. > > In order to indicate which CA root keys they possess, clients MAY > include an extension of type "trusted_ca_keys" in the (extended) > client hello. The "extension_data" field of this extension SHALL > contain "TrustedAuthorities" where: > > struct { > TrustedAuthority trusted_authorities_list<0..2^16-1>; > } TrustedAuthorities; > > struct { > IdentifierType identifier_type; > select (identifier_type) { > case pre_agreed: struct {}; > case key_sha1_hash: SHA1Hash; > case x509_name: DistinguishedName; > case cert_sha1_hash: SHA1Hash; > } identifier; > } TrustedAuthority; > > enum { > pre_agreed(0), key_sha1_hash(1), x509_name(2), > cert_sha1_hash(3), (255) > } IdentifierType; > > opaque DistinguishedName<1..2^16-1>; > > Here, "TrustedAuthorities" provides a list of CA root key identifiers > that the client possesses. Each CA root key is identified via > either: > > - "pre_agreed": no CA root key identity supplied. "pre_agreed" stands for a set of one or more trust anchors that is already known to the other side in the context of a particular deployment. Hence, bandwidth is saved by not sending identifiers for the trust anchors. Using "pre_agreed" to tell the server it can skip sending a certificate chain is not envisioned by RFC 6066. > > IMO, this scheme should be > > standardized and subjected to the attendant level of scrutiny before we > > consider supporting it in DANE. > > The only thing that is different here is that I am using a client contraint > that is different from the examples listed at the start of section 6. What is different is that the server does not send a certificate chain. -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B58473A687E for ; Mon, 21 Mar 2011 13:19:39 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oHzAHeZCT6O for ; Mon, 21 Mar 2011 13:19:32 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id B66153A6876 for ; Mon, 21 Mar 2011 13:19:32 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id 913DE348070; Mon, 21 Mar 2011 13:21:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=Vl6Gle0xU16LMr2dUwdySHj8rJhvzq2CZUXeC9Rfagc NBJkGwDqX+Z+67oALVbB1H9koD0cRiPr2cuKHMERWMTJi12EXDe/jYdXM2KSWdol lKnadeRJc8n/VzNzcUXS7Y63fLYu6ozqOAG2q+yoOh/tfk1qMbV0YzSXa49NEzRk = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=Hzlw6T6iz1E8Xw4IrykqhzfO0pU=; b=tvIZpndgwn g99hmbQcm8E2wsTmWrMeAsy+/szCA/QEm+8yjXQDSHS2us4TbbYEI05XuMwK8ew2 DFYfqyXLFbb+DpdMdblM9/pAdaV1fe+TYMNz+AWGFuPjBOn0uzONAWCOCanBajgB VnRlxJqQ71mgSucdH5uzBoLbdvGYTP55c= Received: from [192.168.1.40] (pool-96-231-2-98.washdc.east.verizon.net [96.231.2.98]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPA id 0AB8134806F; Mon, 21 Mar 2011 13:21:04 -0700 (PDT) From: Matt McCutchen To: Paul Wouters In-Reply-To: References: <201103211551.p2LFp5KR027266@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Mon, 21 Mar 2011 16:21:03 -0400 Message-ID: <1300738863.2117.33.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 20:19:39 -0000 On Mon, 2011-03-21 at 16:02 -0400, Paul Wouters wrote: > Section 7 of 5246 shows me: > > Client Server > > ClientHello --------> > ServerHello > Certificate* > ServerKeyExchange* > CertificateRequest* > <-------- ServerHelloDone > Certificate* > ClientKeyExchange > CertificateVerify* > [ChangeCipherSpec] > Finished --------> > [ChangeCipherSpec] > <-------- Finished > Application Data <-------> Application Data > > * Indicates optional or situation-dependent messages that are not > always sent. > > To me this seems to say that "Certificate*" on the server side could > be omitted in situation-dependent messages. Yes, as described elsewhere in the standard. It doesn't mean that you can omit the Certificate message whenever you please. -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5325B28C0EF for ; Mon, 21 Mar 2011 13:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.938 X-Spam-Level: X-Spam-Status: No, score=-102.938 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIGWysX+sLpQ for ; Mon, 21 Mar 2011 13:09:43 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 80A4028B56A for ; Mon, 21 Mar 2011 13:09:43 -0700 (PDT) Received: by iwl42 with SMTP id 42so7939022iwl.31 for ; Mon, 21 Mar 2011 13:11:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.145.72 with SMTP id e8mr7286902icv.506.1300738276164; Mon, 21 Mar 2011 13:11:16 -0700 (PDT) Received: by 10.42.217.2 with HTTP; Mon, 21 Mar 2011 13:11:16 -0700 (PDT) In-Reply-To: References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <2DDA94E3-3DF7-4A41-8C80-F1790B07C45C@vpnc.org> Date: Mon, 21 Mar 2011 13:11:16 -0700 Message-ID: From: Eric Rescorla To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 20:09:44 -0000 On Mon, Mar 21, 2011 at 12:57 PM, Paul Wouters wrote: > On Mon, 21 Mar 2011, Eric Rescorla wrote: > >> [Speaking as an individual] >> IMO the requirements of 5246 are fairly clear here: > >> In other words, when using any of the ordinarily certificate-based cipher >> suites >> (i.e., all the ones that everyone actually uses), it is not >> permissible either to omit the >> Certificate message or to have it be empty. This is not to say, of >> course, that you >> could not design an extension which would modify this behavior, but in the >> absence of such an extension, any server which does not send its >> certificate >> would not comply with RFC 5246. > > That extension seems to already have been made in RFC 6066. In my opinion, RFC 6066 does not relax the restriction to send Certificates nor does it relax the restriction that it contain the EE's certificate. >> [Speaking as TLS WG Chair] >> An extension along the lines indicated would change basic properties of >> TLS and >> IMO would need to go through the TLS WG, and certainly is outside the >> remit >> of this WG. > > Didn't 6066 go through that process? Yes. > Should an errata be issued stating that RFC6066, section 6, > TrustedAuthority case "pre_agreed" is deprecated? > > I do feel one of these choices has to be made. Either pre_agreed is a valid > part of > TLS, or it is not. It cannot be both. It is a valid part of TLS, but it is not designed to be used for the purpose you indicate. I think that's quite clear from the context of 6066. Obviously, nobody is going to stop you from doing whatever you want in your implementation. However, if you want to have an IETF standards track document that specifies that a TLS stack behave in a certain way then it would be good for that to match the TLS WG's understanding of what the documents say. -Ekr Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AB7728C0F4 for ; Mon, 21 Mar 2011 13:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgtE3LDzfU4D for ; Mon, 21 Mar 2011 13:00:41 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 4EFDF28C164 for ; Mon, 21 Mar 2011 13:00:33 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 14916C582; Mon, 21 Mar 2011 16:02:05 -0400 (EDT) Date: Mon, 21 Mar 2011 16:02:04 -0400 (EDT) From: Paul Wouters To: Martin Rex In-Reply-To: <201103211551.p2LFp5KR027266@fs4113.wdf.sap.corp> Message-ID: References: <201103211551.p2LFp5KR027266@fs4113.wdf.sap.corp> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org, paul.hoffman@vpnc.org Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 20:00:48 -0000 On Mon, 21 Mar 2011, Martin Rex wrote: > See http://tools.ietf.org/html/rfc5246#section-7.4.2 > > When this message will be sent: > > The server MUST send a Certificate message whenever the agreed- > upon key exchange method uses certificates for authentication > (this includes all key exchange methods defined in this document > except DH_anon). This message will always immediately follow the > ServerHello message. > > which part of the "MUST send" is unclear to you? > > What might be slighly misleading in that section is that it > defines a handshake message that is used in two situations > (Server Certificate and Client Certificate) and the semantics of an > empty Certificate handshake message is only defined for the > "Client Certificate" handshake message, but _NOT_ for the Server Certificate > handshake message. Section 7 of 5246 shows me: Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data * Indicates optional or situation-dependent messages that are not always sent. To me this seems to say that "Certificate*" on the server side could be omitted in situation-dependent messages. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3677C28C0F7 for ; Mon, 21 Mar 2011 12:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoXHy3XwIRip for ; Mon, 21 Mar 2011 12:55:32 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 63C2A28B56A for ; Mon, 21 Mar 2011 12:55:32 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id AB222C585; Mon, 21 Mar 2011 15:57:04 -0400 (EDT) Date: Mon, 21 Mar 2011 15:57:04 -0400 (EDT) From: Paul Wouters To: Eric Rescorla In-Reply-To: Message-ID: References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <2DDA94E3-3DF7-4A41-8C80-F1790B07C45C@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 19:55:33 -0000 On Mon, 21 Mar 2011, Eric Rescorla wrote: > [Speaking as an individual] > IMO the requirements of 5246 are fairly clear here: > In other words, when using any of the ordinarily certificate-based cipher suites > (i.e., all the ones that everyone actually uses), it is not > permissible either to omit the > Certificate message or to have it be empty. This is not to say, of > course, that you > could not design an extension which would modify this behavior, but in the > absence of such an extension, any server which does not send its certificate > would not comply with RFC 5246. That extension seems to already have been made in RFC 6066. > [Speaking as TLS WG Chair] > An extension along the lines indicated would change basic properties of TLS and > IMO would need to go through the TLS WG, and certainly is outside the remit > of this WG. Didn't 6066 go through that process? Should an errata be issued stating that RFC6066, section 6, TrustedAuthority case "pre_agreed" is deprecated? I do feel one of these choices has to be made. Either pre_agreed is a valid part of TLS, or it is not. It cannot be both. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65B0228C0DD for ; Mon, 21 Mar 2011 12:55:29 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnIl7FqF5+mK for ; Mon, 21 Mar 2011 12:55:21 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id E8F0A28B56A for ; Mon, 21 Mar 2011 12:55:21 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id AC80170407B; Mon, 21 Mar 2011 12:56:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=FtarSvaDm7EW742unPYzNVHbNchwBJU9mp+P9rWdbrG Wvql6wh007a6tsAaMgEvrvEhnWXe+7twSfjf4Z3Pa5NR771K0LpzFzfSnOxXyHWR KG9VeVpWs1aPV4BC/uZ0M4WkydMI70USoPMx7xrtXnxLGN6PV+AenG9qOUREQxaU = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=7rUk/sOoftF8b2uahnsyL9sWeQU=; b=cuyLc+06gW eu+b2/PKIjBD1HHuT7uoA5/I8MgTa0WhSw6nGZzYOSwDGH5RSjF13yIaRhtHHffO 44HSAxc//1jcKqUcEIj5Hucw/cML7CGUWLLlGIOzd3BpvgZ8L8HjNDA3+SfqJ8NG yZ9Yp5xxfYbTZla2P6yIJ1K2nb84tC3Jk= Received: from [192.168.1.40] (pool-96-231-2-98.washdc.east.verizon.net [96.231.2.98]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPA id 2D5E8704063; Mon, 21 Mar 2011 12:56:54 -0700 (PDT) From: Matt McCutchen To: Paul Wouters In-Reply-To: References: <061.05db8c262c83655cb47a8699cab6c2ac@trac.tools.ietf.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 21 Mar 2011 15:56:52 -0400 Message-ID: <1300737412.2117.22.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] [dane] #23: Asserting DANE exclusivity for an entire domain X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 19:55:29 -0000 On Mon, 2011-03-21 at 15:50 -0400, Paul Wouters wrote: > On Mon, 21 Mar 2011, dane issue tracker wrote: > > > #23: Asserting DANE exclusivity for an entire domain > > > > I would like to be able to assert DANE exclusivity for an entire domain so > > that, with respect to clients that check DANE first and fall back to a > > mainstream public CA list, a public CA cannot fabricate a TLS service I do > > not offer. > > Could this not be done by adding an "empty" CAA record? CAA is not DANE. > Also, is this not what people here call "dictating policy to the client" ? I responded to this objection the first time it was raised. http://www.ietf.org/mail-archive/web/keyassure/current/msg01700.html -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 642FD3A6856 for ; Mon, 21 Mar 2011 12:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d35ifBmCDVvT for ; Mon, 21 Mar 2011 12:49:02 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 608853A684D for ; Mon, 21 Mar 2011 12:49:02 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 5893CC585; Mon, 21 Mar 2011 15:50:34 -0400 (EDT) Date: Mon, 21 Mar 2011 15:50:33 -0400 (EDT) From: Paul Wouters To: dane issue tracker In-Reply-To: <061.05db8c262c83655cb47a8699cab6c2ac@trac.tools.ietf.org> Message-ID: References: <061.05db8c262c83655cb47a8699cab6c2ac@trac.tools.ietf.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] [dane] #23: Asserting DANE exclusivity for an entire domain X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 19:49:03 -0000 On Mon, 21 Mar 2011, dane issue tracker wrote: > #23: Asserting DANE exclusivity for an entire domain > > I would like to be able to assert DANE exclusivity for an entire domain so > that, with respect to clients that check DANE first and fall back to a > mainstream public CA list, a public CA cannot fabricate a TLS service I do > not offer. Could this not be done by adding an "empty" CAA record? Also, is this not what people here call "dictating policy to the client" ? Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EFD828C0DD for ; Mon, 21 Mar 2011 12:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp0JHtz58EZO for ; Mon, 21 Mar 2011 12:44:59 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 93E0628C0D7 for ; Mon, 21 Mar 2011 12:44:58 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 6FB9FC57F; Mon, 21 Mar 2011 15:46:29 -0400 (EDT) Date: Mon, 21 Mar 2011 15:46:28 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: <4BC9E139-CBC5-46EE-A18F-E8F16AE108D6@vpnc.org> Message-ID: References: <4D7BFB41.4000403@vpnc.org> <20110321092514.GE9247@anguilla.noreply.org> <20110321130430.GG9247@anguilla.noreply.org> <4BC9E139-CBC5-46EE-A18F-E8F16AE108D6@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Peter Palfrader , keyassure@ietf.org Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 19:45:00 -0000 On Mon, 21 Mar 2011, Paul Hoffman wrote: >> Why is it needed in the first place? > > > That's a very good question. I don't feel that it is a "need", but it "makes some sense". That is, if I want to go to www.example.com, and I get an A record for www.example.com, and I get a TLSA record for _http._tcp.www.example.com, and I get a certificate that says "this key is associated with www.somethingelse.com", what does it mean? > > I can see both ways: "it doesn't matter what the cert says, we are trusting the binding from the DNS" vs. "the cert needs to mean something"? Jakob and I have that text in because a number of people on the list were in the latter category, but it seems like a reasonable question to ask separately. This is exactly why bare public keys are good for those who do not wish to deal with a CA or making up arbitrary CN= entries in certificates only used to contain a public key verified by DNS. In fact, if forced to use a cert container, I would use a self signed *.xelerance.com, but I definitely not add a *.xelerance.com wildcard in DNS. Demanding information that will be filled in with bogus or unvalidatable information makes no sense from a security point of view. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AFBF3A6847 for ; Mon, 21 Mar 2011 12:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeUURJD5T4c1 for ; Mon, 21 Mar 2011 12:31:01 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 421363A6834 for ; Mon, 21 Mar 2011 12:31:01 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q1kq9-0002EH-Ng; Mon, 21 Mar 2011 12:32:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: matt@mattmccutchen.net X-Trac-Project: dane Date: Mon, 21 Mar 2011 19:32:33 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/23 Message-ID: <061.05db8c262c83655cb47a8699cab6c2ac@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: matt@mattmccutchen.net, keyassure@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: keyassure@ietf.org Subject: [keyassure] [dane] #23: Asserting DANE exclusivity for an entire domain X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 19:31:02 -0000 #23: Asserting DANE exclusivity for an entire domain I would like to be able to assert DANE exclusivity for an entire domain so that, with respect to clients that check DANE first and fall back to a mainstream public CA list, a public CA cannot fabricate a TLS service I do not offer. Previously discussed in [http://www.ietf.org/mail- archive/web/keyassure/current/msg01641.html this thread], but no final decision was reached. One approach to achieve this is to compose (1) a means of asserting the nonexistence of a TLS service at a (hostname, transport, port) triple and (2) a means of applying such an assertion to an entire domain except where otherwise specified. Zack Weinberg made a reasonable proposal for (1): use a single RR with "certificate type" 0 and no "certificate for association". (2) can be done with DNSSEC wildcards, but that is a little messy and will seriously bloat the zone if several different RRtypes each require this treatment. -- ------------------------------------+--------------------------------------- Reporter: matt@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Ticket URL: dane Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B26023A67B5 for ; Mon, 21 Mar 2011 11:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2uO56Jh-w0E for ; Mon, 21 Mar 2011 11:39:04 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id EC5453A67AA for ; Mon, 21 Mar 2011 11:39:03 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49171) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q1k1s-00063B-8n; Mon, 21 Mar 2011 14:40:36 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1300669586.2117.12.camel@localhost> References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> Date: Mon, 21 Mar 2011 14:33:32 -0400 To: Matt McCutchen From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 18:39:04 -0000 At 9:06 PM -0400 3/20/11, Matt McCutchen wrote: >On Sun, 2011-03-20 at 20:40 -0400, Paul Wouters wrote: >> On Sun, 20 Mar 2011, Paul Hoffman wrote: >> > If you want to add bare CA keys, that's fine, but I suspect that >>you actually want to add bare end entity keys, and RFC 6066 doesn't >>allow that. >> >> That difference is muddy anyway, isn't it? Isn't a self-signed >>certificate a CA? > >It is not used to sign any certificates (except itself, but that is >irrelevant because no one ever relies on the self signature), so no. as per the various 580 cites that Paul H. has put in the most recent version of the DANE spec, an SS cert is a CA cert, irrespective of whether it is used to verify sigs on other certs. The one slightly "muddy" situation is when an SS cert is used to convey a trust anchor. A TA is a CA in the usual case, but the cert is just a convenient container to convey the TA data, so there are no checks (in 5280) that are mandated for this case. Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 870D528C19B for ; Mon, 21 Mar 2011 11:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QymGkELdM4Ms for ; Mon, 21 Mar 2011 11:18:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BDC1428C199 for ; Mon, 21 Mar 2011 11:18:02 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q1jhX-00028A-69; Mon, 21 Mar 2011 11:19:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: matt@mattmccutchen.net X-Trac-Project: dane Date: Mon, 21 Mar 2011 18:19:35 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/22 Message-ID: <061.e0845de87f7a8d8d863b8ef546890255@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: matt@mattmccutchen.net, keyassure@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: keyassure@ietf.org Subject: [keyassure] [dane] #22: Provide the security of the strongest digest supported by both sides X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 18:18:03 -0000 #22: Provide the security of the strongest digest supported by both sides I posit that as a general principle, security protocols that support several alternative algorithms should provide the strength of the strongest algorithm supported by both sides. (TLS generally does this in the absence of active attacks.) For DANE, this principle means that I should be able to publish SHA-256 and SHA-512 digests in such a way that a client that supports SHA-512 gets the strength of SHA-512 and a client that supports only SHA-256 still works. This is not possible under the current design of the TLSA RRset. If I publish SHA-256 and SHA-512 digests, then clients that support SHA-512 will still accept any certificate that matches the SHA-256 digest. Indeed, there is no way for them to distinguish this scenario from one in which I have published the SHA-256 of one certificate and the SHA-512 of a different certificate. The necessary and sufficient fix is to indicate which digests refer to the same certificate, either via an ID number or by just putting all the digests of the same certificate in the same RR. The TLSA RRset is based on the DNSSEC DS RRset, which has the same problem. The DS RR contains a key tag, which could almost be used as an ID number, but [https://tools.ietf.org/html/rfc4034#appendix-B RFC 4034 Appendix B] says, "Implementations MUST NOT assume that the key tag uniquely identifies a DNSKEY RR." I would like to get the problem fixed in DNSSEC too, but I have not looked into that yet. -- ------------------------------------+--------------------------------------- Reporter: matt@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Ticket URL: dane Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA8D328C17E for ; Mon, 21 Mar 2011 10:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTk6V1CFf1t6 for ; Mon, 21 Mar 2011 10:30:00 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 4FDE728C165 for ; Mon, 21 Mar 2011 10:30:00 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 5A26E2A2703 for ; Mon, 21 Mar 2011 18:31:32 +0100 (CET) Message-ID: <4D878B74.6090100@nic.cz> Date: Mon, 21 Mar 2011 18:31:32 +0100 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Thunderbird/3.1.9 MIME-Version: 1.0 To: keyassure@ietf.org References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> In-Reply-To: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [keyassure] Issues that no longer issues? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 17:30:01 -0000 On 20.3.2011 19:57, Warren Kumari wrote: > Hi there all, > > It seems that there are a bunch of issues that are not anymore.... > > Issue #9: Self-Signed Certificates --- Addressed in the current version of the draft. > > Issue #11: Hash Function Strength --- Addressed in the current version of the draft, was discussed (and resolved) in issue #21. > > Issue #20: Change the format of the two fields to have fewer certificate types ---- Resolved quite a while ago, and discussed in issue #21. We used different numbers / algorithms. > > > Issue #5 is out of scope for the current draft, I think we'll close it and it can be reopened for a new draft that extends this sometime in the future.... > > > Seeing as there are done, we are planning on closing them (unless we hear any objections, preferably with text!). Just a friendly reminder, with Warren on the plain, I plan to close those issues with no comments (#9, #11 and #5) on tuesday/wednesday, so we have a cleaner table during the meeting. O. -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 642A328C0EB for ; Mon, 21 Mar 2011 08:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.02 X-Spam-Level: X-Spam-Status: No, score=-102.02 tagged_above=-999 required=5 tests=[AWL=0.579, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcMrIlvWGqHU for ; Mon, 21 Mar 2011 08:58:19 -0700 (PDT) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 344C428C0E2 for ; Mon, 21 Mar 2011 08:58:19 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2LFxm20097100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Mar 2011 08:59:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20110321130430.GG9247@anguilla.noreply.org> Date: Mon, 21 Mar 2011 08:59:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4BC9E139-CBC5-46EE-A18F-E8F16AE108D6@vpnc.org> References: <4D7BFB41.4000403@vpnc.org> <20110321092514.GE9247@anguilla.noreply.org> <20110321130430.GG9247@anguilla.noreply.org> To: Peter Palfrader X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 15:58:20 -0000 On Mar 21, 2011, at 6:04 AM, Peter Palfrader wrote: > On Mon, 21 Mar 2011, Jakob Schlyter wrote: >=20 >> On 21 mar 2011, at 10.25, Peter Palfrader wrote: >>=20 >>> Updating the certificate and its corresponding binding in DNS is not >>> dissimilar to updating DNSKEY and DS records: care must be taken to = get >>> the timing right, so that's a potential source of error. >>=20 >> Update TLSA resource records is very different from update DNSKEY et >> al. - as long as you take the TTL into consideration, you can update >> as you wish. >=20 > Create a new cert, create its hash, send to the DNS guys for = inclusion. > Wait TTL. > Deploy new cert. > Mail the DNS people that they can now remove the old hash. >=20 > That's not really something you want to have to do all that often. >=20 >>> But even if we do require SNI for TLSA to be useful with virtual >>> hosting, that still means a virtual hosting provider has to create a >>> certificate for each of the domains they want to serve[2]. >>=20 >> Yes, why would that be a problem? >=20 > Why is it needed in the first place? That's a very good question. I don't feel that it is a "need", but it = "makes some sense". That is, if I want to go to www.example.com, and I = get an A record for www.example.com, and I get a TLSA record for = _http._tcp.www.example.com, and I get a certificate that says "this key = is associated with www.somethingelse.com", what does it mean? I can see both ways: "it doesn't matter what the cert says, we are = trusting the binding from the DNS" vs. "the cert needs to mean = something"? Jakob and I have that text in because a number of people on = the list were in the latter category, but it seems like a reasonable = question to ask separately. --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18F728C167 for ; Mon, 21 Mar 2011 08:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.223 X-Spam-Level: X-Spam-Status: No, score=-10.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMbJyuqJ10ec for ; Mon, 21 Mar 2011 08:49:36 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id A56B128C0F2 for ; Mon, 21 Mar 2011 08:49:35 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p2LFp6qw016284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Mar 2011 16:51:06 +0100 (MET) From: Martin Rex Message-Id: <201103211551.p2LFp5KR027266@fs4113.wdf.sap.corp> To: paul@xelerance.com (Paul Wouters) Date: Mon, 21 Mar 2011 16:51:05 +0100 (MET) In-Reply-To: from "Paul Wouters" at Mar 20, 11 10:18:22 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org, paul.hoffman@vpnc.org Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 15:49:37 -0000 Paul Wouters wrote: > > > This is not > > at all what is envisioned by RFC 6066. To say that your scheme involves > > no TLS protocol changes is a little misleading: you are using existing > > messages but dramatically repurposing them. > > Not at all! According to 6066: > > 6. Trusted CA Indication The part most relevant to this discussion is this: Servers that receive a client hello containing the "trusted_ca_keys" extension MAY use the information contained in the extension to guide their selection of an appropriate certificate chain to return to the client. In this event, the server SHALL include an extension of type "trusted_ca_keys" in the (extended) server hello. The "extension_data" field of this extension SHALL be empty. This TLS extension is merely a hint, never a requirement. In the currently defined TLS protocol (and additional cipher suites documents) the Server Certificate handshake message is always sent, except for (1) anonymous cipher suites (dh_anon), or (2) TLS-PSK cipher suites (pre-shared keys, such as rfc4279). See http://tools.ietf.org/html/rfc5246#section-7.4.2 When this message will be sent: The server MUST send a Certificate message whenever the agreed- upon key exchange method uses certificates for authentication (this includes all key exchange methods defined in this document except DH_anon). This message will always immediately follow the ServerHello message. which part of the "MUST send" is unclear to you? What might be slighly misleading in that section is that it defines a handshake message that is used in two situations (Server Certificate and Client Certificate) and the semantics of an empty Certificate handshake message is only defined for the "Client Certificate" handshake message, but _NOT_ for the Server Certificate handshake message. -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D79173A687E for ; Mon, 21 Mar 2011 08:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.937 X-Spam-Level: X-Spam-Status: No, score=-102.937 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSA8qv75vQQt for ; Mon, 21 Mar 2011 08:35:32 -0700 (PDT) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by core3.amsl.com (Postfix) with ESMTP id BE57F3A687C for ; Mon, 21 Mar 2011 08:35:32 -0700 (PDT) Received: by gxk28 with SMTP id 28so3421368gxk.27 for ; Mon, 21 Mar 2011 08:37:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.82.1 with SMTP id j1mr1930157agl.15.1300721824872; Mon, 21 Mar 2011 08:37:04 -0700 (PDT) Received: by 10.90.72.16 with HTTP; Mon, 21 Mar 2011 08:37:01 -0700 (PDT) In-Reply-To: <2DDA94E3-3DF7-4A41-8C80-F1790B07C45C@vpnc.org> References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <2DDA94E3-3DF7-4A41-8C80-F1790B07C45C@vpnc.org> Date: Mon, 21 Mar 2011 08:37:01 -0700 Message-ID: From: Eric Rescorla To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 15:35:34 -0000 On Sun, Mar 20, 2011 at 6:10 PM, Paul Hoffman wrote= : > On Mar 20, 2011, at 5:40 PM, Paul Wouters wrote: >> Yes, we could make a TLS extension for "public_key" that works like serv= er_name, >> or we could extend server_name to take a new type "public_key", but ther= e >> is simply no need for such an extension, as the server does not need thi= s >> information and cannot do anyting with this information that is not alre= ady >> covered with trusted_ca_keys. > > We fully disagree about what the TLS 1.2 spec says. I'm happy to be wrong= about this if folks in the TLS WG agree with you, but your interpretation = seems novel, to say the least. I understand you not wanting to spend the ef= fort to do this properly with an extension to TLS; however, this WG cannot = just say that we don't care about the requirements in TLS 1.2. [Speaking as an individual] IMO the requirements of 5246 are fairly clear here: 7.4.2. Server Certificate When this message will be sent: The server MUST send a Certificate message whenever the agreed- upon key exchange method uses certificates for authentication (this includes all key exchange methods defined in this document except DH_anon). This message will always immediately follow the ServerHello message. Meaning of this message: This message conveys the server's certificate chain to the client. The certificate MUST be appropriate for the negotiated cipher suite's key exchange algorithm and any negotiated extensions. Structure of this message: opaque ASN.1Cert<1..2^24-1>; struct { ASN.1Cert certificate_list<0..2^24-1>; } Certificate; certificate_list This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. In other words, when using any of the ordinarily certificate-based cipher s= uites (i.e., all the ones that everyone actually uses), it is not permissible either to omit the Certificate message or to have it be empty. This is not to say, of course, that you could not design an extension which would modify this behavior, but in the absence of such an extension, any server which does not send its certificat= e would not comply with RFC 5246. [Speaking as TLS WG Chair] An extension along the lines indicated would change basic properties of TLS= and IMO would need to go through the TLS WG, and certainly is outside the remit of this WG. -Ekr Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 214F43A684A for ; Mon, 21 Mar 2011 06:03:00 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N87hgok1g7wd for ; Mon, 21 Mar 2011 06:02:59 -0700 (PDT) Received: from anguilla.debian.or.at (anguilla.debian.or.at [IPv6:2001:858:10f:6::2]) by core3.amsl.com (Postfix) with ESMTP id D96F93A6846 for ; Mon, 21 Mar 2011 06:02:58 -0700 (PDT) Received: by anguilla.debian.or.at (Postfix, from userid 1002) id 216E610EBAE; Mon, 21 Mar 2011 14:04:30 +0100 (CET) Date: Mon, 21 Mar 2011 14:04:30 +0100 From: Peter Palfrader To: keyassure@ietf.org Message-ID: <20110321130430.GG9247@anguilla.noreply.org> References: <4D7BFB41.4000403@vpnc.org> <20110321092514.GE9247@anguilla.noreply.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: X-PGP: 1024D/94C09C7F 5B00 C96D 5D54 AEE1 206B AF84 DE7A AF6E 94C0 9C7F X-Request-PGP: http://www.palfrader.org/keys/94C09C7F.asc X-Accept-Language: de, en User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Paul Hoffman Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 13:03:00 -0000 On Mon, 21 Mar 2011, Jakob Schlyter wrote: > On 21 mar 2011, at 10.25, Peter Palfrader wrote: > > > Updating the certificate and its corresponding binding in DNS is not > > dissimilar to updating DNSKEY and DS records: care must be taken to get > > the timing right, so that's a potential source of error. > > Update TLSA resource records is very different from update DNSKEY et > al. - as long as you take the TTL into consideration, you can update > as you wish. Create a new cert, create its hash, send to the DNS guys for inclusion. Wait TTL. Deploy new cert. Mail the DNS people that they can now remove the old hash. That's not really something you want to have to do all that often. > > But even if we do require SNI for TLSA to be useful with virtual > > hosting, that still means a virtual hosting provider has to create a > > certificate for each of the domains they want to serve[2]. > > Yes, why would that be a problem? Why is it needed in the first place? -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 881F63A680C for ; Mon, 21 Mar 2011 02:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ra1LxwPbV8WD for ; Mon, 21 Mar 2011 02:58:12 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id E80BD3A6807 for ; Mon, 21 Mar 2011 02:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=BqE8AcDPfsRcMhqk5fdR4lNYiTa8BALQ+d1awT16BAo=; b=MWt5pxkAS4a3cI3tYLMhKKxC9KFYMEfoAFuUpME3rguwAmb19/GID4RUEdSDCbm48pRyhZnTtG5Uq eWmsvEPhiG6yyaBzf3VNZOtp/y97wl87hXCMZnUoI48b4EZcDV4bWXRSHi0wn6pqH+2dV9Dp2GQQS4 kRpzfJP3LeW+gGII= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Mon, 21 Mar 2011 10:59:41 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <20110321092514.GE9247@anguilla.noreply.org> Date: Mon, 21 Mar 2011 10:59:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D7BFB41.4000403@vpnc.org> <20110321092514.GE9247@anguilla.noreply.org> To: Peter Palfrader X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 09:58:13 -0000 On 21 mar 2011, at 10.25, Peter Palfrader wrote: > Updating the certificate and its corresponding binding in DNS is not > dissimilar to updating DNSKEY and DS records: care must be taken to = get > the timing right, so that's a potential source of error. Update TLSA resource records is very different from update DNSKEY et al. = - as long as you take the TTL into consideration, you can update as you = wish. > But even if we do require SNI for TLSA to be useful with virtual > hosting, that still means a virtual hosting provider has to create a > certificate for each of the domains they want to serve[2]. Yes, why would that be a problem? jakob Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CEF93A6806 for ; Mon, 21 Mar 2011 02:23:49 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYiYhs7LZ2CR for ; Mon, 21 Mar 2011 02:23:45 -0700 (PDT) Received: from anguilla.debian.or.at (anguilla.debian.or.at [IPv6:2001:858:10f:6::2]) by core3.amsl.com (Postfix) with ESMTP id 4B5593A67A8 for ; Mon, 21 Mar 2011 02:23:45 -0700 (PDT) Received: by anguilla.debian.or.at (Postfix, from userid 1002) id 36CCD10EBC7; Mon, 21 Mar 2011 10:25:14 +0100 (CET) Date: Mon, 21 Mar 2011 10:25:14 +0100 From: Peter Palfrader To: keyassure@ietf.org Message-ID: <20110321092514.GE9247@anguilla.noreply.org> References: <4D7BFB41.4000403@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <4D7BFB41.4000403@vpnc.org> X-PGP: 1024D/94C09C7F 5B00 C96D 5D54 AEE1 206B AF84 DE7A AF6E 94C0 9C7F X-Request-PGP: http://www.palfrader.org/keys/94C09C7F.asc X-Accept-Language: de, en User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Paul Hoffman Subject: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 09:23:50 -0000 On Sat, 12 Mar 2011, Paul Hoffman wrote: > Comments are, of course, welcome. Verison 06 of the draft, in section 2.3, introduces this new paragraph: | The end entity certificate from TLS, regardless of whether it was | matched with a TLSA type 1 certificate or chained to a TLSA type 2 CA | certificate, must have at least one identifier in the subject or | subjectAltName field of the matched certificates matches the expected | identifier for the TLS server. [..] This requirement has been discussed in passing earlier already (e.g in the thread around [1]), but I think never exhaustively. If it has and I just missed it please accept my apologies (and I'd appreciate a pointer to the right thread). Do we assume that every client that will ever support TLSA will also support SNI? If not, then this would require that every time a virtual host is added to, or removed from a webserver the certificate be re-generated to update the list of SANs and the corresponding TLSA information be updated. Updating the certificate and its corresponding binding in DNS is not dissimilar to updating DNSKEY and DS records: care must be taken to get the timing right, so that's a potential source of error. Another drawback is that a having all the domains listed as subjectAltNames in a certificate leaks that list of domains hosted on a given server. But even if we do require SNI for TLSA to be useful with virtual hosting, that still means a virtual hosting provider has to create a certificate for each of the domains they want to serve[2]. This requirement seems to place some additional burden on the entity implementing TLSA, but it does not provide any benefit that is obvious to me. So I wonder what the rationale for needing a matching CN or SAN in the certificate is. Thanks, Peter 1. http://www.ietf.org/mail-archive/web/keyassure/current/msg01582.html 2. I am not familiar with hardware accelerators for RSA, but I assume there are certain limits on the number of keys such a thing can hold and some overhead for switching keys, so in the end a hoster might be tempted to create all the certificates from the same key material, maybe. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 577A228C107 for ; Sun, 20 Mar 2011 19:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6phleN1m7o3N for ; Sun, 20 Mar 2011 19:16:53 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 14A8A28C0F0 for ; Sun, 20 Mar 2011 19:16:52 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id BFD06C586; Sun, 20 Mar 2011 22:18:22 -0400 (EDT) Date: Sun, 20 Mar 2011 22:18:22 -0400 (EDT) From: Paul Wouters To: Matt McCutchen In-Reply-To: <1300669586.2117.12.camel@localhost> Message-ID: References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <1300669586.2117.12.camel@localhost> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 02:16:54 -0000 On Sun, 20 Mar 2011, Matt McCutchen wrote: >> That difference is muddy anyway, isn't it? Isn't a self-signed certificate a CA? > > It is not used to sign any certificates (except itself, but that is > irrelevant because no one ever relies on the self signature), so no. So if instead, I would send a list of 1 trusted_root_ca with the selfsigned Ca, then thatwould be "in spirit" or 6066? >> The client sends its hello message saying "I have all the CA root trust >> anchors I need from pre-agreement". Whether that means it got information >> from DNSSEC/DANE or elsewhere does not matter. What matters is, is that >> the client can start the TLS handshake without the server sending any >> PKIX certs. > > How does this look at the message level? The server sends a Certificate > message containing a zero-length sequence of certificates? No, it sends an Hello TLS extension of type "trusted_ca_keys" containing in its "extension_data" a 'struct' TrustedAuthorities containing one "TrustedAuthority" that has an "IdentifierType" of "agreed" which is 'struct {}' > This is not > at all what is envisioned by RFC 6066. To say that your scheme involves > no TLS protocol changes is a little misleading: you are using existing > messages but dramatically repurposing them. Not at all! According to 6066: 6. Trusted CA Indication Constrained clients that, due to memory limitations, possess only a small number of CA root keys may wish to indicate to servers which root keys they possess, in order to avoid repeated handshake failures. In order to indicate which CA root keys they possess, clients MAY include an extension of type "trusted_ca_keys" in the (extended) client hello. The "extension_data" field of this extension SHALL contain "TrustedAuthorities" where: struct { TrustedAuthority trusted_authorities_list<0..2^16-1>; } TrustedAuthorities; struct { IdentifierType identifier_type; select (identifier_type) { case pre_agreed: struct {}; case key_sha1_hash: SHA1Hash; case x509_name: DistinguishedName; case cert_sha1_hash: SHA1Hash; } identifier; } TrustedAuthority; enum { pre_agreed(0), key_sha1_hash(1), x509_name(2), cert_sha1_hash(3), (255) } IdentifierType; opaque DistinguishedName<1..2^16-1>; Here, "TrustedAuthorities" provides a list of CA root key identifiers that the client possesses. Each CA root key is identified via either: - "pre_agreed": no CA root key identity supplied. > IMO, this scheme should be > standardized and subjected to the attendant level of scrutiny before we > consider supporting it in DANE. The only thing that is different here is that I am using a client contraint that is different from the examples listed at the start of section 6. Was that list supposed to be an all encompassing list? I did not even add "pre_agreed". It is already there! Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0712E3A6C05 for ; Sun, 20 Mar 2011 18:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.015 X-Spam-Level: X-Spam-Status: No, score=-102.015 tagged_above=-999 required=5 tests=[AWL=0.584, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3WsHLnSzaX0 for ; Sun, 20 Mar 2011 18:08:53 -0700 (PDT) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 7E7E43A6C04 for ; Sun, 20 Mar 2011 18:08:52 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2L1ALYM058266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Mar 2011 18:10:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Sun, 20 Mar 2011 18:10:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2DDA94E3-3DF7-4A41-8C80-F1790B07C45C@vpnc.org> References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> To: Paul Wouters X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 01:08:54 -0000 On Mar 20, 2011, at 5:40 PM, Paul Wouters wrote: > On Sun, 20 Mar 2011, Paul Hoffman wrote: >=20 >> The definition in RFC 6066 for pre-agreed is "no CA root key identity = supplied". Later in the section it says "The option to include no CA = root keys is included to allow the client to indicate possession of some = pre-defined set of CA root keys." Note the use of "CA root key" in both = of those. >=20 > Yes. The predefined set of (required) CA root keys is the empty set. = But whether > it is a preloaded set from Versign or a preloaded set from Komodo, or = a preloaded > empty set is irrelevant to the server receiving a TLS trusted_ca_keys = extended option. >=20 >>> This means we will want to add bare public key into this draft, as = it >>> is the only document that would require changes for bare public key = to work. >>=20 >> If you want to add bare CA keys, that's fine, but I suspect that you = actually want to add bare end entity keys, and RFC 6066 doesn't allow = that. >=20 > That difference is muddy anyway, isn't it? No, not at all. Please see draft-ietf-dane-protocol-06, where Jakob and = I go into this in detail, including quoting from the PKIX standard. > Isn't a self-signed certificate a CA? Not unless it sets the right bits; again, see the current draft. >> If you are truly interested in bare CA keys, we can make that change = if the WG wants. However, I have heard no interest in bare CA keys from = anyone (including you) before today; all of the discussion of bare keys = was for end entity keys. For that, I believe you actually need to write = an extension to TLS. >=20 > We are talking about end entity keys. ...which is not what RFC 6066 is talking about. > The client sends its hello message saying "I have all the CA root = trust > anchors I need from pre-agreement". Whether that means it got = information > from DNSSEC/DANE or elsewhere does not matter. What matters is, is = that > the client can start the TLS handshake without the server sending any > PKIX certs. How do you get this from Section 7.4.2 of RFC 5246? Many sentences in = that section indicate that the server must send its PKIX certificate. I = believe the only way around that is to define a certificate type of = "bare key". > It can already accomplish this without using trusted_ca_keys, or if = the > server does not support the 6066 extension to supress sending its CA > cert chain(s). Not and be compatible with TLS 1.2, I believe. > Whether the client does this because it is "memory starved" (as per = 6066) > or because it obtained trust in the server pubkey via another set of > non-CA trust anchors does not really matter. All the server needs to > know is that it can ommit sending a giant blob of PKIX to the client. >=20 > The *only* thing needed for bare public keys to work is that the = client > does the DNS lookup for the bare key using DANE. No TLS protocol = change > is needed. Therefor, all we need is a method for specifying bare = public > keys in DNS, for which my previous email proposed a structure. >=20 > Yes, we could make a TLS extension for "public_key" that works like = server_name, > or we could extend server_name to take a new type "public_key", but = there > is simply no need for such an extension, as the server does not need = this > information and cannot do anyting with this information that is not = already > covered with trusted_ca_keys. We fully disagree about what the TLS 1.2 spec says. I'm happy to be = wrong about this if folks in the TLS WG agree with you, but your = interpretation seems novel, to say the least. I understand you not = wanting to spend the effort to do this properly with an extension to = TLS; however, this WG cannot just say that we don't care about the = requirements in TLS 1.2. --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36C063A6C04 for ; Sun, 20 Mar 2011 18:04:58 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uyLWXYPD8Bs for ; Sun, 20 Mar 2011 18:04:56 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id 7EC393A6A07 for ; Sun, 20 Mar 2011 18:04:56 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id A622F70406E; Sun, 20 Mar 2011 18:06:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=YTCABtMTZFgTZeXcau5/iDvhdq5P0rlPc2zizjlc21T V2ip87qC74Xj300lnp5r4bIb8ttsEc0KhPjgSRSwIOLnpDQLb6Vu/2m2WKYHM43x i6vnj+dUPX4NyWQstRUF/n48AffH04jSbNyLbVb45XTv6S4mtuJHo+1KAIYGc7Go = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=+9xmF1TiOZbB7KE2f4VJ5I6m8l4=; b=mnL+CUUwOl W0IzKSPg5i4tFHMkN0rlVaH1SBGB4i3PEwo6adkF4IwFBrO940rxIKKVJtSUKLFO 2ghlhY8lMlwTIXqWbfCVqAwgvHSoJ5YbIwBAZt4LZPvhihRdRDNWs8uUazDw/eON DDnpvbaf9BYjKxjUbYkwpfcubpuAONYBY= Received: from [192.168.1.40] (pool-96-231-2-98.washdc.east.verizon.net [96.231.2.98]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPA id 135B370406A; Sun, 20 Mar 2011 18:06:27 -0700 (PDT) From: Matt McCutchen To: Paul Wouters In-Reply-To: References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> Content-Type: text/plain; charset="UTF-8" Date: Sun, 20 Mar 2011 21:06:26 -0400 Message-ID: <1300669586.2117.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 01:04:58 -0000 On Sun, 2011-03-20 at 20:40 -0400, Paul Wouters wrote: > On Sun, 20 Mar 2011, Paul Hoffman wrote: > > If you want to add bare CA keys, that's fine, but I suspect that you actually want to add bare end entity keys, and RFC 6066 doesn't allow that. > > That difference is muddy anyway, isn't it? Isn't a self-signed certificate a CA? It is not used to sign any certificates (except itself, but that is irrelevant because no one ever relies on the self signature), so no. > > If you are truly interested in bare CA keys, we can make that change if the WG wants. However, I have heard no interest in bare CA keys from anyone (including you) before today; all of the discussion of bare keys was for end entity keys. For that, I believe you actually need to write an extension to TLS. > > We are talking about end entity keys. > > The client sends its hello message saying "I have all the CA root trust > anchors I need from pre-agreement". Whether that means it got information > from DNSSEC/DANE or elsewhere does not matter. What matters is, is that > the client can start the TLS handshake without the server sending any > PKIX certs. How does this look at the message level? The server sends a Certificate message containing a zero-length sequence of certificates? This is not at all what is envisioned by RFC 6066. To say that your scheme involves no TLS protocol changes is a little misleading: you are using existing messages but dramatically repurposing them. IMO, this scheme should be standardized and subjected to the attendant level of scrutiny before we consider supporting it in DANE. -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 197683A6C01 for ; Sun, 20 Mar 2011 17:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9PE9cQndLXI for ; Sun, 20 Mar 2011 17:39:07 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id F17853A6A07 for ; Sun, 20 Mar 2011 17:39:06 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id BF1A2C582; Sun, 20 Mar 2011 20:40:36 -0400 (EDT) Date: Sun, 20 Mar 2011 20:40:35 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> Message-ID: References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: keyassure@ietf.org Subject: Re: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 00:39:08 -0000 On Sun, 20 Mar 2011, Paul Hoffman wrote: > The definition in RFC 6066 for pre-agreed is "no CA root key identity supplied". Later in the section it says "The option to include no CA root keys is included to allow the client to indicate possession of some pre-defined set of CA root keys." Note the use of "CA root key" in both of those. Yes. The predefined set of (required) CA root keys is the empty set. But whether it is a preloaded set from Versign or a preloaded set from Komodo, or a preloaded empty set is irrelevant to the server receiving a TLS trusted_ca_keys extended option. >> This means we will want to add bare public key into this draft, as it >> is the only document that would require changes for bare public key to work. > > If you want to add bare CA keys, that's fine, but I suspect that you actually want to add bare end entity keys, and RFC 6066 doesn't allow that. That difference is muddy anyway, isn't it? Isn't a self-signed certificate a CA? > If you are truly interested in bare CA keys, we can make that change if the WG wants. However, I have heard no interest in bare CA keys from anyone (including you) before today; all of the discussion of bare keys was for end entity keys. For that, I believe you actually need to write an extension to TLS. We are talking about end entity keys. The client sends its hello message saying "I have all the CA root trust anchors I need from pre-agreement". Whether that means it got information from DNSSEC/DANE or elsewhere does not matter. What matters is, is that the client can start the TLS handshake without the server sending any PKIX certs. It can already accomplish this without using trusted_ca_keys, or if the server does not support the 6066 extension to supress sending its CA cert chain(s). Whether the client does this because it is "memory starved" (as per 6066) or because it obtained trust in the server pubkey via another set of non-CA trust anchors does not really matter. All the server needs to know is that it can ommit sending a giant blob of PKIX to the client. The *only* thing needed for bare public keys to work is that the client does the DNS lookup for the bare key using DANE. No TLS protocol change is needed. Therefor, all we need is a method for specifying bare public keys in DNS, for which my previous email proposed a structure. Yes, we could make a TLS extension for "public_key" that works like server_name, or we could extend server_name to take a new type "public_key", but there is simply no need for such an extension, as the server does not need this information and cannot do anyting with this information that is not already covered with trusted_ca_keys. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A93028C108 for ; Sun, 20 Mar 2011 17:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.01 X-Spam-Level: X-Spam-Status: No, score=-102.01 tagged_above=-999 required=5 tests=[AWL=0.589, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uxc-Aekv8Jhg for ; Sun, 20 Mar 2011 17:11:41 -0700 (PDT) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id E65CE28C100 for ; Sun, 20 Mar 2011 17:11:40 -0700 (PDT) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2L0DBZh056456 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 20 Mar 2011 17:13:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Paul Hoffman In-Reply-To: Date: Sun, 20 Mar 2011 17:13:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> To: keyassure@ietf.org X-Mailer: Apple Mail (2.1082) Subject: [keyassure] Bare keys again X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 00:11:42 -0000 On Mar 20, 2011, at 4:54 PM, Paul Wouters wrote: > On Sun, 20 Mar 2011, Warren Kumari wrote: >=20 >> Issue #20: Change the format of the two fields to have fewer = certificate types ---- Resolved quite a while ago, and discussed in = issue #21. We used different numbers / algorithms. >=20 > John Gilmore and me looked at TLS bare public key support and we = realised > that it requires no TLS protocol changes if we use RFC6066 = trusted_ca_keys > set to pre-agreed(0) in the client's extended hello options,meaning = the > server will supress sending any PKI certs. The definition in RFC 6066 for pre-agreed is "no CA root key identity = supplied". Later in the section it says "The option to include no CA = root keys is included to allow the client to indicate possession of some = pre-defined set of CA root keys." Note the use of "CA root key" in both = of those. > This means we will want to add bare public key into this draft, as it > is the only document that would require changes for bare public key to = work. If you want to add bare CA keys, that's fine, but I suspect that you = actually want to add bare end entity keys, and RFC 6066 doesn't allow = that. > It would require specifying the various bare public key formats = (likely > re-use the format from PKIX pubkey field, but use base64 encoding = instead > of DER encoding) >=20 > This would also require a few textual changes in the draft where it = now > states "certificate", as we could be using either a certificate or a = bare > public key. If you are truly interested in bare CA keys, we can make that change if = the WG wants. However, I have heard no interest in bare CA keys from = anyone (including you) before today; all of the discussion of bare keys = was for end entity keys. For that, I believe you actually need to write = an extension to TLS. --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69E063A6C01 for ; Sun, 20 Mar 2011 16:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbfjbJNAhUhD for ; Sun, 20 Mar 2011 16:53:21 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 7D5163A69CD for ; Sun, 20 Mar 2011 16:53:21 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 0B4D9C584; Sun, 20 Mar 2011 19:54:51 -0400 (EDT) Date: Sun, 20 Mar 2011 19:54:49 -0400 (EDT) From: Paul Wouters To: Warren Kumari , gnu@toad.com In-Reply-To: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> Message-ID: References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Issues that no longer issues? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 23:53:22 -0000 On Sun, 20 Mar 2011, Warren Kumari wrote: > Issue #20: Change the format of the two fields to have fewer certificate types ---- Resolved quite a while ago, and discussed in issue #21. We used different numbers / algorithms. John Gilmore and me looked at TLS bare public key support and we realised that it requires no TLS protocol changes if we use RFC6066 trusted_ca_keys set to pre-agreed(0) in the client's extended hello options,meaning the server will supress sending any PKI certs. This means we will want to add bare public key into this draft, as it is the only document that would require changes for bare public key to work. It would require specifying the various bare public key formats (likely re-use the format from PKIX pubkey field, but use base64 encoding instead of DER encoding) This would also require a few textual changes in the draft where it now states "certificate", as we could be using either a certificate or a bare public key. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D7723A6BDE for ; Sun, 20 Mar 2011 12:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ye3iffDUFfY for ; Sun, 20 Mar 2011 12:00:38 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id E25123A6BD8 for ; Sun, 20 Mar 2011 12:00:37 -0700 (PDT) Received: from [192.168.0.203] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id BBFE61B40967 for ; Sun, 20 Mar 2011 15:02:09 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 20 Mar 2011 15:02:08 -0400 Message-Id: <79D887E4-D75E-44CB-AFAD-4B5AED30094A@kumari.net> To: keyassure@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [keyassure] Starting Working Group Last Call for draft-ietf-dane-protocol-06 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 19:00:39 -0000 ........ Ok, we are not really doing this now, but, if we were, wouldn't if be = good to know what's actually *in* the draft?! [This is a subtle hint to go read it *before* the meeting] Here it is: https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/ W= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C30C13A6AB1 for ; Sun, 20 Mar 2011 11:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlqNlOUAzxxj for ; Sun, 20 Mar 2011 11:56:07 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id 0CD493A6986 for ; Sun, 20 Mar 2011 11:56:06 -0700 (PDT) Received: from [192.168.0.203] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 2E7161B40967 for ; Sun, 20 Mar 2011 14:57:38 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 20 Mar 2011 14:57:36 -0400 Message-Id: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> To: keyassure@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [keyassure] Issues that no longer issues? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 18:56:07 -0000 Hi there all, It seems that there are a bunch of issues that are not anymore.... Issue #9: Self-Signed Certificates --- Addressed in the current version = of the draft. Issue #11: Hash Function Strength --- Addressed in the current version = of the draft, was discussed (and resolved) in issue #21. Issue #20: Change the format of the two fields to have fewer certificate = types ---- Resolved quite a while ago, and discussed in issue #21. We = used different numbers / algorithms. Issue #5 is out of scope for the current draft, I think we'll close it = and it can be reopened for a new draft that extends this sometime in the = future.... Seeing as there are done, we are planning on closing them (unless we = hear any objections, preferably with text!). I'm about to get on a plane for Prague, so don't expect fast replies.... W= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE8BF3A7073 for ; Mon, 14 Mar 2011 16:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=-1.383, BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8M6WtFBHU2Z for ; Mon, 14 Mar 2011 16:30:44 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 996123A707A for ; Mon, 14 Mar 2011 16:30:29 -0700 (PDT) Received: by wwa36 with SMTP id 36so33793wwa.13 for ; Mon, 14 Mar 2011 16:31:53 -0700 (PDT) Received: by 10.216.142.34 with SMTP id h34mr2949492wej.28.1300145513164; Mon, 14 Mar 2011 16:31:53 -0700 (PDT) Received: from bblfish.home (ALagny-751-1-7-185.w86-218.abo.wanadoo.fr [86.218.106.185]) by mx.google.com with ESMTPS id f30sm3630259wef.31.2011.03.14.16.31.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Mar 2011 16:31:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/html; charset=us-ascii X-Apple-Base-Url: x-msg://4315/ X-Apple-Mail-Plain-Text-Draft: yes From: Henry Story X-Apple-Mail-Remote-Attachments: NO In-Reply-To: <4D63D865.70704@vpnc.org> X-Apple-Windows-Friendly: 1 Content-Transfer-Encoding: 7bit Message-Id: References: <4D619C94.8090702@vpnc.org> <93E9FABD-A84A-4A4E-AF96-6E101604F8B4@bblfish.net> <1FAB667F-44F9-4349-B11B-F4FECD51BB81@bblfish.net> <4D63D865.70704@vpnc.org> X-Uniform-Type-Identifier: com.apple.mail-draft To: Paul Hoffman X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] publishing the public key X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Mon, 14 Mar 2011 23:30:48 -0000 X-Original-Date: Tue, 22 Feb 2011 17:24:52 +0100 X-List-Received-Date: Mon, 14 Mar 2011 23:30:48 -0000 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F9693A6A0B for ; Sun, 13 Mar 2011 09:37:35 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrugDjCt2cBP for ; Sun, 13 Mar 2011 09:37:34 -0700 (PDT) Received: from anchor-post-1.mail.demon.net (anchor-post-1.mail.demon.net [195.173.77.132]) by core3.amsl.com (Postfix) with ESMTP id 1E62D3A69DB for ; Sun, 13 Mar 2011 09:37:34 -0700 (PDT) Received: from happyday.demon.co.uk ([80.177.121.10] helo=happyday.al.cl.cam.ac.uk) by anchor-post-1.mail.demon.net with esmtp (Exim 4.69) id 1PyoJj-00058v-iQ for keyassure@ietf.org; Sun, 13 Mar 2011 16:38:56 +0000 Message-ID: Date: Sun, 13 Mar 2011 16:37:35 +0000 To: keyassure@ietf.org From: Richard Clayton MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.03 M Subject: [keyassure] Call for Participation: SATIN 2011 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 16:37:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Call for Participation: Securing and Trusting Internet Names, SATIN 2011 ======================================================================== Registration is now open, and we look forward to seeing as many people as may wish to attend. When: Monday 4 & Tuesday 5 April 2011 Note that IETF 80 is in Prague, CZ the previous week Where: National Physical Laboratory (NPL) Teddington, London, UK Agenda: http://conferences.npl.co.uk/satin/agenda.html The intent is to make this a workshop that will expose the academics to the real problems that industry is encountering, and to show industry what academia has to offer them. To improve the flow of information, presentations will be restricted to 15 minutes with 15 minutes of general discussion to follow. The agenda also includes a "rump session" for brief presentations of "work in progress" by any attendee. More at: http://conferences.npl.co.uk/satin/ - -- Dr Richard Clayton tel: +44 1223 763570, mobile: +44 7887 794090 Computer Laboratory, University of Cambridge, CB3 0FD National Physical Laboratory, Hampton Road, Teddington, TW11 0LW -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBTXzyz+INNVchEYfiEQLlKACfcbzrhH9dvgDOsxXALfewEyRcFr4AoNQn lqg+QRBKU3RUripcs4vfksY8 =PEOM -----END PGP SIGNATURE----- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33FA43A6A85 for ; Sat, 12 Mar 2011 18:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.556 X-Spam-Level: X-Spam-Status: No, score=-103.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jzOdQnxyZgC for ; Sat, 12 Mar 2011 18:50:38 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 7A54A3A6A75 for ; Sat, 12 Mar 2011 18:50:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1299984720; x=1331520720; h=from:to:subject:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20keyassure@ietf.org|Subject:=20Re:=20[keyassure]=20 End=20entity=20certificate=20matching,=20trust=20anchors, =20and=20protocol-06|Message-Id:=20|Date:=20Sun,=2013=20Mar=202011 =2015:51:59=20+1300; bh=edtITiSHMNMiUA8VxTBmdKypeERUwY5IOl03SpNMN+A=; b=cwuRkIDI+5SK6Ffq+EHqjss2RDrXkm7S/FaiMOjPd3KA3pBHze4Uy3SB a6GV1Ey7MP8QS6wpc5BykeAeO8nJoHaFbtwhJCdwWa6HkN02dvmMGOoA9 qu/d5vlFAlXNDh/5ihuLqIZSPZTCcWL98cbEw+cygeC/KyeSHN+rHzMoP w=; X-IronPort-AV: E=Sophos;i="4.62,309,1296990000"; d="scan'208";a="50661164" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Mar 2011 15:51:59 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PybPT-0003zT-IA for keyassure@ietf.org; Sun, 13 Mar 2011 15:51:59 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PybPT-0002mJ-Iw for keyassure@ietf.org; Sun, 13 Mar 2011 15:51:59 +1300 From: Peter Gutmann To: keyassure@ietf.org Message-Id: Date: Sun, 13 Mar 2011 15:51:59 +1300 Subject: Re: [keyassure] End entity certificate matching, trust anchors, and protocol-06 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 02:50:40 -0000 Paul Hoffman writes: >You may be surprised both by the restrictions that PKIX puts on us (namely >that self-signed certificates are always CA certificates) and by the measures >suggested in -06 (format validation on end entity certificates is relaxed to >allow self-signed certificates for end entities). This particular issue has been an ongoing problem for years. More than a decade ago I proposed the ability to create straightforward self-issued certificates: http://www.cs.auckland.ac.nz/~pgut001/pubs/autonomous.txt but it was nixed by the PKIX chair with the comment "we're not going to turn X.509 into PGP". The need for this is as real as it was ten years ago, but I'm not sure how to progress it (I was told at the time that it would be seen by the IETF as falling within PKIX' purview, and they'd never allow it to be published, which is why I abandoned work on it). On a more general note, it's not surprising then that the current draft has to incorporate wording to say that you have to ignore the PKIX requirements. Peter. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6DA43A6A82 for ; Sat, 12 Mar 2011 18:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.555 X-Spam-Level: X-Spam-Status: No, score=-103.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xke9wJ8Y02+6 for ; Sat, 12 Mar 2011 18:41:26 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 7AF913A6A75 for ; Sat, 12 Mar 2011 18:41:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1299984168; x=1331520168; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20keyassure@ietf.org,=20paul.hoffman@vpnc.org |Subject:=20Re:=20[keyassure]=20End=20entity=20certificat e=20matching,=20trust=20anchors,=20and=20protocol-06 |In-Reply-To:=20<4D7BFB41.4000403@vpnc.org>|Message-Id: =20|Date: =20Sun,=2013=20Mar=202011=2015:42:44=20+1300; bh=sx5x8WylRYaRq2JGC0VDQRCfBt/DyAlVpXv7fSDSSIc=; b=EWWMeABfqr2FO3Es2fB4UpXzqO7t6zTgokigbEQxq0uzUuyBT40Be9Ro e8WIasIJaFzquakVH/4o7SrvslwrJrp73NS9fUiS25rYn45Z4aI3bVlD/ hn/HPbO0vL40o6D8Hs2R68AwhoDMdRM345QEYo/tXwiIJ5fhUS86xCgSn k=; X-IronPort-AV: E=Sophos;i="4.62,309,1296990000"; d="scan'208";a="50660804" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Mar 2011 15:42:44 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PybGW-0003iC-Ho; Sun, 13 Mar 2011 15:42:44 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PybGW-0002WW-FI; Sun, 13 Mar 2011 15:42:44 +1300 From: Peter Gutmann To: keyassure@ietf.org, paul.hoffman@vpnc.org In-Reply-To: <4D7BFB41.4000403@vpnc.org> Message-Id: Date: Sun, 13 Mar 2011 15:42:44 +1300 Subject: Re: [keyassure] End entity certificate matching, trust anchors, and protocol-06 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 02:41:27 -0000 Paul Hoffman writes: >Comments are, of course, welcome. Using http://tools.ietf.org/rfcdiff?url2=draft-ietf-dane-protocol-06.txt (which presnets -06 as diffs against -05) may be helpful here. Peter. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F8C03A6A15 for ; Sat, 12 Mar 2011 15:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YHvtjcbY3Hf for ; Sat, 12 Mar 2011 15:00:02 -0800 (PST) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 0D2DA3A6A5B for ; Sat, 12 Mar 2011 15:00:01 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2CN1MS6096345 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 12 Mar 2011 16:01:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D7BFB41.4000403@vpnc.org> Date: Sat, 12 Mar 2011 15:01:21 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "keyassure@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [keyassure] End entity certificate matching, trust anchors, and protocol-06 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 23:00:03 -0000 Greetings again. Draft -06 has two major changes, mandatory-to-implement algorithms and revised semantics for End entity certificate matching and trust anchors. The first is fairly straight-forward and hopefully exactly what was prescribed for the resolution to now-closed issue #21. The second is more problematic, which is reflected in the fact that there is now much more text. Please read the new text carefully, including the quoted text from RFC 5280. You may be surprised both by the restrictions that PKIX puts on us (namely that self-signed certificates are always CA certificates) and by the measures suggested in -06 (format validation on end entity certificates is relaxed to allow self-signed certificates for end entities). Comments are, of course, welcome. Proposals for new wording if needed are even more welcome. If we have made mistakes in reading RFC 5280, quoting from that document in your messages will be helpful to the entire WG. We will be presenting on this in Prague, but would love to see discussion happen in the weeks before then. --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68E643A68FD; Sat, 12 Mar 2011 14:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12YiwTMHIkYP; Sat, 12 Mar 2011 14:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4683A695B; Sat, 12 Mar 2011 14:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110312224502.21991.26756.idtracker@localhost> Date: Sat, 12 Mar 2011 14:45:02 -0800 Cc: keyassure@ietf.org Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-06.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 22:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Using Secure DNS to Associate Certificates with Domain Names For TLS Author(s) : P. Hoffman, J. Schlyter Filename : draft-ietf-dane-protocol-06.txt Pages : 13 Date : 2011-03-12 TLS and DTLS use certificates for authenticating the server. Users want their applications to verify that the certificate provided by the TLS server is in fact associated with the domain name they expect. DNSSEC provides a mechanism for a zone operator to sign DNS information directly. This way, bindings of keys to domains are asserted not by external entities, but by the entities that operate the DNS. This document describes how to use secure DNS to associate the TLS server's certificate with the intended domain name. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dane-protocol-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-12143807.I-D@ietf.org> --NextPart-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19AC23A690A for ; Fri, 11 Mar 2011 13:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.681 X-Spam-Level: X-Spam-Status: No, score=-106.681 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiD+vwWpoCio for ; Fri, 11 Mar 2011 13:17:16 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 45A6B3A693C for ; Fri, 11 Mar 2011 13:17:14 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-4.tower-120.messagelabs.com!1299878313!7494049!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 2486 invoked from network); 11 Mar 2011 21:18:33 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-4.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Mar 2011 21:18:33 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p2BLIuFu011355 for ; Fri, 11 Mar 2011 16:18:56 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p2BLItoC011329 for ; Fri, 11 Mar 2011 16:18:55 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p2BLIVLg009023 for ; Fri, 11 Mar 2011 16:18:31 -0500 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p2BLIPtB008017 for ; Fri, 11 Mar 2011 16:18:25 -0500 Received: from [135.91.110.95] (dn135-91-110-95.dhcpn.ugn.att.com[135.91.110.95]) by maillennium.att.com (mailgw1) with ESMTP id <20110311211825gw100e4l03e> (Authid: tony); Fri, 11 Mar 2011 21:18:25 +0000 X-Originating-IP: [135.91.110.95] Message-ID: <4D7A91A0.4060902@att.com> Date: Fri, 11 Mar 2011 16:18:24 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <397794924.536913.1299565388720.JavaMail.root@cm-mail03.mozilla.org> <4D765239.40408@ieca.com> <4D7658AA.9010003@vpnc.org> In-Reply-To: <4D7658AA.9010003@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 21:17:17 -0000 On 3/8/2011 11:26 AM, Paul Hoffman wrote: > On 3/8/11 8:10 AM, Nicholas Weaver wrote: >> (Not that I'm saying it should impede this group, I'm happing with >> the language above or similar, I just want to know why people want to >> use SHA-384 instead of SHA-512!) > > There is some reason to believe that the final SHA-3 spec will have a > 384-bit hash that will be faster to calculate than the 512-bit version, Given what NIST is doing with FIPS-180-4-draft and defining SHA-512/t, I'd be surprised if that were true. But it will be interesting to see what comes out of SHA3. > and it will be hard to convince people who were using SHA-2-512 that > going to SHA-3-384 is a good move. They'll claim that it is less safe > because they didn't realize that they didn't even need the strength in > SHA-2-256 to start with. > > It's all headology, unfortunately. Tony Hansen tony@att.com Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC2573A6B48 for ; Fri, 11 Mar 2011 10:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QniBdYM3N+AW for ; Fri, 11 Mar 2011 10:58:51 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id CEC403A68F5 for ; Fri, 11 Mar 2011 10:58:51 -0800 (PST) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id 37B5F1B401D8; Fri, 11 Mar 2011 14:00:11 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <4D7A70A7.8020103@vpnc.org> Date: Fri, 11 Mar 2011 14:00:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8EB57F84-0F78-4939-82FB-5B97FBFF2CD0@kumari.net> <4D7A70A7.8020103@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 18:58:53 -0000 On Mar 11, 2011, at 1:57 PM, Paul Hoffman wrote: > On 3/11/11 10:45 AM, Warren Kumari wrote: >> Ok, >>=20 >> We are calling (rough) consensus as: >>=20 >> SHA-256 MUST be implemented. >> SHA-512 SHOULD be implemented. >>=20 >> We fully expect to support SHA-3 once it is finalized, but we are not = currently reserving code-points for it. >> We can re-visit code-points for SHA-3 as we know more about it, how = many code-points it should have, etc. >=20 > Jakob and I will put out a new draft on Monday with this plus some = different wording on trust anchors (the latter being still confusing to = some folks). The chairs would like to thank our authors for being on top of things, = quickly integrating WG consensus and writing such a readable doc.... W >=20 > --Paul Hoffman > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure >=20 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3713B3A6C6F for ; Fri, 11 Mar 2011 10:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.971 X-Spam-Level: X-Spam-Status: No, score=-101.971 tagged_above=-999 required=5 tests=[AWL=0.628, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrJVNI3yr9gO for ; Fri, 11 Mar 2011 10:56:27 -0800 (PST) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id C9BE93A6B49 for ; Fri, 11 Mar 2011 10:56:25 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2BIviif039701 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 11 Mar 2011 11:57:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D7A70A7.8020103@vpnc.org> Date: Fri, 11 Mar 2011 10:57:43 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: keyassure@ietf.org References: <8EB57F84-0F78-4939-82FB-5B97FBFF2CD0@kumari.net> In-Reply-To: <8EB57F84-0F78-4939-82FB-5B97FBFF2CD0@kumari.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 18:56:28 -0000 On 3/11/11 10:45 AM, Warren Kumari wrote: > Ok, > > We are calling (rough) consensus as: > > SHA-256 MUST be implemented. > SHA-512 SHOULD be implemented. > > We fully expect to support SHA-3 once it is finalized, but we are not currently reserving code-points for it. > We can re-visit code-points for SHA-3 as we know more about it, how many code-points it should have, etc. Jakob and I will put out a new draft on Monday with this plus some different wording on trust anchors (the latter being still confusing to some folks). --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C6D53A6C6F for ; Fri, 11 Mar 2011 10:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DYkMGU0qx5e for ; Fri, 11 Mar 2011 10:51:31 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 182DA3A6B49 for ; Fri, 11 Mar 2011 10:51:31 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Py7SE-0007Id-C9; Fri, 11 Mar 2011 10:52:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: warren@kumari.net X-Trac-Project: dane Date: Fri, 11 Mar 2011 18:52:50 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/21#comment:1 Message-ID: <069.9ae8482dba590afd3b16d4ebca74bf9d@trac.tools.ietf.org> References: <060.7d08a09e8dc701e85028c142516ecaa0@trac.tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <060.7d08a09e8dc701e85028c142516ecaa0@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: warren@kumari.net, keyassure@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: keyassure@ietf.org Subject: Re: [keyassure] [dane] #21: Need to specify which crypto algorithms and certificate types are mandatory to implement X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 18:51:32 -0000 #21: Need to specify which crypto algorithms and certificate types are mandatory to implement Changes (by warren@…): * status: new => closed * resolution: => fixed Comment: We are calling (rough) consensus as: SHA-256 MUST be implemented. SHA-512 SHOULD be implemented. We fully expect to support SHA-3 once it is finalized, but we are not currently reserving code-points for it. We can re-visit code-points for SHA-3 as we know more about it, how many code-points it should have, etc. -- -----------------------------------+---------------------------------------- Reporter: paul.hoffman@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------------+---------------------------------------- Ticket URL: dane Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 647C73A691E for ; Fri, 11 Mar 2011 10:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.392 X-Spam-Level: X-Spam-Status: No, score=-101.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlLVBSlclUYy for ; Fri, 11 Mar 2011 10:44:35 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id A49503A68CB for ; Fri, 11 Mar 2011 10:44:35 -0800 (PST) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id F04431B401D8 for ; Fri, 11 Mar 2011 13:45:54 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Warren Kumari In-Reply-To: Date: Fri, 11 Mar 2011 13:45:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8EB57F84-0F78-4939-82FB-5B97FBFF2CD0@kumari.net> References: To: keyassure@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 18:44:36 -0000 Ok,=20 We are calling (rough) consensus as: SHA-256 MUST be implemented. SHA-512 SHOULD be implemented. We fully expect to support SHA-3 once it is finalized, but we are not = currently reserving code-points for it.=20 We can re-visit code-points for SHA-3 as we know more about it, how many = code-points it should have, etc.=20 W Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AC1B3A67AB for ; Tue, 8 Mar 2011 16:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.925 X-Spam-Level: X-Spam-Status: No, score=-101.925 tagged_above=-999 required=5 tests=[AWL=0.674, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rhu55uIiZU4o for ; Tue, 8 Mar 2011 16:16:45 -0800 (PST) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 534A33A67D2 for ; Tue, 8 Mar 2011 16:16:45 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p290HxoJ058113 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 8 Mar 2011 17:18:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D76C738.1010403@vpnc.org> Date: Tue, 08 Mar 2011 16:18:00 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: keyassure@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 00:16:46 -0000 On 3/8/11 3:48 PM, Peter Gutmann wrote: > > Martin Rex writes: > >> The only two situations, where *I* believe that having more than one >> mandatory to implement hash algorithms for DANE would make sense: >> >> 1) when SHA-1 was permitted (which no one seems to be asking for) >> 2) when the SHA-3 winner has been determined (which hasn't happened yet) >> >> Personally, I would strongly prefer the hash algorithm list for DANE to be >> >> 1) SHA-256 (FIPS 180-3) MUST implement >> 2) SHA-512 (FIPS 180-3) SHOULD implement > > +1. FWIW, I have been saying that I support two MUSTs, but I think most of the milage of that is gotten by one MUST and one SHOULD. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAEB93A67D2 for ; Tue, 8 Mar 2011 15:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXY8OPhjd4HY for ; Tue, 8 Mar 2011 15:50:40 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 607F03A67E3 for ; Tue, 8 Mar 2011 15:50:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1299628316; x=1331164316; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20bmanning@vacation.karoshi.com,=20mrex@sap.com |Subject:=20Re:=20[keyassure]=20Opening=20issue=20#21:=20 "Need=20to=20specify=20which=20crypto|Cc:=20keyassure@iet f.org|In-Reply-To:=20<20110308180516.GC23708@vacation.kar oshi.com.>|Message-Id:=20|Date:=20Wed,=2009=20Mar=202011=2012:51:55 =20+1300; bh=aasBi21FWxbs5HkNAJohDZtsecVa/sbX4Ozdw7oNEZA=; b=ARnjTTjNWbqioWYlx5JCJ0MlkV10BmcscRSv4BSm3MqZ85rQ3AibcLbm 0xQzt5KzhFbsBQkIH5q4zjL0M+qc7edfhMw37GuUCdJe6d59nzKDdMfMV 1WHfPjeuIk8ASogaWjMraKQN51Wd3sY71OmcG11DtbciQCG80ODc4bYTP A=; X-IronPort-AV: E=Sophos;i="4.62,286,1296990000"; d="scan'208";a="49994967" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Mar 2011 12:51:55 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Px6h1-0006md-Hl; Wed, 09 Mar 2011 12:51:55 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Px6h1-0001PH-Eo; Wed, 09 Mar 2011 12:51:55 +1300 From: Peter Gutmann To: bmanning@vacation.karoshi.com, mrex@sap.com In-Reply-To: <20110308180516.GC23708@vacation.karoshi.com.> Message-Id: Date: Wed, 09 Mar 2011 12:51:55 +1300 Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 23:50:41 -0000 bmanning@vacation.karoshi.com writes: >given the pace of the IETF processes, I fully expect there will be a SHA-3 >finalist selected before this spec lands. (YMMV of course) That was my feeling as well, which is why I've been pushing for slots for SHA3 (specifically, SHA3-256 MUST, SHA3-512 MAY). Peter. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D371A3A67D1 for ; Tue, 8 Mar 2011 15:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.548 X-Spam-Level: X-Spam-Status: No, score=-103.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0bHDLG5v5qd for ; Tue, 8 Mar 2011 15:47:32 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id A513A3A67C2 for ; Tue, 8 Mar 2011 15:47:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1299628128; x=1331164128; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20mrex@sap.com|Subject:=20Re:=20[keyassure]=20Openin g=20issue=20#21:=20"Need=20to=20specify=20which=20crypto |Cc:=20keyassure@ietf.org|In-Reply-To:=20<201103081657.p2 8GvYwq001089@fs4113.wdf.sap.corp>|Message-Id:=20|Date:=20Wed,=2009 =20Mar=202011=2012:48:47=20+1300; bh=0Ud2klHsjTvyypYd+A0HWxfwBM3LXFIC+5AoXtLJRCU=; b=NgWMUePeAhPlfZRI3Az9OJUZsPlnwWQdmkCpIYWy1pRCwv06/qJxcqez VRpvkxyWvP883fworPrIvjvYLrfDEflXjFsr5Y2rrTtfxzI8kUKPDFIt/ u6Z/dM/G8O9NRQvceWHds8wyQHcc+3uA7CpJx8/1NT85Dkyv6uP3Y+Rli M=; X-IronPort-AV: E=Sophos;i="4.62,286,1296990000"; d="scan'208";a="49993980" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Mar 2011 12:48:48 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Px6dz-0006dl-IQ; Wed, 09 Mar 2011 12:48:47 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Px6dz-0001Hb-LV; Wed, 09 Mar 2011 12:48:47 +1300 From: Peter Gutmann To: mrex@sap.com In-Reply-To: <201103081657.p28GvYwq001089@fs4113.wdf.sap.corp> Message-Id: Date: Wed, 09 Mar 2011 12:48:47 +1300 Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 23:47:33 -0000 Martin Rex writes: >The only two situations, where *I* believe that having more than one >mandatory to implement hash algorithms for DANE would make sense: > > 1) when SHA-1 was permitted (which no one seems to be asking for) > 2) when the SHA-3 winner has been determined (which hasn't happened yet) > >Personally, I would strongly prefer the hash algorithm list for DANE to be > > 1) SHA-256 (FIPS 180-3) MUST implement > 2) SHA-512 (FIPS 180-3) SHOULD implement +1. >Personally, I believe that SHA-384, and more so SHA-224 should have never >been defined by NIST, because they constantly confuse the crypto-clueless >about the purpose of these algorithms and cause needless discussions. Even more so. Peter. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DAA93A67AB for ; Tue, 8 Mar 2011 15:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.545 X-Spam-Level: X-Spam-Status: No, score=-103.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4M5Gkfohs6H for ; Tue, 8 Mar 2011 15:41:43 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 86B5D3A67B1 for ; Tue, 8 Mar 2011 15:41:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1299627779; x=1331163779; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20bmanning@vacation.karoshi.com,=20hallam@gmail.com |Subject:=20Re:=20[keyassure]=20Opening=20issue=20#21:=20 "Need=20to=20specify=20which=20crypto|Cc:=20keyassure@iet f.org|In-Reply-To:=20|Message-Id:=20|Date:=20Wed,=2009=20Mar=20 2011=2012:42:56=20+1300; bh=PjZfJplYB0nkW7qP4G5duoSaLE9ifLheg2HO1/6Oq7k=; b=kdk8C2txrUUD6LFdKHnDVLkxi1Np+wj4R2Lhi1x+b2X+1mUQrj1Z2Qtu MOqMlgg5GfHNOfxHX77E+KQ+/bLqnJjyCcWVHbyOF/ewSOgjBtIVKOvKF i6Nyw7aMGHE0JFPe+eKPCdBO3dMFpDvaUsoRaHUWwsfoZ/w8cuRBHwW4N A=; X-IronPort-AV: E=Sophos;i="4.62,286,1296990000"; d="scan'208";a="49992112" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Mar 2011 12:42:57 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Px6YK-0006OV-Im; Wed, 09 Mar 2011 12:42:56 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Px6YK-00018y-P3; Wed, 09 Mar 2011 12:42:56 +1300 From: Peter Gutmann To: bmanning@vacation.karoshi.com, hallam@gmail.com In-Reply-To: Message-Id: Date: Wed, 09 Mar 2011 12:42:56 +1300 Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 23:41:45 -0000 Phillip Hallam-Baker writes: >Given that SHA2-512 is fastest on 64 bit machines and given that these are >now the mainstream, Really? When did smart phones and the like switch to 64-bit processors? I must have missed the announcement. (The platforms where performance is irrelevant because the CPU is just sitting there twiddling its thumbs waiting for the next job, desktop PCs and the like, are 64-bit, although even there most are running in 32-bit mode. The platforms where performance is critical because of lack of CPU power and lack of battery power to drive it, are all 32 bit). Peter. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58AF73A659B for ; Tue, 8 Mar 2011 15:19:49 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrMd06wiIY1Y for ; Tue, 8 Mar 2011 15:19:48 -0800 (PST) Received: from mail1.eff.org (mail1.eff.org [64.147.188.4]) by core3.amsl.com (Postfix) with ESMTP id 51FF23A67B7 for ; Tue, 8 Mar 2011 15:19:48 -0800 (PST) Received: from [192.168.1.33] (gw-shotwell.eff.org [75.101.97.66]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: chris) by mail1.eff.org (Postfix) with ESMTPSA id 943AEBE12E for ; Tue, 8 Mar 2011 15:21:05 -0800 (PST) Message-ID: <4D76BA16.8050105@eff.org> Date: Tue, 08 Mar 2011 15:21:58 -0800 From: Chris Palmer User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: keyassure@ietf.org References: <201103081657.p28GvYwq001089@fs4113.wdf.sap.corp> <20110308180516.GC23708@vacation.karoshi.com.> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 23:19:49 -0000 On 03/08/2011 12:47 PM, Phillip Hallam-Baker wrote: > Given that SHA2-512 is fastest on 64 bit machines and given that these > are now the mainstream, Not necessarily. For normal servers, yes of course; but having spiffy machines means that the previous generation of spiffy machines is now available for use in cheap appliances. Lots of people want those, too, and want them to perform well. I personally wouldn't mind having SHA-512 be the only mandatory hash, but reasonable people will bring up this "why penalize cheap servers" argument. -- Chris Palmer Technology Director, Electronic Frontier Foundation https://www.eff.org/code Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8F7B3A635F for ; Tue, 8 Mar 2011 12:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.564 X-Spam-Level: X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99M9KAdJ1wwQ for ; Tue, 8 Mar 2011 12:45:52 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id EE4653A6359 for ; Tue, 8 Mar 2011 12:45:51 -0800 (PST) Received: by bwz13 with SMTP id 13so182137bwz.31 for ; Tue, 08 Mar 2011 12:47:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bKzwR/bVGxynoHA8ML0B/wqDqyhWKjmuabddzGXw9po=; b=rmAWum8hpGeY8mVloTTh7O3uwaZ5qL1Ld1JufdUuZwfmAJ7erubRw8mQXggA61huN4 rCKf2LcoA+Gt8E8HpjgP1BX0L8BAfVJwwFrLT+hwMUUfdcbclUKazAHITQ0RfSN5Ca+K K2bIdXZB8FJhNtLtttC1hKB8uipqIyyI7BysY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dCkFFs/ZWXPkfXF0SffUOhC7+PB1RIRwGRFj/x3X5Ezg4vl+7LqNDsvltNOcSlD8o5 4fEP0TxffN+B4CMWfMTCMXc5ib4HiTsR9mxB+ZSC+HdDiDLFOI8wcCC8VBB1qkq9HCdK EDIlolz6voI3ODkRQloT/+osQvxjQPldY88Fk= MIME-Version: 1.0 Received: by 10.204.59.140 with SMTP id l12mr4694449bkh.168.1299617226410; Tue, 08 Mar 2011 12:47:06 -0800 (PST) Received: by 10.204.14.139 with HTTP; Tue, 8 Mar 2011 12:47:06 -0800 (PST) In-Reply-To: <20110308180516.GC23708@vacation.karoshi.com.> References: <201103081657.p28GvYwq001089@fs4113.wdf.sap.corp> <20110308180516.GC23708@vacation.karoshi.com.> Date: Tue, 8 Mar 2011 15:47:06 -0500 Message-ID: From: Phillip Hallam-Baker To: bmanning@vacation.karoshi.com Content-Type: multipart/alternative; boundary=001636ed6d011fd7ff049dfeb7af Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 20:45:53 -0000 --001636ed6d011fd7ff049dfeb7af Content-Type: text/plain; charset=ISO-8859-1 Quite possibly, but most people know not to wait for IETF process before deployment. I don't like the idea of SHA2-512/256 because the new IV is going to require people to use a different code library to get support and that may be tricky. Given that SHA2-512 is fastest on 64 bit machines and given that these are now the mainstream, would it not make sense to simply go to SHA2-384 or SHA2-512 as the only mandatory for the time being with the expectation of adding in some flavor of SHA3 when that is possible? I think we need to break this down in matrix fashion 1) Attack A compromise that could lead an attacker to break DANE. 2) Reputation A compromise that falls short of enabling an actual attack against DANE but will lead to concerns amongst users and pressure for a new algorithm. (c.f. demands to change HMAC-MD5 despite no evidence this is necessary). 3) Support Is the algorithm supported in standard cryptographic toolkits, is widespread support to be expected in the future. 4) Performance Not really a factor for this application but will determine whether it is used for other purposes. 5) Industry Is the algorithm THE industry standard or merely A standard. SHA-1: Good for 20 years on attack but unknown as far as reputation. Is the main target of cryptanalysis at the moment. Support is universal. SHA2-256: Good for 30+ years on attack and at least 10 for reputation. Support is near universal. SHA2-386: Good for 40+ years on attack and probably 30+ for reputation. Support is near universal SHA2-512: Good for 50+ years on attack but likely 20+ on reputation due to the fact that if 512 bits is specified in a protocol it is difficult to explain why less than 512 bits are necessary. SHA3-*: Will be THE standard in some strength as far as we can predict. While it is possible something else will beat SHA3, I can't see that happening and people being happy with SHA2. So my recommendation would be 1) Do not define any code point for SHA1. 2) Define code point for SHA2-384 3) Expect to support SHA3 in the future via some mechanism. Add it to the draft if the competition schedule makes this practical. As a general rule I would prefer to only define IANA code points for algorithms that the IETF REQUIRES. I would support all other crypto by reserving one code point for specifying algorithms by means of ASN.1 OID prefix. The reason for doing that is that it means that the group does not need to consider the inevitable requests to support other algorithms or deal with the damage caused when a refusal is ignored. We cannot stop the Russian federation from using GOST but we can stop them getting a reserved code point. On Tue, Mar 8, 2011 at 1:05 PM, wrote: > On Tue, Mar 08, 2011 at 05:57:34PM +0100, Martin Rex wrote: > > > > It fosters on the premise that SHA-1 is completely and throroughly > > broken and SHA-256 impaired by more serious attacks than currently > > known for SHA-1 _long_ before a SHA-3 finalist is selected. > > > > > > -Martin > > my working analog here is that you don't shoot at a moving > target - you shoot ahead of it. > > given the pace of the IETF processes, I fully expect there will > be a SHA-3 finalist selected before this spec lands. (YMMV of > course) > > --bill > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --001636ed6d011fd7ff049dfeb7af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Quite possibly, but most people know not to wait for IETF process before de= ployment.

I don't like the idea of SHA2-512/256 beca= use the new IV is going to require people to use a different code library t= o get support and that may be tricky.

Given that SHA2-512 is fastest on 64 bit machines and g= iven that these are now the mainstream, would it not make sense to simply g= o to SHA2-384 or SHA2-512 as the only mandatory for the time being with the= expectation of adding in some flavor of SHA3 when that is possible?


I think we need to break this down in ma= trix fashion

1) Attack
=A0=A0 =A0A compr= omise that could lead an attacker to break DANE.

2= ) Reputation
=A0=A0 A compromise that falls short of enabling an actual attack agai= nst DANE but will lead to concerns amongst users and pressure for a new alg= orithm. (c.f. demands to change HMAC-MD5 despite no evidence this is necess= ary).

3) Support
=A0=A0 Is the algorithm supported = in standard cryptographic toolkits, is widespread support to be expected in= the future.

4) Performance
=A0=A0 =A0No= t really a factor for this application but will determine whether it is use= d for other purposes.

5) Industry
=A0=A0 Is the algorithm THE indus= try standard or merely A standard.

SHA-1: =A0Good = for 20 years on attack but unknown as far as reputation. Is the main target= of cryptanalysis at the moment. Support is universal.

SHA2-256: Good for 30+ years on attack and at least 10 = for reputation. Support is near universal.=A0

SHA2= -386: Good for 40+ years on attack and probably 30+ for reputation. Support= is near universal

SHA2-512: Good for 50+ years on attack but likely 20+ o= n reputation due to the fact that if 512 bits is specified in a protocol it= is difficult to explain why less than 512 bits are necessary.

SHA3-*: Will be THE standard in some strength as far as we c= an predict. While it is possible something else will beat SHA3, I can't= see that happening and people being happy with SHA2.=A0

So my recommendation would be

1) Do not defin= e any code point for SHA1.

2) Define code point fo= r SHA2-384

3) Expect to support SHA3 in the future= via some mechanism. Add it to the draft if the competition schedule makes = this practical.


As a general rule I would prefer to only= define IANA code points for algorithms that the IETF REQUIRES.
<= br>
I would support all other crypto by reserving one code point = for specifying algorithms by means of ASN.1 OID prefix.

The reason for doing that is that it means that the gro= up does not need to consider the inevitable requests to support other algor= ithms or deal with the damage caused when a refusal is ignored.

We cannot stop the Russian federation from using GOST but we= can stop them getting a reserved code point.

On Tue, Mar 8, 2011 at 1:05 PM, <bmanning@vacation.karoshi.com= > wrote:
On Tue, Mar 08, 2011 at 05:57:34PM +0100, Martin Rex wrote:
>
> It fosters on the premise that SHA-1 is completely and throroughly
> broken and SHA-256 impaired by more serious attacks than currently
> known for SHA-1 _long_ before a SHA-3 finalist is selected.
>
>
> -Martin

=A0 =A0 =A0 =A0my working analog here is that you don't shoot at a mov= ing
=A0 =A0 =A0 =A0target - you shoot ahead of it.

=A0 =A0 =A0 =A0given the pace of the IETF processes, I fully expect there = will
=A0 =A0 =A0 =A0be a SHA-3 finalist selected before this spec lands. =A0(YM= MV of course)

--bill
_________________________________________= ______
keyassure mailing list
keyassure@ietf.org
https://www.ietf.org/mailman/listinfo/keyassure



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

--001636ed6d011fd7ff049dfeb7af-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0067A3A6951 for ; Tue, 8 Mar 2011 12:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.565 X-Spam-Level: X-Spam-Status: No, score=-10.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EaODyJqR1z1 for ; Tue, 8 Mar 2011 12:40:22 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 7C2E93A6781 for ; Tue, 8 Mar 2011 12:40:21 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p28KfX1Q010745; Tue, 8 Mar 2011 22:41:33 +0200 X-CheckPoint: {4D769467-3-1B221DC2-FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 8 Mar 2011 22:41:33 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 8 Mar 2011 22:41:32 +0200 From: Yoav Nir To: Paul Hoffman Date: Tue, 8 Mar 2011 22:41:30 +0200 Thread-Topic: [keyassure] Opening issue #21: "Need to specify which crypto Thread-Index: Acvd0TUCnQYkmFqCRSWfkMZjzMNC8w== Message-ID: <7867185F-5D8E-48EA-AE90-57184207CF5A@checkpoint.com> References: <397794924.536913.1299565388720.JavaMail.root@cm-mail03.mozilla.org> <4D765239.40408@ieca.com> <4D7658AA.9010003@vpnc.org> In-Reply-To: <4D7658AA.9010003@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 20:40:23 -0000 On Mar 8, 2011, at 6:26 PM, Paul Hoffman wrote: > On 3/8/11 8:10 AM, Nicholas Weaver wrote: >> (Not that I'm saying it should impede this group, I'm happing with the l= anguage above or similar, I just want to know why people want to use SHA-38= 4 instead of SHA-512!) >=20 > There is some reason to believe that the final SHA-3 spec will have a=20 > 384-bit hash that will be faster to calculate than the 512-bit version,=20 > and it will be hard to convince people who were using SHA-2-512 that=20 > going to SHA-3-384 is a good move. They'll claim that it is less safe=20 > because they didn't realize that they didn't even need the strength in=20 > SHA-2-256 to start with. That would explain the relatively slow adoption of ECDSA. I want my 2048 bi= ts of security.= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03F0A3A6928 for ; Tue, 8 Mar 2011 10:06:05 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GpeVGCb7zNw for ; Tue, 8 Mar 2011 10:06:04 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id AA9763A6857 for ; Tue, 8 Mar 2011 10:06:03 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p28I5k7s026293; Tue, 8 Mar 2011 18:06:01 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p28I5LRp026278; Tue, 8 Mar 2011 18:05:21 GMT Date: Tue, 8 Mar 2011 18:05:16 +0000 From: bmanning@vacation.karoshi.com To: Martin Rex Message-ID: <20110308180516.GC23708@vacation.karoshi.com.> References: <201103081657.p28GvYwq001089@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201103081657.p28GvYwq001089@fs4113.wdf.sap.corp> User-Agent: Mutt/1.4.1i Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 18:06:05 -0000 On Tue, Mar 08, 2011 at 05:57:34PM +0100, Martin Rex wrote: > > It fosters on the premise that SHA-1 is completely and throroughly > broken and SHA-256 impaired by more serious attacks than currently > known for SHA-1 _long_ before a SHA-3 finalist is selected. > > > -Martin my working analog here is that you don't shoot at a moving target - you shoot ahead of it. given the pace of the IETF processes, I fully expect there will be a SHA-3 finalist selected before this spec lands. (YMMV of course) --bill Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E33653A68AF for ; Tue, 8 Mar 2011 09:39:16 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9u2o1zI5Dcjq for ; Tue, 8 Mar 2011 09:39:16 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 19F953A68DC for ; Tue, 8 Mar 2011 09:39:11 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p28Hdd7s025557; Tue, 8 Mar 2011 17:39:56 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p28HdTGW025550; Tue, 8 Mar 2011 17:39:29 GMT Date: Tue, 8 Mar 2011 17:39:24 +0000 From: bmanning@vacation.karoshi.com To: Paul Hoffman Message-ID: <20110308173924.GB23708@vacation.karoshi.com.> References: <397794924.536913.1299565388720.JavaMail.root@cm-mail03.mozilla.org> <4D765239.40408@ieca.com> <4D7658AA.9010003@vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D7658AA.9010003@vpnc.org> User-Agent: Mutt/1.4.1i Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 17:39:17 -0000 On Tue, Mar 08, 2011 at 08:26:18AM -0800, Paul Hoffman wrote: > On 3/8/11 8:10 AM, Nicholas Weaver wrote: > >(Not that I'm saying it should impede this group, I'm happing with the > >language above or similar, I just want to know why people want to use > >SHA-384 instead of SHA-512!) > > There is some reason to believe that the final SHA-3 spec will have a > 384-bit hash that will be faster to calculate than the 512-bit version, > and it will be hard to convince people who were using SHA-2-512 that > going to SHA-3-384 is a good move. They'll claim that it is less safe > because they didn't realize that they didn't even need the strength in > SHA-2-256 to start with. and what are those reasons? --bill > > It's all headology, unfortunately. > > --Paul Hoffman > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0243B3A67FB for ; Tue, 8 Mar 2011 08:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.221 X-Spam-Level: X-Spam-Status: No, score=-10.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNvFYuuu83AZ for ; Tue, 8 Mar 2011 08:56:24 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id EAF523A67E7 for ; Tue, 8 Mar 2011 08:56:23 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p28GvZ2C019811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Mar 2011 17:57:35 +0100 (MET) From: Martin Rex Message-Id: <201103081657.p28GvYwq001089@fs4113.wdf.sap.corp> To: nweaver@icsi.berkeley.edu (Nicholas Weaver) Date: Tue, 8 Mar 2011 17:57:34 +0100 (MET) In-Reply-To: from "Nicholas Weaver" at Mar 8, 11 08:10:21 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 16:56:25 -0000 Nicholas Weaver wrote: > > I still don't get why SHA-384 instead of SHA-512. > SHA-384 just seems silly to me: its no FASTER than SHA-512, > it MUST be less secure than SHA-512. There is no reason to this (in the sense of reasonable explanation). It fosters on the premise that SHA-1 is completely and throroughly broken and SHA-256 impaired by more serious attacks than currently known for SHA-1 _long_ before a SHA-3 finalist is selected. The only two situations, where *I* believe that having more than one mandatory to implement hash algorithms for DANE would make sense: 1) when SHA-1 was permitted (which no one seems to be asking for) 2) when the SHA-3 winner has been determined (which hasn't happened yet) Personally, I would strongly prefer the hash algorithm list for DANE to be 1) SHA-256 (FIPS 180-3) MUST implement 2) SHA-512 (FIPS 180-3) SHOULD implement Personally, I believe that SHA-384, and more so SHA-224 should have never been defined by NIST, because they constantly confuse the crypto-clueless about the purpose of these algorithms and cause needless discussions. -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE5BC3A691E for ; Tue, 8 Mar 2011 08:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.911 X-Spam-Level: X-Spam-Status: No, score=-101.911 tagged_above=-999 required=5 tests=[AWL=0.688, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qdfhwC7jX+Q for ; Tue, 8 Mar 2011 08:25:04 -0800 (PST) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 837BC3A68F8 for ; Tue, 8 Mar 2011 08:25:04 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p28GQIrK039129 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 8 Mar 2011 09:26:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D7658AA.9010003@vpnc.org> Date: Tue, 08 Mar 2011 08:26:18 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: keyassure@ietf.org References: <397794924.536913.1299565388720.JavaMail.root@cm-mail03.mozilla.org> <4D765239.40408@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 16:25:05 -0000 On 3/8/11 8:10 AM, Nicholas Weaver wrote: > (Not that I'm saying it should impede this group, I'm happing with the language above or similar, I just want to know why people want to use SHA-384 instead of SHA-512!) There is some reason to believe that the final SHA-3 spec will have a 384-bit hash that will be faster to calculate than the 512-bit version, and it will be hard to convince people who were using SHA-2-512 that going to SHA-3-384 is a good move. They'll claim that it is less safe because they didn't realize that they didn't even need the strength in SHA-2-256 to start with. It's all headology, unfortunately. --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C41B63A692F for ; Tue, 8 Mar 2011 08:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmP3FR62PLDu for ; Tue, 8 Mar 2011 08:09:08 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 70D263A691B for ; Tue, 8 Mar 2011 08:09:06 -0800 (PST) Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id B0AF136A016; Tue, 8 Mar 2011 08:10:21 -0800 (PST) References: <397794924.536913.1299565388720.JavaMail.root@cm-mail03.mozilla.org> <4D765239.40408@ieca.com> In-Reply-To: <4D765239.40408@ieca.com> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Tue, 8 Mar 2011 08:10:21 -0800 To: Sean Turner X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 16:09:08 -0000 On Mar 8, 2011, at 7:58 AM, Sean Turner wrote: > I think I'm in this camp. It's hard to use 2119-language for = something that nobody can claim conformance to. Somebody is still going = to need to write a draft that says here's the SHA-3 alg, here's it's = reference and we're updating the registry regardless so I think the = draft could just as well do this: >=20 > Value Short description Ref. > ----------------------------------------------------- > 0 No hash used [This] > 1 SHA-1 NIST FIPS 180-3 > 2 SHA-256 NIST FIPS 180-3 > 3 SHA-384 NIST FIPS 180-3 > 4-254 Unassigned >=20 > Applications to the registry can request specific values that have > yet to be assigned. Note that there is every intent to update this > registry when [SHA-3] is finalized. Implementors are strongly > encouraged to support a flexible implementation strategy in order > to support an orderly migration to [SHA-3] shortly after this > registry is updated. I still don't get why SHA-384 instead of SHA-512. SHA-384 just seems = silly to me: its no FASTER than SHA-512, it MUST be less secure than = SHA-512, and the "every bit is sacred" zombie-idea in DNS needs its head = lopped off: 16B larger hashes does NOT make a difference in DNS, = especially for a single signature over a big blob of data. (Not that I'm saying it should impede this group, I'm happing with the = language above or similar, I just want to know why people want to use = SHA-384 instead of SHA-512!) Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3FEC3A67B7 for ; Tue, 8 Mar 2011 07:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yG-OlWS0aMZ7 for ; Tue, 8 Mar 2011 07:57:34 -0800 (PST) Received: from nm22-vm0.bullet.mail.ac4.yahoo.com (nm22-vm0.bullet.mail.ac4.yahoo.com [98.139.53.218]) by core3.amsl.com (Postfix) with SMTP id F3EF53A67AA for ; Tue, 8 Mar 2011 07:57:33 -0800 (PST) Received: from [98.139.52.196] by nm22.bullet.mail.ac4.yahoo.com with NNFMP; 08 Mar 2011 15:58:49 -0000 Received: from [98.139.52.176] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 08 Mar 2011 15:58:48 -0000 Received: from [127.0.0.1] by omp1059.mail.ac4.yahoo.com with NNFMP; 08 Mar 2011 15:58:48 -0000 X-Yahoo-Newman-Id: 969158.1073.bm@omp1059.mail.ac4.yahoo.com Received: (qmail 45734 invoked from network); 8 Mar 2011 15:58:48 -0000 Received: from thunderfish.local (turners@96.231.129.124 with plain) by smtp112.biz.mail.re2.yahoo.com with SMTP; 08 Mar 2011 07:58:48 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: j13cYxsVM1kp7UYWIyWfNeRlGawb8KMKJMu7uKn_2aDhCX9 7vjaN_bT9N.eDfz1GfRbVxyaRrzpRQIbx0aIPSjKHApXOD0KKqjHmg6ssJzi eZz7xkYW3oOl9dNJdbV8CpcZun2XWvEHxTl3bX3qVG8C0A_QbcsQ7AnctJfU Jct66q9elAt7OgHzz_UM067efsM_Isv6NXMywjvDaeQqjiWYiKdyDyR_AX7B jKUDfLt3Vag35KoGIcISktotBAvdG X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D765239.40408@ieca.com> Date: Tue, 08 Mar 2011 10:58:49 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: keyassure@ietf.org References: <397794924.536913.1299565388720.JavaMail.root@cm-mail03.mozilla.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 15:57:35 -0000 On 3/8/11 2:20 AM, Jakob Schlyter wrote: > On 8 mar 2011, at 07.23, Brian Smith wrote: > >> It would be better to have both SHA-384 mandatory for clients. Those two algorithms are already practically required because they are both required for a good implementation of TLS 1.2. Making SHA-384 mandatory for clients makes it easier for server administrators to switch from SHA-256 to SHA-384 if that would ever be helpful; that could be a real possibility considering the deployment of SHA-3 on clients is a long way off. > > +1 - having two algorithms (although from the same family) from the start is better than just one. And we add SHA-3 and friends later - no need to "reserve" code points for them at this point. I think I'm in this camp. It's hard to use 2119-language for something that nobody can claim conformance to. Somebody is still going to need to write a draft that says here's the SHA-3 alg, here's it's reference and we're updating the registry regardless so I think the draft could just as well do this: Value Short description Ref. ----------------------------------------------------- 0 No hash used [This] 1 SHA-1 NIST FIPS 180-3 2 SHA-256 NIST FIPS 180-3 3 SHA-384 NIST FIPS 180-3 4-254 Unassigned Applications to the registry can request specific values that have yet to be assigned. Note that there is every intent to update this registry when [SHA-3] is finalized. Implementors are strongly encouraged to support a flexible implementation strategy in order to support an orderly migration to [SHA-3] shortly after this registry is updated. or something like that. I can already envision the GEN-Art comment/IESG discuss on needing a stable reference for SHA-3 if it's a normative reference. If there's no requirements associated with it you'll probably get away with an informative reference to [SHA-3]: [SHA-3] "Cryptographic Hash Algorithm Competition", NIST Computer Security Resource Center Cryptographic Hash Project. There is precedent to using this reference but it was in a draft with an intended status of informational and it was an informational reference. spt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3568D3A6836 for ; Tue, 8 Mar 2011 02:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.715 X-Spam-Level: X-Spam-Status: No, score=0.715 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWwqiLtz1LnK for ; Tue, 8 Mar 2011 02:22:58 -0800 (PST) Received: from smtp-out4.blueyonder.co.uk (smtp-out4.blueyonder.co.uk [195.188.213.7]) by core3.amsl.com (Postfix) with ESMTP id 364333A6821 for ; Tue, 8 Mar 2011 02:22:58 -0800 (PST) Received: from [172.23.170.147] (helo=anti-virus03-10) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1Pwu5I-000854-3j; Tue, 08 Mar 2011 10:24:08 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1Pwu5E-0001lg-Ct; Tue, 08 Mar 2011 10:24:04 +0000 Message-ID: From: "George Barwood" To: "Ben Laurie" , "Peter Gutmann" References: <4D752197.5090403@vpnc.org> Date: Tue, 8 Mar 2011 10:24:02 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Cc: keyassure@ietf.org, paul.hoffman@vpnc.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 10:23:02 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkJlbiBMYXVyaWUiIDxiZW5s QGdvb2dsZS5jb20+DQpUbzogIlBldGVyIEd1dG1hbm4iIDxwZ3V0MDAxQGNzLmF1Y2tsYW5kLmFj Lm56Pg0KQ2M6IDxrZXlhc3N1cmVAaWV0Zi5vcmc+OyA8cGF1bC5ob2ZmbWFuQHZwbmMub3JnPg0K U2VudDogVHVlc2RheSwgTWFyY2ggMDgsIDIwMTEgOTowNiBBTQ0KU3ViamVjdDogUmU6IFtrZXlh c3N1cmVdIE9wZW5pbmcgaXNzdWUgIzIxOiAiTmVlZCB0byBzcGVjaWZ5IHdoaWNoIGNyeXB0bw0K DQoNCk9uIDggTWFyY2ggMjAxMSAwNDowNiwgUGV0ZXIgR3V0bWFubiA8cGd1dDAwMUBjcy5hdWNr bGFuZC5hYy5uej4gd3JvdGU6DQo+IFBhdWwgSG9mZm1hbiA8cGF1bC5ob2ZmbWFuQHZwbmMub3Jn PiB3cml0ZXM6DQoNCj4gRG9uJ3QgcmVhbGx5IHNlZSB0aGUgcG9pbnQgb2YgU0hBLTM4NCBteXNl bGYsIGJ1dCBJJ20gbm90IHBhcnRpY3VsYXJseSBvcHBvc2VkIHRvIGl0cyBpbmNsdXNpb24uDQoN ClNIQS0zODQgaXMgZmFzdGVyIHRvIGNvbXB1dGUgdGhhbiBTSEEtMjU2IG9uIDY0LWJpdCBtYWNo aW5lcywgYW5kIGhhcyBhIGJpZ2dlciBtYXJnaW4gb2Ygc2VjdXJpdHkuDQoNCkl0J3MgY2hlYXAg dG8gaW5jbHVkZSBpdCBub3csIGFuZCBhdm9pZHMgYSBwb3RlbnRpYWwgYmlnIGhlYWRhY2hlIGlm L3doZW4gU0hBLTI1NiBwcm92ZXMgdG8gYmUgdnVsbmVyYWJsZS4NCg0KVGhhdCBkb2Vzbid0IHNl ZW0gdmVyeSBsaWtlbHkgaW4gdGhlIG5lYXIgZnV0dXJlLCBidXQgaGlzdG9yeSBpbmRpY2F0ZXMg dGhhdCB3ZSBzaG91bGRuJ3QgYmUgdG9vIGNvbmZpZGVudC4NCg0KQnkgdGhlIHNhbWUgYXJndW1l bnQgU0hBLTUxMiBjb3VsZCBhbHNvIGJlIGRlZmluZWQsIGV2ZW4gaWYgd2UgZG9uJ3QgZXhwZWN0 IHRvIHVzZSBpdCBhbnkgdGltZSBzb29uLg0KDQpUaGVyZSBpcyBhIHJlYXNvbiBOSVNUIGRlZmlu ZWQgdGhlc2UgZnVuY3Rpb25zICggZXZlbiBpZiBhcyBub24tc3BlY2lhbGlzdHMgd2UgbWF5IG5v dCBmdWxseSB1bmRlcnN0YW5kICkuDQoNCg0KDQo= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9F8D3A677E for ; Tue, 8 Mar 2011 01:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.677 X-Spam-Level: X-Spam-Status: No, score=-5.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVc+J0YdbS70 for ; Tue, 8 Mar 2011 01:31:05 -0800 (PST) Received: from ian.brad.office.comodo.net (brad.comodogroup.com [82.109.38.202]) by core3.amsl.com (Postfix) with ESMTP id D7CDE3A6765 for ; Tue, 8 Mar 2011 01:31:04 -0800 (PST) Received: (qmail 29599 invoked by uid 1000); 8 Mar 2011 09:32:16 -0000 Received: from nigel.brad.office.comodo.net (HELO nigel.localnet) (192.168.0.58) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPS; Tue, 08 Mar 2011 09:32:16 +0000 From: Rob Stradling To: keyassure@ietf.org, mrex@sap.com Date: Tue, 8 Mar 2011 09:32:25 +0000 User-Agent: KMail/1.13.5 (Linux/2.6.36-gentoo-r5; KDE/4.4.5; i686; ; ) References: <201103071425.p27EPvrB000688@fs4113.wdf.sap.corp> In-Reply-To: <201103071425.p27EPvrB000688@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103080932.25467.rob.stradling@comodo.com> Cc: Phillip Hallam-Baker , paul.hoffman@vpnc.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 09:31:10 -0000 On Monday 07 Mar 2011 14:25:57 Martin Rex wrote: > Phillip Hallam-Baker wrote: > > We do require TLS however. > > > > VeriSign and Comodo have created roots with SHA2-256 and SHA2-384, the > > choice is thus not 'oddball'. > > I assume you rather mean the signature algorithms > sha256WithRsaEncryption OID { 1, 2, 840, 113549, 1, 1, 11 } > sha384WithRsaEncryption OID { 1, 2, 840, 113549, 1, 1, 12 } Yes, and also... ecdsa-with-SHA384 OID { 1 2 840 10045 4 3 3 } > rather than the hash algorithms. > > > The criteria for abandoning an existing digest is not when the work > > factor below a certain threshold, it is when the work factor falls > > significantly below that advertised. > > Nope, I doesn't have anything to do with advertisements. > The problem is when _assumptions_ about an algorithms strength are > shown to not hold, independent of how "strong" that algorithm is > advertised. > > This is why we do worry about md5 when used for digital signatures, > and worry much less when md5 is used as HMAC-MD5 for integrity protection > of online communication protocols. > > > So SHA2-384 is to be preferred over SHA2-512 because even though it is > > easier to break, it has a much higher safety factor. > > > > If someone comes up with an attack against SHA2-512 with O(2^480/2) > > complexity it would reduce the cost of attacking SHA2-512 but not the > > cost of attacking SHA2-384. So the 512 bit version would be > > 'compromised' but the 384 version would not. > > That is marketing nonsense. > > With that reasoning, we should use SHA-512/256 rather than SHA-256 > > http://www.schneier.com/blog/archives/2011/02/nist_defines_ne.html > http://csrc.nist.gov/publications/PubsDrafts.html#fips-180-4 > > > I don't see any value in mandating any algorithm beyond SHA-256 > at this point -- anticipating that there is going to be SHA-3 > in the not so far future and a desire to support SHA-3 in DANE. > > > > -Martin > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5ED93A6803 for ; Tue, 8 Mar 2011 01:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdZ9eJNUB+4O for ; Tue, 8 Mar 2011 01:05:23 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id BC4053A67F8 for ; Tue, 8 Mar 2011 01:05:23 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p2896bd7019370 for ; Tue, 8 Mar 2011 01:06:37 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299575197; bh=VGGSJteKUYBz7xt91YBXQ25n7Xs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=ry/SwlLX4t4vARt1zJUUVmoRl3IgrAVK4hZirXyEVtNHiRP0tdU/twPmH/SUsqgou xGmpknXw/hNXP0vdNQKjg== Received: from vws13 (vws13.prod.google.com [10.241.21.141]) by wpaz17.hot.corp.google.com with ESMTP id p2896ap6013569 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 8 Mar 2011 01:06:36 -0800 Received: by vws13 with SMTP id 13so5132970vws.28 for ; Tue, 08 Mar 2011 01:06:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bahsXa29stoPiPtLuQOOzbwbBOLof8BQNjGdT6D85Wk=; b=T6FsU1C5jL7X4TRHFKm9+hMaCPzi2xLwUHmrzSk3hLDEKvk04TNmcduAuOi4RVFqcy OpGiwSgD5J4FJPgacVQw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ba+NLJsuTvfG0c7RP1Bx7Fp7YSQBB1LhUPbyr4uzpcpSY8Nqj8rA7hL4V7ZsWU05B4 T6GL53mJLW+pQd1kDrGg== MIME-Version: 1.0 Received: by 10.220.48.215 with SMTP id s23mr1234149vcf.260.1299575195671; Tue, 08 Mar 2011 01:06:35 -0800 (PST) Received: by 10.220.88.137 with HTTP; Tue, 8 Mar 2011 01:06:35 -0800 (PST) In-Reply-To: References: <4D752197.5090403@vpnc.org> Date: Tue, 8 Mar 2011 09:06:35 +0000 Message-ID: From: Ben Laurie To: Peter Gutmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: keyassure@ietf.org, paul.hoffman@vpnc.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 09:05:24 -0000 On 8 March 2011 04:06, Peter Gutmann wrote: > Paul Hoffman writes: > >>Are you saying that the rough consensus is obvious, or that you believe t= here >>can be none and we should give up, or...? > > I believe we should shoot anyone who doesn't agree that { SHA256 + SHA3 }= is > the right solution. =A0Then we will have consensus and can move on. =A0Bu= t that's > just my opinion... +1 :-) Don't really see the point of SHA-384 myself, but I'm not particularly opposed to its inclusion. SHA3 obviously doesn't exist yet, but happy to have it included in the plan= . > > Peter. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB86A3A68FE for ; Mon, 7 Mar 2011 23:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Opv5YLJA7Z0A for ; Mon, 7 Mar 2011 23:19:45 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id 45F053A68EF for ; Mon, 7 Mar 2011 23:19:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=lFdONtQCX1MYR6Esrt+cm0qw38d4Jl86j92FylCgap8=; b=qr8yTjN4J16xCvKS49el+fOPUwovtNB4p3vSXWDDdRB+RMiNvWY3+u79iKjWlVa6olCZzkidpmofN rZkBQbULotN3Y0tNLC5GnMpXN61l7BSxlvFgdTadCm+a6KYED50XRt5nERT5sD0OY2R78i/WoX3G3U pqw5XalJrj7EPw0Q= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTP; Tue, 8 Mar 2011 08:20:54 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <397794924.536913.1299565388720.JavaMail.root@cm-mail03.mozilla.org> Date: Tue, 8 Mar 2011 08:20:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <397794924.536913.1299565388720.JavaMail.root@cm-mail03.mozilla.org> To: Brian Smith X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 07:19:46 -0000 On 8 mar 2011, at 07.23, Brian Smith wrote: > It would be better to have both SHA-384 mandatory for clients. Those = two algorithms are already practically required because they are both = required for a good implementation of TLS 1.2. Making SHA-384 mandatory = for clients makes it easier for server administrators to switch from = SHA-256 to SHA-384 if that would ever be helpful; that could be a real = possibility considering the deployment of SHA-3 on clients is a long way = off. +1 - having two algorithms (although from the same family) from the = start is better than just one. And we add SHA-3 and friends later - no = need to "reserve" code points for them at this point. jakob Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB38F3A68E0 for ; Mon, 7 Mar 2011 22:21:55 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMFhvDMtUBOU for ; Mon, 7 Mar 2011 22:21:54 -0800 (PST) Received: from mail.mozilla.com (corp01.sj.mozilla.com [63.245.208.141]) by core3.amsl.com (Postfix) with ESMTP id 997E03A68E4 for ; Mon, 7 Mar 2011 22:21:54 -0800 (PST) Received: from mail.mozilla.com (mail.mozilla.com [10.2.72.15]) by mail.mozilla.com (Postfix) with ESMTP id C243C17FC445 for ; Mon, 7 Mar 2011 22:23:08 -0800 (PST) Date: Mon, 7 Mar 2011 22:23:08 -0800 (PST) From: Brian Smith To: keyassure@ietf.org Message-ID: <397794924.536913.1299565388720.JavaMail.root@cm-mail03.mozilla.org> In-Reply-To: <4B7097F3-26FD-412F-B96E-8AB46D1E967C@eff.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [98.248.46.107] X-Mailer: Zimbra 6.0.8_GA_2678 (ZimbraWebClient - FF3.0 (Win)/6.0.8_GA_2661) Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 06:21:56 -0000 Chris Palmer wrote: > Actually, I thought that people had roughly agreed to specify SHA-256 > and -384 and to create a slot for SHA-3. If I'm wrong and that's not > what people have roughly agreed, then I apologize and here are my two > cents: As long as the minimum is -256 with a plan for SHA-3, I'm > happy. It would be better to have both SHA-384 mandatory for clients. Those two algorithms are already practically required because they are both required for a good implementation of TLS 1.2. Making SHA-384 mandatory for clients makes it easier for server administrators to switch from SHA-256 to SHA-384 if that would ever be helpful; that could be a real possibility considering the deployment of SHA-3 on clients is a long way off. Cheers, Brian Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18E803A683D for ; Mon, 7 Mar 2011 20:56:37 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkOIurmuFpMi for ; Mon, 7 Mar 2011 20:56:36 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id E5C1F3A67CF for ; Mon, 7 Mar 2011 20:56:35 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p284tn7s005353; Tue, 8 Mar 2011 04:56:18 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p284tEWJ005340; Tue, 8 Mar 2011 04:55:14 GMT Date: Tue, 8 Mar 2011 04:55:08 +0000 From: bmanning@vacation.karoshi.com To: Peter Gutmann Message-ID: <20110308045508.GA5304@vacation.karoshi.com.> References: <4D752197.5090403@vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: keyassure@ietf.org, paul.hoffman@vpnc.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 04:56:37 -0000 On Tue, Mar 08, 2011 at 05:06:29PM +1300, Peter Gutmann wrote: > Paul Hoffman writes: > > >Are you saying that the rough consensus is obvious, or that you believe there > >can be none and we should give up, or...? > > I believe we should shoot anyone who doesn't agree that { SHA256 + SHA3 } is > the right solution. Then we will have consensus and can move on. But that's > just my opinion... > > Peter. two to the chest, one to the head... or in other words +1 --bill (I beleive also) Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6952F3A68C7 for ; Mon, 7 Mar 2011 20:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.544 X-Spam-Level: X-Spam-Status: No, score=-103.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92xJR0cmJerP for ; Mon, 7 Mar 2011 20:05:18 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id D24EB3A67CF for ; Mon, 7 Mar 2011 20:05:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1299557193; x=1331093193; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20keyassure@ietf.org,=20paul.hoffman@vpnc.org |Subject:=20Re:=20[keyassure]=20Opening=20issue=20#21:=20 "Need=20to=20specify=20which=20crypto|In-Reply-To:=20<4D7 52197.5090403@vpnc.org>|Message-Id:=20|Date:=20Tue,=2008=20Mar=20201 1=2017:06:29=20+1300; bh=0CulAv9Nimmuv5eXuh/ukhVkfTLhuNtTzfydrC60Et0=; b=Wlmfu0OhWsremk2LsJppCrG8G+v3h4GemjVkSI1sZXxy5o3BQWiq2sFw TCysOlKnDWBRFEJdcnrWCw37lUwSUOQuoHWL39rE6h982UsQjdZzZUqFb YabU6PG5JeeCvHs0jUxDKOCCj/NUD3ddNaC2smEIPTtDrtc46wIkE/Sc6 U=; X-IronPort-AV: E=Sophos;i="4.62,282,1296990000"; d="scan'208";a="49843380" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Mar 2011 17:06:29 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PwoBp-0008WO-Hh; Tue, 08 Mar 2011 17:06:29 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PwoBp-00079A-ED; Tue, 08 Mar 2011 17:06:29 +1300 From: Peter Gutmann To: keyassure@ietf.org, paul.hoffman@vpnc.org In-Reply-To: <4D752197.5090403@vpnc.org> Message-Id: Date: Tue, 08 Mar 2011 17:06:29 +1300 Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 04:05:20 -0000 Paul Hoffman writes: >Are you saying that the rough consensus is obvious, or that you believe there >can be none and we should give up, or...? I believe we should shoot anyone who doesn't agree that { SHA256 + SHA3 } is the right solution. Then we will have consensus and can move on. But that's just my opinion... Peter. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2644628C0FB for ; Mon, 7 Mar 2011 17:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTPEKmw0A7NG for ; Mon, 7 Mar 2011 17:40:09 -0800 (PST) Received: from mail1.eff.org (mail1.eff.org [64.147.188.4]) by core3.amsl.com (Postfix) with ESMTP id 6B3833A69E9 for ; Mon, 7 Mar 2011 17:40:09 -0800 (PST) Received: from [192.168.0.28] (208-90-214-239.PUBLIC.monkeybrains.net [208.90.214.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: chris) by mail1.eff.org (Postfix) with ESMTPSA id AD372BDC1F; Mon, 7 Mar 2011 17:41:22 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Chris Palmer In-Reply-To: <4D758064.9090608@vpnc.org> Date: Mon, 7 Mar 2011 17:41:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4D880A4A-9044-4027-9A40-E46E5586E8D8@eff.org> References: <201103071425.p27EPvrB000688@fs4113.wdf.sap.corp> <208C68A5-568B-4447-854C-70A4A229B84C@checkpoint.com> <9C30235F-FF8C-44E7-B7BC-5D284586D11B@eff.org> <4D752197.5090403@vpnc.org> <8FB60B62-483F-48B5-8A36-390872C18BD5@kumari.net> <4B7097F3-26FD-412F-B96E-8AB46D1E967C@eff.org> <4D758064.9090608@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 01:40:10 -0000 On Mar 7, 2011, at 5:03 PM, Paul Hoffman wrote: > One specific thing that this author would like to see is what you and = others specifically mean by "a slot for SHA-3" and "a plan for SHA-3". = To me, those are quite different. We already have slots for SHA-3, = SHA-42, and so on; they are not named as such, but they are there. Change this: """ 4.3. TLSA Hash Types This document creates a new registry, "Hash Types for TLSA Resource Records". The registry policy is "Specification Required". The initial entries in the registry are: Value Short description Ref. ----------------------------------------------------- 0 No hash used [This] 1 SHA-1 NIST FIPS 180-2 2 SHA-256 NIST FIPS 180-2 3 SHA-384 NIST FIPS 180-2 4-254 Unassigned Applications to the registry can request specific values that have yet to be assigned. """ To something like this: 4.3. TLSA Hash Types This document creates a new registry, "Hash Types for TLSA Resource Records". The registry policy is "Specification Required". The initial entries in the registry are: Value Short description Ref. ----------------------------------------------------- 0 No hash used [This] 1 SHA-1 NIST FIPS 180-2 2 SHA-256 NIST FIPS 180-2 3 SHA-384 NIST FIPS 180-2 4 Reserved 5 Reserved 6-254 Unassigned Applications to the registry can request specific values that have yet to be assigned. Note that that types 4 and 5 are reserved to indicate the SHA-3 algorithm, when it is defined. Future revisions to this document SHALL require implementations to support SHA-3, and implementors SHOULD prepare for this with a flexible implementation strategy. I don't really speak RFC-ese, but hopefully this makes enough sense. :) --=20 Chris Palmer Technology Director, Electronic Frontier Foundation Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F723A69D7 for ; Mon, 7 Mar 2011 17:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.896 X-Spam-Level: X-Spam-Status: No, score=-101.896 tagged_above=-999 required=5 tests=[AWL=0.703, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svdRgFv5im2f for ; Mon, 7 Mar 2011 17:02:21 -0800 (PST) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id DFE473A69C0 for ; Mon, 7 Mar 2011 17:02:19 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2813WUD000495 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 7 Mar 2011 18:03:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D758064.9090608@vpnc.org> Date: Mon, 07 Mar 2011 17:03:32 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: keyassure@ietf.org References: <201103071425.p27EPvrB000688@fs4113.wdf.sap.corp> <208C68A5-568B-4447-854C-70A4A229B84C@checkpoint.com> <9C30235F-FF8C-44E7-B7BC-5D284586D11B@eff.org> <4D752197.5090403@vpnc.org> <8FB60B62-483F-48B5-8A36-390872C18BD5@kumari.net> <4B7097F3-26FD-412F-B96E-8AB46D1E967C@eff.org> In-Reply-To: <4B7097F3-26FD-412F-B96E-8AB46D1E967C@eff.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 01:02:22 -0000 On 3/7/11 4:05 PM, Chris Palmer wrote: > Actually, I thought that people had roughly agreed to specify SHA-256 > and -384 and to create a slot for SHA-3. If I'm wrong and that's not > what people have roughly agreed, then I apologize and here are my two > cents: As long as the minimum is -256 with a plan for SHA-3, I'm > happy. One specific thing that this author would like to see is what you and others specifically mean by "a slot for SHA-3" and "a plan for SHA-3". To me, those are quite different. We already have slots for SHA-3, SHA-42, and so on; they are not named as such, but they are there. We do not have a plan for anything that is not currently listed in the document: they are just slots. If you or others want "a plan for SHA-3", what would that say in specific? My personal opinion is "SHA-256 and SHA-384 (or 'and SHA-512') and slots for others in the future but with no plan for those slots", but a few folks here have spoken of plans (which means more words), so I don't have words to suggest for plans. --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F5FB3A69B5 for ; Mon, 7 Mar 2011 16:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.044 X-Spam-Level: X-Spam-Status: No, score=-6.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSFOgAKg2hnt for ; Mon, 7 Mar 2011 16:04:25 -0800 (PST) Received: from mail1.eff.org (mail1.eff.org [64.147.188.4]) by core3.amsl.com (Postfix) with ESMTP id CF00B3A68AA for ; Mon, 7 Mar 2011 16:04:25 -0800 (PST) Received: from [192.168.0.28] (208-90-214-239.PUBLIC.monkeybrains.net [208.90.214.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: chris) by mail1.eff.org (Postfix) with ESMTPSA id 21425BDD55; Mon, 7 Mar 2011 16:05:41 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Chris Palmer In-Reply-To: <8FB60B62-483F-48B5-8A36-390872C18BD5@kumari.net> Date: Mon, 7 Mar 2011 16:05:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4B7097F3-26FD-412F-B96E-8AB46D1E967C@eff.org> References: <201103071425.p27EPvrB000688@fs4113.wdf.sap.corp> <208C68A5-568B-4447-854C-70A4A229B84C@checkpoint.com> <9C30235F-FF8C-44E7-B7BC-5D284586D11B@eff.org> <4D752197.5090403@vpnc.org> <8FB60B62-483F-48B5-8A36-390872C18BD5@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 00:04:26 -0000 On Mar 7, 2011, at 3:09 PM, Warren Kumari wrote: > The WG chairs (well, this one at least) sees no consensus yet[0].... Actually, I thought that people had roughly agreed to specify SHA-256 = and -384 and to create a slot for SHA-3. If I'm wrong and that's not = what people have roughly agreed, then I apologize and here are my two = cents: As long as the minimum is -256 with a plan for SHA-3, I'm happy. --=20 Chris Palmer Technology Director, Electronic Frontier Foundation Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 811DE28C107 for ; Mon, 7 Mar 2011 15:08:11 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnrowAUg08Go for ; Mon, 7 Mar 2011 15:08:10 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id 8BB5828C0FB for ; Mon, 7 Mar 2011 15:08:10 -0800 (PST) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id 5DF9F1B40B58; Mon, 7 Mar 2011 18:09:24 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <4D752197.5090403@vpnc.org> Date: Mon, 7 Mar 2011 18:09:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8FB60B62-483F-48B5-8A36-390872C18BD5@kumari.net> References: <201103071425.p27EPvrB000688@fs4113.wdf.sap.corp> <208C68A5-568B-4447-854C-70A4A229B84C@checkpoint.com> <9C30235F-FF8C-44E7-B7BC-5D284586D11B@eff.org> <4D752197.5090403@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 23:08:11 -0000 On Mar 7, 2011, at 1:19 PM, Paul Hoffman wrote: > On 3/7/11 10:02 AM, Chris Palmer wrote: >> Let's end this thread and move to the next important topic. >=20 > The document authors need to hear from the WG chairs what the rough = consensus on this issue is before we can instantiate it in the next = draft. The WG chairs (well, this one at least) sees no consensus yet[0].... > Are you saying that the rough consensus is obvious, or that you = believe there can be none and we should give up, or...? W [0]: I'm sure that you already knew that (and that that was your point), = but figured I'd make it explicit.... >=20 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure >=20 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5832B3A680D for ; Mon, 7 Mar 2011 10:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.888 X-Spam-Level: X-Spam-Status: No, score=-101.888 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJb5HHs0Kouu for ; Mon, 7 Mar 2011 10:17:52 -0800 (PST) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 125C53A681D for ; Mon, 7 Mar 2011 10:17:50 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p27IJ3ek084889 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 7 Mar 2011 11:19:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D752197.5090403@vpnc.org> Date: Mon, 07 Mar 2011 10:19:03 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: keyassure@ietf.org References: <201103071425.p27EPvrB000688@fs4113.wdf.sap.corp> <208C68A5-568B-4447-854C-70A4A229B84C@checkpoint.com> <9C30235F-FF8C-44E7-B7BC-5D284586D11B@eff.org> In-Reply-To: <9C30235F-FF8C-44E7-B7BC-5D284586D11B@eff.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 18:17:53 -0000 On 3/7/11 10:02 AM, Chris Palmer wrote: > Let's end this thread and move to the next important topic. The document authors need to hear from the WG chairs what the rough consensus on this issue is before we can instantiate it in the next draft. Are you saying that the rough consensus is obvious, or that you believe there can be none and we should give up, or...? Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4483A680F for ; Mon, 7 Mar 2011 10:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCwfTsFNpMCz for ; Mon, 7 Mar 2011 10:01:20 -0800 (PST) Received: from mail1.eff.org (mail1.eff.org [64.147.188.4]) by core3.amsl.com (Postfix) with ESMTP id 685883A680C for ; Mon, 7 Mar 2011 10:01:18 -0800 (PST) Received: from [192.168.0.28] (208-90-214-239.PUBLIC.monkeybrains.net [208.90.214.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: chris) by mail1.eff.org (Postfix) with ESMTPSA id D987ABE638 for ; Mon, 7 Mar 2011 10:02:32 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Chris Palmer In-Reply-To: <208C68A5-568B-4447-854C-70A4A229B84C@checkpoint.com> Date: Mon, 7 Mar 2011 10:02:31 -0800 Content-Transfer-Encoding: 7bit Message-Id: <9C30235F-FF8C-44E7-B7BC-5D284586D11B@eff.org> References: <201103071425.p27EPvrB000688@fs4113.wdf.sap.corp> <208C68A5-568B-4447-854C-70A4A229B84C@checkpoint.com> To: keyassure@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 18:01:20 -0000 Let's end this thread and move to the next important topic. -- Chris Palmer Technology Director, Electronic Frontier Foundation Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 448963A67D3 for ; Mon, 7 Mar 2011 06:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.562 X-Spam-Level: X-Spam-Status: No, score=-10.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKUF3HP6Ux5a for ; Mon, 7 Mar 2011 06:51:40 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id EFD8228C0F7 for ; Mon, 7 Mar 2011 06:51:39 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p27EqplE010200; Mon, 7 Mar 2011 16:52:51 +0200 X-CheckPoint: {4D74F135-9-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 7 Mar 2011 16:52:51 +0200 From: Yoav Nir To: "mrex@sap.com" Date: Mon, 7 Mar 2011 16:52:54 +0200 Thread-Topic: [keyassure] Opening issue #21: "Need to specify which crypto Thread-Index: Acvc11TVaECLx+c7RnSXV6DVHmORBw== Message-ID: <208C68A5-568B-4447-854C-70A4A229B84C@checkpoint.com> References: <201103071425.p27EPvrB000688@fs4113.wdf.sap.corp> In-Reply-To: <201103071425.p27EPvrB000688@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "keyassure@ietf.org" , Phillip Hallam-Baker , "paul.hoffman@vpnc.org" Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 14:51:42 -0000 On Mar 7, 2011, at 4:25 PM, Martin Rex wrote: >> So SHA2-384 is to be preferred over SHA2-512 because even though it is >> easier to break, it has a much higher safety factor. >>=20 >> If someone comes up with an attack against SHA2-512 with O(2^480/2) >> complexity it would reduce the cost of attacking SHA2-512 but not the co= st >> of attacking SHA2-384. So the 512 bit version would be 'compromised' but= the >> 384 version would not. >=20 > That is marketing nonsense. >=20 > With that reasoning, we should use SHA-512/256 rather than SHA-256 >=20 > http://www.schneier.com/blog/archives/2011/02/nist_defines_ne.html > http://csrc.nist.gov/publications/PubsDrafts.html#fips-180-4 The point of SHA-512/256 is not marketing or even security, but speed. http://eprint.iacr.org/2010/548.pdf > I don't see any value in mandating any algorithm beyond SHA-256 > at this point -- anticipating that there is going to be SHA-3 > in the not so far future and a desire to support SHA-3 in DANE. I disagree. SHA-512 (and -384) are touted for longevity - we hope that they= will be resistant to pre-image and collision attacks for longer than SHA-2= 56. This is important for document signing and somewhat for certificates, b= ut not so much for resource records. If it takes a year from "sha-256 broke= n" to "exploit in the wild", that's plenty of time to replace all resource = records. So it doesn't make sense to publish SHA-384 resource records now, but we ne= ed the consumers of such records to be ready for SHA-384 records. The reaso= n that the transition from MD5 to SHA-1 certificates was so smooth is that = all browsers at the time supported SHA-1.=20 Yoav Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADA593A6962 for ; Mon, 7 Mar 2011 06:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.219 X-Spam-Level: X-Spam-Status: No, score=-10.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Viy7bgm8FreO for ; Mon, 7 Mar 2011 06:24:51 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 2DECD3A67CF for ; Mon, 7 Mar 2011 06:24:51 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p27EPwpA026406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Mar 2011 15:26:03 +0100 (MET) From: Martin Rex Message-Id: <201103071425.p27EPvrB000688@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Mon, 7 Mar 2011 15:25:57 +0100 (MET) In-Reply-To: from "Phillip Hallam-Baker" at Mar 5, 11 11:33:01 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org, paul.hoffman@vpnc.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 14:24:52 -0000 Phillip Hallam-Baker wrote: > > We do require TLS however. > > VeriSign and Comodo have created roots with SHA2-256 and SHA2-384, the > choice is thus not 'oddball'. I assume you rather mean the signature algorithms sha256WithRsaEncryption OID { 1, 2, 840, 113549, 1, 1, 11 } sha384WithRsaEncryption OID { 1, 2, 840, 113549, 1, 1, 12 } rather than the hash algorithms. > > The criteria for abandoning an existing digest is not when the work factor > below a certain threshold, it is when the work factor falls significantly > below that advertised. Nope, I doesn't have anything to do with advertisements. The problem is when _assumptions_ about an algorithms strength are shown to not hold, independent of how "strong" that algorithm is advertised. This is why we do worry about md5 when used for digital signatures, and worry much less when md5 is used as HMAC-MD5 for integrity protection of online communication protocols. > > So SHA2-384 is to be preferred over SHA2-512 because even though it is > easier to break, it has a much higher safety factor. > > If someone comes up with an attack against SHA2-512 with O(2^480/2) > complexity it would reduce the cost of attacking SHA2-512 but not the cost > of attacking SHA2-384. So the 512 bit version would be 'compromised' but the > 384 version would not. That is marketing nonsense. With that reasoning, we should use SHA-512/256 rather than SHA-256 http://www.schneier.com/blog/archives/2011/02/nist_defines_ne.html http://csrc.nist.gov/publications/PubsDrafts.html#fips-180-4 I don't see any value in mandating any algorithm beyond SHA-256 at this point -- anticipating that there is going to be SHA-3 in the not so far future and a desire to support SHA-3 in DANE. -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28C1628C0CF for ; Sun, 6 Mar 2011 00:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4DP9pVXBTtB for ; Sun, 6 Mar 2011 00:40:10 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id 6E9E13A6918 for ; Sun, 6 Mar 2011 00:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=823ijBuj14QYR7dSvct/T/2sLEVT2nBtCRUNP306uO0=; b=jcwrmdFWOwVxGk778ypx0sA959bqUFXQjQWtK8s9IYpUnJSC4dmk6Um0+aiLCTEtD0Kq12ovFGBxl lw8nWHT0WtAl5/9au66k59UJDkO9pg8vxvtdtWRIkmoEhMtLQZu+YlGwHH8gO6SfGC9UNI71X11gTV sYP1byRK47gEtF4Q= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Sun, 6 Mar 2011 09:41:17 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <4D725DF4.5000806@vpnc.org> Date: Sun, 6 Mar 2011 09:41:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9933A160-3DAF-42FA-B5FA-DDF185FA5C63@kumari.net> <7CDBED48-C800-4169-AF59-72075BA7EC2E@kumari.net> <8A18EE8A-EA0B-4AB5-A222-5D572458E9F1@kirei.se> <4D725DF4.5000806@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement" X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 08:40:11 -0000 On 5 mar 2011, at 16.59, Paul Hoffman wrote: > This is not an argument against SHA-512, but if we are going to make = arguments for its use, let's make sensible ones. I don't think there are = many sensible ones for anything other than SHA-1, so we can just pick = what we want. I agree and after some more thinking (and reading) about this I do = believe we should settle for SHA-256 and SHA-384 as the initial set of, = and mandatory to implement, digest algorithms for TLSA (just as Warren = proposed). jakob Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD53B3A6A99 for ; Sat, 5 Mar 2011 08:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8u8hKj7Bw2j for ; Sat, 5 Mar 2011 08:41:53 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 4771A3A6A8C for ; Sat, 5 Mar 2011 08:41:52 -0800 (PST) Received: by bwz13 with SMTP id 13so3379744bwz.31 for ; Sat, 05 Mar 2011 08:43:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8LwVwqx34b6OzBMkGQUwJn988K0/h0GDxKdNgq1RGVk=; b=Pjn/aqdd91+sMoqWto27OROUZy2b77NyyVtgVQPVG2JhoNZmbkLm/gpc8NKUpyX4RY 5mKdP/XdW4L8SVh4P2qJ0liMrYZZvfEN1LNn/kXtodcAYWLi9jWMK3Dxe+Co8JTTR0g2 Hj7x136SyNMt+M3/MTcURfQZEXpi4rAR0MTmA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=h/lL0ROrZEPuegaSwdBO8vb/UPLBUeDQfY/6Tzq5baDg0NW3LyJ7C0x4Bq/i101S6Y XRvvIg6bgl5/v6xSZI4tanzbYQviRMK2FdgnfGNpOC3GfqgOX1fvwwvCZYSTAFlUiLdA IN5PstfBOdK7tpUVHVy7fauOsfYXRZ6ZAbxIE= MIME-Version: 1.0 Received: by 10.204.20.66 with SMTP id e2mr1632722bkb.141.1299343382072; Sat, 05 Mar 2011 08:43:02 -0800 (PST) Received: by 10.204.14.139 with HTTP; Sat, 5 Mar 2011 08:43:02 -0800 (PST) In-Reply-To: <372FD3F6803A48078FF57645312B755D@local> References: <9933A160-3DAF-42FA-B5FA-DDF185FA5C63@kumari.net> <7CDBED48-C800-4169-AF59-72075BA7EC2E@kumari.net> <8A18EE8A-EA0B-4AB5-A222-5D572458E9F1@kirei.se> <4D725DF4.5000806@vpnc.org> <372FD3F6803A48078FF57645312B755D@local> Date: Sat, 5 Mar 2011 11:43:02 -0500 Message-ID: From: Phillip Hallam-Baker To: George Barwood Content-Type: multipart/alternative; boundary=00032555450ebacfba049dbef445 Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement" X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 16:41:55 -0000 --00032555450ebacfba049dbef445 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 5, 2011 at 11:26 AM, George Barwood < george.barwood@blueyonder.co.uk> wrote: > > ----- Original Message ----- > From: "Paul Hoffman" > To: > Sent: Saturday, March 05, 2011 3:59 PM > Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto > algorithms and certificate types are mandatory to implement" > > > > It is not correct in that DNSSEC only defines hashes as part of > > signature algorithms, not separately. > > Not quite, there are actually three contexts where DNSSEC defines hashes. > > Signature algorithms, where RSASHA256 and RSASHA512 are the most modern. > > The DigestType for a DS record, where SHA1 and SHA256 are the ones defined. > > And finally the NSEC3 hash function, where only SHA1 is defined. > Lets say you live in a house built in 1980, it does not have smoke alarms. But you want to buy a new house, it has to have smoke alarms and if you renovate an old house, you have to retrofit. We can't depend on existing protocols for precedent here. DNSSEC is in the middle of a deployment phase and the code base is going to be changing for some time. I do not expect us to have a final code base for verifiers until long after the algorithm competition concludes in 2012. At the conclusion of the competition I expect that we will have a complete suite of symmetric algorithms that there is a broad industry consensus to support. At that point I would expect that to become a requirement across the board. The concern about the security of SHA1 is sufficient to make use in new protocols inappropriate but does not rise to the level of justifying emergency action to update existing protocols. -- Website: http://hallambaker.com/ --00032555450ebacfba049dbef445 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Mar 5, 2011 at 11:26 AM, George Barwood <george.barwood@blueyonder.co.= uk> wrote:

----- Original Message -----
From: "Paul Hoffman" <paul.hoffman@vpnc.org>
To: <keyassure@ietf.org> Sent: Saturday, March 05, 2011 3:59 PM
Subject: Re: [keyassure] Opening issue #21: "Need to specify which cry= pto algorithms and certificate types are mandatory to implement"


> It is not correct in that DNSSEC only defines hashes as part of
> signature algorithms, not separately.

Not quite, there are actually three contexts where DNSSEC defines has= hes.

Signature algorithms, where RSASHA256 and RSASHA512 are the most modern.
The DigestType for a DS record, where SHA1 and SHA256 are the ones defined.=

And finally the NSEC3 hash function, where only SHA1 is defined.
=

Lets say you live in a house built in 1980, i= t does not have smoke alarms. But you want to buy a new house, it has to ha= ve smoke alarms and if you renovate an old house, you have to retrofit.
We can't depend on existing protocols for precedent here. DNSSEC is= in the middle of a deployment phase and the code base is going to be chang= ing for some time. I do not expect us to have a final code base for verifie= rs until long after the algorithm competition concludes in 2012.


At the conclusion of the competition I expect= that we will have a complete suite of symmetric algorithms that there is a= broad industry consensus to support. At that point I would expect that to = become a requirement across the board.

The concern about the security of SHA1 is sufficient to= make use in new protocols inappropriate but does not rise to the level of = justifying emergency action to update existing protocols.
--00032555450ebacfba049dbef445-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB87C3A6A98 for ; Sat, 5 Mar 2011 08:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.864 X-Spam-Level: X-Spam-Status: No, score=-101.864 tagged_above=-999 required=5 tests=[AWL=0.735, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2sCO7KpI+kH for ; Sat, 5 Mar 2011 08:34:37 -0800 (PST) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 94A2A3A6A96 for ; Sat, 5 Mar 2011 08:34:36 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p25GZkYr086759 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 5 Mar 2011 09:35:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D726662.6050208@vpnc.org> Date: Sat, 05 Mar 2011 08:35:46 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: keyassure@ietf.org References: <9933A160-3DAF-42FA-B5FA-DDF185FA5C63@kumari.net> <7CDBED48-C800-4169-AF59-72075BA7EC2E@kumari.net> <8A18EE8A-EA0B-4AB5-A222-5D572458E9F1@kirei.se> <4D725DF4.5000806@vpnc.org> <372FD3F6803A48078FF57645312B755D@local> In-Reply-To: <372FD3F6803A48078FF57645312B755D@local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement" X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 16:34:38 -0000 On 3/5/11 8:26 AM, George Barwood wrote: > > ----- Original Message ----- > From: "Paul Hoffman" > To: > Sent: Saturday, March 05, 2011 3:59 PM > Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement" > > >> It is not correct in that DNSSEC only defines hashes as part of >> signature algorithms, not separately. > > Not quite, there are actually three contexts where DNSSEC defines hashes. > > Signature algorithms, where RSASHA256 and RSASHA512 are the most modern. > > The DigestType for a DS record, where SHA1 and SHA256 are the ones defined. > > And finally the NSEC3 hash function, where only SHA1 is defined. > Quite right. And, for those of you who want to find these (I missed the middle one and purposely ignored the last one), they are at - Signature algs: - DigestType for DS: - NSEC3: Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4404F3A6A8C for ; Sat, 5 Mar 2011 08:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.564 X-Spam-Level: X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4oEAIRJrD7x for ; Sat, 5 Mar 2011 08:31:51 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 5358A3A6A95 for ; Sat, 5 Mar 2011 08:31:51 -0800 (PST) Received: by bwz13 with SMTP id 13so3375195bwz.31 for ; Sat, 05 Mar 2011 08:33:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ok6E/AqOKtl2NQad7q/mWaMHlYuy/JIW0SM2FLlNA7M=; b=UHxKkxzPtlie3BCXu2vhr0vbk9rbO7PsxAQ5oLLPoX6JnHelaJS1Qqz6yOO6Zg1w/W EIIKX4wUoAJz7P0R22tOfgkc7WFDbE5FyvVXsVqXgxNjwFThWiXbdGVWFwwedVUOY0mg WbuvHF07xjdhIrITCf83Wrf/SCATAT1w0ui5I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=M1SrPbSqEKM+PT/YzArnD+rcMAsgD2no6oMzMaE354ob8AJ1dvPUB8QbH4+Mn3fImn 2l+2lPj+rW/2zOaiHqbuQVjCNp9VFOxmaUKq1sFMy7jPHwrpykdhcfdO5p3Bd0kzQeAj +D6CInJAke0rDGpqAUjedSg5rYdlyCvh1mKuI= MIME-Version: 1.0 Received: by 10.204.154.199 with SMTP id p7mr1630382bkw.114.1299342781286; Sat, 05 Mar 2011 08:33:01 -0800 (PST) Received: by 10.204.14.139 with HTTP; Sat, 5 Mar 2011 08:33:01 -0800 (PST) In-Reply-To: <4D725DF4.5000806@vpnc.org> References: <9933A160-3DAF-42FA-B5FA-DDF185FA5C63@kumari.net> <7CDBED48-C800-4169-AF59-72075BA7EC2E@kumari.net> <8A18EE8A-EA0B-4AB5-A222-5D572458E9F1@kirei.se> <4D725DF4.5000806@vpnc.org> Date: Sat, 5 Mar 2011 11:33:01 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=0015175def8ceb8938049dbed06d Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement" X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 16:31:53 -0000 --0015175def8ceb8938049dbed06d Content-Type: text/plain; charset=ISO-8859-1 We do require TLS however. VeriSign and Comodo have created roots with SHA2-256 and SHA2-384, the choice is thus not 'oddball'. >From a strict security point of view SHA2-512 is more secure than SHA2-384, there is no attack on 512 that will not also break 384. However, there is an interesting piece of logic at work here. First, let me point out that SHA2-384 (m) = trunc (SHA2-512 (m), 384). Its the same algorithm, just truncated. The criteria for abandoning an existing digest is not when the work factor below a certain threshold, it is when the work factor falls significantly below that advertised. Thus we started getting worried about SHA1 when attacks were announced that shaved only about 15 bits off the strength, even though what remained was sufficient for any purpose. The reason we got worried was that customers started to ask questions and that starts to cost real money when you have a lot of customers and a lot of sales people. So SHA2-384 is to be preferred over SHA2-512 because even though it is easier to break, it has a much higher safety factor. If someone comes up with an attack against SHA2-512 with O(2^480/2) complexity it would reduce the cost of attacking SHA2-512 but not the cost of attacking SHA2-384. So the 512 bit version would be 'compromised' but the 384 version would not. On Sat, Mar 5, 2011 at 10:59 AM, Paul Hoffman wrote: > On 3/5/11 1:01 AM, Jakob Schlyter wrote: > >> On 4 mar 2011, at 18.37, Ben Laurie wrote: >> >> On 3 March 2011 19:36, Warren Kumari wrote: >>> >>>> Hi all, >>>> >>>> After watching the thread, I'd like to propose this as a strawman: >>>> >>>> Mandatory to implement algorithms are SHA-256 and SHA-384. For now, >>>> these are all we specify. >>>> >>>> My reasoning behind this is: >>>> 3: In order to do DANE, you have to be able to do DNSSEC -- in order to >>>> do DNSSEC you should already support the above. >>>> >>> >>> Hang on. SHA-384? I don't think that is required by DNSSEC. >>> >> >> Correct, in order to require what DNSSEC use we should specify SHA-256 and >> SHA-512. >> > > Not actually correct, and not actually relevant. > > It is not correct in that DNSSEC only defines hashes as part of signature > algorithms, not separately. And, if we are going to go that route, the only > hash that is mandatory for DNSSEC is SHA-1; it feels like this WG doesn't > want to go there. > > It is also not relevant because we do not demand TLS applications to be > doing DNSSEC themselves: they simply need to know that DNSSEC was used on > the data they receive. > > This is not an argument against SHA-512, but if we are going to make > arguments for its use, let's make sensible ones. I don't think there are > many sensible ones for anything other than SHA-1, so we can just pick what > we want. > > --Paul Hoffman > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --0015175def8ceb8938049dbed06d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We do require TLS however.

VeriSign and Comodo have crea= ted roots with SHA2-256 and SHA2-384, the choice is thus not 'oddball&#= 39;.

From a strict security point of view SHA2-512= is more secure than SHA2-384, there is no attack on 512 that will not also= break 384.

However, there is an interesting piece of logic at work= here.=A0


<= div>First, let me point out that SHA2-384 (m) =3D trunc (SHA2-512 (m), 384)= . Its the same algorithm, just truncated.


The criteria for abandoning an exi= sting digest is not when the work factor below a certain threshold, it is w= hen the work factor falls significantly below that advertised.

Thus we started getting worried about SHA1 when attacks were= announced that shaved only about 15 bits off the strength, even though wha= t remained was sufficient for any purpose. The reason we got worried was th= at customers started to ask questions and that starts to cost real money wh= en you have a lot of customers and a lot of sales people.

So SHA2-384 is to be preferred over SHA2-512 because ev= en though it is easier to break, it has a much higher safety factor.
<= div>
If someone comes up with an attack against SHA2-512 with= O(2^480/2) complexity it would reduce the cost of attacking SHA2-512 but n= ot the cost of attacking SHA2-384. So the 512 bit version would be 'com= promised' but the 384 version would not.



On Sat, M= ar 5, 2011 at 10:59 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On 3/5/11 1:01 AM, Jakob Schlyter wrote:
On 4 mar 2011, at 18.37, Ben Laurie wrote:

On 3 March 2011 19:36, Warren Kumari<warren@kumari.net> =A0wrote:
Hi all,

After watching the thread, I'd like to propose this as a strawman:

Mandatory to implement algorithms are SHA-256 and SHA-384. For now, these a= re all we specify.

My reasoning behind this is:
3: In order to do DANE, you have to be able to do DNSSEC -- in order to do = DNSSEC you should already support the above.

Hang on. SHA-384? I don't think that is required by DNSSEC.

Correct, in order to require what DNSSEC use we should specify SHA-256 and = SHA-512.

Not actually correct, and not actually relevant.

It is not correct in that DNSSEC only defines hashes as part of signature a= lgorithms, not separately. And, if we are going to go that route, the only = hash that is mandatory for DNSSEC is SHA-1; it feels like this WG doesn'= ;t want to go there.

It is also not relevant because we do not demand TLS applications to be doi= ng DNSSEC themselves: they simply need to know that DNSSEC was used on the = data they receive.

This is not an argument against SHA-512, but if we are going to make argume= nts for its use, let's make sensible ones. I don't think there are = many sensible ones for anything other than SHA-1, so we can just pick what = we want.

--Paul Hoffman

_______________________________________________
keyassure mailing list
keyassure@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/keyassure



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

--0015175def8ceb8938049dbed06d-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC6813A6A96 for ; Sat, 5 Mar 2011 08:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.728 X-Spam-Level: X-Spam-Status: No, score=0.728 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq3vKM3AwvNR for ; Sat, 5 Mar 2011 08:25:38 -0800 (PST) Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by core3.amsl.com (Postfix) with ESMTP id 2CEBA3A6A95 for ; Sat, 5 Mar 2011 08:25:37 -0800 (PST) Received: from [172.23.170.147] (helo=anti-virus03-10) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1PvuJb-00062t-Bs; Sat, 05 Mar 2011 16:26:47 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out1.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1PvuJL-0007Tr-Kx; Sat, 05 Mar 2011 16:26:31 +0000 Message-ID: <372FD3F6803A48078FF57645312B755D@local> From: "George Barwood" To: "Paul Hoffman" , References: <9933A160-3DAF-42FA-B5FA-DDF185FA5C63@kumari.net> <7CDBED48-C800-4169-AF59-72075BA7EC2E@kumari.net> <8A18EE8A-EA0B-4AB5-A222-5D572458E9F1@kirei.se> <4D725DF4.5000806@vpnc.org> Date: Sat, 5 Mar 2011 16:26:29 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement" X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 16:25:39 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlBhdWwgSG9mZm1hbiIgPHBh dWwuaG9mZm1hbkB2cG5jLm9yZz4NClRvOiA8a2V5YXNzdXJlQGlldGYub3JnPg0KU2VudDogU2F0 dXJkYXksIE1hcmNoIDA1LCAyMDExIDM6NTkgUE0NClN1YmplY3Q6IFJlOiBba2V5YXNzdXJlXSBP cGVuaW5nIGlzc3VlICMyMTogIk5lZWQgdG8gc3BlY2lmeSB3aGljaCBjcnlwdG8gYWxnb3JpdGht cyBhbmQgY2VydGlmaWNhdGUgdHlwZXMgYXJlIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQiDQoNCg0K PiBJdCBpcyBub3QgY29ycmVjdCBpbiB0aGF0IEROU1NFQyBvbmx5IGRlZmluZXMgaGFzaGVzIGFz IHBhcnQgb2YgDQo+IHNpZ25hdHVyZSBhbGdvcml0aG1zLCBub3Qgc2VwYXJhdGVseS4gDQoNCk5v dCBxdWl0ZSwgdGhlcmUgYXJlIGFjdHVhbGx5IHRocmVlIGNvbnRleHRzIHdoZXJlIEROU1NFQyBk ZWZpbmVzIGhhc2hlcy4NCg0KU2lnbmF0dXJlIGFsZ29yaXRobXMsIHdoZXJlIFJTQVNIQTI1NiBh bmQgUlNBU0hBNTEyIGFyZSB0aGUgbW9zdCBtb2Rlcm4uDQoNClRoZSBEaWdlc3RUeXBlIGZvciBh IERTIHJlY29yZCwgd2hlcmUgU0hBMSBhbmQgU0hBMjU2IGFyZSB0aGUgb25lcyBkZWZpbmVkLg0K DQpBbmQgZmluYWxseSB0aGUgTlNFQzMgaGFzaCBmdW5jdGlvbiwgd2hlcmUgb25seSBTSEExIGlz IGRlZmluZWQuDQoNCkdlb3JnZQ0KDQo= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CCFB28C0E6 for ; Sat, 5 Mar 2011 07:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.847 X-Spam-Level: X-Spam-Status: No, score=-101.847 tagged_above=-999 required=5 tests=[AWL=0.752, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZi4vKv6BWaz for ; Sat, 5 Mar 2011 07:58:39 -0800 (PST) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 5985228C0E4 for ; Sat, 5 Mar 2011 07:58:39 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p25FxmL6085261 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 5 Mar 2011 08:59:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D725DF4.5000806@vpnc.org> Date: Sat, 05 Mar 2011 07:59:48 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: keyassure@ietf.org References: <9933A160-3DAF-42FA-B5FA-DDF185FA5C63@kumari.net> <7CDBED48-C800-4169-AF59-72075BA7EC2E@kumari.net> <8A18EE8A-EA0B-4AB5-A222-5D572458E9F1@kirei.se> In-Reply-To: <8A18EE8A-EA0B-4AB5-A222-5D572458E9F1@kirei.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement" X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 15:58:40 -0000 On 3/5/11 1:01 AM, Jakob Schlyter wrote: > On 4 mar 2011, at 18.37, Ben Laurie wrote: > >> On 3 March 2011 19:36, Warren Kumari wrote: >>> Hi all, >>> >>> After watching the thread, I'd like to propose this as a strawman: >>> >>> Mandatory to implement algorithms are SHA-256 and SHA-384. For now, these are all we specify. >>> >>> My reasoning behind this is: >>> 3: In order to do DANE, you have to be able to do DNSSEC -- in order to do DNSSEC you should already support the above. >> >> Hang on. SHA-384? I don't think that is required by DNSSEC. > > Correct, in order to require what DNSSEC use we should specify SHA-256 and SHA-512. Not actually correct, and not actually relevant. It is not correct in that DNSSEC only defines hashes as part of signature algorithms, not separately. And, if we are going to go that route, the only hash that is mandatory for DNSSEC is SHA-1; it feels like this WG doesn't want to go there. It is also not relevant because we do not demand TLS applications to be doing DNSSEC themselves: they simply need to know that DNSSEC was used on the data they receive. This is not an argument against SHA-512, but if we are going to make arguments for its use, let's make sensible ones. I don't think there are many sensible ones for anything other than SHA-1, so we can just pick what we want. --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F9C93A68EC for ; Sat, 5 Mar 2011 01:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdMVndUVwxJf for ; Sat, 5 Mar 2011 01:00:33 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id 640A23A6859 for ; Sat, 5 Mar 2011 01:00:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=bpF8YiNjIbDLxsvLv559fUen+/Vztf2snZryxXbhWOY=; b=LpRvhaKU4CB9DzP4qe1AQT4aQS4kS7gktotm2jXjlYk30B5Y44P+Qnl44b4KzSTLQY7fLlySTeHhG gKSN1WpY454EzAHU3YWKbCRaFWrv4gFBv+lV8JFcBHR2BU0qtrdQrhSAY622KleDc0mvIm14WMfon9 XKCHjFug5VvGGLaQ= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Sat, 5 Mar 2011 10:01:37 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Sat, 5 Mar 2011 10:01:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8A18EE8A-EA0B-4AB5-A222-5D572458E9F1@kirei.se> References: <9933A160-3DAF-42FA-B5FA-DDF185FA5C63@kumari.net> <7CDBED48-C800-4169-AF59-72075BA7EC2E@kumari.net> To: Ben Laurie X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement" X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 09:00:34 -0000 On 4 mar 2011, at 18.37, Ben Laurie wrote: > On 3 March 2011 19:36, Warren Kumari wrote: >> Hi all, >>=20 >> After watching the thread, I'd like to propose this as a strawman: >>=20 >> Mandatory to implement algorithms are SHA-256 and SHA-384. For now, = these are all we specify. >>=20 >> My reasoning behind this is: >> 3: In order to do DANE, you have to be able to do DNSSEC -- in order = to do DNSSEC you should already support the above. >=20 > Hang on. SHA-384? I don't think that is required by DNSSEC. Correct, in order to require what DNSSEC use we should specify SHA-256 = and SHA-512. jakob Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63E7D3A69C7 for ; Fri, 4 Mar 2011 09:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NkvzxG9MaRz for ; Fri, 4 Mar 2011 09:36:14 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 6116D28B23E for ; Fri, 4 Mar 2011 09:36:14 -0800 (PST) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p24HbMlo019512 for ; Fri, 4 Mar 2011 09:37:22 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299260242; bh=RQSfKIzMa7ADLyx0swNnLBBr+IE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=XBmu/Y9ehjvpoNHws/rcAQAB0Iueqe7P2nBk1gGrs44snkcs6thtYyJKLgxX4XKL3 UJ3vyQFsW5Yy3GpK/AuFg== Received: from pwi14 (pwi14.prod.google.com [10.241.219.14]) by hpaq1.eem.corp.google.com with ESMTP id p24HbJMZ014127 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 4 Mar 2011 09:37:20 -0800 Received: by pwi14 with SMTP id 14so476487pwi.21 for ; Fri, 04 Mar 2011 09:37:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pBBbKHJY7741haNrQL8YQuaFi1Qby7SjCCrVzcWuE2w=; b=o8DPRJgJGmR20UxEKi5McKi+/znccnI2XTjPrHkiaeEN4yx9fVlLiH4qAuYJcCPKRF kGZtNfe71ltfyc4tfnUw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=q57cKgFMIDucn7HkXDB8nxSPuhdwXISbY41QBnDOr65e8M3dnFmH1SImldtWuxYjxG CgC+SDjJ8cjSdzsGfCQw== MIME-Version: 1.0 Received: by 10.142.144.17 with SMTP id r17mr740609wfd.96.1299260238871; Fri, 04 Mar 2011 09:37:18 -0800 (PST) Received: by 10.142.47.14 with HTTP; Fri, 4 Mar 2011 09:37:18 -0800 (PST) In-Reply-To: <7CDBED48-C800-4169-AF59-72075BA7EC2E@kumari.net> References: <9933A160-3DAF-42FA-B5FA-DDF185FA5C63@kumari.net> <7CDBED48-C800-4169-AF59-72075BA7EC2E@kumari.net> Date: Fri, 4 Mar 2011 17:37:18 +0000 Message-ID: From: Ben Laurie To: Warren Kumari Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement" X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 17:36:15 -0000 On 3 March 2011 19:36, Warren Kumari wrote: > Hi all, > > After watching the thread, I'd like to propose this as a strawman: > > Mandatory to implement algorithms are SHA-256 and SHA-384. For now, these are all we specify. > > My reasoning behind this is: > 3: In order to do DANE, you have to be able to do DNSSEC -- in order to do DNSSEC you should already support the above. Hang on. SHA-384? I don't think that is required by DNSSEC. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E26C3A684A for ; Fri, 4 Mar 2011 08:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.303 X-Spam-Level: X-Spam-Status: No, score=-104.303 tagged_above=-999 required=5 tests=[AWL=-0.704, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLBrgtZWFZII for ; Fri, 4 Mar 2011 08:48:35 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id EF05C3A6817 for ; Fri, 4 Mar 2011 08:48:34 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 4 Mar 2011 08:49:44 -0800 From: "Murray S. Kucherawy" To: "keyassure@ietf.org" Date: Fri, 4 Mar 2011 08:49:43 -0800 Thread-Topic: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement" Thread-Index: AcvaDdvEzJrolfFvQ5KiVhEfe+n/vAAfkQjw Message-ID: References: <9933A160-3DAF-42FA-B5FA-DDF185FA5C63@kumari.net> <7CDBED48-C800-4169-AF59-72075BA7EC2E@kumari.net> <4D70443A.2040807@vpnc.org> In-Reply-To: <4D70443A.2040807@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement" X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 16:48:35 -0000 > -----Original Message----- > From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On B= ehalf Of Paul Hoffman > Sent: Thursday, March 03, 2011 5:46 PM > To: keyassure@ietf.org > Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto= algorithms and certificate types are mandatory to implement" >=20 > On 3/3/11 4:29 PM, Phillip Hallam-Baker wrote: > > That works for me >=20 > And me as well. +1 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E80C83A69C7 for ; Fri, 4 Mar 2011 08:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.913 X-Spam-Level: X-Spam-Status: No, score=-103.913 tagged_above=-999 required=5 tests=[AWL=-1.314, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dx+1GGqkzY9P for ; Fri, 4 Mar 2011 08:47:00 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 3E2053A69BC for ; Fri, 4 Mar 2011 08:47:00 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 4 Mar 2011 08:48:09 -0800 From: "Murray S. Kucherawy" To: "keyassure@ietf.org" Date: Fri, 4 Mar 2011 08:48:07 -0800 Thread-Topic: [keyassure] Opening issue #21: "Need to specify which crypto Thread-Index: AcvadlpYcPCOfEaqTpe+ZH1xJ9kdggAFWmpQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 16:47:01 -0000 > -----Original Message----- > From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On B= ehalf Of Peter Gutmann > Sent: Friday, March 04, 2011 6:13 AM > To: hallam@gmail.com; mrex@sap.com > Cc: keyassure@ietf.org > Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto >=20 > >If SHA3 is ready in time (i.e. we are still not ready in 2012) we could > >consider making SHA3-256 the required algorithm. If not make SHA2-256 an= d > >SHA2-512 the required algorithms. >=20 > Sounds good, although I'd make 256 a MUST and 512 a MAY, both to keep the > every-bit-is-sacred crowd happy and because in practice there's going to = be a > de facto universal default that everyone uses, and my guess is it'll be -= 256, > in the same way that currently the universal default that everyone uses i= s > SHA1, no matter what other algorithms the spec allows. If the experience with DKIM (which did MUST for SHA1 and SHOULD for SHA256)= is any indication, your guess is right on the money. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B24973A67AF for ; Fri, 4 Mar 2011 08:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.564 X-Spam-Level: X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81JC2GHae6iD for ; Fri, 4 Mar 2011 08:14:42 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 2747A3A67A1 for ; Fri, 4 Mar 2011 08:14:41 -0800 (PST) Received: by bwz13 with SMTP id 13so2571775bwz.31 for ; Fri, 04 Mar 2011 08:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eBMapswD55ygTS5qCN0OFfbuOv/SbJGT0cGuPa4kpfo=; b=k+AqjeUweJbgilNRhNwd5XwS2GnkA7M9K4yc0klV2koEpL1SZgs/NhegYH/9QO/edq 6blwZm3wDFK7YbEftDnxeSPV3IXo12HtUvptaPT382iseOT7HBcwDNOlaJusA/cJ5CmJ 8HlefcLywIYHzoqWdqZQIqcGm+/YbIeEVjSqw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uELBYaipym1r/dzjh8/TsROWE56irNqioxGprFy7x1RfWVoK5jJRzcEBWHA0oU2h3K vKSsh0rCAckwE4ORJ57B8o8PJc4nLqqMMN9lpQlho3w5gsoDGy6uj25NUGxUMs/yjLN9 6ijv8YepVnWZvrZzlaoGz4Bqz2bvHOrecxKAM= MIME-Version: 1.0 Received: by 10.204.154.74 with SMTP id n10mr733548bkw.33.1299255350638; Fri, 04 Mar 2011 08:15:50 -0800 (PST) Received: by 10.204.14.139 with HTTP; Fri, 4 Mar 2011 08:15:50 -0800 (PST) In-Reply-To: <4D70F990.2040202@vpnc.org> References: <7CDBED48-C800-4169-AF59-72075BA7EC2E@kumari.net> <201103041246.p24CkHZt011245@fs4113.wdf.sap.corp> <4D70F990.2040202@vpnc.org> Date: Fri, 4 Mar 2011 11:15:50 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=0015175cf8d4a5ba18049daa759a Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 16:14:43 -0000 --0015175cf8d4a5ba18049daa759a Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 4, 2011 at 9:39 AM, Paul Hoffman wrote: > On 3/4/11 5:57 AM, Phillip Hallam-Baker wrote: > >> OK, how about this >> >> Define code points for >> >> SHA2-256 >> SHA2-512 >> SHA3-256 (reserved) >> SHA3-512 (reserved) >> > > This would only work if we knew today that there will be algorithms with > those exact names. Those of us following the NIST hash competition have seen > that there is a good chance that will *not* be the case: NIST is explicitly > allowing (some would say encouraging) parameters on the functions. All the finalists are designed to be used as a drop in replacement for SHA2, which is a mandatory requirement. But I do prefer using a hash that incorporates random data in the hash mechanism. It provides a lot of protection against attack, in most cases an attacker has to achieve a first preimage attack rather than a second. So while we could certainly reserve a slot now, it is likely that there will be further discussion on the choice of mode. And I would really like us to be having one IETF conversation at that point and not ten with different combinations of what is mostly the same people. Since we are going to be using this with TLS it is probably going to make most sense to consider what algorithms TLS is going to use. -- Website: http://hallambaker.com/ --0015175cf8d4a5ba18049daa759a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Mar 4, 2011 at 9:39 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrot= e:
On 3/4/11 5:57 AM, Phillip Hallam-Baker wrote:
OK, how about this

Define code points for

SHA2-256
SHA2-512
SHA3-256 (reserved)
SHA3-512 (reserved)

This would only work if we knew today that there will be algorithms with th= ose exact names. Those of us following the NIST hash competition have seen = that there is a good chance that will *not* be the case: NIST is explicitly= allowing (some would say encouraging) parameters on the functions.

All the finalists are designed to be used as a drop in = replacement for SHA2, which is a mandatory requirement.

But I do prefer using a hash that incorporates random data in the has= h mechanism. It provides a lot of protection against attack, in most cases = an attacker has to achieve a first preimage attack rather than a second.=A0=
=A0

So while we could certainly reserve a slo= t now, it is likely that there will be further discussion on the choice of = mode.=A0And I would really like us to be having one IETF conversation at th= at point and not ten with different combinations of what is mostly the same= people.

Since we are going to be using this with TLS it is prob= ably going to make most sense to consider what algorithms TLS is going to u= se.


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

--0015175cf8d4a5ba18049daa759a-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04F173A6A3B for ; Fri, 4 Mar 2011 07:19:42 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1hAurwnVtSf for ; Fri, 4 Mar 2011 07:19:41 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 158673A694C for ; Fri, 4 Mar 2011 07:19:36 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p24FJt7s032466; Fri, 4 Mar 2011 15:20:10 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p24FJdgG032465; Fri, 4 Mar 2011 15:19:39 GMT Date: Fri, 4 Mar 2011 15:19:34 +0000 From: bmanning@vacation.karoshi.com To: Andrew Sullivan Message-ID: <20110304151934.GA31668@vacation.karoshi.com.> References: <6B5E58CC-4DBB-4C43-93F4-FC97A9D358AA@checkpoint.com> <20110304121318.GG16012@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110304121318.GG16012@shinkuro.com> User-Agent: Mutt/1.4.1i Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 15:19:42 -0000 On Fri, Mar 04, 2011 at 07:13:18AM -0500, Andrew Sullivan wrote: > On Fri, Mar 04, 2011 at 11:51:10PM +1300, Peter Gutmann wrote: > > is finalised all I need to do is plug the algorithm in. Putting the same > > thing into DANE isn't hard, and makes it easier to deploy future-compatible > > implementations from day one. > > I don't see any reason to say specifically, "We'll be moving to _x_ so > you better have a placeholder for it". That will simply encourage > foolish programmers to write one placeholder spot, and then when SHA-4 > or whatever comes along we have a new problem. depends on how the spec is written. you have already indicated a preference for more than one algo. Lets call them current & future. for current, lets say we use SHA-256 and future, SHA3. we could then move SHA3 to current and move AndrewsKewlKode to future... and so on... right? > The right way to do this is something like the unknown RRTYPE in DNS. > In that case, you have to be able to handle anything you get (within > the valid codepoint range) _even if_ you don't understand it. By > "handle", I mean, "be able to pass messages; not spit up and die," and > so on. It does not mean, of course, that you have to be able to do > whatever additional section processing or whatever is required, and > you don't need to be able to do anything useful (if you don't know > what NSEC3 is, you're not going to be able to validate with it). > > I'm not sure how to say something similar in this case, but I think > it's the right sort of framework. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C8513A694C for ; Fri, 4 Mar 2011 06:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.829 X-Spam-Level: X-Spam-Status: No, score=-101.829 tagged_above=-999 required=5 tests=[AWL=0.770, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stHobJ9QiOIu for ; Fri, 4 Mar 2011 06:57:31 -0800 (PST) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 64F903A69D7 for ; Fri, 4 Mar 2011 06:57:27 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p24EwWtc030679 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 4 Mar 2011 07:58:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D70FE18.2040703@vpnc.org> Date: Fri, 04 Mar 2011 06:58:32 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: keyassure@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 14:57:32 -0000 On 3/4/11 6:13 AM, Peter Gutmann wrote: > Phillip Hallam-Baker writes: > >> OK, how about this >> >> Define code points for >> >> SHA2-256 >> SHA2-512 >> SHA3-256 (reserved) >> SHA3-512 (reserved) >> >> If SHA3 is ready in time (i.e. we are still not ready in 2012) we could >> consider making SHA3-256 the required algorithm. If not make SHA2-256 and >> SHA2-512 the required algorithms. > > Sounds good, although I'd make 256 a MUST and 512 a MAY, both to keep the > every-bit-is-sacred crowd happy and because in practice there's going to be a > de facto universal default that everyone uses, and my guess is it'll be -256, > in the same way that currently the universal default that everyone uses is > SHA1, no matter what other algorithms the spec allows. While I prefer Warren's original proposal (two mandatory algorithms now), I can see a reason to have just one now followed by strong wording that we are likely to change this in the foreseeable future to a specific code point so implementers need to plan for that now. We don't have to be specific about what will go in that code point because we won't know until NIST is finished, but we can say that we expect that to become mandatory as well. --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C953A687E for ; Fri, 4 Mar 2011 06:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-jJLlv6205v for ; Fri, 4 Mar 2011 06:50:22 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 828293A6864 for ; Fri, 4 Mar 2011 06:50:22 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6CD741ECB41D for ; Fri, 4 Mar 2011 14:51:31 +0000 (UTC) Date: Fri, 4 Mar 2011 09:51:29 -0500 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20110304145129.GF16703@shinkuro.com> References: <6B5E58CC-4DBB-4C43-93F4-FC97A9D358AA@checkpoint.com> <20110304121318.GG16012@shinkuro.com> <4D70F8FA.7020506@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D70F8FA.7020506@vpnc.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 14:50:23 -0000 On Fri, Mar 04, 2011 at 06:36:42AM -0800, Paul Hoffman wrote: > The way I read Warren's proposal, we get exactly what you want. There > are two different mandatory code points defined for two different > hashes, so we are sure that the deployed code will be able to handle > hash agility. We don't care which algorithm people use in practice > because they are both mandatory, so there is no spitting up or dying. > > Does that work for you? Sort of. Maybe it's recent exposure to brain-dead programmers, but I've encountered the situation where a spec says, "There are now two; there might be more in the future." What the programmer does is go away and write an implementation that has the two, and puts a comment in the code that says, "Future code changes may need to be here, because there might be new things defined." Or something like that. As I say, I can't think of much to say about this that's different, so maybe I'm fretting over nothing. But algorithm maintenance is already a headache for DNSSEC, and we've only started deployment. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C1293A6864 for ; Fri, 4 Mar 2011 06:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.82 X-Spam-Level: X-Spam-Status: No, score=-101.82 tagged_above=-999 required=5 tests=[AWL=0.779, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z22mmdi2vdSy for ; Fri, 4 Mar 2011 06:38:07 -0800 (PST) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 82EAA3A6834 for ; Fri, 4 Mar 2011 06:38:07 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p24EdCXo029376 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 4 Mar 2011 07:39:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D70F990.2040202@vpnc.org> Date: Fri, 04 Mar 2011 06:39:12 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: keyassure@ietf.org References: <7CDBED48-C800-4169-AF59-72075BA7EC2E@kumari.net> <201103041246.p24CkHZt011245@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 14:38:08 -0000 On 3/4/11 5:57 AM, Phillip Hallam-Baker wrote: > OK, how about this > > Define code points for > > SHA2-256 > SHA2-512 > SHA3-256 (reserved) > SHA3-512 (reserved) This would only work if we knew today that there will be algorithms with those exact names. Those of us following the NIST hash competition have seen that there is a good chance that will *not* be the case: NIST is explicitly allowing (some would say encouraging) parameters on the functions. --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A52473A6864 for ; Fri, 4 Mar 2011 06:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.81 X-Spam-Level: X-Spam-Status: No, score=-101.81 tagged_above=-999 required=5 tests=[AWL=0.789, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJZ1XHyFcI3N for ; Fri, 4 Mar 2011 06:35:38 -0800 (PST) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 4B6BC3A6834 for ; Fri, 4 Mar 2011 06:35:38 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p24Eah7N029240 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 4 Mar 2011 07:36:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D70F8FA.7020506@vpnc.org> Date: Fri, 04 Mar 2011 06:36:42 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: keyassure@ietf.org References: <6B5E58CC-4DBB-4C43-93F4-FC97A9D358AA@checkpoint.com> <20110304121318.GG16012@shinkuro.com> In-Reply-To: <20110304121318.GG16012@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 14:35:39 -0000 On 3/4/11 4:13 AM, Andrew Sullivan wrote: > On Fri, Mar 04, 2011 at 11:51:10PM +1300, Peter Gutmann wrote: >> is finalised all I need to do is plug the algorithm in. Putting the same >> thing into DANE isn't hard, and makes it easier to deploy future-compatible >> implementations from day one. > > I don't see any reason to say specifically, "We'll be moving to _x_ so > you better have a placeholder for it". That will simply encourage > foolish programmers to write one placeholder spot, and then when SHA-4 > or whatever comes along we have a new problem. > > The right way to do this is something like the unknown RRTYPE in DNS. > In that case, you have to be able to handle anything you get (within > the valid codepoint range) _even if_ you don't understand it. By > "handle", I mean, "be able to pass messages; not spit up and die," and > so on. It does not mean, of course, that you have to be able to do > whatever additional section processing or whatever is required, and > you don't need to be able to do anything useful (if you don't know > what NSEC3 is, you're not going to be able to validate with it). > > I'm not sure how to say something similar in this case, but I think > it's the right sort of framework. The way I read Warren's proposal, we get exactly what you want. There are two different mandatory code points defined for two different hashes, so we are sure that the deployed code will be able to handle hash agility. We don't care which algorithm people use in practice because they are both mandatory, so there is no spitting up or dying. Does that work for you? --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BCC628C0CF for ; Fri, 4 Mar 2011 06:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.541 X-Spam-Level: X-Spam-Status: No, score=-103.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YacAjd6xKAl for ; Fri, 4 Mar 2011 06:12:24 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id E3B8F3A69CF for ; Fri, 4 Mar 2011 06:12:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1299248014; x=1330784014; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20hallam@gmail.com,=20mrex@sap.com|Subject:=20Re:=20 [keyassure]=20Opening=20issue=20#21:=20"Need=20to=20speci fy=20which=20crypto|Cc:=20keyassure@ietf.org|In-Reply-To: =20|Message-Id:=20|Date:=20Sat,=2005=20Mar=202011=2003:13:26=20 +1300; bh=fJs1VQbn79QOP8pKccl+SnfU7LwU0YmZVQfGGcGyszw=; b=IQHXCCU1cWxNVXOwqs9W0sY7+9rr8yPfChsodb2nHuSRTuSE8IVvo+Pi 3fPeUDdW+BO6gAtPMGw+YLOFnrsyyyMqt+jsEIqQlqSAPowqIVV/mmWqu tPD4AUODmRx2Hl262aTVpRPrMIIEZU6LA512nYazNfJfj1YpM/STcndhl M=; X-IronPort-AV: E=Sophos;i="4.62,263,1296990000"; d="scan'208";a="49195972" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 05 Mar 2011 03:13:27 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PvVl0-0004aA-Io; Sat, 05 Mar 2011 03:13:26 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PvVl0-0005Oy-PT; Sat, 05 Mar 2011 03:13:26 +1300 From: Peter Gutmann To: hallam@gmail.com, mrex@sap.com In-Reply-To: Message-Id: Date: Sat, 05 Mar 2011 03:13:26 +1300 Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 14:12:25 -0000 Phillip Hallam-Baker writes: >OK, how about this > >Define code points for > >SHA2-256 >SHA2-512 >SHA3-256 (reserved) >SHA3-512 (reserved) > >If SHA3 is ready in time (i.e. we are still not ready in 2012) we could >consider making SHA3-256 the required algorithm. If not make SHA2-256 and >SHA2-512 the required algorithms. Sounds good, although I'd make 256 a MUST and 512 a MAY, both to keep the every-bit-is-sacred crowd happy and because in practice there's going to be a de facto universal default that everyone uses, and my guess is it'll be -256, in the same way that currently the universal default that everyone uses is SHA1, no matter what other algorithms the spec allows. Peter. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C32953A686D for ; Fri, 4 Mar 2011 05:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaLAKzn8Vhe1 for ; Fri, 4 Mar 2011 05:56:01 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 0A4CF3A67F0 for ; Fri, 4 Mar 2011 05:56:00 -0800 (PST) Received: by bwz13 with SMTP id 13so2433184bwz.31 for ; Fri, 04 Mar 2011 05:57:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+STIRGGS306OgLrgqSsxWtj09frbPAnSJraaOLBEaQE=; b=EDmk9V7BPhEy5QF/9PIRu04jQYm7YlzYF9ZmeawAoet7gJ05lD6WojX1PMoouWGQok BKrj5ANbSa8PrqIl75x7JPadnFMvWqgJOislT+qSse2aREwxXZfxhBoBMFo3kNGDQDKY ccBpmTilUbf6bRCJ28Sm9TlSEPYkILcfuY9RI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qVJkdKfOq7uZE03Rsai7ohPFau8bgPbbln/88rDzpnfqbIlwNmaBPMx6op56f/Ur6h 3s1K+x6Iaz/fBU29VyfRXMosUrlkGNIckUYCIqlXpdj6lS/aWUIfIXMV4rAJeikhXdjk tdjrnPV/D71+eATcOIyH+1ZSZnCwdO1tDhMog= MIME-Version: 1.0 Received: by 10.204.126.148 with SMTP id c20mr580779bks.87.1299247029148; Fri, 04 Mar 2011 05:57:09 -0800 (PST) Received: by 10.204.14.139 with HTTP; Fri, 4 Mar 2011 05:57:09 -0800 (PST) In-Reply-To: <201103041246.p24CkHZt011245@fs4113.wdf.sap.corp> References: <7CDBED48-C800-4169-AF59-72075BA7EC2E@kumari.net> <201103041246.p24CkHZt011245@fs4113.wdf.sap.corp> Date: Fri, 4 Mar 2011 08:57:09 -0500 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=0016e6d6415aa5dc08049da88515 Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 13:56:02 -0000 --0016e6d6415aa5dc08049da88515 Content-Type: text/plain; charset=ISO-8859-1 OK, how about this Define code points for SHA2-256 SHA2-512 SHA3-256 (reserved) SHA3-512 (reserved) If SHA3 is ready in time (i.e. we are still not ready in 2012) we could consider making SHA3-256 the required algorithm. If not make SHA2-256 and SHA2-512 the required algorithms. I don't see the objective here being 'algorithm agility' like we were fixated on in the 90s. We are not picking eight algorithms with a similar level of security in the hope that one of them is going to be secure. What we are doing here is coping with the fact that at the moment we do not have an industry standard digest function that we can be completely happy with and we are currently in the mid point of a transition. On Fri, Mar 4, 2011 at 7:46 AM, Martin Rex wrote: > Warren Kumari wrote: > > > > After watching the thread, I'd like to propose this as a strawman: > > > > Mandatory to implement algorithms are SHA-256 and SHA-384. > > For now, these are all we specify. > > > > 2: Having more than 1 algorithm forces implementations to understand that > > there is not just one, and so should help lead towards algorithm agility > > I'm OK with defining SHA-256 plus another, stronger hash for use with DANE > > I'm OK with mandating SHA-256. > > > I do NOT buy the assertion that it is necessary to have _two_mandatory_ > algorithms for algorithm agility. For other protocols in the security > area, one single manadatory and additional recommended&optional > algorithms are perfectly sufficient. > > SHA-384 also looks like an oddball to me. For agility and interop tests, > defining SHA-512 should be fine. I would expect that by the time > we need to move away from SHA-256, there is a SHA-3 available, and > it would be OK for DANE to move from SHA-256 mandatory to SHA-3 manadatory > without ever making SHA-512 mandatory (only recommended). > > -Martin > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --0016e6d6415aa5dc08049da88515 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OK, how about this

Define code points for=A0
<= br>
SHA2-256
SHA2-512
SHA3-256 (reserved)
SHA3-512 (reserved)

If SHA3 is ready in tim= e (i.e. we are still not ready in 2012) we could consider making SHA3-256 t= he required algorithm. If not make SHA2-256 and SHA2-512 the required algor= ithms.


I don't see the objective here being= 'algorithm agility' like we were fixated on in the 90s. We are not= picking eight algorithms with a similar level of security in the hope that= one of them is going to be secure.=A0

What we are doing here is coping with the fact that at = the moment we do not have an industry standard digest function that we can = be completely happy with and we are currently in the mid point of a transit= ion.


On Fri, Mar 4, 2011 at 7:46 AM= , Martin Rex <mrex@sap= .com> wrote:
Warren Kumari wrote:
>
> After watching the thread, I'd like to propose this as a strawman:=
>
> Mandatory to implement algorithms are SHA-256 and SHA-384.
> For now, these are all we specify.
>
> 2: Having more than 1 algorithm forces implementations to understand t= hat
> there is not just one, and so should help lead towards algorithm agili= ty

I'm OK with defining SHA-256 plus another, stronger hash for use with D= ANE

I'm OK with mandating SHA-256.


I do NOT buy the assertion that it is necessary to have _two_mandatory_
algorithms for algorithm agility. =A0For other protocols in the security area, one single manadatory and additional recommended&optional
algorithms are perfectly sufficient.

SHA-384 also looks like an oddball to me. =A0For agility and interop tests,=
defining SHA-512 should be fine. =A0I would expect that by the time
we need to move away from SHA-256, there is a SHA-3 available, and
it would be OK for DANE to move from SHA-256 mandatory to SHA-3 manadatory<= br> without ever making SHA-512 mandatory (only recommended).

-Martin
__________________________________= _____________
keyassure mailing list
keyassure@ietf.org
https://www.ietf.org/mailman/listinfo/keyassure



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

--0016e6d6415aa5dc08049da88515-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB9DD3A6A2F for ; Fri, 4 Mar 2011 04:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.236 X-Spam-Level: X-Spam-Status: No, score=-10.236 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwDPMAXM1Bnh for ; Fri, 4 Mar 2011 04:45:11 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id AB3F03A6994 for ; Fri, 4 Mar 2011 04:45:10 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p24CkHB4027387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Mar 2011 13:46:17 +0100 (MET) From: Martin Rex Message-Id: <201103041246.p24CkHZt011245@fs4113.wdf.sap.corp> To: warren@kumari.net (Warren Kumari) Date: Fri, 4 Mar 2011 13:46:17 +0100 (MET) In-Reply-To: <7CDBED48-C800-4169-AF59-72075BA7EC2E@kumari.net> from "Warren Kumari" at Mar 3, 11 02:36:21 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 12:45:11 -0000 Warren Kumari wrote: > > After watching the thread, I'd like to propose this as a strawman: > > Mandatory to implement algorithms are SHA-256 and SHA-384. > For now, these are all we specify. > > 2: Having more than 1 algorithm forces implementations to understand that > there is not just one, and so should help lead towards algorithm agility I'm OK with defining SHA-256 plus another, stronger hash for use with DANE I'm OK with mandating SHA-256. I do NOT buy the assertion that it is necessary to have _two_mandatory_ algorithms for algorithm agility. For other protocols in the security area, one single manadatory and additional recommended&optional algorithms are perfectly sufficient. SHA-384 also looks like an oddball to me. For agility and interop tests, defining SHA-512 should be fine. I would expect that by the time we need to move away from SHA-256, there is a SHA-3 available, and it would be OK for DANE to move from SHA-256 mandatory to SHA-3 manadatory without ever making SHA-512 mandatory (only recommended). -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4445B3A6996 for ; Fri, 4 Mar 2011 04:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiuVYQg0HqhL for ; Fri, 4 Mar 2011 04:12:11 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 7AE733A68A7 for ; Fri, 4 Mar 2011 04:12:11 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 187A91ECB41D for ; Fri, 4 Mar 2011 12:13:20 +0000 (UTC) Date: Fri, 4 Mar 2011 07:13:18 -0500 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20110304121318.GG16012@shinkuro.com> References: <6B5E58CC-4DBB-4C43-93F4-FC97A9D358AA@checkpoint.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 12:12:12 -0000 On Fri, Mar 04, 2011 at 11:51:10PM +1300, Peter Gutmann wrote: > is finalised all I need to do is plug the algorithm in. Putting the same > thing into DANE isn't hard, and makes it easier to deploy future-compatible > implementations from day one. I don't see any reason to say specifically, "We'll be moving to _x_ so you better have a placeholder for it". That will simply encourage foolish programmers to write one placeholder spot, and then when SHA-4 or whatever comes along we have a new problem. The right way to do this is something like the unknown RRTYPE in DNS. In that case, you have to be able to handle anything you get (within the valid codepoint range) _even if_ you don't understand it. By "handle", I mean, "be able to pass messages; not spit up and die," and so on. It does not mean, of course, that you have to be able to do whatever additional section processing or whatever is required, and you don't need to be able to do anything useful (if you don't know what NSEC3 is, you're not going to be able to validate with it). I'm not sure how to say something similar in this case, but I think it's the right sort of framework. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A1BE3A69B1 for ; Fri, 4 Mar 2011 02:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.57 X-Spam-Level: X-Spam-Status: No, score=-103.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pHgtWzKNDl2 for ; Fri, 4 Mar 2011 02:50:11 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 1E2583A6A05 for ; Fri, 4 Mar 2011 02:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1299235880; x=1330771880; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20nweaver@icsi.berkeley.edu,=20ynir@checkpoint.com |Subject:=20Re:=20[keyassure]=20Opening=20issue=20#21:=20 "Need=20to=20specify=20which=20crypto|Cc:=20hallam@gmail. com,=20keyassure@ietf.org,=20paul.hoffman@vpnc.org |In-Reply-To:=20<6B5E58CC-4DBB-4C43-93F4-FC97A9D358AA@che ckpoint.com>|Message-Id:=20|Date:=20Fri,=2004=20Mar=202011=2023:51:1 0=20+1300; bh=olqN9+6Q94SZ3ALQrpFjwa2USPlc9RwNksJwAHsr4/0=; b=bggGvXgr1/BNmWM9GJtXMkKrevdew9vcTkbYVp1KkrpAh65GlrK+J0QY 10xhaHGPlacUWO3fQ6UcvJmPj00Wkq1iQNFqEqPpSGgeLB1TfHLd881GT NgYo05QlvDP49M30rYQmuJEVzfsBBOBBr2UZ5aw+pHWC9IVNm0u57kyoy o=; X-IronPort-AV: E=Sophos;i="4.62,263,1296990000"; d="scan'208";a="49183272" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 04 Mar 2011 23:51:11 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PvSbG-0007Hx-Ig; Fri, 04 Mar 2011 23:51:10 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PvSbG-0003G9-Nd; Fri, 04 Mar 2011 23:51:10 +1300 From: Peter Gutmann To: nweaver@icsi.berkeley.edu, ynir@checkpoint.com In-Reply-To: <6B5E58CC-4DBB-4C43-93F4-FC97A9D358AA@checkpoint.com> Message-Id: Date: Fri, 04 Mar 2011 23:51:10 +1300 Cc: keyassure@ietf.org, hallam@gmail.com, paul.hoffman@vpnc.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 10:50:18 -0000 Yoav Nir writes: >On Mar 4, 2011, at 4:26 AM, Nicholas Weaver wrote: >> We should not try to scrimp 16B out in message formatting in this case, its >> silly, redundant, AND encouraging brokenness (bad fragmentation & truncation >> behavior) to remain borken. > >I agree. Ditto. >That's weird text. If when SHA-3 arrives, the RFC had been published, we make >a 3-page "SHA-3 and its use in DANE" draft. If it hasn't, we open an issue and >add it. It would be good though to include a placeholder for SHA3 to that, at most, implementations just have to drop in the implementation code. I've had a placeholder in my code for a while now, it's been tested throughout the code (by using a dummy implementation that returns a constant "hash"), so when SHA3 is finalised all I need to do is plug the algorithm in. Putting the same thing into DANE isn't hard, and makes it easier to deploy future-compatible implementations from day one. Peter. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF70D3A693A for ; Thu, 3 Mar 2011 22:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.57 X-Spam-Level: X-Spam-Status: No, score=-10.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNZsAcfLRGuu for ; Thu, 3 Mar 2011 22:06:45 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 27B7E3A692B for ; Thu, 3 Mar 2011 22:06:39 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p2467hHj031681; Fri, 4 Mar 2011 08:07:43 +0200 X-CheckPoint: {4D7081B3-0-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 4 Mar 2011 08:07:43 +0200 From: Yoav Nir To: Nicholas Weaver Date: Fri, 4 Mar 2011 08:07:41 +0200 Thread-Topic: [keyassure] Opening issue #21: "Need to specify which crypto Thread-Index: AcvaMnkDS32bK0mXQbO4jL1dwTdp9Q== Message-ID: <6B5E58CC-4DBB-4C43-93F4-FC97A9D358AA@checkpoint.com> References: <0412C4C8-347A-418E-9B92-39D4C093525F@icsi.berkeley.edu> In-Reply-To: <0412C4C8-347A-418E-9B92-39D4C093525F@icsi.berkeley.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "keyassure@ietf.org" , Phillip Hallam-Baker , "paul.hoffman@vpnc.org" Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 06:06:48 -0000 On Mar 4, 2011, at 4:26 AM, Nicholas Weaver wrote: >=20 > On Mar 3, 2011, at 5:44 PM, Phillip Hallam-Baker wrote: >=20 >>=20 >>=20 >> On Thu, Mar 3, 2011 at 8:19 PM, Peter Gutmann wrote: >> Paul Hoffman writes: >>=20 >>> 1) Make support for SHA2-256 and SHA2-384 REQUIRED >>=20 >> Why the oddball SHA384, which is just a truncated SHA512? If SHA256 isn= 't >> enough then use the full SHA512, not some oddball variant. >>=20 >> Because we are working in DNS and so the number of bits is actually an i= ssue. >>=20 >> I agree that there is little point to the truncation step when the diges= t is used with a digital signature. But here the extra bits do count. >=20 > A whopping 16 bytes does NOT count: In very VERY few cases will it cause= the DNS message to fall past the magic ~1472B and ~4000B boundries where y= ou start to have fragmentation & truncation, AND in those cases, the resolv= er damn well better be able to handle it. >=20 > We should not try to scrimp 16B out in message formatting in this case, i= ts silly, redundant, AND encouraging brokenness (bad fragmentation & trunca= tion behavior) to remain borken. I agree. >=20 >> When is your estimate for the SHA3 process completing? >>=20 >> I am a bit nervous having a WG depend on the output of any external proc= ess. >=20 > Why not "AND, when NIST approves it, SHA3"? in the text? That's weird text. If when SHA-3 arrives, the RFC had been published, we ma= ke a 3-page "SHA-3 and its use in DANE" draft. If it hasn't, we open an iss= ue and add it.= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D96D43A6806 for ; Thu, 3 Mar 2011 18:25:29 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnLyuPxA26hJ for ; Thu, 3 Mar 2011 18:25:29 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 04C7D3A65A6 for ; Thu, 3 Mar 2011 18:25:29 -0800 (PST) Received: from albook.hsd1.ca.comcast.net (c-67-164-126-174.hsd1.ca.comcast.net [67.164.126.174]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 16B0236A416; Thu, 3 Mar 2011 18:26:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Thu, 3 Mar 2011 18:26:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0412C4C8-347A-418E-9B92-39D4C093525F@icsi.berkeley.edu> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org, paul.hoffman@vpnc.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 02:25:30 -0000 On Mar 3, 2011, at 5:44 PM, Phillip Hallam-Baker wrote: >=20 >=20 > On Thu, Mar 3, 2011 at 8:19 PM, Peter Gutmann = wrote: > Paul Hoffman writes: >=20 > >1) Make support for SHA2-256 and SHA2-384 REQUIRED >=20 > Why the oddball SHA384, which is just a truncated SHA512? If SHA256 = isn't > enough then use the full SHA512, not some oddball variant. >=20 > Because we are working in DNS and so the number of bits is actually an = issue. >=20 > I agree that there is little point to the truncation step when the = digest is used with a digital signature. But here the extra bits do = count. A whopping 16 bytes does NOT count: In very VERY few cases will it = cause the DNS message to fall past the magic ~1472B and ~4000B boundries = where you start to have fragmentation & truncation, AND in those cases, = the resolver damn well better be able to handle it. We should not try to scrimp 16B out in message formatting in this case, = its silly, redundant, AND encouraging brokenness (bad fragmentation & = truncation behavior) to remain borken. > When is your estimate for the SHA3 process completing? >=20 > I am a bit nervous having a WG depend on the output of any external = process. Why not "AND, when NIST approves it, SHA3"? in the text? Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31CAD3A6814 for ; Thu, 3 Mar 2011 17:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.8 X-Spam-Level: X-Spam-Status: No, score=-101.8 tagged_above=-999 required=5 tests=[AWL=0.799, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aX+dB2uI0krN for ; Thu, 3 Mar 2011 17:44:23 -0800 (PST) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 1047F3A65A5 for ; Thu, 3 Mar 2011 17:44:22 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p241jUtK094544 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 3 Mar 2011 18:45:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D70443A.2040807@vpnc.org> Date: Thu, 03 Mar 2011 17:45:30 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: keyassure@ietf.org References: <9933A160-3DAF-42FA-B5FA-DDF185FA5C63@kumari.net> <7CDBED48-C800-4169-AF59-72075BA7EC2E@kumari.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement" X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 01:44:24 -0000 On 3/3/11 4:29 PM, Phillip Hallam-Baker wrote: > That works for me And me as well. --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B60403A6814 for ; Thu, 3 Mar 2011 17:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEqJMKbJR34Q for ; Thu, 3 Mar 2011 17:43:45 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 36D213A65A5 for ; Thu, 3 Mar 2011 17:43:45 -0800 (PST) Received: by bwz13 with SMTP id 13so1993098bwz.31 for ; Thu, 03 Mar 2011 17:44:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R5k29iNFEbpqU2xilHhnr605+WafktYpDWmUjSgOf84=; b=VEvmoZIisKUlpjssD3+F2jt9Ug8FLYktN0K8W7c2uSzc9q3uZM84Dm0lOsBXKjr46F IEmZlktWF6TDxgvwl5HEB72+OwIlGLmb8wjx1uYfjR+b4voDH45gim9HLjvvihv2aJdd pWFVMRdXRweyKaQaCI0zeqSQBDv3sHg0017mo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rqWf6SWkCgHL/8y4E+eCt3jL0WFr00VtOPcm5h3jTjgbXrKuy0M2elgkLdDuIKuplH m5Xv2Zbcrb3/InyoPa98oVeDGiN6IwvcLT8qjz/CIOIZcXnQSPWYX52WcTJYnpUVry0x Eirx+QPuECs4j3sTmkppcwO5D7OTNguy5M5Yg= MIME-Version: 1.0 Received: by 10.204.126.148 with SMTP id c20mr30809bks.87.1299203092959; Thu, 03 Mar 2011 17:44:52 -0800 (PST) Received: by 10.204.14.139 with HTTP; Thu, 3 Mar 2011 17:44:52 -0800 (PST) In-Reply-To: References: Date: Thu, 3 Mar 2011 20:44:52 -0500 Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann Content-Type: multipart/alternative; boundary=0016e6d6415ad8d1d1049d9e4ac2 Cc: keyassure@ietf.org, paul.hoffman@vpnc.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 01:43:46 -0000 --0016e6d6415ad8d1d1049d9e4ac2 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 3, 2011 at 8:19 PM, Peter Gutmann wrote: > Paul Hoffman writes: > > >1) Make support for SHA2-256 and SHA2-384 REQUIRED > > Why the oddball SHA384, which is just a truncated SHA512? If SHA256 isn't > enough then use the full SHA512, not some oddball variant. > Because we are working in DNS and so the number of bits is actually an issue. I agree that there is little point to the truncation step when the digest is used with a digital signature. But here the extra bits do count. > In any case what we should really be specifying is SHA256 and SHA3. If > SHA256 > really isn't cromulent enough for people then SHA384 won't be either, and > by > the time this sees significant deployment we'll have SHA3 anyway. How much > real-world support is there for SHA384? I've only just seen SHA256 > creeping > in here and there, but never SHA384. Again, by the time there's even > single- > digit deployment of SHA384 (if there ever is), we'll have SHA3 ready to go. When is your estimate for the SHA3 process completing? I am a bit nervous having a WG depend on the output of any external process. -- Website: http://hallambaker.com/ --0016e6d6415ad8d1d1049d9e4ac2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Mar 3, 2011 at 8:19 PM, Peter Gu= tmann <pg= ut001@cs.auckland.ac.nz> wrote:
Paul Hoffman <paul.hoffman@vpnc.org> writes:

>1) Make support for SHA2-256 and SHA2-384 REQUIRED

Why the oddball SHA384, which is just a truncated SHA512? =A0If SHA25= 6 isn't
enough then use the full SHA512, not some oddball variant.
=

Because we are working in DNS and so the number of bits= is actually an issue.

I agree that there is littl= e point to the truncation step when the digest is used with a digital signa= ture. But here the extra bits do count.

=A0
In any case what we should really be specifying is SHA256 and SHA3. =A0If S= HA256
really isn't cromulent enough for people then SHA384 won't be eithe= r, and by
the time this sees significant deployment we'll have SHA3 anyway. =A0Ho= w much
real-world support is there for SHA384? =A0I've only just seen SHA256 c= reeping
in here and there, but never SHA384. =A0Again, by the time there's even= single-
digit deployment of SHA384 (if there ever is), we'll have SHA3 ready to= go.

When is your estimate for the SHA3 pro= cess completing?

I am a bit nervous having a WG de= pend on the output of any external process.
=A0

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

--0016e6d6415ad8d1d1049d9e4ac2-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1C463A683F for ; Thu, 3 Mar 2011 17:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.594 X-Spam-Level: X-Spam-Status: No, score=-103.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAUiYG1-sCtT for ; Thu, 3 Mar 2011 17:18:41 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id A1A0F3A6814 for ; Thu, 3 Mar 2011 17:18:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1299201591; x=1330737591; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20hallam@gmail.com,=20paul.hoffman@vpnc.org|Subject: =20Re:=20[keyassure]=20Opening=20issue=20#21:=20"Need=20t o=20specify=20which=20crypto|Cc:=20keyassure@ietf.org |In-Reply-To:=20|Message-Id:=20|Date:=20Fri,=2004=20Mar=202 011=2014:19:48=20+1300; bh=kNvNZ1wwmZr0Uq7329hAo/KBUYsGz/MIl6a13iWmpNw=; b=NJ3IqrV9T0KJIJ902nio/UXeqyc72RRCE/mLO2gRP0b1o9wLzCxj3Lws 4FX0xzglSRmJBKjZ4gYAMYGhFpnMxKHjVHMKwAJAWKJsJ4uZ1rCL1O38f lbrO69hPuU26nYYbVlMdM775Drk4dq2UMG5aV747htH4MFIhTxPPqsunf M=; X-IronPort-AV: E=Sophos;i="4.62,261,1296990000"; d="scan'208";a="49097943" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 04 Mar 2011 14:19:48 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PvJgK-0004dp-GM; Fri, 04 Mar 2011 14:19:48 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PvJgK-0003AF-04; Fri, 04 Mar 2011 14:19:48 +1300 From: Peter Gutmann To: hallam@gmail.com, paul.hoffman@vpnc.org In-Reply-To: Message-Id: Date: Fri, 04 Mar 2011 14:19:48 +1300 Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 01:18:42 -0000 Paul Hoffman writes: >1) Make support for SHA2-256 and SHA2-384 REQUIRED Why the oddball SHA384, which is just a truncated SHA512? If SHA256 isn't enough then use the full SHA512, not some oddball variant. In any case what we should really be specifying is SHA256 and SHA3. If SHA256 really isn't cromulent enough for people then SHA384 won't be either, and by the time this sees significant deployment we'll have SHA3 anyway. How much real-world support is there for SHA384? I've only just seen SHA256 creeping in here and there, but never SHA384. Again, by the time there's even single- digit deployment of SHA384 (if there ever is), we'll have SHA3 ready to go. Peter. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3BF3A6806 for ; Thu, 3 Mar 2011 17:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.79 X-Spam-Level: X-Spam-Status: No, score=-101.79 tagged_above=-999 required=5 tests=[AWL=0.809, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SH7d49LuDjlV for ; Thu, 3 Mar 2011 17:15:55 -0800 (PST) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 23ACB3A67FC for ; Thu, 3 Mar 2011 17:15:54 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p241H1vt093447 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 3 Mar 2011 18:17:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D703D8E.4050006@vpnc.org> Date: Thu, 03 Mar 2011 17:17:02 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: "keyassure@ietf.org" Content-Type: multipart/mixed; boundary="------------020105010507090504000909" Subject: [keyassure] Not yet for WG consideration: draft-hoffman-dane-smime-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 01:15:56 -0000 This is a multi-part message in MIME format. --------------020105010507090504000909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is just a heads-up that Jakob and I have submitted a new draft that might be considered by the WG, BUT NOT YET. We did this now so that we can do a brief presentation at the Prague meeting, but the chairs have asked that we *not* take WG focus from the current TLSA work, and that sounds fine to us. --Paul Hoffman -------- Original Message -------- Subject: I-D Action:draft-hoffman-dane-smime-00.txt Date: Thu, 03 Mar 2011 13:45:01 -0800 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using Secure DNS to Associate Certificates with Domain Names For S/MIME Author(s) : P. Hoffman, J. Schlyter Filename : draft-hoffman-dane-smime-00.txt Pages : 8 Date : 2011-03-03 S/MIME uses certificates for authenticating and encrypting messages. Users want their mail user agents to securely associate a certificate with the sender of an encrypted and/or signed message. DNSSEC provides a mechanism for a zone operator to sign DNS information directly. This way, bindings of certificates to users within a domain are asserted not by external entities, but by the entities that operate the DNS. This document describes how to use secure DNS to associate an S/MIME user's certificate with the the intended domain name. IMPORTANT NOTE: This draft is intentionally sketchy. It is meant as a possible starting point for the DANE WG if it wants to consider making a protocol similar to TLSA, as described in draft-ietf-dane-protocol, but that applies to S/MIME. The WG may or may not want to adopt such work, or if it does, may want to use a very different scheme from the one described here. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoffman-dane-smime-00.txt --------------020105010507090504000909 Content-Type: Message/External-body; name="draft-hoffman-dane-smime-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-hoffman-dane-smime-00.txt" Content-Type: text/plain Content-ID: <2011-03-03134055.I-D@ietf.org> --------------020105010507090504000909 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------020105010507090504000909-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B420A3A68AE for ; Thu, 3 Mar 2011 16:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.594 X-Spam-Level: X-Spam-Status: No, score=-103.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAy6aDfWnCnI for ; Thu, 3 Mar 2011 16:56:47 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 4D46A3A687C for ; Thu, 3 Mar 2011 16:56:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1299200276; x=1330736276; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20hallam@gmail.com,=20rob.stradling@comodo.com |Subject:=20Re:=20[keyassure]=20crypto=20hash=20alg=20dep recation=20is=20a=20myth|Cc:=20keyassure@ietf.org |In-Reply-To:=20|Message-Id:=20|Date:=20Fri,=2004=20Mar=202011 =2013:57:53=20+1300; bh=vn+oF59GDNarM0Pb3s0GuNEBs5f92cU3oYh06LxBJDk=; b=gOukHHpPHTunZ8Veo6IRVJh278Fj9Z4gxzsIjDoqz9qgMXetagn7+zQX WPbJ35xhwQfh+ccAvgjuOKEq1lHpGLTd+zMwaj6K8UD6FjbhiYW8z9d4A 8Xaz2VQzWsGzFP0DWoNuZ6KORLJZTjWd5XFP8uZ46wKfDu2lHcYiWtVs3 Q=; X-IronPort-AV: E=Sophos;i="4.62,261,1296990000"; d="scan'208";a="49085946" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 04 Mar 2011 13:57:53 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PvJL7-0003k1-Gz; Fri, 04 Mar 2011 13:57:53 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PvJL7-0001ue-72; Fri, 04 Mar 2011 13:57:53 +1300 From: Peter Gutmann To: hallam@gmail.com, rob.stradling@comodo.com In-Reply-To: Message-Id: Date: Fri, 04 Mar 2011 13:57:53 +1300 Cc: keyassure@ietf.org Subject: Re: [keyassure] crypto hash alg deprecation is a myth X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 00:56:48 -0000 Phillip Hallam-Baker writes: >The reason that there is concern about algorithm support in protocols is that >it takes a very very long time to get changes through the system. It can take >five years to persuade vendors to make changes and then another ten for the >old software to work through the system. See also Question J of http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt (based on a very ad hoc survey of a bunch of implementers, but it's good enough as a rough guide). Peter. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B47743A68E2 for ; Thu, 3 Mar 2011 16:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o92Q3Podq3tW for ; Thu, 3 Mar 2011 16:28:46 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 94A8D3A68B5 for ; Thu, 3 Mar 2011 16:28:45 -0800 (PST) Received: by bwz13 with SMTP id 13so1951690bwz.31 for ; Thu, 03 Mar 2011 16:29:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Tu9tjFncnEJJNFIt5sLqvT5w1NkgZRgP5OA+ZTu3UuA=; b=QzQqCWV9jhtmDku9pK7GpVedrSE8kFkWyl+DUzfyDOPaSXP3tGe4XRqRH6Cu1XGYZm Dnw8n1pgjgSCOouuMmutcyLU4I4Y80ktWY0hvwAUufBdxV4Z/9DEJpP/XREVIdXdPCxr EO40WXzyIogVKcFiBwYzILzuKi6ZxZRToJyTk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BzNiRzmVVxLripV6jI01jWwqIEc+q5RUyguhKvDGMAOadKmU+cmZgFXbl4ngW4fwKz lKo9glaX0ys394cz7qS9Qk+tHOXMMY5VVzyIv1h0Pq3Jixq1wHC7AOxOFKMcDC3z6l+T YWntLcCWyoAWKwMl3/TfhW41qXNl/hT72JYDs= MIME-Version: 1.0 Received: by 10.204.231.2 with SMTP id jo2mr27333bkb.60.1299198593030; Thu, 03 Mar 2011 16:29:53 -0800 (PST) Received: by 10.204.14.139 with HTTP; Thu, 3 Mar 2011 16:29:52 -0800 (PST) In-Reply-To: <7CDBED48-C800-4169-AF59-72075BA7EC2E@kumari.net> References: <9933A160-3DAF-42FA-B5FA-DDF185FA5C63@kumari.net> <7CDBED48-C800-4169-AF59-72075BA7EC2E@kumari.net> Date: Thu, 3 Mar 2011 19:29:52 -0500 Message-ID: From: Phillip Hallam-Baker To: Warren Kumari Content-Type: multipart/alternative; boundary=485b393ab631a158ad049d9d3ee9 Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement" X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 00:28:47 -0000 --485b393ab631a158ad049d9d3ee9 Content-Type: text/plain; charset=ISO-8859-1 That works for me On Thu, Mar 3, 2011 at 2:36 PM, Warren Kumari wrote: > Hi all, > > After watching the thread, I'd like to propose this as a strawman: > > Mandatory to implement algorithms are SHA-256 and SHA-384. For now, these > are all we specify. > > My reasoning behind this is: > 1: We don't want to support too many algorithms -- it leads to complexity > (which leads to weaker security) and opens the door to interoperability > issues and fights over why algorithm X was allowed and Y was not. > > 2: Having more than 1 algorithm forces implementations to understand that > there is not just one, and so should help lead towards algorithm agility > > 3: In order to do DANE, you have to be able to do DNSSEC -- in order to do > DNSSEC you should already support the above. > > 4: (IMO, an important one, even if not technical one) giving people the > ability to choose will lead to greater deployment. Some folk will claim that > SHA-256 is too short. Some will claim that SHA-384 is excessively long and > computationally expensive. Some will claim something completely random. > Almost none of them will have any (rational) basis for their claims, but > allowing them to use the algorithm they believe is superior will make them > more likely to deploy. > > 5: 2 algorithms seems like enough. While SHA1 may or may not be suitable > (my (and to be completely blunt, your) views don't really matter) -- there > are enough strong views on the strength / lifetime that we are likely to get > bogged down / splinter over this. If we were already deployed with SHA1 this > would be an important decision, but seeing as we're not, I think that > avoiding fight (and living to see another day) is best. > Once again, I'm not saying that I think that SHA1 is (or isn't) fine for > this, rather that, in order to get deployed, we should avoid the issue. > > #4 and #5 might be pandering, but if it doesn't decrease security, and > leads to sooner / more deployment it seems like a win.... > > Does anyone object to this (for any reasons other than "You're running away > from the fight, you coward!")? > Please speak soon, as we'd love to close this out.... > > > Please don't let this dissolve into a "algorithm X is better than Y, and Z > is a pile o' rubble" discussion -- while that may be true, this is not the > time or place to have it.... > > > W > > > On Feb 25, 2011, at 4:31 PM, Warren Kumari wrote: > > > Hi all, > > > > While we are all ruminating on the other issues, I figured we might as > well try address this one: > > > > Need to specify which crypto algorithms and certificate types are > mandatory to implement -- > http://trac.tools.ietf.org/wg/dane/trac/ticket/21 > > > > Description: > > Currently, the draft is silent on which crypto algorithms and certificate > types must be implemented for interoperability. It should be specific before > the document is finished. > > > > > > W > > _______________________________________________ > > keyassure mailing list > > keyassure@ietf.org > > https://www.ietf.org/mailman/listinfo/keyassure > > > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --485b393ab631a158ad049d9d3ee9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That works for me


On Thu, Mar 3= , 2011 at 2:36 PM, Warren Kumari <warren@kumari.net> wrote:
Hi all,

After watching the thread, I'd like to propose this as a strawman:

Mandatory to implement algorithms are SHA-256 and SHA-384. For now, these a= re all we specify.

My reasoning behind this is:
1: We don't want to support too many algorithms -- it leads to complexi= ty (which leads to weaker security) and opens the door to interoperability = issues and fights over why algorithm X was allowed and Y was not.

2: Having more than 1 algorithm forces implementations to understand that t= here is not just one, and so should help lead towards algorithm agility

3: In order to do DANE, you have to be able to do DNSSEC -- in order to do = DNSSEC you should already support the above.

4: (IMO, an important one, even if not technical one) giving people the abi= lity to choose will lead to greater deployment. Some folk will claim that S= HA-256 is too short. Some will claim that SHA-384 is excessively long and c= omputationally expensive. Some will claim something completely random. Almo= st none of them will have any (rational) basis for their claims, but allowi= ng them to use the algorithm they believe is superior will make them more l= ikely to deploy.

5: 2 algorithms seems like enough. While SHA1 may or may not be suitable (m= y (and to be completely blunt, your) views don't really matter) -- ther= e are enough strong views on the strength / lifetime that we are likely to = get bogged down / splinter over this. If we were already deployed with SHA1= this would be an important decision, but seeing as we're not, I think = that avoiding fight (and living to see another day) is best.
Once again, I'm not saying that I think that SHA1 is (or isn't) fin= e for this, rather that, in order to get deployed, we should avoid the issu= e.

#4 and #5 might be pandering, but if it doesn't decrease security, and = leads to sooner / more deployment it seems like a win....

Does anyone object to this (for any reasons other than "You're run= ning away from the fight, you coward!")?
Please speak soon, as we'd love to close this out....

<chair hat>
Please don't let this dissolve into a "algorithm X is better than = Y, and Z is a pile o' rubble" discussion -- while that may be true= , this is not the time or place to have it....
</chair hat>

W


On Feb 25, 2011, at 4:31 PM, Warren Kumari wrote:

> Hi all,
>
> While we are all ruminating on the other issues, I figured we might as= well try address this one:
>
> Need to specify which crypto algorithms and certificate types are mand= atory to implement -- http://trac.tools.ietf.org/wg/dane/trac/ticket/2= 1
>
> Description:
> Currently, the draft is silent on which crypto algorithms and certific= ate types must be implemented for interoperability. It should be specific b= efore the document is finished.
>
>
> W
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure
>

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



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

--485b393ab631a158ad049d9d3ee9-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E531A3A688F for ; Thu, 3 Mar 2011 12:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.064 X-Spam-Level: X-Spam-Status: No, score=-102.064 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEMqUqMyJaij for ; Thu, 3 Mar 2011 12:25:07 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id D29753A686A for ; Thu, 3 Mar 2011 12:25:07 -0800 (PST) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta01.emeryville.ca.mail.comcast.net with comcast id EkHd1g0040mlR8UA1kSGYM; Thu, 03 Mar 2011 20:26:16 +0000 Received: from olympia.mars.sol ([68.33.77.0]) by omta11.emeryville.ca.mail.comcast.net with comcast id EkSD1g01100PQ6U8XkSE22; Thu, 03 Mar 2011 20:26:15 +0000 Received: from olympia.mars.sol (localhost [127.0.0.1]) by olympia.mars.sol (8.14.4/8.14.3) with ESMTP id p23KQCe5002840 for ; Thu, 3 Mar 2011 15:26:12 -0500 Received: (from draco@localhost) by olympia.mars.sol (8.14.4/8.14.4/Submit) id p23KQCcg002838 for keyassure@ietf.org; Thu, 3 Mar 2011 15:26:12 -0500 Date: Thu, 3 Mar 2011 15:26:12 -0500 From: Scott Schmit To: keyassure@ietf.org Message-ID: <20110303202612.GA2782@odin.mars.sol> Mail-Followup-To: keyassure@ietf.org References: <9933A160-3DAF-42FA-B5FA-DDF185FA5C63@kumari.net> <7CDBED48-C800-4169-AF59-72075BA7EC2E@kumari.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7CDBED48-C800-4169-AF59-72075BA7EC2E@kumari.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement" X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 20:25:10 -0000 On Thu, Mar 03, 2011 at 02:36:21PM -0500, Warren Kumari wrote keyassure: > Hi all, > > After watching the thread, I'd like to propose this as a strawman: > > Mandatory to implement algorithms are SHA-256 and SHA-384. For now, these are all we specify. > Seems like a perfectly reasonable compromise to me. -- Scott Schmit Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1E0B3A69F4 for ; Thu, 3 Mar 2011 11:35:14 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfTh-JmPAG18 for ; Thu, 3 Mar 2011 11:35:14 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id DAA843A69EE for ; Thu, 3 Mar 2011 11:35:13 -0800 (PST) Received: from dhcp-172-29-46-185.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id 4C5081B40F5D; Thu, 3 Mar 2011 14:36:21 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <9933A160-3DAF-42FA-B5FA-DDF185FA5C63@kumari.net> Date: Thu, 3 Mar 2011 14:36:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7CDBED48-C800-4169-AF59-72075BA7EC2E@kumari.net> References: <9933A160-3DAF-42FA-B5FA-DDF185FA5C63@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement" X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 19:35:15 -0000 Hi all, After watching the thread, I'd like to propose this as a strawman: Mandatory to implement algorithms are SHA-256 and SHA-384. For now, = these are all we specify. My reasoning behind this is: 1: We don't want to support too many algorithms -- it leads to = complexity (which leads to weaker security) and opens the door to = interoperability issues and fights over why algorithm X was allowed and = Y was not. 2: Having more than 1 algorithm forces implementations to understand = that there is not just one, and so should help lead towards algorithm = agility 3: In order to do DANE, you have to be able to do DNSSEC -- in order to = do DNSSEC you should already support the above. 4: (IMO, an important one, even if not technical one) giving people the = ability to choose will lead to greater deployment. Some folk will claim = that SHA-256 is too short. Some will claim that SHA-384 is excessively = long and computationally expensive. Some will claim something completely = random. Almost none of them will have any (rational) basis for their = claims, but allowing them to use the algorithm they believe is superior = will make them more likely to deploy.=20 5: 2 algorithms seems like enough. While SHA1 may or may not be suitable = (my (and to be completely blunt, your) views don't really matter) -- = there are enough strong views on the strength / lifetime that we are = likely to get bogged down / splinter over this. If we were already = deployed with SHA1 this would be an important decision, but seeing as = we're not, I think that avoiding fight (and living to see another day) = is best. Once again, I'm not saying that I think that SHA1 is (or isn't) fine for = this, rather that, in order to get deployed, we should avoid the issue. #4 and #5 might be pandering, but if it doesn't decrease security, and = leads to sooner / more deployment it seems like a win.... Does anyone object to this (for any reasons other than "You're running = away from the fight, you coward!")?=20 Please speak soon, as we'd love to close this out.... Please don't let this dissolve into a "algorithm X is better than Y, and = Z is a pile o' rubble" discussion -- while that may be true, this is not = the time or place to have it.... W On Feb 25, 2011, at 4:31 PM, Warren Kumari wrote: > Hi all, >=20 > While we are all ruminating on the other issues, I figured we might as = well try address this one: >=20 > Need to specify which crypto algorithms and certificate types are = mandatory to implement -- = http://trac.tools.ietf.org/wg/dane/trac/ticket/21 >=20 > Description: > Currently, the draft is silent on which crypto algorithms and = certificate types must be implemented for interoperability. It should be = specific before the document is finished. >=20 >=20 > W > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure >=20 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F37D3A6964 for ; Thu, 3 Mar 2011 06:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjF8cc7W5oXQ for ; Thu, 3 Mar 2011 06:33:11 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 4D2543A67E7 for ; Thu, 3 Mar 2011 06:33:11 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3ABA71ECB41D for ; Thu, 3 Mar 2011 14:34:18 +0000 (UTC) Date: Thu, 3 Mar 2011 09:34:16 -0500 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20110303143415.GE51215@shinkuro.com> References: <201103030509.p2359FSK025866@fs4113.wdf.sap.corp> <201103030746.53024.rob.stradling@comodo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] crypto hash alg deprecation is a myth X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 14:33:12 -0000 On Thu, Mar 03, 2011 at 08:57:04AM -0500, Phillip Hallam-Baker wrote: > > One of the very few signals available that is listened to is to stop > supporting old algorithms in new protocols. But as I think Warren said upthread, we simply don't need to list the protocols we don't want _at all_. Then they're not supported from the get go. We don't need to talk about algorithms we don't want to support. The key thing, I think we all agree, is to make sure algorithm change can happen. This is an area where DNSSEC is still somewhat less than perfect, for instance. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF1743A67F2 for ; Thu, 3 Mar 2011 05:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.573 X-Spam-Level: X-Spam-Status: No, score=-3.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ups5W+vSwXD9 for ; Thu, 3 Mar 2011 05:56:08 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 1B1363A6964 for ; Thu, 3 Mar 2011 05:55:57 -0800 (PST) Received: by bwz13 with SMTP id 13so1356013bwz.31 for ; Thu, 03 Mar 2011 05:57:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KmcpZkRfN3ABJA711hWFzFBebWUIKRFmUBjcWFE9cyc=; b=f+/QXsAvF2wH+75q1Gq/35sSH3trE6/haZimwktdxP7sfl1aMKbK2Juz6Jwss40wmP 1n+iU7J/1UO2J4lbdS2Uo0FfVnMsy8E6VjkQjTiFsmRsOjRi6tbmSc4XKWu4R0DdaDKD 9j8FwmLYqcygS5IYD3EI7CYo7sdwsTy+nOAmk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Ct47dm5z74poEQ5WZ+D/JaB+1JW2pkmjbsmWZiTdg7d1TL16jY3a8jXlYXRhmxbQim i/EAUCz4j6gLmTo/t2D2fH33kwy5gzMiJ8G27bUS47Wet/EVNL2y9ACT3xhbmhCFIGU6 leicUWmjRnlGiXyiiXPN+PHXidGNRPyIcZ+Zg= MIME-Version: 1.0 Received: by 10.204.126.99 with SMTP id b35mr1420144bks.168.1299160625011; Thu, 03 Mar 2011 05:57:05 -0800 (PST) Received: by 10.204.14.139 with HTTP; Thu, 3 Mar 2011 05:57:04 -0800 (PST) In-Reply-To: <201103030746.53024.rob.stradling@comodo.com> References: <201103030509.p2359FSK025866@fs4113.wdf.sap.corp> <201103030746.53024.rob.stradling@comodo.com> Date: Thu, 3 Mar 2011 08:57:04 -0500 Message-ID: From: Phillip Hallam-Baker To: Rob Stradling Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] crypto hash alg deprecation is a myth X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 13:56:11 -0000 On another algorithm issue, certain people were waiting for CAs to support the new algorithm before implementing them in application software. By support, they meant issue certificates that would break with their softw= are. The reason that there is concern about algorithm support in protocols is that it takes a very very long time to get changes through the system. It can take five years to persuade vendors to make changes and then another ten for the old software to work through the system. Auto update helps, but that may only prove to be a temporary change. There are enough applications out there that do auto update very badly that people are being taught to turn them off. One of the very few signals available that is listened to is to stop supporting old algorithms in new protocols. On Thu, Mar 3, 2011 at 2:46 AM, Rob Stradling wr= ote: > On Thursday 03 Mar 2011 05:09:15 Martin Rex wrote: >> Phillip Hallam-Baker wrote: >> > Further, even though we stopped using MD5 in the mid 90s >> > >> Firefox happily verifies md5WithRsaEncryption signatures on TLS server >> certs. > > Not for much longer. > > https://wiki.mozilla.org/CA:MD5and1024 says: > " =A0 =A0* June 30, 2011 =96 Mozilla will stop accepting MD5 as a hash al= gorithm for > intermediate and end-entity certificates. After this date software publis= hed > by Mozilla will return an error when a certificate with an MD5-based sign= ature > is used. > =A0 =A0 =A0 =A0 =A0o This change is being tracked in > https://bugzilla.mozilla.org/show_bug.cgi?id=3D590364" > > >> MSIE 8 on Windows 7 (and prior) will happily talk to TLS servers >> using certs signed not only with md5WithRsaSignature, but also >> md2WithRsaSignature and even (**cough**) md4WithRsaSignature! > > http://technet.microsoft.com/en-us/library/cc751157.aspx#EMAA says: > "In the event of an imminent MD5 pre-image attack > Microsoft may update Windows to reject all MD2, MD4 or MD5 end-entity and > subordinate CA certificates when it has reasons to believe that successfu= l MD5 > pre-image attacks are imminent." > > Perhaps somebody should ask them to consider switching off MD2 and MD4 so= oner > than that. > > >> (If it is possible to disable md5WithRsaEncryption signature verificatio= n >> =A0in Firefox 3.5 -- then it is sufficiently well hidden that I don't >> =A0see it.) > > https://bugzilla.mozilla.org/show_bug.cgi?id=3D590364 suggests setting th= e > following environment variable: > > NSS_HASH_ALG_SUPPORT=3D-MD2,-MD5 > > > > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A3A83A6942 for ; Wed, 2 Mar 2011 23:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.677 X-Spam-Level: X-Spam-Status: No, score=-5.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhY9I71t3oHJ for ; Wed, 2 Mar 2011 23:45:45 -0800 (PST) Received: from ian.brad.office.comodo.net (brad.comodogroup.com [82.109.38.202]) by core3.amsl.com (Postfix) with ESMTP id C677F3A6403 for ; Wed, 2 Mar 2011 23:45:41 -0800 (PST) Received: (qmail 30840 invoked by uid 1000); 3 Mar 2011 07:46:46 -0000 Received: from nigel.brad.office.comodo.net (HELO nigel.localnet) (192.168.0.58) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPS; Thu, 03 Mar 2011 07:46:46 +0000 From: Rob Stradling To: keyassure@ietf.org, mrex@sap.com Date: Thu, 3 Mar 2011 07:46:52 +0000 User-Agent: KMail/1.13.5 (Linux/2.6.32-gentoo-r7; KDE/4.4.5; i686; ; ) References: <201103030509.p2359FSK025866@fs4113.wdf.sap.corp> In-Reply-To: <201103030509.p2359FSK025866@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201103030746.53024.rob.stradling@comodo.com> Cc: Phillip Hallam-Baker Subject: Re: [keyassure] crypto hash alg deprecation is a myth X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 07:45:46 -0000 On Thursday 03 Mar 2011 05:09:15 Martin Rex wrote: > Phillip Hallam-Baker wrote: > > Further, even though we stopped using MD5 in the mid 90s >=20 > Firefox happily verifies md5WithRsaEncryption signatures on TLS server > certs. Not for much longer. https://wiki.mozilla.org/CA:MD5and1024 says: " * June 30, 2011 =E2=80=93 Mozilla will stop accepting MD5 as a hash al= gorithm for=20 intermediate and end-entity certificates. After this date software publishe= d=20 by Mozilla will return an error when a certificate with an MD5-based signat= ure=20 is used. o This change is being tracked in=20 https://bugzilla.mozilla.org/show_bug.cgi?id=3D590364" > MSIE 8 on Windows 7 (and prior) will happily talk to TLS servers > using certs signed not only with md5WithRsaSignature, but also > md2WithRsaSignature and even (**cough**) md4WithRsaSignature! http://technet.microsoft.com/en-us/library/cc751157.aspx#EMAA says: "In the event of an imminent MD5 pre-image attack Microsoft may update Windows to reject all MD2, MD4 or MD5 end-entity and=20 subordinate CA certificates when it has reasons to believe that successful = MD5=20 pre-image attacks are imminent." Perhaps somebody should ask them to consider switching off MD2 and MD4 soon= er=20 than that. > (If it is possible to disable md5WithRsaEncryption signature verification > in Firefox 3.5 -- then it is sufficiently well hidden that I don't > see it.) https://bugzilla.mozilla.org/show_bug.cgi?id=3D590364 suggests setting the= =20 following environment variable: NSS_HASH_ALG_SUPPORT=3D-MD2,-MD5 Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9037E3A6967 for ; Wed, 2 Mar 2011 21:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.235 X-Spam-Level: X-Spam-Status: No, score=-10.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACA9N8UGVKwr for ; Wed, 2 Mar 2011 21:08:13 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 420173A6960 for ; Wed, 2 Mar 2011 21:08:13 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p2359GEx029569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Mar 2011 06:09:17 +0100 (MET) From: Martin Rex Message-Id: <201103030509.p2359FSK025866@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Thu, 3 Mar 2011 06:09:15 +0100 (MET) In-Reply-To: from "Phillip Hallam-Baker" at Mar 2, 11 06:09:11 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: [keyassure] crypto hash alg deprecation is a myth X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 05:08:14 -0000 Phillip Hallam-Baker wrote: > > Further, even though we stopped using MD5 in the mid 90s This seems wrong for most "we" and most environments that I can think of, certainly for the use of TLS on the internet. The very little thing that TLSv1.0 changed at the beginning of the new millenium is that it removed MD5 from the PRF that derives the TLS session master-secret and traffic keys. TLS did not affect in any way the use of MD5 for digitial signatures. On my scorecard, neither deprecation of the MD5 hash algorithms, nor migration away from MD5 hash algorithm has happend so far. Firefox happily verifies md5WithRsaEncryption signatures on TLS server certs. Only digital signature algorithms based on MD4 and MD2 seem to have been disabled since 3.0.something. MSIE 8 on Windows 7 (and prior) will happily talk to TLS servers using certs signed not only with md5WithRsaSignature, but also md2WithRsaSignature and even (**cough**) md4WithRsaSignature! Some may think "but Windows has a FIPS-compliant crypto algs switch". This (carefully hidden) switch disables SSLv3, but does NOT affect the acceptance of TLS server certificates signed with md5withRsaEncryption, md2WithRsaEncryption or md4WithRsaEncryption. (If it is possible to disable md5WithRsaEncryption signature verification in Firefox 3.5 -- then it is sufficiently well hidden that I don't see it.) To me, the claim that MD5 in digital signatures was deprecated in mid-90's is seriously defying the real world. It may have happened in small isolated environments, but it definitely did not happen yet where TLS is used on the internet today. I'm puzzled why so many commercial CAs are fiercly resisting the deprecation of obsolete digital signature algorithms such as md2WithRsaEncryption and md5WithRsaEncryption by continuing to distribute TrustAnchors as self-signed X.509 certs with such signatures on them. Look in the cert store of your favourite browser, or look into Microsofts TrustList distribution that my Windows box tries polling from here: http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19DF03A6969 for ; Wed, 2 Mar 2011 20:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.235 X-Spam-Level: X-Spam-Status: No, score=-10.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5dFWxditqiU for ; Wed, 2 Mar 2011 20:56:00 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 0D5403A695E for ; Wed, 2 Mar 2011 20:55:59 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p234v4Qx012329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Mar 2011 05:57:04 +0100 (MET) From: Martin Rex Message-Id: <201103030457.p234v4g5025114@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Thu, 3 Mar 2011 05:57:04 +0100 (MET) In-Reply-To: <4D6EE7E1.1070700@vpnc.org> from "Paul Hoffman" at Mar 2, 11 04:59:13 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 04:56:01 -0000 Paul Hoffman wrote: > > Phillip Hallam-Baker wrote: > > > > 1) Make support for SHA2-256 and SHA2-384 REQUIRED > > 2) Ensure that it is feasible to transition from use of SHA2 > > to a new algorithm > > 3) Deprecate use of MD2,MD4,MD5 and SHA1. > > We disagree on #1 in that I don't think that requiring SHA-384 has any > practical value and adds a second code path where none is needed. > > We agree only partially on #2. You keep saying "SHA2" when you probably > mean "SHA-256 and SHA-384". I agree that making the transition feasible > is good, and we already have that. > > We disagree on #3, and deprecating crypto is a different issue than > mandating crypto. I agree to all what Paul wrote. Iff SHA-256 is to be a mandatory to implement hash for DANE, then I see _no_ point in supporting SHA-1 at all (and saves us migration). -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC9FA3A6956 for ; Wed, 2 Mar 2011 19:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.573 X-Spam-Level: X-Spam-Status: No, score=-3.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blQiIJivsCS1 for ; Wed, 2 Mar 2011 19:54:14 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 77C473A6954 for ; Wed, 2 Mar 2011 19:54:14 -0800 (PST) Received: by bwz13 with SMTP id 13so943368bwz.31 for ; Wed, 02 Mar 2011 19:55:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pYt2G2HdKuXcLV2ZaiUg4iXn495WPjULr1SkaJ0mQCc=; b=xNyKSNqop6czo2ZO9I6ss4WIYiKh6BrOoefbjF3OT2af7BvAKiM7aOcV/aRiaMqUGt BsfEohNdYFDqqjOI8wm3crlOeucStWnA2LXJoZvrd78J4JaSkuZ2vsSH7YwcMfijYwgH Z25LM63wHADsJWjm+ZE20zNPFOY2IUKZfuCwk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sC2Z0dmy/AsV1KmtXrbxsGy4HHIXSkBwB3YowPQdj4UeZfTNvSyuZ//DRA2PkVlUYS BRHgUcSdFjXQoytt/tIj/wHvR72K7CGyELjz9inzcnhV+mZ4spbco10XKBDDd3ljzH0n U3zzTqcHbuFDYGgHjMFAvq+SQ7dgJtbTp7WJs= MIME-Version: 1.0 Received: by 10.204.7.213 with SMTP id e21mr898953bke.47.1299124520229; Wed, 02 Mar 2011 19:55:20 -0800 (PST) Received: by 10.204.14.139 with HTTP; Wed, 2 Mar 2011 19:55:20 -0800 (PST) In-Reply-To: <4D6EE7E1.1070700@vpnc.org> References: <201103011815.p21IFukr020670@fs4113.wdf.sap.corp> <4D6D7551.3070606@vpnc.org> <4D6EE7E1.1070700@vpnc.org> Date: Wed, 2 Mar 2011 22:55:20 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 03:54:16 -0000 On Wed, Mar 2, 2011 at 7:59 PM, Paul Hoffman wrote: > On 3/2/11 3:24 PM, Phillip Hallam-Baker wrote: >> >> There is currently no evidence that SHA2-256 is unacceptably weak. >> >> However it is based on the same construction as MD4, MD5 and SHA1. And >> thus the reason for the current NIST competition. > > I believe that NIST said many times that it is *a* reason, not *the* reason. > >> Since the NIST competition is not currently complete, there is >> currently no viable alternative to SHA2. While there are other >> algorithms in use, I would expect the competition to supersede those >> as well. > > It would be useful to this discussion for each of us to speak only for > ourselves and for those who have asked us to speak for them, or to quote > others whom we think are authorities. NIST has not, I believe, said that the > results of the competition will supersede SHA-2; if I'm wrong, please send > full quotes. Pot, kettle black. I would really prefer it if you Paul would not take it upon yourself to chair this particular working group because (1) you are not the chair and (2) your contributions appear to me to be a constant stream of personal attacks. When I say "I would expect the competition to supersede those as well." the group should assume that I am speaking for myself and that I have in fact consulted myself on the topic in question. As it happens I was probably the first person to suggest a digest competition to NIST since I met with Bill Burr less than an hour after the weakness in the SHA-1 construction was announced by Adi Shamir. I had previously had discussions with Burt Kaliski, Rivest and others in the field. By the end of the show it was clear that there would be a digest algorithm competition, the only question was whether it would be sponsored by NIST or another party. I probably wasn't the only person who had authorization to offer to underwrite a competition. So on this particular topic, as with many others, your sniping and carping is completely off base. I was there and you were not. -- Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F723A6920 for ; Wed, 2 Mar 2011 16:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.507 X-Spam-Level: X-Spam-Status: No, score=-101.507 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wX5ze1Wmp61 for ; Wed, 2 Mar 2011 16:59:23 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 037C93A68D0 for ; Wed, 2 Mar 2011 16:59:22 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p230xDFp031170 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 2 Mar 2011 17:59:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D6EE7E1.1070700@vpnc.org> Date: Wed, 02 Mar 2011 16:59:13 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: keyassure@ietf.org References: <201103011815.p21IFukr020670@fs4113.wdf.sap.corp> <4D6D7551.3070606@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 00:59:23 -0000 On 3/2/11 3:24 PM, Phillip Hallam-Baker wrote: > There is currently no evidence that SHA2-256 is unacceptably weak. > > However it is based on the same construction as MD4, MD5 and SHA1. And > thus the reason for the current NIST competition. I believe that NIST said many times that it is *a* reason, not *the* reason. > Since the NIST competition is not currently complete, there is > currently no viable alternative to SHA2. While there are other > algorithms in use, I would expect the competition to supersede those > as well. It would be useful to this discussion for each of us to speak only for ourselves and for those who have asked us to speak for them, or to quote others whom we think are authorities. NIST has not, I believe, said that the results of the competition will supersede SHA-2; if I'm wrong, please send full quotes. > I think that what we should do here is > > 1) Make support for SHA2-256 and SHA2-384 REQUIRED > 2) Ensure that it is feasible to transition from use of SHA2 to a new algorithm > 3) Deprecate use of MD2,MD4,MD5 and SHA1. > > > The second point is really rather important since even though it is > possible to emit bit strings that use SHA2 in protocols such as SSL > and S/MIME, it is not feasible to use them in practice because there > is no way to know whether the other party is one of those which is > capable of using them. We disagree on #1 in that I don't think that requiring SHA-384 has any practical value and adds a second code path where none is needed. We agree only partially on #2. You keep saying "SHA2" when you probably mean "SHA-256 and SHA-384". I agree that making the transition feasible is good, and we already have that. We disagree on #3, and deprecating crypto is a different issue than mandating crypto. --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD9873A6920 for ; Wed, 2 Mar 2011 16:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxRyReh62ZsD for ; Wed, 2 Mar 2011 16:49:29 -0800 (PST) Received: from nm29.bullet.mail.ac4.yahoo.com (nm29.bullet.mail.ac4.yahoo.com [98.139.52.226]) by core3.amsl.com (Postfix) with SMTP id 72F463A6919 for ; Wed, 2 Mar 2011 16:49:29 -0800 (PST) Received: from [98.139.52.193] by nm29.bullet.mail.ac4.yahoo.com with NNFMP; 03 Mar 2011 00:50:33 -0000 Received: from [98.139.52.156] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 03 Mar 2011 00:50:33 -0000 Received: from [127.0.0.1] by omp1039.mail.ac4.yahoo.com with NNFMP; 03 Mar 2011 00:50:33 -0000 X-Yahoo-Newman-Id: 550574.24918.bm@omp1039.mail.ac4.yahoo.com Received: (qmail 27278 invoked from network); 3 Mar 2011 00:50:33 -0000 Received: from thunderfish.local (turners@96.241.2.32 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 02 Mar 2011 16:50:32 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: VYwpaYIVM1ldnr5Fvs74NmHb8svPm9r7forTUBbgtxrKMcW Xn45pSblKWkFIBpPEHutTIbOgSC0maqGwfYa9Q0kibNhRQHNJerWTBqAZ9tg 7tlUOiaRw9s6XCMgtV7nErSwJs2Zk7NUkI4kP37sHLHkYgs7ufIXOjtCK.Zd tBRSzp9jz_skKEK5pMI0rjPhpUwceNk.hMBMckBs.gWUTnLT.kVM6pCwKJK_ o_ZTXZYUNZenljwHielIPd5pqO9O9gcXgFpSfiNzu7xDtgL70_mVb4ZOKsV_ D5CNj20dSQGvvMFM1jlz.WhFpiBaip.vKkVgADaqS_TCmrmP.efOE1w4a5No t.pwLUkxfGJ7ZjVBmqChtRNfjCpNpkb08qA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D6EE5D7.4080108@ieca.com> Date: Wed, 02 Mar 2011 19:50:31 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <201103011815.p21IFukr020670@fs4113.wdf.sap.corp> <4D6D7551.3070606@vpnc.org> <65BDECDA-2A61-49E0-A2DA-8E2E5162C0C8@kumari.net> In-Reply-To: <65BDECDA-2A61-49E0-A2DA-8E2E5162C0C8@kumari.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 00:49:30 -0000 On 3/2/11 6:43 PM, Warren Kumari wrote: > > On Mar 2, 2011, at 6:24 PM, Phillip Hallam-Baker wrote: > >> There is currently no evidence that SHA2-256 is unacceptably weak. >> >> However it is based on the same construction as MD4, MD5 and SHA1. And >> thus the reason for the current NIST competition. >> >> >> Since the NIST competition is not currently complete, there is >> currently no viable alternative to SHA2. While there are other >> algorithms in use, I would expect the competition to supersede those >> as well. >> >> I think that what we should do here is >> >> 1) Make support for SHA2-256 and SHA2-384 REQUIRED >> 2) Ensure that it is feasible to transition from use of SHA2 to a new >> algorithm > > > Shouldn't this be much much more general? "Ensure that it is feasible to > transition to new algorithms"? also don't see why "from SHA2" would be a special case> > >> 3) Deprecate use of MD2,MD4,MD5 and SHA1. >> > > Um, I'm confused by number 3 -- I think that the only things we need to > do *here* is decide what we *do* support.... > Deprecating the use of other things, while fine and good, doesn't need > to happen *here* if we don't support them... > > W > #3 is kind of taken care of. MD2 and MD4 are being made historic: http://datatracker.ietf.org/doc/draft-turner-md2-to-historic/ http://datatracker.ietf.org/doc/draft-turner-md4-to-historic/ and the security considerations for MD5 were updated: http://datatracker.ietf.org/doc/draft-turner-md5-seccon-update/ spt >> >> The second point is really rather important since even though it is >> possible to emit bit strings that use SHA2 in protocols such as SSL >> and S/MIME, it is not feasible to use them in practice because there >> is no way to know whether the other party is one of those which is >> capable of using them. >> >> On Tue, Mar 1, 2011 at 5:38 PM, Paul Hoffman >> wrote: >>> On 3/1/11 1:37 PM, Phillip Hallam-Baker wrote: >>>> >>>> This particular topic is one on which the Security ADs and the IETF >>>> chair have very very specific opinions on. And given their role in >>>> trying to effect an industry wide transition to stronger algorithms, I >>>> think that they are quite right to insist on them. >>> >>> If you can quote previous statements from any of them suggesting that >>> SHA-256 is suspect, that would be more useful than you simply suggesting >>> that they had said something. It would be useful to this discussion >>> for each >>> of us to speak only for ourselves and for those who have asked us to >>> speak >>> for them, or to quote others whom we think are authorities. >>> _______________________________________________ >>> keyassure mailing list >>> keyassure@ietf.org >>> https://www.ietf.org/mailman/listinfo/keyassure >>> >> >> >> >> -- >> Website: http://hallambaker.com/ >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >> > > -- > We know about as much about software quality problems as they knew about > the Black Plague in the 1600s. We've seen the victims' agonies and > helped burn the corpses. We don't know what causes it; we don't really > know if there is only one disease. We just suffer -- and keep pouring > our sewage into our water supply. > > -- Tom Van Vleck > > > > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CE4F3A687D for ; Wed, 2 Mar 2011 15:42:49 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuirkwI2NDbl for ; Wed, 2 Mar 2011 15:42:48 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id 7117D3A68E2 for ; Wed, 2 Mar 2011 15:42:48 -0800 (PST) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id C6A201B401D8; Wed, 2 Mar 2011 18:43:54 -0500 (EST) Message-Id: <65BDECDA-2A61-49E0-A2DA-8E2E5162C0C8@kumari.net> From: Warren Kumari To: Phillip Hallam-Baker In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 2 Mar 2011 18:43:54 -0500 References: <201103011815.p21IFukr020670@fs4113.wdf.sap.corp> <4D6D7551.3070606@vpnc.org> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 23:42:49 -0000 On Mar 2, 2011, at 6:24 PM, Phillip Hallam-Baker wrote: > There is currently no evidence that SHA2-256 is unacceptably weak. > > However it is based on the same construction as MD4, MD5 and SHA1. And > thus the reason for the current NIST competition. > > > Since the NIST competition is not currently complete, there is > currently no viable alternative to SHA2. While there are other > algorithms in use, I would expect the competition to supersede those > as well. > > I think that what we should do here is > > 1) Make support for SHA2-256 and SHA2-384 REQUIRED > 2) Ensure that it is feasible to transition from use of SHA2 to a > new algorithm Shouldn't this be much much more general? "Ensure that it is feasible to transition to new algorithms"? > 3) Deprecate use of MD2,MD4,MD5 and SHA1. > Um, I'm confused by number 3 -- I think that the only things we need to do *here* is decide what we *do* support.... Deprecating the use of other things, while fine and good, doesn't need to happen *here* if we don't support them... W > > The second point is really rather important since even though it is > possible to emit bit strings that use SHA2 in protocols such as SSL > and S/MIME, it is not feasible to use them in practice because there > is no way to know whether the other party is one of those which is > capable of using them. > > On Tue, Mar 1, 2011 at 5:38 PM, Paul Hoffman > wrote: >> On 3/1/11 1:37 PM, Phillip Hallam-Baker wrote: >>> >>> This particular topic is one on which the Security ADs and the IETF >>> chair have very very specific opinions on. And given their role in >>> trying to effect an industry wide transition to stronger >>> algorithms, I >>> think that they are quite right to insist on them. >> >> If you can quote previous statements from any of them suggesting that >> SHA-256 is suspect, that would be more useful than you simply >> suggesting >> that they had said something. It would be useful to this discussion >> for each >> of us to speak only for ourselves and for those who have asked us >> to speak >> for them, or to quote others whom we think are authorities. >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >> > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- We know about as much about software quality problems as they knew about the Black Plague in the 1600s. We've seen the victims' agonies and helped burn the corpses. We don't know what causes it; we don't really know if there is only one disease. We just suffer -- and keep pouring our sewage into our water supply. -- Tom Van Vleck Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C89E93A68E8 for ; Wed, 2 Mar 2011 15:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roHPAGAn-p+h for ; Wed, 2 Mar 2011 15:23:38 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id D57033A68B5 for ; Wed, 2 Mar 2011 15:23:37 -0800 (PST) Received: by bwz13 with SMTP id 13so780876bwz.31 for ; Wed, 02 Mar 2011 15:24:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SduGOtzVYVfzGx9ZT8P92GpLn8JDAuL37j/mzJw8Af8=; b=KcYelfdAoCU2mYyY0uxtNCjv3qBA5qrybTFKvLb1LVAwteTm0WJbk+CMgwFdu8dyvb xkut5tdoTpPk2S6sUNEm7O0P9L6OywJfjhXs/TH7W+eBEpQ7RUacFzwtrv7ys6Lrtdb2 JrZNngiTvxFizYnwev1K7BP/ASUQaUaLiiqF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ATxeNqbpNFfm2eBEnjaF4hjWhOssRMsmbXHmmC8WbeDYl4gNQadDEqrn01JvHCafMg XH5XAWnDzHfdt4BEwzkhsYkm3OZ7QstQsQ/0qh58UTiXA0rHoPBRt1wt/cE6fgom3c3S vsrwt7juJY7bXU6iotP0QBuyo+1iOyunVgxco= MIME-Version: 1.0 Received: by 10.204.52.136 with SMTP id i8mr673795bkg.74.1299108283886; Wed, 02 Mar 2011 15:24:43 -0800 (PST) Received: by 10.204.14.139 with HTTP; Wed, 2 Mar 2011 15:24:43 -0800 (PST) In-Reply-To: <4D6D7551.3070606@vpnc.org> References: <201103011815.p21IFukr020670@fs4113.wdf.sap.corp> <4D6D7551.3070606@vpnc.org> Date: Wed, 2 Mar 2011 18:24:43 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 23:23:39 -0000 There is currently no evidence that SHA2-256 is unacceptably weak. However it is based on the same construction as MD4, MD5 and SHA1. And thus the reason for the current NIST competition. Since the NIST competition is not currently complete, there is currently no viable alternative to SHA2. While there are other algorithms in use, I would expect the competition to supersede those as well. I think that what we should do here is 1) Make support for SHA2-256 and SHA2-384 REQUIRED 2) Ensure that it is feasible to transition from use of SHA2 to a new algorithm 3) Deprecate use of MD2,MD4,MD5 and SHA1. The second point is really rather important since even though it is possible to emit bit strings that use SHA2 in protocols such as SSL and S/MIME, it is not feasible to use them in practice because there is no way to know whether the other party is one of those which is capable of using them. On Tue, Mar 1, 2011 at 5:38 PM, Paul Hoffman wrote: > On 3/1/11 1:37 PM, Phillip Hallam-Baker wrote: >> >> This particular topic is one on which the Security ADs and the IETF >> chair have very very specific opinions on. And given their role in >> trying to effect an industry wide transition to stronger algorithms, I >> think that they are quite right to insist on them. > > If you can quote previous statements from any of them suggesting that > SHA-256 is suspect, that would be more useful than you simply suggesting > that they had said something. It would be useful to this discussion for each > of us to speak only for ourselves and for those who have asked us to speak > for them, or to quote others whom we think are authorities. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B293A687D for ; Wed, 2 Mar 2011 15:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.74 X-Spam-Level: X-Spam-Status: No, score=-104.74 tagged_above=-999 required=5 tests=[AWL=1.859, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdnYqXANepXr for ; Wed, 2 Mar 2011 15:16:35 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by core3.amsl.com (Postfix) with ESMTP id A5D3C3A68B7 for ; Wed, 2 Mar 2011 15:16:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 3C4793E40AC; Wed, 2 Mar 2011 23:17:11 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1299107830; bh=JRatl/lNTqDRB5 gYWkuO59qBVr86YdQl4A/u6ula/H4=; b=q8LlnbUlBbLPe5ySPlVZtDScf1/ZLL sUN9jFxKdfqEiCZtBStT1vL2p0hANBBDDykZNoHyv+k5clfpx7ReWcaoJTP+vAdG zsQBYoq/fn9xO6ZhMgeKsO2pr+SyCiRurt+2G3gCWXEKamvlZm1U1a4m5ieGz4aB S4gmkvTP193S0jCC1K2JBQ1jjCeII+kiVyQhAMCJZewQAH7aoL539dETGxm2n1hS l1swV31ChC3EkvPMcBq8GMFtLvLo53UsgPu+i0x55W0KteKjcqcJkrBcznLR7MFs 6Sugo9+tJa9aAtuzoGiv5luHPL+ZssZk5XcSnqgKDMYMFBc6pbEQMqjg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id bc22EIQsGhHE; Wed, 2 Mar 2011 23:17:10 +0000 (GMT) Received: from [10.87.48.2] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 3FFBD3E40AB; Wed, 2 Mar 2011 23:17:10 +0000 (GMT) Message-ID: <4D6ECFF5.7030507@cs.tcd.ie> Date: Wed, 02 Mar 2011 23:17:09 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <201103021724.p22HOttB009647@fs4113.wdf.sap.corp> <4DD7F1F3-476F-4C2F-9DCD-6A6678045C69@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 23:16:36 -0000 I think this is a good enough statement of the situation as I understand it. Thanks, S. On 02/03/11 23:09, Phillip Hallam-Baker wrote: > What I meant to write was that SHA1 is only marginally more secure > than MD5 was when we decided to stop using it. Obviously with 32 extra > bits it is harder to break. > > > If you look at the internals of SHA1-0, the original proposal, you > will find that it is in effect simply MD5 with an additional set of > state variables to extend the size to 160 bits. > > The spec was amended to add in an additional expansion function before > it was approved. In a private conversation in 1995 at the time the > Dobbertin attack was first circulated, Rivest was of the opinion that > this would make it somewhat more resistant to the Dobbertin attack but > not considerably so. > > > While the attacks on SHA1 are currently theoretical, they are rapidly > approaching the point at which we started to decide that use of MD5 > should be avoided. > > Further, even though we stopped using MD5 in the mid 90s, it is still > possible to use MD5 securely but doing so requires considerable > attention to other security precautions. So even if there is a > theoretical break of SHA1 we are hardly in a situation where we will > face an immediate crisis. > > If SHA1 is 'broken' tomorrow it is likely going to be 2020 before > there is a practical exploit based on that attack. But that is not > reason for complacency as it is likely to take us a decade to dig our > way out of using SHA1. > > > On Wed, Mar 2, 2011 at 4:37 PM, Stephen Farrell > wrote: >> >> >> On 2 Mar 2011, at 21:24, Phillip Hallam-Baker wrote: >> >>> Which is why I am arguing it is time to withdraw SHA1 from service. It >>> is only marginally more secure than MD5. >> >> "Marginally"? Evidence please? I dont think exageration helps your case. >> >> S >> >> >>> >>> >>> >>> On Wed, Mar 2, 2011 at 12:24 PM, Martin Rex wrote: >>>> Phillip Hallam-Baker wrote: >>>>> >>>>> The use of MD2 in a self signed cert has little risk as far as use of >>>>> the cert itself goes since it only serves as proof of possession which >>>>> is only relevant when the browser provider chooses to install it in >>>>> the browser. >>>> >>>> In the universe where I live, there exist collision attacks against MD2. >>>> (check http://en.wikipedia.org/wiki/MD2_%28cryptography%29) >>>> >>>> So an RSA-key for which a PKCS#1 encrypted MD2 signature has been >>>> published is a real security problem and ought to have been discarded >>>> long ago. >>>> >>>> Else someone could try to use the preimage attack to issue himself >>>> an intermediate CA cert under such a root cert, reusing the md2-based >>>> signature on the RootCA cert. >>>> >>>> I would REALLY like to kill md2withRsaEncryption as a digital >>>> signature algorithm from our PKI implementation, like I did >>>> with all of md4-based digital signature algorithms. >>>> >>>> >>>> Getting rid of "tainted" RSA keys is also important. >>>> >>>> Why do you think that FIPS 186-3 says that you are not allowed >>>> to use an RSA keypair for both PKCS-v1.5 and PKCS-PSS signatures? >>>> Because you "taint" your RSA key on the first time that you use it >>>> for a weak scheme. >>>> >>>> -Martin >>>> >>> >>> >>> >>> -- >>> Website: http://hallambaker.com/ >>> _______________________________________________ >>> keyassure mailing list >>> keyassure@ietf.org >>> https://www.ietf.org/mailman/listinfo/keyassure >> > > > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00A7D3A68E5 for ; Wed, 2 Mar 2011 15:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6a-xErxd-FHa for ; Wed, 2 Mar 2011 15:08:07 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id C927D3A68DD for ; Wed, 2 Mar 2011 15:08:06 -0800 (PST) Received: by bwz13 with SMTP id 13so769828bwz.31 for ; Wed, 02 Mar 2011 15:09:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=onAriBZrpJ58YU69DRzytAcLneJ9FmAOJZb3aJZDDZs=; b=HsHrYh/t4kBeRzG+3XvY9SEgtgA58NCABTcdDpME02jUU46MaGsx0H6r05psp9kGmm VyTP89MDG7N3fx3NfNHATJ0OTTtMk/yB9jO5c27V/7SjNe/UTpzssSqO8p3WKRHowJwz v4bTtpVTuREpxqhAb3xVkY+to3/v/4raRfISc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=No9HpXg4q8H0NNrDuaC2x9mL91CzzF6oR9QBKcnvzwdr6+GL58nSXmLika7TufJBG6 imwLlh7aLwePzHIiFt+AzbrZAN8Hl/p++L0/bl0OM+S9r7pazDEvHmYjHd64QwnSZnd7 xCP6B1bGQfPmNmAQkDi6GPj+/8AhC64iILbrI= MIME-Version: 1.0 Received: by 10.204.65.83 with SMTP id h19mr649761bki.101.1299107351925; Wed, 02 Mar 2011 15:09:11 -0800 (PST) Received: by 10.204.14.139 with HTTP; Wed, 2 Mar 2011 15:09:11 -0800 (PST) In-Reply-To: <4DD7F1F3-476F-4C2F-9DCD-6A6678045C69@cs.tcd.ie> References: <201103021724.p22HOttB009647@fs4113.wdf.sap.corp> <4DD7F1F3-476F-4C2F-9DCD-6A6678045C69@cs.tcd.ie> Date: Wed, 2 Mar 2011 18:09:11 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 23:08:09 -0000 What I meant to write was that SHA1 is only marginally more secure than MD5 was when we decided to stop using it. Obviously with 32 extra bits it is harder to break. If you look at the internals of SHA1-0, the original proposal, you will find that it is in effect simply MD5 with an additional set of state variables to extend the size to 160 bits. The spec was amended to add in an additional expansion function before it was approved. In a private conversation in 1995 at the time the Dobbertin attack was first circulated, Rivest was of the opinion that this would make it somewhat more resistant to the Dobbertin attack but not considerably so. While the attacks on SHA1 are currently theoretical, they are rapidly approaching the point at which we started to decide that use of MD5 should be avoided. Further, even though we stopped using MD5 in the mid 90s, it is still possible to use MD5 securely but doing so requires considerable attention to other security precautions. So even if there is a theoretical break of SHA1 we are hardly in a situation where we will face an immediate crisis. If SHA1 is 'broken' tomorrow it is likely going to be 2020 before there is a practical exploit based on that attack. But that is not reason for complacency as it is likely to take us a decade to dig our way out of using SHA1. On Wed, Mar 2, 2011 at 4:37 PM, Stephen Farrell wrote: > > > On 2 Mar 2011, at 21:24, Phillip Hallam-Baker wrote: > >> Which is why I am arguing it is time to withdraw SHA1 from service. It >> is only marginally more secure than MD5. > > "Marginally"? Evidence please? I dont think exageration helps your case. > > S > > >> >> >> >> On Wed, Mar 2, 2011 at 12:24 PM, Martin Rex wrote: >>> Phillip Hallam-Baker wrote: >>>> >>>> The use of MD2 in a self signed cert has little risk as far as use of >>>> the cert itself goes since it only serves as proof of possession which >>>> is only relevant when the browser provider chooses to install it in >>>> the browser. >>> >>> In the universe where I live, there exist collision attacks against MD2= . >>> =A0(check http://en.wikipedia.org/wiki/MD2_%28cryptography%29) >>> >>> So an RSA-key for which a PKCS#1 encrypted MD2 signature has been >>> published is a real security problem and ought to have been discarded >>> long ago. >>> >>> Else someone could try to use the preimage attack to issue himself >>> an intermediate CA cert under such a root cert, reusing the md2-based >>> signature on the RootCA cert. >>> >>> I would REALLY like to kill md2withRsaEncryption as a digital >>> signature algorithm from our PKI implementation, like I did >>> with all of md4-based digital signature algorithms. >>> >>> >>> Getting rid of "tainted" RSA keys is also important. >>> >>> Why do you think that FIPS 186-3 says that you are not allowed >>> to use an RSA keypair for both PKCS-v1.5 and PKCS-PSS signatures? >>> Because you "taint" your RSA key on the first time that you use it >>> for a weak scheme. >>> >>> -Martin >>> >> >> >> >> -- >> Website: http://hallambaker.com/ >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A27E3A68E8 for ; Wed, 2 Mar 2011 15:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.533 X-Spam-Level: X-Spam-Status: No, score=-104.533 tagged_above=-999 required=5 tests=[AWL=2.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74UvceAc6qQq for ; Wed, 2 Mar 2011 15:02:36 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by core3.amsl.com (Postfix) with ESMTP id 9EF6D3A68D4 for ; Wed, 2 Mar 2011 15:02:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5FB303E40AB; Wed, 2 Mar 2011 23:03:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1299106992; bh=I4dMVS1GUm0wRe OmAiFXU2SccT867lVWMc6D27faLLQ=; b=lt4rYvbR7licXjG74rbZQYyEo37YKl ISZxe6cqYX8JGL+UZ7golUh9tfh4mcSDylra0YkCvFW//0g6nukSSfCJ0WhvOR7c ajBpKjZMxJz87P0Fqh3muteMcQIJDIRULqjMgHuHTdO1ZhXPRM/bCk2+WTW/2KlU 7lh43siiXWVMwTWqonQl1ypardM2p9o/2H6QL+t82R6gjVnZBGyb433TIYh8RRRY BMQ8p2081Pdb6uV6ia5Aue62t01+TPWNN1bFqB/yhUpXppojmSKgHfpybSBgxJGR jSl7aBVK6lkuEC90ubU9Gox+RXZkmwbKUCkngBqth45lgbJt1tWZ101A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id VvnPUVtkLavl; Wed, 2 Mar 2011 23:03:12 +0000 (GMT) Received: from [10.87.48.2] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0CB453E40A7; Wed, 2 Mar 2011 23:03:12 +0000 (GMT) Message-ID: <4D6ECCAE.3050204@cs.tcd.ie> Date: Wed, 02 Mar 2011 23:03:10 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Nicholas Weaver References: <201103021724.p22HOttB009647@fs4113.wdf.sap.corp> <4DD7F1F3-476F-4C2F-9DCD-6A6678045C69@cs.tcd.ie> <8ADE8790-307C-4323-9253-3FE761CBD752@icsi.berkeley.edu> <4962C1C0-D5E6-48D7-9C51-38434CA7D314@cs.tcd.ie> <8AC53FFD-EE6C-405F-BCCC-12949F719C51@ICSI.Berkeley.EDU> In-Reply-To: <8AC53FFD-EE6C-405F-BCCC-12949F719C51@ICSI.Berkeley.EDU> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "keyassure@ietf.org" , Phillip Hallam-Baker Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 23:02:37 -0000 On 02/03/11 22:47, Nicholas Weaver wrote: > I'll take Ron Rivest's word on it: http://mail.python.org/pipermail/python-dev/2005-December/058850.html Note the date on that is 2005. We've been moving away from sha-1 since then and continue to do so as we should. Overstating the situation is not a good way to make progress in that. S. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D33F3A68FE for ; Wed, 2 Mar 2011 14:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.583 X-Spam-Level: X-Spam-Status: No, score=-100.583 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0Q4OEv6u537 for ; Wed, 2 Mar 2011 14:58:11 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 96C4E3A6816 for ; Wed, 2 Mar 2011 14:58:04 -0800 (PST) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p21McALR062114 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 1 Mar 2011 15:38:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D6D7551.3070606@vpnc.org> Date: Tue, 01 Mar 2011 14:38:09 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <201103011815.p21IFukr020670@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 22:58:12 -0000 On 3/1/11 1:37 PM, Phillip Hallam-Baker wrote: > This particular topic is one on which the Security ADs and the IETF > chair have very very specific opinions on. And given their role in > trying to effect an industry wide transition to stronger algorithms, I > think that they are quite right to insist on them. If you can quote previous statements from any of them suggesting that SHA-256 is suspect, that would be more useful than you simply suggesting that they had said something. It would be useful to this discussion for each of us to speak only for ourselves and for those who have asked us to speak for them, or to quote others whom we think are authorities. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C0E03A68E7 for ; Wed, 2 Mar 2011 14:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjQeoOc1YFVu for ; Wed, 2 Mar 2011 14:46:16 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 898B93A68EA for ; Wed, 2 Mar 2011 14:46:16 -0800 (PST) Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 538D236A3DA; Wed, 2 Mar 2011 14:47:23 -0800 (PST) References: <201103021724.p22HOttB009647@fs4113.wdf.sap.corp> <4DD7F1F3-476F-4C2F-9DCD-6A6678045C69@cs.tcd.ie> <8ADE8790-307C-4323-9253-3FE761CBD752@icsi.berkeley.edu> <4962C1C0-D5E6-48D7-9C51-38434CA7D314@cs.tcd.ie> In-Reply-To: <4962C1C0-D5E6-48D7-9C51-38434CA7D314@cs.tcd.ie> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <8AC53FFD-EE6C-405F-BCCC-12949F719C51@ICSI.Berkeley.EDU> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Wed, 2 Mar 2011 14:47:22 -0800 To: Stephen Farrell X-Mailer: Apple Mail (2.1082) Cc: Phillip Hallam-Baker , Nicholas Weaver , "keyassure@ietf.org" Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 22:46:19 -0000 On Mar 2, 2011, at 2:35 PM, Stephen Farrell wrote: >=20 >=20 > On 2 Mar 2011, at 21:41, Nicholas Weaver = wrote: >=20 >>=20 >> On Mar 2, 2011, at 1:37 PM, Stephen Farrell wrote: >>=20 >>>=20 >>>=20 >>> On 2 Mar 2011, at 21:24, Phillip Hallam-Baker = wrote: >>>=20 >>>> Which is why I am arguing it is time to withdraw SHA1 from service. = It >>>> is only marginally more secure than MD5. >>>=20 >>> "Marginally"? Evidence please? I dont think exageration helps your = case. >>>=20 >>> S >>=20 >> http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html >=20 > Yes, sha2 is the hash algorithm of the day.=20 >=20 > But where's it say there's only a marginal difference between sha1 and = md5? Absent evidence that's just spreading FUD which is not a good way = to argue, even for the right thing. I'll take Ron Rivest's word on it: = http://mail.python.org/pipermail/python-dev/2005-December/058850.html > I'm curious as to the status of upgrading cryptographic > hash function support in Python, now that md5 and sha1 are > both clearly broken (in terms of collision-resistance). If he puts the two in the same category of broken, I'd trust that = judgement. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2BA3A68B5 for ; Wed, 2 Mar 2011 14:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.498 X-Spam-Level: X-Spam-Status: No, score=-101.498 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKtyimP1Rgep for ; Wed, 2 Mar 2011 14:44:08 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 3C75B3A68E4 for ; Wed, 2 Mar 2011 14:44:08 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p22Lg6rw024300 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 2 Mar 2011 14:42:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D6EB9AE.2060106@vpnc.org> Date: Wed, 02 Mar 2011 13:42:06 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: keyassure@ietf.org References: <201103021724.p22HOttB009647@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 22:44:09 -0000 On 3/2/11 1:24 PM, Phillip Hallam-Baker wrote: > Which is why I am arguing it is time to withdraw SHA1 from service. It > is only marginally more secure than MD5. The wording for Issue #21 is: Currently, the draft is silent on which crypto algorithms and certificate types must be implemented for interoperability. It should be specific before the document is finished. It sounds like you want to open a different issue that deals with which crypto algorithms MUST NOT be supported. Does that sound correct? --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 404303A68E2 for ; Wed, 2 Mar 2011 14:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.914 X-Spam-Level: X-Spam-Status: No, score=-101.914 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9D8Z4H+1OS6q for ; Wed, 2 Mar 2011 14:34:47 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id A36643A68BD for ; Wed, 2 Mar 2011 14:34:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id EE2863E40AB; Wed, 2 Mar 2011 22:35:52 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1299105352; bh=0dz3t uBsoBZdImxi0EemaL6IB/qVbniXreK82W2c3zQ=; b=7fqyi47yo08NT94TxrLpf GMYNY3px4VxPCyuPEFyTGj5VjuwQNIVI++SgH9syuGJad0/KJ073MfWb+397h0mj Q8LbQDAUznyaSe0+AtxT0CJ76pdUM7nBDMF2b6j2ieeCRCpZwJjMiyZzc8xlJCrt EmFeOyu5rA21iGxoJAP32HImdPRDIJESzo0DxYTfJFKHTEnZe451lQF9vqORfUrW tUOmC4e3xqxVBeI8eO+0c0ci/efAlLjzDPFXDCGCvwRRGUBVqpnq2JlPVgV2Y7Oo qjkbBx7A+dE4TD598QvBE3i/QM8OfzVDxHckUQD2p3oskaTLNRvpBMNjdp0shoJ6 g== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id xAg6jBWxkB7x; Wed, 2 Mar 2011 22:35:52 +0000 (GMT) Received: from [10.87.48.4] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 433E73E40A7; Wed, 2 Mar 2011 22:35:52 +0000 (GMT) References: <201103021724.p22HOttB009647@fs4113.wdf.sap.corp> <4DD7F1F3-476F-4C2F-9DCD-6A6678045C69@cs.tcd.ie> <8ADE8790-307C-4323-9253-3FE761CBD752@icsi.berkeley.edu> In-Reply-To: <8ADE8790-307C-4323-9253-3FE761CBD752@icsi.berkeley.edu> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <4962C1C0-D5E6-48D7-9C51-38434CA7D314@cs.tcd.ie> X-Mailer: iPhone Mail (8C148) From: Stephen Farrell Date: Wed, 2 Mar 2011 22:35:49 +0000 To: Nicholas Weaver Cc: Phillip Hallam-Baker , "keyassure@ietf.org" Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 22:34:50 -0000 On 2 Mar 2011, at 21:41, Nicholas Weaver wrote: >=20 > On Mar 2, 2011, at 1:37 PM, Stephen Farrell wrote: >=20 >>=20 >>=20 >> On 2 Mar 2011, at 21:24, Phillip Hallam-Baker wrote: >>=20 >>> Which is why I am arguing it is time to withdraw SHA1 from service. It >>> is only marginally more secure than MD5. >>=20 >> "Marginally"? Evidence please? I dont think exageration helps your case. >>=20 >> S >=20 > http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html Yes, sha2 is the hash algorithm of the day.=20 But where's it say there's only a marginal difference between sha1 and md5? A= bsent evidence that's just spreading FUD which is not a good way to argue, e= ven for the right thing. S >=20 >> March 15, 2006: The SHA-2 family of hash functions (i.e., SHA-224, SHA-25= 6, SHA-384 and SHA-512) may be used by Federal agencies for all applications= using secure hash algorithms. Federal agencies should stop using SHA-1 for d= igital signatures, digital time stamping and other applications that require= collision resistance as soon as practical, and must use the SHA-2 family of= hash functions for these applications after 2010. After 2010, Federal agenc= ies may use SHA-1 only for the following applications: hash-based message au= thentication codes (HMACs); key derivation functions (KDFs); and random numb= er generators (RNGs). Regardless of use, NIST encourages application and pro= tocol designers to use the SHA-2 family of hash functions for all new applic= ations and protocols. >=20 > I agree with depricating SHA-1 in DANE. >=20 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF74D3A68D5 for ; Wed, 2 Mar 2011 13:54:56 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0YZsHFwiYXY for ; Wed, 2 Mar 2011 13:54:56 -0800 (PST) Received: from mail1.eff.org (mail1.eff.org [64.147.188.4]) by core3.amsl.com (Postfix) with ESMTP id 0DB733A68BD for ; Wed, 2 Mar 2011 13:54:56 -0800 (PST) Received: from [192.168.1.184] (gw-shotwell.eff.org [75.101.97.66]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: chris) by mail1.eff.org (Postfix) with ESMTPSA id 4E0A7BDF3E for ; Wed, 2 Mar 2011 13:56:05 -0800 (PST) Message-ID: <4D6EBD00.7000206@eff.org> Date: Wed, 02 Mar 2011 13:56:16 -0800 From: Chris Palmer User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <201103021724.p22HOttB009647@fs4113.wdf.sap.corp> <4DD7F1F3-476F-4C2F-9DCD-6A6678045C69@cs.tcd.ie> <8ADE8790-307C-4323-9253-3FE761CBD752@icsi.berkeley.edu> In-Reply-To: <8ADE8790-307C-4323-9253-3FE761CBD752@icsi.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 21:54:56 -0000 On 03/02/2011 01:41 PM, Nicholas Weaver wrote: > I agree with depricating SHA-1 in DANE. Indeed, I can hardly understand why we're arguing about it. SHA-1 is over and has no place in new protocols. -- Chris Palmer Technology Director, Electronic Frontier Foundation Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 870D13A68C6 for ; Wed, 2 Mar 2011 13:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2opiiBefjXek for ; Wed, 2 Mar 2011 13:39:58 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 7F8083A68BB for ; Wed, 2 Mar 2011 13:39:58 -0800 (PST) Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 57E6236A032; Wed, 2 Mar 2011 13:41:05 -0800 (PST) References: <201103021724.p22HOttB009647@fs4113.wdf.sap.corp> <4DD7F1F3-476F-4C2F-9DCD-6A6678045C69@cs.tcd.ie> In-Reply-To: <4DD7F1F3-476F-4C2F-9DCD-6A6678045C69@cs.tcd.ie> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <8ADE8790-307C-4323-9253-3FE761CBD752@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Wed, 2 Mar 2011 13:41:04 -0800 To: Stephen Farrell X-Mailer: Apple Mail (2.1082) Cc: Phillip Hallam-Baker , "keyassure@ietf.org" Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 21:39:59 -0000 On Mar 2, 2011, at 1:37 PM, Stephen Farrell wrote: >=20 >=20 > On 2 Mar 2011, at 21:24, Phillip Hallam-Baker = wrote: >=20 >> Which is why I am arguing it is time to withdraw SHA1 from service. = It >> is only marginally more secure than MD5. >=20 > "Marginally"? Evidence please? I dont think exageration helps your = case. >=20 > S http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html > March 15, 2006: The SHA-2 family of hash functions (i.e., SHA-224, = SHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all = applications using secure hash algorithms. Federal agencies should stop = using SHA-1 for digital signatures, digital time stamping and other = applications that require collision resistance as soon as practical, and = must use the SHA-2 family of hash functions for these applications after = 2010. After 2010, Federal agencies may use SHA-1 only for the following = applications: hash-based message authentication codes (HMACs); key = derivation functions (KDFs); and random number generators (RNGs). = Regardless of use, NIST encourages application and protocol designers to = use the SHA-2 family of hash functions for all new applications and = protocols. I agree with depricating SHA-1 in DANE. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 237D13A68BB for ; Wed, 2 Mar 2011 13:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.614 X-Spam-Level: X-Spam-Status: No, score=-102.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSBgNZDhgJm2 for ; Wed, 2 Mar 2011 13:36:09 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id BC0DC3A68A9 for ; Wed, 2 Mar 2011 13:36:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 8AC8A3E40AB; Wed, 2 Mar 2011 21:37:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1299101833; bh=SFrlp 3lhVX5Tq2ZslykU5F/8zu+ZWPyhPZQ/Ja3VAvc=; b=vdewKfbvxu9ulK+lNVwhN 4OiajkNMY0LxksbddATgb6LsxFEXnK0wm7A96e+6xTIalsC6qTDCiniu95kQL3iz 0RwQb8oGdILmcrvVmPMGXOVujzc13PFvtiUnBYhp3BBS/4pf85NktIaJOrF+t56j KoqvVd+9UltEx699Cc+ecPP6wx+kjC9X2ZOCutbxwaUMMAaaMmZvAOQ9s74E25NM jtaW/CYN4UfB4wBZ+UAS3/Ptd+EmnI3ARc4M4S/ECu7WCS41dvLeGRk05wtUWpw4 A6xi+ypLr6o4Tp3oGeQQymXOaYqU/Dgr6wzrTfvyvYqi7O64pQ1f0TUwq8K9OEWX A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 0eHfQhtqSqzU; Wed, 2 Mar 2011 21:37:13 +0000 (GMT) Received: from [10.87.48.4] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 9856F3E40A7; Wed, 2 Mar 2011 21:37:12 +0000 (GMT) References: <201103021724.p22HOttB009647@fs4113.wdf.sap.corp> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <4DD7F1F3-476F-4C2F-9DCD-6A6678045C69@cs.tcd.ie> X-Mailer: iPhone Mail (8C148) From: Stephen Farrell Date: Wed, 2 Mar 2011 21:37:09 +0000 To: Phillip Hallam-Baker Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 21:36:11 -0000 On 2 Mar 2011, at 21:24, Phillip Hallam-Baker wrote: > Which is why I am arguing it is time to withdraw SHA1 from service. It > is only marginally more secure than MD5. "Marginally"? Evidence please? I dont think exageration helps your case. S > > > > On Wed, Mar 2, 2011 at 12:24 PM, Martin Rex wrote: >> Phillip Hallam-Baker wrote: >>> >>> The use of MD2 in a self signed cert has little risk as far as use of >>> the cert itself goes since it only serves as proof of possession which >>> is only relevant when the browser provider chooses to install it in >>> the browser. >> >> In the universe where I live, there exist collision attacks against MD2. >> (check http://en.wikipedia.org/wiki/MD2_%28cryptography%29) >> >> So an RSA-key for which a PKCS#1 encrypted MD2 signature has been >> published is a real security problem and ought to have been discarded >> long ago. >> >> Else someone could try to use the preimage attack to issue himself >> an intermediate CA cert under such a root cert, reusing the md2-based >> signature on the RootCA cert. >> >> I would REALLY like to kill md2withRsaEncryption as a digital >> signature algorithm from our PKI implementation, like I did >> with all of md4-based digital signature algorithms. >> >> >> Getting rid of "tainted" RSA keys is also important. >> >> Why do you think that FIPS 186-3 says that you are not allowed >> to use an RSA keypair for both PKCS-v1.5 and PKCS-PSS signatures? >> Because you "taint" your RSA key on the first time that you use it >> for a weak scheme. >> >> -Martin >> > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBD083A6850 for ; Wed, 2 Mar 2011 13:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhwCsR+0VwBX for ; Wed, 2 Mar 2011 13:23:37 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 506B33A6816 for ; Wed, 2 Mar 2011 13:23:34 -0800 (PST) Received: by bwz13 with SMTP id 13so680868bwz.31 for ; Wed, 02 Mar 2011 13:24:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eSYi5jinXVdrHG5Rg8+6z3+8KWTnxiJPFi0urM+06Bw=; b=LaEdo1KBjzEwY3SEkd+llbCHya+/WVtQuSnUBQ+c3qptfEEj4BFPosdPu89igfPSa9 6/I+DMvjomIrl6uJe14b007vFUqHkxzf8YEYAub7yhth2nnMZl/yuT0BARfBPae7wiUv oydSOKbclti1m3rWDyvcyarzWRdA6tTkcSQZo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mqXf38Ugxw/d4IU3+xirVrysVIidfrMUUyH6tn+U+8tfmMaNmxMOIk5YX+PCaDF6Bg hDAD566I7nRwB7heKzswQWRbS2EG3jdjp8EAnW9FW8Dyfjp2ornWWjjTceAON9A+1+IO FVzt+8ZCOt/WVUJ14MP1O7c1GOQswGX10wL7s= MIME-Version: 1.0 Received: by 10.204.52.136 with SMTP id i8mr566699bkg.74.1299101080044; Wed, 02 Mar 2011 13:24:40 -0800 (PST) Received: by 10.204.14.139 with HTTP; Wed, 2 Mar 2011 13:24:40 -0800 (PST) In-Reply-To: <201103021724.p22HOttB009647@fs4113.wdf.sap.corp> References: <201103021724.p22HOttB009647@fs4113.wdf.sap.corp> Date: Wed, 2 Mar 2011 16:24:40 -0500 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 21:23:39 -0000 I was aware of that attack. That is not a problem with the use of MD2 in a self-signed certificate. That is a problem of having used MD2. The problem there is that if you have a key that has been used to sign with MD2 it is going to be permanently tainted regardless of what place the cert is in the chain and regardless of what type of cert it is. The attacker can 'correct' for any defect wrt cert type, validity interval etc. There is only one effective defense against that attack and that is to withdraw the MD2 algorithm from service. You don't get any additional security from adding additional stronger algorithms to the support list. You only get additional security from withdrawing a weak algorithm from service. Which is why I am arguing it is time to withdraw SHA1 from service. It is only marginally more secure than MD5. On Wed, Mar 2, 2011 at 12:24 PM, Martin Rex wrote: > Phillip Hallam-Baker wrote: >> >> The use of MD2 in a self signed cert has little risk as far as use of >> the cert itself goes since it only serves as proof of possession which >> is only relevant when the browser provider chooses to install it in >> the browser. > > In the universe where I live, there exist collision attacks against MD2. > =A0(check http://en.wikipedia.org/wiki/MD2_%28cryptography%29) > > So an RSA-key for which a PKCS#1 encrypted MD2 signature has been > published is a real security problem and ought to have been discarded > long ago. > > Else someone could try to use the preimage attack to issue himself > an intermediate CA cert under such a root cert, reusing the md2-based > signature on the RootCA cert. > > I would REALLY like to kill md2withRsaEncryption as a digital > signature algorithm from our PKI implementation, like I did > with all of md4-based digital signature algorithms. > > > Getting rid of "tainted" RSA keys is also important. > > Why do you think that FIPS 186-3 says that you are not allowed > to use an RSA keypair for both PKCS-v1.5 and PKCS-PSS signatures? > Because you "taint" your RSA key on the first time that you use it > for a weak scheme. > > -Martin > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D45E3A6857 for ; Wed, 2 Mar 2011 09:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.234 X-Spam-Level: X-Spam-Status: No, score=-10.234 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0B8IwuInEug for ; Wed, 2 Mar 2011 09:23:52 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id EBF9D3A6855 for ; Wed, 2 Mar 2011 09:23:51 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p22HOuQf013826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Mar 2011 18:24:56 +0100 (MET) From: Martin Rex Message-Id: <201103021724.p22HOttB009647@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Wed, 2 Mar 2011 18:24:55 +0100 (MET) In-Reply-To: from "Phillip Hallam-Baker" at Mar 2, 11 12:04:56 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 17:23:53 -0000 Phillip Hallam-Baker wrote: > > The use of MD2 in a self signed cert has little risk as far as use of > the cert itself goes since it only serves as proof of possession which > is only relevant when the browser provider chooses to install it in > the browser. In the universe where I live, there exist collision attacks against MD2. (check http://en.wikipedia.org/wiki/MD2_%28cryptography%29) So an RSA-key for which a PKCS#1 encrypted MD2 signature has been published is a real security problem and ought to have been discarded long ago. Else someone could try to use the preimage attack to issue himself an intermediate CA cert under such a root cert, reusing the md2-based signature on the RootCA cert. I would REALLY like to kill md2withRsaEncryption as a digital signature algorithm from our PKI implementation, like I did with all of md4-based digital signature algorithms. Getting rid of "tainted" RSA keys is also important. Why do you think that FIPS 186-3 says that you are not allowed to use an RSA keypair for both PKCS-v1.5 and PKCS-PSS signatures? Because you "taint" your RSA key on the first time that you use it for a weak scheme. -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9C013A6774 for ; Wed, 2 Mar 2011 09:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngqeWKsZ-1et for ; Wed, 2 Mar 2011 09:03:52 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 7864C3A6848 for ; Wed, 2 Mar 2011 09:03:52 -0800 (PST) Received: by bwz13 with SMTP id 13so403677bwz.31 for ; Wed, 02 Mar 2011 09:04:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oCGM7MyzhoQkJ7ub0s8ceb0uiD1kp/VMgUgXVpAOGy0=; b=bzhEtdMwr5nrAkPIyg/ehqx5tY3J7OUV8j0z629L4qVILEcgKzFt7Q1JYCeZMZFjhS STzf1fETrlt4OyZmUxT/X5YkNSRVi/xbe/GgdL5BKKvogvpkuQKiqzb3C9A8ZwWHEGGh 0f7xAh3WzzciC+rWWSWxWuVYu+IUy7rW/n/0I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mCiK46G0ztG5ucJfCLkzY3QvKFvs/gsJlXtczJbN1PPe+t++jucs4WwPEYfUQvmeHm 8Ohief/Kffro9MRkIIrDoLtoLkrPlQI7+NFmwFF/EvciCMlntZDXg4Zd6WSAvU/j+hPX Q+mwiMvO9GKUsMgFEJsU5+J9ltqKLqOuuP6Gg= MIME-Version: 1.0 Received: by 10.204.73.160 with SMTP id q32mr226644bkj.155.1299085496782; Wed, 02 Mar 2011 09:04:56 -0800 (PST) Received: by 10.204.14.139 with HTTP; Wed, 2 Mar 2011 09:04:56 -0800 (PST) In-Reply-To: <201103021529.p22FTFOu002845@fs4113.wdf.sap.corp> References: <201103020150.p221owI6017784@fs4113.wdf.sap.corp> <201103021529.p22FTFOu002845@fs4113.wdf.sap.corp> Date: Wed, 2 Mar 2011 12:04:56 -0500 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 17:03:53 -0000 The use of MD2 in a self signed cert has little risk as far as use of the cert itself goes since it only serves as proof of possession which is only relevant when the browser provider chooses to install it in the browser. Under windows the cert is actually authenticated under the CTL structure which uses SHA1 at the least. There are certainly issues with MD2, but that is not one of them. Argument by analogy is a really bad way to conduct a security review. We are not at all happy with the situation with respect to digets algorithms. Moving away from SHA1 is going to be a huge problem for the industry. If anyone here thinks that DANE is going to be allowed to add to that problem, well they need learning otherwise. Choice of the crypto alg is meant to be the easy part of the problem. On Wed, Mar 2, 2011 at 10:29 AM, Martin Rex wrote: > Martin Rex wrote: >> >> And there are still a number of TrustAnchors in every Browser that >> carry an md5WithRsaEncryption signature. >> >> But it's actually worse than that -- VeriSign still has a CA cert >> in service with an md2WithRsaEncryption -- and is still using it >> productively (check https://www.hp.com/). > > I'm terribly sorry, I mixed up the (by now long) list of VeriSign > RootCA certs. > > The RootCA cert under which the server cert for https://www.hp.com > is "VeriSign Class 3 Public Primary Certification Authority - G2" > and uses sha1WithRsaEncryption. =A0But it still is an X.509v1 cert. > > My Firefox 3.5.13 comes with these three VeriSign RooCA certs > that are X.509v1, use md2WithRsaSignature and valid until 02-Aug-2028: > > =A0 "VeriSign Class 1 Public Primary Certification Authority" > =A0 "VeriSign Class 2 Public Primary Certification Authority" > =A0 "VeriSign Class 3 Public Primary Certification Authority" > > > -Martin > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56DF23A680F for ; Wed, 2 Mar 2011 07:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.234 X-Spam-Level: X-Spam-Status: No, score=-10.234 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ni3+VKSVMhqL for ; Wed, 2 Mar 2011 07:28:11 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 54ACF3A67D0 for ; Wed, 2 Mar 2011 07:28:11 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p22FTF6X004553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Mar 2011 16:29:15 +0100 (MET) From: Martin Rex Message-Id: <201103021529.p22FTFOu002845@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Wed, 2 Mar 2011 16:29:15 +0100 (MET) In-Reply-To: <201103020150.p221owI6017784@fs4113.wdf.sap.corp> from "Martin Rex" at Mar 2, 11 02:50:58 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: hallam@gmail.com, keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 15:28:12 -0000 Martin Rex wrote: > > And there are still a number of TrustAnchors in every Browser that > carry an md5WithRsaEncryption signature. > > But it's actually worse than that -- VeriSign still has a CA cert > in service with an md2WithRsaEncryption -- and is still using it > productively (check https://www.hp.com/). I'm terribly sorry, I mixed up the (by now long) list of VeriSign RootCA certs. The RootCA cert under which the server cert for https://www.hp.com is "VeriSign Class 3 Public Primary Certification Authority - G2" and uses sha1WithRsaEncryption. But it still is an X.509v1 cert. My Firefox 3.5.13 comes with these three VeriSign RooCA certs that are X.509v1, use md2WithRsaSignature and valid until 02-Aug-2028: "VeriSign Class 1 Public Primary Certification Authority" "VeriSign Class 2 Public Primary Certification Authority" "VeriSign Class 3 Public Primary Certification Authority" -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9A3F3A6A24 for ; Tue, 1 Mar 2011 17:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.234 X-Spam-Level: X-Spam-Status: No, score=-10.234 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1SvaEF39Fq6 for ; Tue, 1 Mar 2011 17:49:57 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 9FC933A6A21 for ; Tue, 1 Mar 2011 17:49:56 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p221oxoW020020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Mar 2011 02:50:59 +0100 (MET) From: Martin Rex Message-Id: <201103020150.p221owI6017784@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Wed, 2 Mar 2011 02:50:58 +0100 (MET) In-Reply-To: from "Phillip Hallam-Baker" at Mar 1, 11 04:37:27 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 01:49:57 -0000 Phillip Hallam-Baker wrote: > > Plenty is not the point. > > SHA1 is no longer regarded as acceptably secure. SHA2 is based on the > same construction and is thus similarly suspect. > > We don't use SHA1 in legacy browsers because we like it. We use SHA1 > in legacy browsers because we have not worked out how to transition > away from it. The transition from MD5 to SHA1 was painless only > because all browsers were required to support both standards. Transition from MD5 to SHA1? I seem to have missed that entirely. MD5 was removed from the PRF in the SSLv3->TLSv1.0 protocol revision, but even TLSv1.1 uses a combination of MD5+SHA1 for digital signatures. And there are still a number of TrustAnchors in every Browser that carry an md5WithRsaEncryption signature. But it's actually worse than that -- VeriSign still has a CA cert in service with an md2WithRsaEncryption -- and is still using it productively (check https://www.hp.com/). Considering the transition SHA-1 --> SHA-256. That was goofed in TLSv1.2, by defining the default hash algorithm for the digital signature structs to default to SHA-1 (only) -- which is actually weaker than SSLv3/TLSv1.0/TLSv1.1 ... > > This particular topic is one on which the Security ADs and the IETF > chair have very very specific opinions on. And given their role in > trying to effect an industry wide transition to stronger algorithms, I > think that they are quite right to insist on them. DANEs security is vitally dependent on DNSSEC, and for DNSSEC, SHA-1 seems to be the mandatory-to-implement algorithm for signatures. Inuitively, why don't we tie DANE's hash algorithm to DNSSECs algorithm? Making DANE an early adopter of SHA-3 while DNSSEC still uses SHA-1 amounts to silicon snake oil -- i.e. needless complexity. -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5F673A6BF3 for ; Tue, 1 Mar 2011 15:46:51 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8e2LcrvZn0P for ; Tue, 1 Mar 2011 15:46:51 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id E9F983A6BF2 for ; Tue, 1 Mar 2011 15:46:50 -0800 (PST) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id 7356C1B411AC; Tue, 1 Mar 2011 18:47:54 -0500 (EST) Message-Id: From: Warren Kumari To: Warren Kumari In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 1 Mar 2011 18:47:54 -0500 References: X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] Meeting in Prague. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 23:46:51 -0000 On Feb 25, 2011, at 12:15 PM, Warren Kumari wrote: > Hello all. > > We have been granted a meeting slot in Prague. > > If anyone wants agenda time to discuss things *in our charter*, let > the chairs know well ahead of time so that we can schedule you. A gentle reminder -- please give us as much notice as possible... W > TLS is also scheduled to meet -- if what you want to discuss > involves changes to TLS (like bare keys), please take it to TLS.... > > Also, if you want to suggest something like TLSA for a non-TLS > protocol that doesn't already have keys, that is fine too, *as long > as you have a published draft before the meeting*. > > Cutoff date for -00 submissions: > 2011-03-07 (Monday): Internet Draft Cut-off for initial document > (-00) submission by 17:00 PT (01:00 Tuesday, March 8 UTC), upload > using IETF ID Submission Tool. > > Thank you and hope to see you in Prague! > W > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > For every complex problem, there is a solution that is simple, neat, and wrong. -- H. L. Mencken Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6949C3A6AB8 for ; Tue, 1 Mar 2011 13:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHhK3WFDYQTZ for ; Tue, 1 Mar 2011 13:36:25 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id E8A483A6AB3 for ; Tue, 1 Mar 2011 13:36:24 -0800 (PST) Received: by bwz13 with SMTP id 13so5785401bwz.31 for ; Tue, 01 Mar 2011 13:37:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6kGE+dqLkw1qm5dtXJvTt+l6A1yoU7BUrcgGFgBSyxY=; b=JJPohz0rE0RH8I7pWl+hJUf3X5PgYL11MymmjNEeJ9JJM9gLLDqQvvdJvHhRm7cM+r icMQBCw89LLec60uOPouQs6T4mTrY6wrkuGbX7I2UeMYDQaOOz0k3mM0O1StaI8x6/AS A4PIHQFDibea8ZTayl56YL5HTzczplMt9o8dA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OQLJGuM3xczuay89Nu2oS/rcvGP849Xlu+2YDms8SBMuVpllQDzdW4J5WLjXmcy3m/ f4gyo5PMHuBofEKu/gIbK6VjecwFu8klxYmGVXWzxLz8W37arJJtCxsUxzWAie3NDfef TjBYg7sagCDMOs3ZodEJPdSWw1OsOW6nh4n5U= MIME-Version: 1.0 Received: by 10.204.14.202 with SMTP id h10mr6392860bka.182.1299015447536; Tue, 01 Mar 2011 13:37:27 -0800 (PST) Received: by 10.204.14.139 with HTTP; Tue, 1 Mar 2011 13:37:27 -0800 (PST) In-Reply-To: <201103011815.p21IFukr020670@fs4113.wdf.sap.corp> References: <201103011815.p21IFukr020670@fs4113.wdf.sap.corp> Date: Tue, 1 Mar 2011 16:37:27 -0500 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 21:36:26 -0000 Plenty is not the point. SHA1 is no longer regarded as acceptably secure. SHA2 is based on the same construction and is thus similarly suspect. We don't use SHA1 in legacy browsers because we like it. We use SHA1 in legacy browsers because we have not worked out how to transition away from it. The transition from MD5 to SHA1 was painless only because all browsers were required to support both standards. This particular topic is one on which the Security ADs and the IETF chair have very very specific opinions on. And given their role in trying to effect an industry wide transition to stronger algorithms, I think that they are quite right to insist on them. On Tue, Mar 1, 2011 at 1:15 PM, Martin Rex wrote: > Phillip Hallam-Baker wrote: >> >> Currently, the only digest algorithm that can be recommended is SHA-2 >> >> We really do need SHA2 in here as a MUST, unless we are still discussing >> this when the SHA3 competition results are out. > > SHA-256 looks like plenty. > > You do realize, that many (if not most) implementations of TLS are going > to use SHA-1 for digital signatures for quite some time to come? > > And even document like the updated TLS extensions document (rfc6066) > use SHA-1 all over the place. > > -Martin > -- Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E099A3A698E for ; Tue, 1 Mar 2011 10:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.233 X-Spam-Level: X-Spam-Status: No, score=-10.233 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gk3A5yz9bEJ0 for ; Tue, 1 Mar 2011 10:14:55 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id DE1C23A6957 for ; Tue, 1 Mar 2011 10:14:54 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p21IFuSa014735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Mar 2011 19:15:56 +0100 (MET) From: Martin Rex Message-Id: <201103011815.p21IFukr020670@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Tue, 1 Mar 2011 19:15:56 +0100 (MET) In-Reply-To: from "Phillip Hallam-Baker" at Feb 25, 11 04:52:06 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 18:14:56 -0000 Phillip Hallam-Baker wrote: > > Currently, the only digest algorithm that can be recommended is SHA-2 > > We really do need SHA2 in here as a MUST, unless we are still discussing > this when the SHA3 competition results are out. SHA-256 looks like plenty. You do realize, that many (if not most) implementations of TLS are going to use SHA-1 for digital signatures for quite some time to come? And even document like the updated TLS extensions document (rfc6066) use SHA-1 all over the place. -Martin