From mike-list@pobox.com Wed Jun 1 17:12:47 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70BCE0758; Wed, 1 Jun 2011 17:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgYLHiC-vZQR; Wed, 1 Jun 2011 17:12:47 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by ietfa.amsl.com (Postfix) with ESMTP id 0743FE06EB; Wed, 1 Jun 2011 17:12:46 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 354EB5301; Wed, 1 Jun 2011 20:14:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=rAT14u/PnnlT 9njGwwRAjppPf6w=; b=HwzkKa8w9pOi970ZPqVd1J45cSuKi9WkpGFjYcY6zH5T 4DEqnaDsjfXAi5klw7xzFweJob+mlQuhHqdgaH8mLV7JiWYMtRwhc0qtXJ5spZtH vpXoSCkvq/coM9nbZWmzvGkdjz0uDlOApa3lusZk9hZ6KtJhnkf4EUwGVRormxw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=M3OkeU u87FlFEX4q9sMWYfPWfQZZFvzj+U3ebiMPVyqzZA8lzjIDzkq7f/TascPgoYnGQe xCq/35aHqLHJPcYHaIq41csuN8V20F2vjbN/pHfAGT5fanbljUr7EXs38F7we24v zMfSBKNtvHo0qvdk1KF7ClTJIHo+xWqKktc+U= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id E2B065300; Wed, 1 Jun 2011 20:14:50 -0400 (EDT) Received: from iMac.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 1637C52FF; Wed, 1 Jun 2011 20:14:46 -0400 (EDT) Message-ID: <4DE6D575.2000808@pobox.com> Date: Wed, 01 Jun 2011 17:12:37 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Paul Hoffman References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 553A7E4E-8CAD-11E0-BCCC-D6B6226F3D4C-38729857!a-pb-sasl-sd.pobox.com Cc: pkix@ietf.org, TLS Mailing List Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 00:12:48 -0000 Paul Hoffman wrote: > > I support the PKIX WG adopting as a work item (wording taken from the CAA draft's text) "DNS Resource Records that allow a DNS domain name holder to specify the certificate signing certificate(s) authorized to issue certificates for that domain". I haven't read the draft, but from the quote it appears that this could improve the weakest part of TLS (as it is used today in browsers) where any of the hundreds of preinstalled root CAs is trusted to issue a certificate to any possible domain name. [CC'ed to the TLS working group] Mike From ynir@checkpoint.com Wed Jun 1 21:10:59 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE6AE068F; Wed, 1 Jun 2011 21:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.979 X-Spam-Level: X-Spam-Status: No, score=-9.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYv4ApGYkawW; Wed, 1 Jun 2011 21:10:57 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 98CC1E0676; Wed, 1 Jun 2011 21:10:56 -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 p524AriS024146; Thu, 2 Jun 2011 07:10:53 +0300 X-CheckPoint: {4DE719E9-0-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, 2 Jun 2011 07:10:53 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 2 Jun 2011 07:10:53 +0300 From: Yoav Nir To: "Michael D'Errico" Date: Thu, 2 Jun 2011 07:10:52 +0300 Thread-Topic: [TLS] [pkix] Proposing CAA as PKIX Working Group Item Thread-Index: Acwg2w/ucXVWFeMOTFGqsb86yZzLiQ== Message-ID: <7A11CFD1-F0AA-4CA4-8542-CA7998D2FBEF@checkpoint.com> References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> <4DE6D575.2000808@pobox.com> In-Reply-To: <4DE6D575.2000808@pobox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" , Paul Hoffman , TLS Mailing List Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 04:10:59 -0000 On Jun 2, 2011, at 3:12 AM, Michael D'Errico wrote: > Paul Hoffman wrote: >>=20 >> I support the PKIX WG adopting as a work item (wording taken from the CA= A draft's text) "DNS Resource Records that allow a DNS domain name holder t= o specify the certificate signing certificate(s) authorized to issue certif= icates for that domain". >=20 > I haven't read the draft, but from the quote it appears that > this could improve the weakest part of TLS (as it is used > today in browsers) where any of the hundreds of preinstalled > root CAs is trusted to issue a certificate to any possible > domain name. I'm not opposed to this draft, but I don't think it solves this problem. Th= e issue is not even the dozens of pre-installed root CAs, but that those ro= ot CAs can have many many affiliates, whether they're sub-CAs or registrati= on authorities.=20 The two famous attacks of the last two years have not been about Verisign o= r Comodo. The "MD5 sub-CA" was issued by RapidSSL, which is part of the "Ve= risign trust network" but not Verisign itself. In the recent case it was a = small Italian RA. In both cases the problem was an affiliate with not quite= best practices that caused the mis-issue. CAA works if all root CAs and affiliates follow it. That's hundreds or thou= sands of entities. Any one of them that fails to comply might ignore the CA= A record. PHB says that having the CAA record may aid in assigning blame, and thus pe= rhaps at some point, liability. Remains to be seen, but at least in the sho= rt term, CAA is not a panacea. That's why I believe that the DANE record that is aimed at relying parties = is a necessary complement to this work. I know I've said the opposite on th= e DANE list, but I've changed my mind since then. Yoav= From hallam@gmail.com Thu Jun 2 06:46:03 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E26DE06E3; Thu, 2 Jun 2011 06:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.978 X-Spam-Level: X-Spam-Status: No, score=-2.978 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYIPQhYy6uF7; Thu, 2 Jun 2011 06:46:02 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5DEE0692; Thu, 2 Jun 2011 06:46:02 -0700 (PDT) Received: by gxk19 with SMTP id 19so430784gxk.31 for ; Thu, 02 Jun 2011 06:46:01 -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=prU8UQTtRwAzI3BDjsYM/Ug4VIvCMuieUEGebFRtEHY=; b=TMT5ipF/YktJ+C0csbz/P5iFCZY97f4lJtv3OSb2g+ETO/UAWNwCm0Qm5Hu1SFWW4R iAd9aeMkOKCO5PIqBrSgKbgQK7V30zJkip3hklge6vw0BTb2a1L3tISvBUtf0fu4lMpZ YDBvH8JCi59GuS6EZFPJKiV27jfagCySD4e9E= 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=xZOJmv0f8jYzU9Wnj+EDu4V1XwhGYwLkTrOQxLoSFiayi1G8oB+q9hQAeGiAsXRQNB zkCf4IJhrR+syeNgOoRQI++gdsAluwco8LfkccVpSqmZNd+afp08Ed2gWV/4D62Gmt8D FgHMAvH2UFf2rUnlObrCjIjLG7gIiIvyxPrtI= MIME-Version: 1.0 Received: by 10.101.11.14 with SMTP id o14mr461549ani.88.1307022358736; Thu, 02 Jun 2011 06:45:58 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Thu, 2 Jun 2011 06:45:58 -0700 (PDT) In-Reply-To: <7A11CFD1-F0AA-4CA4-8542-CA7998D2FBEF@checkpoint.com> References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> <4DE6D575.2000808@pobox.com> <7A11CFD1-F0AA-4CA4-8542-CA7998D2FBEF@checkpoint.com> Date: Thu, 2 Jun 2011 09:45:58 -0400 Message-ID: From: Phillip Hallam-Baker To: Yoav Nir Content-Type: multipart/alternative; boundary=0016e68fcec467efc004a4badb85 Cc: "pkix@ietf.org" , Paul Hoffman , TLS Mailing List Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 13:46:03 -0000 --0016e68fcec467efc004a4badb85 Content-Type: text/plain; charset=ISO-8859-1 That is not quite right. First off, measurement of the failure rate of CAs is rather difficult because we only actually know the failure rate for CAs that self-report. It is not zero but it is close enough to being zero that people can work themselves up into a lather about it. At the end of the day buffer over-run exploits will still trump any deficiencies in the CA infrastructure. But those don't have people running round suggesting urgent remedies because they are too common to bear notice. CAs and RAs are definitely not the weakest link in the chain here. Anyone claiming that is either grandstanding or has failed to pay attention. But more importantly, an RA does not have issuing power by definition. Only a CA can issue certificates because that is the definition of a CA. The intention of CAA is that it be enforced by the CA so that an RA cannot issue a non compliant cert either. One area where I could see a possible use case for extending CAA would be to enable better RA management controls. For example the vast majority of the 'RAs' identified in the EFF study are actually intermediate roots assigned to RAs at educational institutions. Such RAs only have general issuing powers in a minority of circumstances. We had some discussion of this after my SAAG presentation. Here is the issue: some of these controls will be technical and some will be policy. Some of these controls will be the type of thing IETF likes to work on and some will not. That is why we have CABForum. And then another question that naturally comes up is how much of this we should do in phase 1 and whether we should attempt to do everything at once or to do the lowest of the low hanging fruit first, gain some experience and then add in features to support additional use cases. The final point made is that some CAs may not want to support CAA. I can't see why this would be so unless either: 1) The technology is deficient (something PKIX might fix). 2) They really want to be able to issue fraudulent certificates. 3) They resist change for the sake of it. 4) It is not yet an IETF standard Now I have no idea which of the above might apply if any. But the only way to find out is going to be to deploy. This is still a worthwhile exercise if the only effect is to identify CAs that wish to issue fraudulent certificates. The IETF does not have the power to police such CAs but others do. On Thu, Jun 2, 2011 at 12:10 AM, Yoav Nir wrote: > > On Jun 2, 2011, at 3:12 AM, Michael D'Errico wrote: > > > Paul Hoffman wrote: > >> > >> I support the PKIX WG adopting as a work item (wording taken from the > CAA draft's text) "DNS Resource Records that allow a DNS domain name holder > to specify the certificate signing certificate(s) authorized to issue > certificates for that domain". > > > > I haven't read the draft, but from the quote it appears that > > this could improve the weakest part of TLS (as it is used > > today in browsers) where any of the hundreds of preinstalled > > root CAs is trusted to issue a certificate to any possible > > domain name. > > I'm not opposed to this draft, but I don't think it solves this problem. > The issue is not even the dozens of pre-installed root CAs, but that those > root CAs can have many many affiliates, whether they're sub-CAs or > registration authorities. > > The two famous attacks of the last two years have not been about Verisign > or Comodo. The "MD5 sub-CA" was issued by RapidSSL, which is part of the > "Verisign trust network" but not Verisign itself. In the recent case it was > a small Italian RA. In both cases the problem was an affiliate with not > quite best practices that caused the mis-issue. > > CAA works if all root CAs and affiliates follow it. That's hundreds or > thousands of entities. Any one of them that fails to comply might ignore the > CAA record. > > PHB says that having the CAA record may aid in assigning blame, and thus > perhaps at some point, liability. Remains to be seen, but at least in the > short term, CAA is not a panacea. > > That's why I believe that the DANE record that is aimed at relying parties > is a necessary complement to this work. I know I've said the opposite on the > DANE list, but I've changed my mind since then. > > Yoav > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Website: http://hallambaker.com/ --0016e68fcec467efc004a4badb85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That is not quite right.

First off, measurement of the f= ailure rate of CAs is rather difficult because we only actually know the fa= ilure rate for CAs that self-report. It is not zero but it is close enough = to being zero that people can work themselves up into a lather about it.=A0=

At the end of the day buffer over-run exploits will sti= ll trump any deficiencies in the CA infrastructure. But those don't hav= e people running round suggesting urgent remedies because they are too comm= on to bear notice. CAs and RAs are definitely not the weakest link in the c= hain here. Anyone claiming that is either grandstanding or has failed to pa= y attention.


But more importantly, an RA does not hav= e issuing power by definition. Only a CA can issue certificates because tha= t is the definition of a CA. The intention of CAA is that it be enforced by= the CA so that an RA cannot issue a non compliant cert either.

One area where I could see a possible use case for exte= nding CAA would be to enable better RA management controls. For example the= vast majority of the 'RAs' identified in the EFF study are actuall= y intermediate roots assigned to RAs at educational institutions. Such RAs = only have general issuing powers in a minority of circumstances.

We had some discussion of this after my SAAG presentati= on.

Here is the issue: some of these controls will= be technical and some will be policy. Some of these controls will be the t= ype of thing IETF likes to work on and some will not. That is why we have C= ABForum.

And then another question that naturally comes up is ho= w much of this we should do in phase 1 and whether we should attempt to do = everything at once or to do the lowest of the low hanging fruit first, gain= some experience and then add in features to support additional use cases.<= /div>


The final point made is that some CAs ma= y not want to support CAA. I can't see why this would be so unless eith= er:

1) The technology is deficient (something PKIX= might fix).
2) They really want to be able to issue fraudulent certificates.
=
3) They resist change for the sake of it.
4) It is not yet a= n IETF standard

Now I have no idea which of the ab= ove might apply if any. But the only way to find out is going to be to depl= oy.=A0

This is still a worthwhile exercise if the only effect = is to identify CAs that wish to issue fraudulent certificates. The IETF doe= s not have the power to police such CAs but others do.


On Thu, Jun 2, 2011 at 12:10 AM, Yoav N= ir <ynir@checkp= oint.com> wrote:

On Jun 2, 2011, at 3:12 AM, Michael D'Errico wrote:

> Paul Hoffman wrote:
>>
>> I support the PKIX WG adopting as a work item (wording taken from = the CAA draft's text) "DNS Resource Records that allow a DNS domai= n name holder to specify the certificate signing certificate(s) authorized = to issue certificates for that domain".
>
> I haven't read the draft, but from the quote it appears that
> this could improve the weakest part of TLS (as it is used
> today in browsers) where any of the hundreds of preinstalled
> root CAs is trusted to issue a certificate to any possible
> domain name.

I'm not opposed to this draft, but I don't think it sol= ves this problem. The issue is not even the dozens of pre-installed root CA= s, but that those root CAs can have many many affiliates, whether they'= re sub-CAs or registration authorities.

The two famous attacks of the last two years have not been about Verisign o= r Comodo. The "MD5 sub-CA" was issued by RapidSSL, which is part = of the "Verisign trust network" but not Verisign itself. In the r= ecent case it was a small Italian RA. In both cases the problem was an affi= liate with not quite best practices that caused the mis-issue.

CAA works if all root CAs and affiliates follow it. That's hundreds or = thousands of entities. Any one of them that fails to comply might ignore th= e CAA record.

PHB says that having the CAA record may aid in assigning blame, and thus pe= rhaps at some point, liability. Remains to be seen, but at least in the sho= rt term, CAA is not a panacea.

That's why I believe that the DANE record that is aimed at relying part= ies is a necessary complement to this work. I know I've said the opposi= te on the DANE list, but I've changed my mind since then.

Yoav
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls



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

--0016e68fcec467efc004a4badb85-- From ynir@checkpoint.com Thu Jun 2 08:40:16 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573B8E07CC; Thu, 2 Jun 2011 08:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.53 X-Spam-Level: X-Spam-Status: No, score=-10.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4Zq6YCy7-K3; Thu, 2 Jun 2011 08:40:15 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C1F95E06FD; Thu, 2 Jun 2011 08:40:14 -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 p52FeBKR008989; Thu, 2 Jun 2011 18:40:11 +0300 X-CheckPoint: {4DE7BB74-17-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, 2 Jun 2011 18:40:11 +0300 From: Yoav Nir To: Phillip Hallam-Baker Date: Thu, 2 Jun 2011 18:37:36 +0300 Thread-Topic: [TLS] [pkix] Proposing CAA as PKIX Working Group Item Thread-Index: AcwhO1t+ULi0hC8VSoeVpXSIgYhHIw== Message-ID: <7043B742-0AAA-4875-8642-764E7F41DFD5@checkpoint.com> References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> <4DE6D575.2000808@pobox.com> <7A11CFD1-F0AA-4CA4-8542-CA7998D2FBEF@checkpoint.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: "pkix@ietf.org" , Paul Hoffman , TLS Mailing List Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 15:40:16 -0000 On Jun 2, 2011, at 4:45 PM, Phillip Hallam-Baker wrote: >=20 > The final point made is that some CAs may not want to support CAA. I can'= t see why this would be so unless either: >=20 > 1) The technology is deficient (something PKIX might fix). > 2) They really want to be able to issue fraudulent certificates. > 3) They resist change for the sake of it. > 4) It is not yet an IETF standard >=20 > Now I have no idea which of the above might apply if any. But the only wa= y to find out is going to be to deploy.=20 I can offer a couple of others 5) They're too lazy to care 6) It's cheaper to not do anything than to do something In late 2008, when some researchers got RapidSSL to sign a certificate requ= est that collided with their rogue sub-CA certificate, several things came = to light: - They were using MD5 10 years after RFC 2459 recommended not to - They were a ridiculously small company, with the only full-time employee= . An accountant - They were doing a bunch of other "industry worst practices" - every fiel= d in the certificate was predictable The root problem is that the RapidSSLs of the world issue certificates that= are considered by browsers to be just as valid as any DV certificate issue= d by responsible CAs. So getting a certificate that validates is as easy as= getting a rogue certificate from the worst CA or sub-CA. And with so many = to choose from, I'm sure it will be possible to find one that didn't implem= ent CAA correctly. It's still worthwhile, IMO. Because maybe that particular CA that implement= ed CAA wrong is not using MD5, or maybe they have some other security mecha= nism done right. It may very well help thwart the next researcher or hacker= . I just don't think it's the ultimate solution to the "weakest link" probl= em. Yoav From marsh@extendedsubset.com Thu Jun 2 09:07:11 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1408E07F9; Thu, 2 Jun 2011 09:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xmx-gJq8w1Xz; Thu, 2 Jun 2011 09:07:11 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 57CABE07CC; Thu, 2 Jun 2011 09:07:11 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1QSAQP-0004oW-76; Thu, 02 Jun 2011 16:07:09 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id AB72E606D; Thu, 2 Jun 2011 16:07:06 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18ZaeEObNEyW+qN1tQpVBHZRJYsUTihz8k= Message-ID: <4DE7B529.9040206@extendedsubset.com> Date: Thu, 02 Jun 2011 11:07:05 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> <4DE6D575.2000808@pobox.com> <7A11CFD1-F0AA-4CA4-8542-CA7998D2FBEF@checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" , Paul Hoffman , TLS Mailing List Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 16:07:12 -0000 On 06/02/2011 08:45 AM, Phillip Hallam-Baker wrote: > > At the end of the day buffer over-run exploits will still trump any > deficiencies in the CA infrastructure. But those don't have people > running round suggesting urgent remedies because they are too common to > bear notice. CAs and RAs are definitely not the weakest link in the > chain here. Anyone claiming that is either grandstanding or has failed > to pay attention. Well that depends entirely on the chain in question doesn't it? Not everything that uses TLS or certificates is an unpatched web browser with Adobe plugins operated by an ignorant user for the purpose of securing nothing particularly important. Over time it becomes increasingly difficult for _any_ distributed application to run over ports other than TCP 443 due to the growth of egress filtering. So stuff is bundled in with web traffic that may, in fact, be implemented for high security requirements. Perhaps a solution is to implement your own application-specific trust root that doesn't rely on the current profusion of CAs. But as an application developer I can attest to the fact that it's difficult to use standard platform TLS libraries without also trusting everything in the system root store, too. Some sites will insist on using their own in-house CAs too, which is fine, but it's further pressure on everything else to integrate/be vulnerable with the browser trust model. The net security world has changed dramatically over the last couple of years. We have to move past this broken-browser-as-least-common-denominator mentality. - Marsh From hallam@gmail.com Thu Jun 2 09:31:20 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF1EE07FC; Thu, 2 Jun 2011 09:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HD5Nc-FXcVkN; Thu, 2 Jun 2011 09:31:18 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 80BBDE07FA; Thu, 2 Jun 2011 09:31:15 -0700 (PDT) Received: by gxk19 with SMTP id 19so515766gxk.31 for ; Thu, 02 Jun 2011 09:31:15 -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=d3H1o1MfWU+6RcBf8CWGxD6qvH6V0IkUT3snbqlwYyI=; b=N32MUR3BOUl4OhXzElbn2wL9zWCKXXFF6igVeYkiiER5fZ1kjfes7kTlys2xfQYjGS 7wS/RO3esjrANTvAMjyBcC/EBQxv0BNdoIpAY4IA9WsyNJOZ0FT4DCaK4cVzAOwSRSXp SBYRywXMHeGwg44Z4D9BhkuUGQIb8dnQg/Bcs= 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=szE0GcwzrvDGP22jEkpvht7JN3bDzsXG+FBNO33WkrJ/fbd/J8fTrSV7f/5Vyp2d2w mlEQ4EWbjEOcvfkq1DCvu4DUKZyyY2oTQKtHPXGcVx/zbgMIwX4A9FGKMAjZwYZF6f97 Mt5D9VfVtDsV+7nRb1gX+ciEIR7mah0HqusfQ= MIME-Version: 1.0 Received: by 10.101.74.10 with SMTP id b10mr590618anl.107.1307032273119; Thu, 02 Jun 2011 09:31:13 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Thu, 2 Jun 2011 09:31:13 -0700 (PDT) In-Reply-To: <4DE7B529.9040206@extendedsubset.com> References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> <4DE6D575.2000808@pobox.com> <7A11CFD1-F0AA-4CA4-8542-CA7998D2FBEF@checkpoint.com> <4DE7B529.9040206@extendedsubset.com> Date: Thu, 2 Jun 2011 12:31:13 -0400 Message-ID: From: Phillip Hallam-Baker To: Marsh Ray Content-Type: multipart/alternative; boundary=0016368e1f855969d804a4bd2a38 Cc: "pkix@ietf.org" , Paul Hoffman , TLS Mailing List Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 16:31:20 -0000 --0016368e1f855969d804a4bd2a38 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 2, 2011 at 12:07 PM, Marsh Ray wrote: > On 06/02/2011 08:45 AM, Phillip Hallam-Baker wrote: > >> >> At the end of the day buffer over-run exploits will still trump any >> deficiencies in the CA infrastructure. But those don't have people >> running round suggesting urgent remedies because they are too common to >> bear notice. CAs and RAs are definitely not the weakest link in the >> chain here. Anyone claiming that is either grandstanding or has failed >> to pay attention. >> > > Well that depends entirely on the chain in question doesn't it? > > Not everything that uses TLS or certificates is an unpatched web browser > with Adobe plugins operated by an ignorant user for the purpose of securing > nothing particularly important. > I hear you. But lets be realistic here, we are currently actually doing worse for non browser security. The weakest link in the TLS protocol is actually the end user who is for some bizarre reason expected to be looking for padlock icons and green bars and know when to look for which one. This is even more problematic when applying TLS to Web services as there isn't even a user to make the decision and no real idea of what should do that instead. CAA is not going to solve every problem associated with trust on the Internet and CA infrastructure. Nor is TLS and nor is strict security. But I do think that a combination of those three ideas can make a major step forward. That is why CAA is designed to be arbitrarily extensible with a tag-value format even though there are only two property tags currently defined. I really like the work that Paypal and Jeff Hodges have been doing and would like to have a way to eventually bring CAA into alignment there. But for the moment we have to avoid 'crossing the streams' as Stephen F. put it to me. Lets work on the part of the problem that we can while the Web Security folk work on understanding the complexities of what strict security involves. > Perhaps a solution is to implement your own application-specific trust root > that doesn't rely on the current profusion of CAs. But as an application > developer I can attest to the fact that it's difficult to use standard > platform TLS libraries without also trusting everything in the system root > store, too. Some sites will insist on using their own in-house CAs too, > which is fine, but it's further pressure on everything else to integrate/be > vulnerable with the browser trust model. > Yes and that may well end up motivating a mechanism to allow for protocol specific path properties so that enterprises can have separate CAs authorized for separate protocols. Web Services security is a big part of what I am interested in supporting here. We went into the Web Services world with certain interests promoting UDDI as the central directory to make it all work. So now we have a protocol stack predicated on the existence of a directory with no directory to work with. I have some ideas there, but again, that would be crossing the streams at this point. I think the way to get traction there will be to propose a Web Service application with some pretty severe security requirements and make that the test application for a framework designed to 'do it right'. -- Website: http://hallambaker.com/ --0016368e1f855969d804a4bd2a38 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jun 2, 2011 at 12:07 PM, Marsh R= ay <marsh@= extendedsubset.com> wrote:
On 06/02/2011 08:45 AM, Phillip Hallam-Baker wrote:

At the end of the day buffer over-run exploits will still trump any
deficiencies in the CA infrastructure. But those don't have people
running round suggesting urgent remedies because they are too common to
bear notice. CAs and RAs are definitely not the weakest link in the
chain here. Anyone claiming that is either grandstanding or has failed
to pay attention.

Well that depends entirely on the chain in question doesn't it?

Not everything that uses TLS or certificates is an unpatched web browser wi= th Adobe plugins operated by an ignorant user for the purpose of securing n= othing particularly important.

I hear y= ou.

But lets be realistic here, we are currently actually d= oing worse for non browser security.=A0

The weakes= t link in the TLS protocol is actually the end user who is for some bizarre= reason expected to be looking for padlock icons and green bars and know wh= en to look for which one.

This is even more problematic when applying TLS to Web = services as there isn't even a user to make the decision and no real id= ea of what should do that instead.


CAA is not going to solve every problem associated with trust on the Intern= et and CA infrastructure. Nor is TLS and nor is strict security. But I do t= hink that a combination of those three ideas can make a major step forward.=

That is why CAA is designed to be arbitrarily extensibl= e with a tag-value format even though there are only two property tags curr= ently defined. I really like the work that Paypal and Jeff Hodges have been= doing and would like to have a way to eventually bring CAA into alignment = there.


But for the moment we have to avoid '= ;crossing the streams' as Stephen F. put it to me.=A0

Lets work on the part of the problem that we can while the Web Secu= rity folk work on understanding the complexities of what strict security in= volves.


=A0
Perhaps a solution is to implement your own application-specific trust root= that doesn't rely on the current profusion of CAs. But as an applicati= on developer I can attest to the fact that it's difficult to use standa= rd platform TLS libraries without also trusting everything in the system ro= ot store, too. Some sites will insist on using their own in-house CAs too, = which is fine, but it's further pressure on everything else to integrat= e/be vulnerable with the browser trust model.

Yes and that may well end up motivating a = mechanism to allow for protocol specific path properties so that enterprise= s can have separate CAs authorized for separate protocols.=A0
Web Services security is a big part of what I am interested in s= upporting here. We went into the Web Services world with certain interests = promoting UDDI as the central directory to make it all work. So now we have= a protocol stack predicated on the existence of a directory with no direct= ory to work with.


I have some ideas there, but again, that= would be crossing the streams at this point. I think the way to get tracti= on there will be to propose a Web Service application with some pretty seve= re security requirements and make that the test application for a framework= designed to 'do it right'.=A0

--0016368e1f855969d804a4bd2a38-- From pgut001@login01.cs.auckland.ac.nz Thu Jun 2 19:55:38 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E2FE06D7; Thu, 2 Jun 2011 19:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ALziVOGGYE9; Thu, 2 Jun 2011 19:55:37 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id ABB7CE074C; Thu, 2 Jun 2011 19:55:35 -0700 (PDT) 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=1307069737; x=1338605737; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20hallam@gmail.com,=20ynir@checkpoint.com|Subject: =20Re:=20[TLS]=20[pkix]=20Proposing=20CAA=20as=20PKIX=20W orking=20Group=20Item|Cc:=20paul.hoffman@vpnc.org,=20pkix @ietf.org,=20tls@ietf.org|In-Reply-To:=20<7043B742-0AAA-4 875-8642-764E7F41DFD5@checkpoint.com>|Message-Id:=20|Date:=20Fri,=20 03=20Jun=202011=2014:55:34=20+1200; bh=wnYdBq8MBiWbHSTxGA5aGMJ1ClVLNjOAbWIyKY86+Lc=; b=MpP6lzJ+ov61iJ3+mYxQ2Eh+rMeTio0i36eT/FrhSToqMIgyzJIzmLyv iuVXD5khWhKZfZymM+WCCH0eilB50KwyewXeXy4I6pPUDAHCD5M+6fRYr biyLVTXqmyU2wt3YAgqR0ZpkxixSD8x1kMoAP8mF6TU0lfuqRPwGgLyXi k=; X-IronPort-AV: E=Sophos;i="4.65,313,1304251200"; d="scan'208";a="65395569" 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; 03 Jun 2011 14:55:34 +1200 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 1QSKXu-00061N-Gc; Fri, 03 Jun 2011 14:55:34 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QSKXu-0000S2-2s; Fri, 03 Jun 2011 14:55:34 +1200 From: Peter Gutmann To: hallam@gmail.com, ynir@checkpoint.com In-Reply-To: <7043B742-0AAA-4875-8642-764E7F41DFD5@checkpoint.com> Message-Id: Date: Fri, 03 Jun 2011 14:55:34 +1200 Cc: pkix@ietf.org, paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 02:55:38 -0000 Yoav Nir writes: >In late 2008, when some researchers got RapidSSL to sign a certificate >request that collided with their rogue sub-CA certificate, several things >came to light: > - They were a ridiculously small company, with the only full-time employee. >An accountant I wasn't aware of this one, do you have any pointers to info on this? I guess a Webtrust audit doesn't check whether you have more than a single employee :-). Peter. From marsh@extendedsubset.com Thu Jun 2 20:54:08 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0362DE07A3; Thu, 2 Jun 2011 20:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0GWUXR3ACr8; Thu, 2 Jun 2011 20:54:07 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9D2E0678; Thu, 2 Jun 2011 20:54:07 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1QSLST-000P6T-Fv; Fri, 03 Jun 2011 03:54:01 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id D66AE601A; Fri, 3 Jun 2011 03:53:58 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18is+iucigW3xeJKZDAYuxJ2Ihv2PXGOsI= Message-ID: <4DE85AD7.8010407@extendedsubset.com> Date: Thu, 02 Jun 2011 22:53:59 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: paul.hoffman@vpnc.org, tls@ietf.org, pkix@ietf.org Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 03:54:08 -0000 On 06/02/2011 09:55 PM, Peter Gutmann wrote: > Yoav Nir writes: > >> In late 2008, when some researchers got RapidSSL to sign a certificate >> request that collided with their rogue sub-CA certificate, several things >> came to light: >> - They were a ridiculously small company, with the only full-time employee. >> An accountant > > I wasn't aware of this one, do you have any pointers to info on this? I guess > a Webtrust audit doesn't check whether you have more than a single employee :-). I think he's referring to Stevens, Sotirov, et al. 2008 http://www.win.tue.nl/hashclash/rogue-ca/ which I'm sure you heard about. I hadn't heard the part about the single employee though. - Marsh From pgut001@login01.cs.auckland.ac.nz Thu Jun 2 21:03:24 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6AAE0678; Thu, 2 Jun 2011 21:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.363 X-Spam-Level: X-Spam-Status: No, score=-3.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3SuT3RVD6Nf; Thu, 2 Jun 2011 21:03:23 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 146C3E0674; Thu, 2 Jun 2011 21:03:20 -0700 (PDT) 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=1307073803; x=1338609803; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20marsh@extendedsubset.com,=20pgut001@cs.auckland.ac .nz|Subject:=20Re:=20[pkix]=20[TLS]=20=20Proposing=20CAA =20as=20PKIX=20Working=20Group=20Item|Cc:=20paul.hoffman@ vpnc.org,=20pkix@ietf.org,=20tls@ietf.org|In-Reply-To:=20 <4DE85AD7.8010407@extendedsubset.com>|Message-Id:=20|Date:=20Fri,=20 03=20Jun=202011=2016:03:19=20+1200; bh=OhN/axvzIYTiy73X7OYil9R21Prk+br2xAWp9hNOXoo=; b=dFzfLDrYfzTaiPdvNpVNAFAsAgifUz4y+SML3svMswbBOSoaW3O7rJ8P HYL0kqoj/0yp/TBgc45SfqVatwHLrTRZmVmwCJ9Yqk4LzDeD2+rJxiVup 1luQeM/VB8JSoQQMsw9W0tFAp55Ulp9g65R+MxHGLSzcWR50BUl91DwpG w=; X-IronPort-AV: E=Sophos;i="4.65,313,1304251200"; d="scan'208";a="65450460" 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; 03 Jun 2011 16:03:20 +1200 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 1QSLbT-0000NU-J8; Fri, 03 Jun 2011 16:03:19 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QSLbT-000401-SQ; Fri, 03 Jun 2011 16:03:19 +1200 From: Peter Gutmann To: marsh@extendedsubset.com, pgut001@cs.auckland.ac.nz In-Reply-To: <4DE85AD7.8010407@extendedsubset.com> Message-Id: Date: Fri, 03 Jun 2011 16:03:19 +1200 Cc: pkix@ietf.org, paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 04:03:24 -0000 Marsh Ray writes: >I hadn't heard the part about the single employee though. That's the bit I hadn't heard before. Sounds a bit minimal for a commercial CA. Perhaps the OP confused it with Honest Achmed. Peter. From n.mavrogiannopoulos@gmail.com Fri Jun 3 00:27:14 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5A8E0665 for ; Fri, 3 Jun 2011 00:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzo39i2BYwXC for ; Fri, 3 Jun 2011 00:27:13 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 82ED3E0662 for ; Fri, 3 Jun 2011 00:27:13 -0700 (PDT) Received: by wwa36 with SMTP id 36so926929wwa.13 for ; Fri, 03 Jun 2011 00:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=/ydD7VEKrCLN5wsR7LSjgVPhsT4FmAkK1BV9ApHkdho=; b=tWW7aEls9BYcO0Q3Btb7mZ65XreDdBeMknWMIkNgkquCRHUAnfKfvnfKbe97ARPQM8 VlKghxtuCBJPJiUfxzQ34/phEbjjDaa2JvZz2SDBKRkpWSQlAoZzn/lJw2J6VvtLk2o8 u5SHdWd0XEgCKx8LRQ5bm/vw91ZlyH0YWkiUQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=fyuKipzp64Fp1IhB8SWqi1KhgizIZQwSWtlosrWDyq9+nU0JJ3h/Dj16mNCl7M0Eie qjELgvlRpc7nF090JflZlISLyHMZsz1YcFWE17UCv44JZ3v1fMzDi++W0EMONiHUaoU0 Ed6QYjXXU/fcYegTNHMqEkhsMI4wKgNB/8QDU= Received: by 10.217.7.72 with SMTP id z50mr1486051wes.60.1307086032485; Fri, 03 Jun 2011 00:27:12 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id w10sm667370weq.27.2011.06.03.00.27.10 (version=SSLv3 cipher=OTHER); Fri, 03 Jun 2011 00:27:11 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4DE88CCD.5010303@gnutls.org> Date: Fri, 03 Jun 2011 09:27:09 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: "tls@ietf.org" X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] tls with DSA and ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 07:27:14 -0000 Hello, I've submitted: http://tools.ietf.org/html/draft-mavrogiannopoulos-tls-dss-00 The purpose is to define choices for the hash algorithm to be used for the TLS handshake and eventually make the hash algorithm selection for the DSS signature standard deterministic. That is because DSS as a standard allows the usage of any SHAx hash function truncated or not. For example given 256-bit curve, I could use SHA-256, or SHA-384 truncated to 256 bits, or SHA-512 truncated to 256 bits, to sign. This document tries to restrict the choices to promote interoperability. This is in line with rfc5480 that does the same thing for PKIX ECDSA certificates. regards, Nikos From agl@google.com Fri Jun 3 11:45:32 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C2CE07AB for ; Fri, 3 Jun 2011 11:45:32 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rk+gRR1TqDFO for ; Fri, 3 Jun 2011 11:45:32 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 19EADE06BF for ; Fri, 3 Jun 2011 11:45:31 -0700 (PDT) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id p53IjKXr026299 for ; Fri, 3 Jun 2011 11:45:21 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307126725; bh=ncr3uMXfTvA1cCuGi69mebNnacE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=l0Z5j37zUbBR8KEjR5xNuteKCff2OhCUCXetVY0VJGfEjhvTSQOGKRjxnEM0ocgWL rlzoDC8/6fIrehnu7zmMQ== Received: from gwj16 (gwj16.prod.google.com [10.200.10.16]) by kpbe13.cbf.corp.google.com with ESMTP id p53IicDM032489 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 3 Jun 2011 11:45:19 -0700 Received: by gwj16 with SMTP id 16so1193883gwj.23 for ; Fri, 03 Jun 2011 11:45:19 -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=Jgr8ihov9LwsYeX4Mv4Go+ZEooHcIjgwgKxx+EEIpsU=; b=pR20bevupYP50UtxQ4LsY9fii772QOSJti5xmco9dlN9ff8ECkU67wsFEU+tvenlKs 4TeRwku/cDFJqBz4wmbQ== 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=iroMrFFmShgRmDUDXdgdiqLF64Et1lHBOiu0sXfXHw6fERB1nouIf+lrtIdU4QKCxM /SmEHuLwI9sadEllYz2A== MIME-Version: 1.0 Received: by 10.150.48.28 with SMTP id v28mr2298930ybv.428.1307126719308; Fri, 03 Jun 2011 11:45:19 -0700 (PDT) Received: by 10.150.177.1 with HTTP; Fri, 3 Jun 2011 11:45:19 -0700 (PDT) In-Reply-To: <4DE88CCD.5010303@gnutls.org> References: <4DE88CCD.5010303@gnutls.org> Date: Fri, 3 Jun 2011 14:45:19 -0400 Message-ID: From: Adam Langley To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tls@ietf.org" Subject: Re: [TLS] tls with DSA and ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 18:45:33 -0000 On Fri, Jun 3, 2011 at 3:27 AM, Nikos Mavrogiannopoulos w= rote: > Hello, > =C2=A0I've submitted: > http://tools.ietf.org/html/draft-mavrogiannopoulos-tls-dss-00 Looks good to me. AGL From n.mavrogiannopoulos@gmail.com Fri Jun 3 12:30:14 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F238E07D9 for ; Fri, 3 Jun 2011 12:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECIPDiEdcKz4 for ; Fri, 3 Jun 2011 12:30:14 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C73F8E07B7 for ; Fri, 3 Jun 2011 12:30:13 -0700 (PDT) Received: by wyb29 with SMTP id 29so1919965wyb.31 for ; Fri, 03 Jun 2011 12:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=YUsMivq3xT/JAlluBjgdvDl9/C+mOeMosTMKIVyheX4=; b=IvIxR64G9w5+logo/pOjpGXPgVxk9IbX+WQqvqcj2w7KP5M8gO6HoTM5CVS14QSzll LwCvZpecw4N/uMPtcXw3La2tdQeXxkXWKtPiyjNZu1b6M2amDUMDls7SI/rQGLiGTwOF 2SoJafWqip/ZLLb+0/TjhCqYMqwC1UgBToAtc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=egYzumwbo/jOKBlGAspB/Sclp7lQ130HxnjfnfsTxyTg9OcIeL2RYL0zWL8srFQQ8T t42O8j2jkTC7X3drZnC0+e4EBZ0FvPvOtMqpg+jZX+wCFm84XGzssck2C2kCNErTQyRx 2ibhECjhnscZZZJzK9AvFwwfsyZLyyHqxUeuk= Received: by 10.216.174.195 with SMTP id x45mr1102881wel.64.1307129412762; Fri, 03 Jun 2011 12:30:12 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id fm14sm1239373wbb.24.2011.06.03.12.30.10 (version=SSLv3 cipher=OTHER); Fri, 03 Jun 2011 12:30:10 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4DE93640.1030301@gnutls.org> Date: Fri, 03 Jun 2011 21:30:08 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Eric Rescorla References: <4DDA70B6.9030203@gnutls.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Final (hopefully) issues with DTLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 19:30:14 -0000 On 05/30/2011 05:38 PM, Eric Rescorla wrote: > The effect of this restriction is to require the client to send the > same ClientHello > (except with the cookie that he sent initially). This maps to the TLS semantics > where there is only a single ClientHello message sent which is processed > immediately. IMO this makes analysis easier since it makes DTLS behave > more like TLS. > There's no need for the server to do any negotiation at this point, > it should simply generate a HelloVerifyRequest with the highest matching > version (regardless of cipher suite considerations) and then process the > ClientHello de novo [after checking for matching parameters.] Yes, this leaves > open the possibility that the handshake will eventually negotiate to some yet > lower TLS version, but that's what happens in one round trip with TLS. I > would be happy to add a note to the effect that a yet lower version might > be negotiated. Though note that it's arguable that RFC 5246 S 7.4.1.3 > prohibits conditioning version on ciphersuite even for TLS "This field > will contain the lower of that suggested by the client > in the client hello and the highest supported by the server. For this > version of the specification, the version is 3.3. (See > Appendix E for details about backward compatibility.)" My implementation of this HelloVerifyRequest was made without using or allocating server state. That means it doesn't even know which (DTLS) protocols are enabled or not. It could even be implemented in a totally different subsystem (a firewall) in front of the server. Thus it might not know information the server knows. For me this packet should be as simple as possible. Using a fixed DTLS version would satisfy this goal. I see no benefit from doing the DTLS version number negotiation at this "stateless" point. regards, Nikos From ekr@rtfm.com Fri Jun 3 13:09:41 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159C2E07A9 for ; Fri, 3 Jun 2011 13:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27LhS3CWq4io for ; Fri, 3 Jun 2011 13:09:40 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 11FD5E06BF for ; Fri, 3 Jun 2011 13:09:39 -0700 (PDT) Received: by wwa36 with SMTP id 36so1389520wwa.13 for ; Fri, 03 Jun 2011 13:09:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.64.209 with SMTP id c59mr5757397wed.41.1307131779007; Fri, 03 Jun 2011 13:09:39 -0700 (PDT) Received: by 10.216.163.143 with HTTP; Fri, 3 Jun 2011 13:09:38 -0700 (PDT) In-Reply-To: <4DE93640.1030301@gnutls.org> References: <4DDA70B6.9030203@gnutls.org> <4DE93640.1030301@gnutls.org> Date: Fri, 3 Jun 2011 13:09:38 -0700 Message-ID: From: Eric Rescorla To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Final (hopefully) issues with DTLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 20:09:41 -0000 On Fri, Jun 3, 2011 at 12:30 PM, Nikos Mavrogiannopoulos wrote: > On 05/30/2011 05:38 PM, Eric Rescorla wrote: > >> The effect of this restriction is to require the client to send the >> same ClientHello >> (except with the cookie that he sent initially). This maps to the TLS se= mantics >> where there is only a single ClientHello message sent which is processed >> immediately. IMO this makes analysis easier since it makes DTLS behave >> more like TLS. >> There's no need for the server to do any negotiation at this point, >> it should simply generate a HelloVerifyRequest with the highest matching >> version (regardless of cipher suite considerations) and then process the >> ClientHello de novo [after checking for matching parameters.] Yes, this = leaves >> open the possibility that the handshake will eventually negotiate to som= e yet >> lower TLS version, but that's what happens in one round trip with TLS. I >> would be happy to add a note to the effect that a yet lower version migh= t >> be negotiated. Though note that it's arguable that RFC 5246 S 7.4.1.3 >> prohibits conditioning version on ciphersuite even for TLS "This field >> will contain the lower of that suggested by the client >> in the client hello and the highest supported by the server. =A0For this >> version of the specification, the version is 3.3. =A0(See >> Appendix E for details about backward compatibility.)" > > My implementation of this HelloVerifyRequest was made without using or > allocating server state. That means it doesn't even know which (DTLS) > protocols are enabled or not. It could even be implemented in a > totally different subsystem (a firewall) in front of the server. Thus it > might not know information the server knows. For me this packet > should be as simple as possible. Using a fixed DTLS version would > satisfy this goal. I see no benefit from doing the DTLS version number > negotiation at this "stateless" point. I don't see a problem with the server echoing the client's version number here. Does anyone disagree with making an explicit exemption in the spec for that? -Ekr From n.mavrogiannopoulos@gmail.com Fri Jun 3 14:16:59 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B96CE07CA for ; Fri, 3 Jun 2011 14:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5xuzJ0UWwTK for ; Fri, 3 Jun 2011 14:16:58 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3DED3E07C2 for ; Fri, 3 Jun 2011 14:16:58 -0700 (PDT) Received: by wwk4 with SMTP id 4so5475727wwk.1 for ; Fri, 03 Jun 2011 14:16:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=tgCdCFDGMB1T1hqX6zBi9p1aNf40R7/gm5++gSMZvGs=; b=nOKLvJy2GGsyucU9ynG3v0TuJAjiRIvZA5tWnBtTu+6lwp9vJhQtTdtYyh7+y9bGNJ fmmNrFFfrFPIlSEjJkXwMUe2WyHbQBrW4SXGpfMW8s2QttJFcTkVmfeaYKMX5KNgbDyi U+p34jl9ht2hOs9qm9wYWSGgIjYiONZ0iafPE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=pLqTE4AVXBzW+XMu409F8DEaKuvBoOo9DbH7Lpe8VS7ky5h9Os/uqGAlfiMEzjvB4Y sT7JzqbQksO/iqm7ILo/L4RNd6fKiCCB5zXBlJSmQ/57ekSqg6VqNSNY7oGM0zMrF0g4 KqpBQQ56fFOgTT7YhQeaNPji/Sv5aOHVNAwVI= Received: by 10.216.144.2 with SMTP id m2mr2183037wej.114.1307135816871; Fri, 03 Jun 2011 14:16:56 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id f60sm1050071wef.37.2011.06.03.14.16.55 (version=SSLv3 cipher=OTHER); Fri, 03 Jun 2011 14:16:55 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4DE94F46.6050406@gnutls.org> Date: Fri, 03 Jun 2011 23:16:54 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Eric Rescorla References: <4DDA70B6.9030203@gnutls.org> <4DE93640.1030301@gnutls.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Final (hopefully) issues with DTLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 21:16:59 -0000 On 06/03/2011 10:09 PM, Eric Rescorla wrote: >> My implementation of this HelloVerifyRequest was made without using or >> allocating server state. That means it doesn't even know which (DTLS) >> protocols are enabled or not. It could even be implemented in a >> totally different subsystem (a firewall) in front of the server. Thus it >> might not know information the server knows. For me this packet >> should be as simple as possible. Using a fixed DTLS version would >> satisfy this goal. I see no benefit from doing the DTLS version number >> negotiation at this "stateless" point. > I don't see a problem with the server echoing the client's version number > here. Does anyone disagree with making an explicit exemption in the spec > for that? By reflecting the version back you lose the ability to use a different format later on (under another version number). It might be better to just fix it to a protocol number, e.g. DTLS 1.0, and if the format changes then some other number is used. regards, Nikos From ynir@checkpoint.com Sat Jun 4 23:54:03 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FB321F8445; Sat, 4 Jun 2011 23:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZP4WUEOhMt6; Sat, 4 Jun 2011 23:54:02 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id EF51021F8444; Sat, 4 Jun 2011 23:54:01 -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 p556redl021536; Sun, 5 Jun 2011 09:53:41 +0300 X-CheckPoint: {4DEB347F-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; Sun, 5 Jun 2011 09:53:40 +0300 From: Yoav Nir To: Peter Gutmann Date: Sun, 5 Jun 2011 09:53:41 +0300 Thread-Topic: [TLS] [pkix] Proposing CAA as PKIX Working Group Item Thread-Index: AcwjTUzaSKIvgKIwQTaLFKFXCxvBOw== Message-ID: <81856AC0-F6FB-4321-93FE-559D5C5E2743@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: "pkix@ietf.org" , "paul.hoffman@vpnc.org" , "tls@ietf.org" Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 06:54:03 -0000 On Jun 3, 2011, at 5:55 AM, Peter Gutmann wrote: > Yoav Nir writes: >=20 >> In late 2008, when some researchers got RapidSSL to sign a certificate >> request that collided with their rogue sub-CA certificate, several thing= s >> came to light: >> - They were a ridiculously small company, with the only full-time employ= ee. >> An accountant >=20 > I wasn't aware of this one, do you have any pointers to info on this? I = guess=20 > a Webtrust audit doesn't check whether you have more than a single employ= ee :-). >=20 > Peter. I'm not sure where I've read it. Probably some blog entry about the inciden= t. Not Bruce Schneier's because his entries are still online.=20 Anyway, checking the data for now, Business Week has this: http://investing.businessweek.com/research/stocks/private/people.asp?privca= pId=3D20888814 It lists two "key executives", VP Marketing and VP Sales and no CEO/Preside= nt. Click their links, and both have other jobs at Globalsign and other com= panies. The key issue is the total lack of in-house expertise. Late in 2008, it was= n't RapidSSL that switched to MD5. Verisign did it for them: http://www.thetechherald.com/article.php/200852/2708/VeriSign-replaces-Rapi= dSSL-certificates From geoffk@geoffk.org Sun Jun 5 01:45:01 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4E021F8491; Sun, 5 Jun 2011 01:45: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acJVPe3Mjbum; Sun, 5 Jun 2011 01:45:00 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id D47D121F8490; Sun, 5 Jun 2011 01:45:00 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id C0CB333D18D; Sun, 5 Jun 2011 08:44:58 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Yoav Nir References: <81856AC0-F6FB-4321-93FE-559D5C5E2743@checkpoint.com> From: Geoffrey Keating Date: 05 Jun 2011 01:44:58 -0700 In-Reply-To: <81856AC0-F6FB-4321-93FE-559D5C5E2743@checkpoint.com> Message-ID: Lines: 24 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "pkix@ietf.org" , "tls@ietf.org" Subject: Re: [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 08:45:01 -0000 Yoav Nir writes: > Yoav Nir writes: > >> In late 2008, when some researchers got RapidSSL to sign a certificate >> request that collided with their rogue sub-CA certificate, several things >> came to light: >> - They were a ridiculously small company, with the only full-time employee. >> An accountant ... > I'm not sure where I've read it. Probably some blog entry about the incident. Not Bruce Schneier's because his entries are still online. > > Anyway, checking the data for now, Business Week has this: > http://investing.businessweek.com/research/stocks/private/people.asp?privcapId=20888814 > > It lists two "key executives", VP Marketing and VP Sales and no CEO/President. Click their links, and both have other jobs at Globalsign and other companies. > > The key issue is the total lack of in-house expertise. Late in 2008, it wasn't RapidSSL that switched to MD5. Verisign did it for them: > http://www.thetechherald.com/article.php/200852/2708/VeriSign-replaces-RapidSSL-certificates RapidSSL is owned by GeoTrust which at the time was owned by VeriSign (thus the press release), and now by Symantec. It wouldn't surprise me if RapidSSL itself has no employees at all. I don't think Business Week's data is reliable in this case. From koichi.sugimoto@globalsign.com Mon Jun 6 18:32:02 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A762311E8096; Mon, 6 Jun 2011 18:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DEAR_SOMETHING=1.605, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTXsdE5lYO9x; Mon, 6 Jun 2011 18:32:01 -0700 (PDT) Received: from mail-pz0-f66.google.com (mail-pz0-f66.google.com [209.85.210.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5F59011E8090; Mon, 6 Jun 2011 18:32:01 -0700 (PDT) Received: by pzk7 with SMTP id 7so449896pzk.1 for ; Mon, 06 Jun 2011 18:32:00 -0700 (PDT) Received: by 10.68.22.231 with SMTP id h7mr24678pbf.25.1307410320794; Mon, 06 Jun 2011 18:32:00 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id o2sm4076833pbj.65.2011.06.06.18.32.00 (version=SSLv3 cipher=OTHER); Mon, 06 Jun 2011 18:32:00 -0700 (PDT) Received: by pzk5 with SMTP id 5so2448373pzk.31 for ; Mon, 06 Jun 2011 18:32:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.17.129 with SMTP id o1mr2256205pbd.178.1307410320002; Mon, 06 Jun 2011 18:32:00 -0700 (PDT) Received: by 10.68.52.166 with HTTP; Mon, 6 Jun 2011 18:31:59 -0700 (PDT) In-Reply-To: <81856AC0-F6FB-4321-93FE-559D5C5E2743@checkpoint.com> References: <81856AC0-F6FB-4321-93FE-559D5C5E2743@checkpoint.com> Date: Tue, 7 Jun 2011 10:31:59 +0900 Message-ID: From: koichi sugimoto To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 07 Jun 2011 09:05:03 -0700 Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" , "tls@ietf.org" Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 01:32:02 -0000 Dear Sirs, I've heard the fact was as follows: ------------------------------------------------------------------------- Paul Tourret and Steve Waite were independent agents assigned the responsibility of sales and marketing for the RapidSSL brand, acting under a company called Certification Services Ltd (CSL). Verisign served termination notice to CSL immediately after the announcement of the GeoTrust acquisition. CSL then later changed its name to GlobalSign Limited following successful acquisition of GlobalSign NV. RapidSSL.com was, and always had been, an SSL brand owned in full by GeoTrust Inc. GeoTrust elected to represent the brand as a business unit and as mentioned above, Paul Tourret and Steve Waite were assigned as "agents" to promote the brand. All root Certificates and infrastructure was maintained and operated alongside the GeoTrust branded roots and in infrastructure operated by GeoTrust Inc. In 2006 VeriSign acquired GeoTrust and all its assets, including the RapidSSL brand and root Certificates. Paul and Steve ceased their relationship with GeoTrust (now owned by VeriSign) in late 2006. At the time of the rogue issuance of RapidSSL root Certificates, ownership and infrastructure of maintenance had been under VeriSign's control for over 2 years. To be clear, VeriSign did not switch away from MD5 on behalf of RapidSSL, RapidSSL is just a product brand (not a company) owned in full by VeriSign. ---------------------------------------------------------------------------= --------------- Regards, Koichi Sugimoto. 2011/6/5 Yoav Nir : > > On Jun 3, 2011, at 5:55 AM, Peter Gutmann wrote: > >> Yoav Nir writes: >> >>> In late 2008, when some researchers got RapidSSL to sign a certificate >>> request that collided with their rogue sub-CA certificate, several thin= gs >>> came to light: >>> - They were a ridiculously small company, with the only full-time emplo= yee. >>> An accountant >> >> I wasn't aware of this one, do you have any pointers to info on this? = =A0I guess >> a Webtrust audit doesn't check whether you have more than a single emplo= yee :-). >> >> Peter. > > I'm not sure where I've read it. Probably some blog entry about the incid= ent. Not Bruce Schneier's because his entries are still online. > > Anyway, checking the data for now, Business Week has this: > http://investing.businessweek.com/research/stocks/private/people.asp?priv= capId=3D20888814 > > It lists two "key executives", VP Marketing and VP Sales and no CEO/Presi= dent. Click their links, and both have other jobs at Globalsign and other c= ompanies. > > The key issue is the total lack of in-house expertise. Late in 2008, it w= asn't RapidSSL that switched to MD5. Verisign did it for them: > http://www.thetechherald.com/article.php/200852/2708/VeriSign-replaces-Ra= pidSSL-certificates > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From pgut001@login01.cs.auckland.ac.nz Tue Jun 7 23:56:34 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1328611E807E; Tue, 7 Jun 2011 23:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FcCxblZTNEM; Tue, 7 Jun 2011 23:56:33 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id EE9B511E8071; Tue, 7 Jun 2011 23:56:30 -0700 (PDT) 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=1307516193; x=1339052193; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20mike-list@pobox.com,=20ynir@checkpoint.com |Subject:=20Re:=20[TLS]=20[pkix]=20Proposing=20CAA=20as =20PKIX=20Working=20Group=20Item|Cc:=20paul.hoffman@vpnc. org,=20pkix@ietf.org,=20tls@ietf.org|In-Reply-To:=20<7A11 CFD1-F0AA-4CA4-8542-CA7998D2FBEF@checkpoint.com> |Message-Id:=20|Date:=20Wed,=2008=20Jun=202011=2018:56:23=20+1200; bh=O2tUc5o3a1E/NNKVf+HeDFmU3abPphITTo9tj1TPDj8=; b=lL8OFgSwQioBqRlDcMGvE+r8FVz0DKpkNT6JRHoDlgnRmfbdNzGk9NnX FlfF4cUmOw8h+q9PYt5nMA0qvlUEQgc/eyAzM5vo4v2kCxNaN/y2uoZOI Xw5BCj+mjHJ33smCQqgRYSG2NIPXutnxxGUE27eziJ+zGGLGWzUwja1Wh M=; X-IronPort-AV: E=Sophos;i="4.65,337,1304251200"; d="scan'208";a="66155298" 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 Jun 2011 18:56:23 +1200 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 1QUCgh-0007ro-IA; Wed, 08 Jun 2011 18:56:23 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QUCgh-0005Mx-J4; Wed, 08 Jun 2011 18:56:23 +1200 From: Peter Gutmann To: mike-list@pobox.com, ynir@checkpoint.com In-Reply-To: <7A11CFD1-F0AA-4CA4-8542-CA7998D2FBEF@checkpoint.com> Message-Id: Date: Wed, 08 Jun 2011 18:56:23 +1200 Cc: pkix@ietf.org, paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 06:56:34 -0000 Yoav Nir writes: >CAA works if all root CAs and affiliates follow it. That's hundreds or >thousands of entities. Any one of them that fails to comply might ignore the >CAA record. That was my problem with it, any CA (and/or RA) that's already diligent about cert issuance doesn't need CAA, and any one that isn't won't use it anyway, so it doesn't address any existing problem. Peter. From ynir@checkpoint.com Wed Jun 8 00:31:03 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E680121F8476; Wed, 8 Jun 2011 00:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.496 X-Spam-Level: X-Spam-Status: No, score=-8.496 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, DEAR_SOMETHING=1.605, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sm47PD2AzLe2; Wed, 8 Jun 2011 00:31:03 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E7C8121F8475; Wed, 8 Jun 2011 00:31:01 -0700 (PDT) X-CheckPoint: {4DEF3337-3-1B221DC2-FFFF} 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 p587Tbhb017894; Wed, 8 Jun 2011 10:29:37 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 8 Jun 2011 10:29:36 +0300 From: Yoav Nir To: koichi sugimoto Date: Wed, 8 Jun 2011 10:29:35 +0300 Thread-Topic: [pkix] [TLS] Proposing CAA as PKIX Working Group Item Thread-Index: AcwlrdFQ52d6dZUqTy+rISP51yR8yw== Message-ID: References: <81856AC0-F6FB-4321-93FE-559D5C5E2743@checkpoint.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: "pkix@ietf.org" , "paul.hoffman@vpnc.org" , "tls@ietf.org" Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 07:31:04 -0000 On Jun 7, 2011, at 4:31 AM, koichi sugimoto wrote: > Dear Sirs, >=20 > I've heard the fact was as follows: >=20 > ------------------------------------------------------------------------- > Paul Tourret and Steve Waite were independent agents assigned the > responsibility of sales and marketing for the RapidSSL brand, acting unde= r > a company called Certification Services Ltd (CSL). Verisign served > termination notice to CSL immediately after the announcement of the > GeoTrust acquisition. CSL then later changed its name to GlobalSign > Limited following successful acquisition of GlobalSign NV. RapidSSL.com > was, and always had been, an SSL brand owned in full by GeoTrust Inc. > GeoTrust elected to represent the brand as a business unit and as > mentioned above, Paul Tourret and Steve Waite were assigned as "agents" t= o > promote the brand. All root Certificates and infrastructure was > maintained and operated alongside the GeoTrust branded roots and in > infrastructure operated by GeoTrust Inc. In 2006 VeriSign acquired > GeoTrust and all its assets, including the RapidSSL brand and root > Certificates. Paul and Steve ceased their relationship with GeoTrust (no= w > owned by VeriSign) in late 2006. At the time of the rogue issuance of > RapidSSL root Certificates, ownership and infrastructure of maintenance > had been under VeriSign's control for over 2 years. To be clear, VeriSig= n > did not switch away from MD5 on behalf of RapidSSL, RapidSSL is just a > product brand (not a company) owned in full by VeriSign. > -------------------------------------------------------------------------= ----------------- Thanks for this. The point remains, that the customers see only the RapidSSL brand, no sign = of Verisign on the homepage. And obviously they were running with a very di= fferent web application than other Verisign affiliates. Even as just a prod= uct brand, some people were assigned to handle the website and the CA, and = despite being owned by Verisign, those people apparently weren't doing a ve= ry good job. Yoav From ynir@checkpoint.com Wed Jun 8 00:32:57 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E95A21F8476; Wed, 8 Jun 2011 00:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.548 X-Spam-Level: X-Spam-Status: No, score=-9.548 tagged_above=-999 required=5 tests=[AWL=1.051, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+KPvno+EZ6e; Wed, 8 Jun 2011 00:32:57 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE7621F8475; Wed, 8 Jun 2011 00:32:55 -0700 (PDT) X-CheckPoint: {4DEF33AA-2-1B221DC2-FFFF} 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 p587Woog018324; Wed, 8 Jun 2011 10:32:50 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 8 Jun 2011 10:32:49 +0300 From: Yoav Nir To: Peter Gutmann Date: Wed, 8 Jun 2011 10:32:48 +0300 Thread-Topic: [TLS] [pkix] Proposing CAA as PKIX Working Group Item Thread-Index: AcwlrkRXTAB8wUHGRnqB4ujQJkVunw== Message-ID: <6201F47E-26F1-43F0-839B-78D1360D2EC4@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: "pkix@ietf.org" , "paul.hoffman@vpnc.org" , "tls@ietf.org" Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 07:32:57 -0000 On Jun 8, 2011, at 9:56 AM, Peter Gutmann wrote: > Yoav Nir writes: >=20 >> CAA works if all root CAs and affiliates follow it. That's hundreds or >> thousands of entities. Any one of them that fails to comply might ignore= the >> CAA record. >=20 > That was my problem with it, any CA (and/or RA) that's already diligent a= bout=20 > cert issuance doesn't need CAA, and any one that isn't won't use it anywa= y, so=20 > it doesn't address any existing problem. >=20 > Peter. It would have prevented what has become known as "Comodo-gate". The attacke= r subverted an RA. If the CA was doing the CAA checking, the attacker would= be foiled. If checking the CAA is delegated to the RA, it would not help, = but the draft specifically talks about certification authorities. From pgut001@login01.cs.auckland.ac.nz Wed Jun 8 00:46:20 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995B021F8503; Wed, 8 Jun 2011 00:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-RH7m4BWMvn; Wed, 8 Jun 2011 00:46:20 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id B9E9821F8502; Wed, 8 Jun 2011 00:46:17 -0700 (PDT) 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=1307519180; x=1339055180; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20pgut001@cs.auckland.ac.nz,=20ynir@checkpoint.com |Subject:=20Re:=20[TLS]=20[pkix]=20Proposing=20CAA=20as =20PKIX=20Working=20Group=20Item|Cc:=20mike-list@pobox.co m,=20paul.hoffman@vpnc.org,=20pkix@ietf.org,=0D=0A=20=20 =20=20tls@ietf.org|In-Reply-To:=20<6201F47E-26F1-43F0-839 B-78D1360D2EC4@checkpoint.com>|Message-Id:=20|Date:=20Wed,=2008=20Ju n=202011=2019:46:09=20+1200; bh=3TezGZHmIxV4TACv5M8PRhmDR8zo2Kp+hvi+/V+1rnY=; b=AkU5y/Xkrdiw61INRqhM2ohnIk7Y7e/PVJlSZxtnq15IOZvP2YjdS9k8 +7nDi/Gs9iC6LZy9oZOOu8T3XQ8v2X/PQv/KpAshMwOjvRdluf24N+OSj e4VgOzidfyM8eqst8lmh20W7NiUoZsvgWRJnSzZ+k/FmKfVwnHTcz7c9N w=; X-IronPort-AV: E=Sophos;i="4.65,337,1304251200"; d="scan'208";a="66158433" 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 Jun 2011 19:46:10 +1200 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 1QUDSr-0000yL-I7; Wed, 08 Jun 2011 19:46:09 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QUDSr-00081X-EE; Wed, 08 Jun 2011 19:46:09 +1200 From: Peter Gutmann To: pgut001@cs.auckland.ac.nz, ynir@checkpoint.com In-Reply-To: <6201F47E-26F1-43F0-839B-78D1360D2EC4@checkpoint.com> Message-Id: Date: Wed, 08 Jun 2011 19:46:09 +1200 Cc: pkix@ietf.org, paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 07:46:20 -0000 Yoav Nir writes: >It would have prevented what has become known as "Comodo-gate". The attacker >subverted an RA. If the CA was doing the CAA checking, the attacker would be >foiled. Uh, re-read my original text: > That was my problem with it, any CA (and/or RA) that's already diligent about > cert issuance doesn't need CAA, and any one that isn't won't use it anyway, so > it doesn't address any existing problem. What makes you class Comodo as a diligent CA? (Not wanting to re-open the Comodo bashing again, but I'd use "Comodogate" as a prime example of why CAA won't do much good). Peter. From ynir@checkpoint.com Wed Jun 8 01:38:10 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B012111E809C; Wed, 8 Jun 2011 01:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.898 X-Spam-Level: X-Spam-Status: No, score=-9.898 tagged_above=-999 required=5 tests=[AWL=0.701, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OS2GKX47gXtx; Wed, 8 Jun 2011 01:38:10 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED1411E8127; Wed, 8 Jun 2011 01:38:08 -0700 (PDT) X-CheckPoint: {4DEF42F3-3-1B221DC2-FFFF} 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 p588bkxo027984; Wed, 8 Jun 2011 11:37:51 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 8 Jun 2011 11:37:45 +0300 From: Yoav Nir To: Peter Gutmann Date: Wed, 8 Jun 2011 11:37:44 +0300 Thread-Topic: [TLS] [pkix] Proposing CAA as PKIX Working Group Item Thread-Index: Acwlt1asQvXn+f4lQqiE84ZHpQRMsQ== Message-ID: <6B039F9F-B66E-41A3-894E-8F1996A87209@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: "pkix@ietf.org" , "paul.hoffman@vpnc.org" , "tls@ietf.org" Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 08:38:10 -0000 On Jun 8, 2011, at 10:46 AM, Peter Gutmann wrote: > Yoav Nir writes: >=20 >> It would have prevented what has become known as "Comodo-gate". The atta= cker >> subverted an RA. If the CA was doing the CAA checking, the attacker woul= d be >> foiled. >=20 > Uh, re-read my original text: >=20 >> That was my problem with it, any CA (and/or RA) that's already diligent = about >> cert issuance doesn't need CAA, and any one that isn't won't use it anyw= ay, so >> it doesn't address any existing problem. >=20 > What makes you class Comodo as a diligent CA? What did Comodo fail to do? The RA is handing contact with the customer, so it's their job to make sure= that the customer is in fact the owner of the domain name in the certifica= te request. Without CAA, there's nothing left for Comodo to check. Yoav= From pgut001@login01.cs.auckland.ac.nz Wed Jun 8 01:53:30 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4EED11E811B; Wed, 8 Jun 2011 01:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgekbfE5pile; Wed, 8 Jun 2011 01:53:29 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 69AA911E8113; Wed, 8 Jun 2011 01:53:27 -0700 (PDT) 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=1307523210; x=1339059210; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20pgut001@cs.auckland.ac.nz,=20ynir@checkpoint.com |Subject:=20Re:=20[TLS]=20[pkix]=20Proposing=20CAA=20as =20PKIX=20Working=20Group=20Item|Cc:=20mike-list@pobox.co m,=20paul.hoffman@vpnc.org,=20pkix@ietf.org,=0D=0A=20=20 =20=20tls@ietf.org|In-Reply-To:=20<6B039F9F-B66E-41A3-894 E-8F1996A87209@checkpoint.com>|Message-Id:=20|Date:=20Wed,=2008=20Ju n=202011=2020:53:26=20+1200; bh=mQGmPUxcT3d2Vq0alyPtFc2lc1e5t4tBu/CJAfiYHF0=; b=jw6oCd5FlKxtHbB/8ouMEGJMc80nFlJVwGaargey2VpDVDMe3vSGlj6X cTVhHQ9JvDNJa0bD1ji8CiecJJ8uMZbk3aTWjUPbZSNazpszv7qdZbSVN 4ASton2Gp40yXvI/WoKau3CiOGquNs9VHqc4UPR8ZfB8czJ8rErKIXuvu I=; X-IronPort-AV: E=Sophos;i="4.65,337,1304251200"; d="scan'208";a="66163827" 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 Jun 2011 20:53:26 +1200 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 1QUEVy-00035c-IB; Wed, 08 Jun 2011 20:53:26 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QUEVy-0002cB-JN; Wed, 08 Jun 2011 20:53:26 +1200 From: Peter Gutmann To: pgut001@cs.auckland.ac.nz, ynir@checkpoint.com In-Reply-To: <6B039F9F-B66E-41A3-894E-8F1996A87209@checkpoint.com> Message-Id: Date: Wed, 08 Jun 2011 20:53:26 +1200 Cc: pkix@ietf.org, paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 08:53:30 -0000 Yoav Nir writes: >What did Comodo fail to do? Hmm, this could get back into the Comodo-bashing flamewar, so I'd prefer not to continue this one... see endless earlier threads on this. Peter. From n.mavrogiannopoulos@gmail.com Wed Jun 8 02:20:30 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134F911E8128 for ; Wed, 8 Jun 2011 02:20:30 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uitGYI1SZhIn for ; Wed, 8 Jun 2011 02:20:29 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4345B11E80B5 for ; Wed, 8 Jun 2011 02:20:29 -0700 (PDT) Received: by pwi5 with SMTP id 5so171525pwi.31 for ; Wed, 08 Jun 2011 02:20:29 -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=+Eg1X6iuDTrSxXl2Puaq4eGzfodji0QllpPWUqwieDM=; b=uXztkLDzgRBRVhGXlXgUrOOMpS0WRMgqVO7XqWr0owL6SuUx9zsv1HdDiCQg+P2N1x eE5xS4P9JCNElyQZB7D56+S3gnCWwO7UHAyEkfoZ7OLYZi7H57dP7z4wGC4vJw5QYV8+ m5lqj7C+Cy1YIF0e8KcN3ycDYtYdCiSkVlocU= 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=GRgZqhbd+6uavvwRdPQY+jaNPW0OlVITZzlICPFH7ZBHXt+m/PSwQfkVPGrTr/4HNQ F0C0CxY/Sbtm2BOlHFX0UuEaNYWTPbKuCNV8nLtO2JUsRQTQPe0TVFBY9AdBmrMWtyFd Xs/mhrk+ypTEBToC+XBpzpZS/rKOkHX92ZxJw= MIME-Version: 1.0 Received: by 10.143.26.12 with SMTP id d12mr235491wfj.333.1307524828824; Wed, 08 Jun 2011 02:20:28 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.142.133.9 with HTTP; Wed, 8 Jun 2011 02:20:28 -0700 (PDT) Date: Wed, 8 Jun 2011 11:20:28 +0200 X-Google-Sender-Auth: VHjTvd5qukFTulQcswf27SXT6-o Message-ID: From: Nikos Mavrogiannopoulos To: tls@ietf.org, Eric Rescorla , jsalowey@cisco.com Content-Type: text/plain; charset=UTF-8 Subject: [TLS] more TLS extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 09:20:30 -0000 Hello, I've submitted the following draft: http://datatracker.ietf.org/doc/draft-mavrogiannopoulos-tls-more-extensions/ It adds two TLS extensions, to solve two issues of the TLS protocols, that I believe they should be fixed. These are the: * Short finished message signature fixed to 12 bytes. * TLS version negotiation (fallback protocol is implicit). described previously in [0]. In the document I give more detailed description and rationale of the problems. Please consider them to be included as WG items. regards, Nikos [0]. http://www.ietf.org/mail-archive/web/tls/current/msg07633.html From hallam@gmail.com Wed Jun 8 05:56:13 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E2A21F8466; Wed, 8 Jun 2011 05:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XFGnt0X6ge1; Wed, 8 Jun 2011 05:56:12 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB57B21F8465; Wed, 8 Jun 2011 05:56:11 -0700 (PDT) Received: by gxk19 with SMTP id 19so242872gxk.31 for ; Wed, 08 Jun 2011 05:56:11 -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=4DKvSgqeqGU/20oCZl/vKyuSeqaNw/OyCxczAeSzsFI=; b=qRMpfes9zGNg28E/I1QH2y6T+uexpAy8V+veV9h80vm/4LaHyCqS1tAJ2E7VYIJx0S /ETNBV24J8ffW99fR/wuL45QKNkg3/3Hfjx5yn+33f8ksgX/cNSwx3NYl0OODln3Yqs9 AHeLQB0cRfkPzFAwEBf85qpiXKrFm+pFFgxmM= 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=D2MElVWPNwOzZXkZLYxyHEV15vKJc5+xXt54KynWpTLuf8/SXetcUnObwFa8YarBxG DLJMzkCcSBrCSxs0nQSaC2UOJsBp+Wuh3CORtHoL115a702fE9NTExY2uuaE0J9t/iuX 3oN9K+K5q4CtOD4miAN+U+skN/h4IrMFGqgiE= MIME-Version: 1.0 Received: by 10.101.200.1 with SMTP id c1mr6093068anq.63.1307537771053; Wed, 08 Jun 2011 05:56:11 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Wed, 8 Jun 2011 05:56:10 -0700 (PDT) In-Reply-To: References: <6B039F9F-B66E-41A3-894E-8F1996A87209@checkpoint.com> Date: Wed, 8 Jun 2011 08:56:10 -0400 Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann Content-Type: multipart/alternative; boundary=0016e68deca85fc31c04a532dcf1 Cc: pkix@ietf.org, paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 12:56:13 -0000 --0016e68deca85fc31c04a532dcf1 Content-Type: text/plain; charset=ISO-8859-1 First off, I think that people need to stop using the -gate suffix. Just because a competitor decided that they would attempt to apply it does not mean it is justified. That is an old game and a rather silly one in our industry. The relevant cautionary text here being John 8:7. What differentiates companies in our industry is not whether they are breached, it is whether they give prompt, voluntary notice of breaches that occur or not. The market leaders in the CA industry have a track record of having done so. As for CAA being a response to the Iranian attack, Ben, Rob and I developed it a year earlier. The point of proposals like CAA is not whether they are 'necessary' or not, it is whether they mitigate risk. I have never seen a security control involving a human element that is guaranteed to be operated with 100% accuracy every time. So whenever there are humans involved I like to have strength in depth. There would be no problem here if browsers actually implemented revocation checking either. But we have had that in PKIX specs for 15 years and it still isn't deployed in hard fail mode. Which is rather sad when you consider that about 70% of the complexity of PKI comes from the need for revocation. --0016e68deca85fc31c04a532dcf1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable First off, I think that people need to stop using the -gate suffix. Just be= cause a competitor decided that they would attempt to apply it does not mea= n it is justified. That is an old game and a rather silly one in our indust= ry. The relevant cautionary text here being John 8:7.

What differentiates companies in our industry is not wh= ether they are breached, it is whether they give prompt, voluntary notice o= f breaches that occur or not. The market leaders in the CA industry have a = track record of having done so.


As for CAA being a response to the Irani= an attack, Ben, Rob and I developed it a year earlier.

=
The point of proposals like CAA is not whether they are 'necessary= ' or not, it is whether they mitigate risk. I have never seen a securit= y control involving a human element that is guaranteed to be operated with = 100% accuracy every time. So whenever there are humans involved I like to h= ave strength in depth.=A0

There would be no problem here if browsers actually imp= lemented revocation checking either. But we have had that in PKIX specs for= 15 years and it still isn't deployed in hard fail mode. Which is rathe= r sad when you consider that about 70% of the complexity of PKI comes from = the need for revocation.
--0016e68deca85fc31c04a532dcf1-- From hallam@gmail.com Wed Jun 8 05:57:33 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A5721F852C; Wed, 8 Jun 2011 05:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dybddd2mWtha; Wed, 8 Jun 2011 05:57:32 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B0F1221F8558; Wed, 8 Jun 2011 05:56:51 -0700 (PDT) Received: by gxk19 with SMTP id 19so243199gxk.31 for ; Wed, 08 Jun 2011 05:56:51 -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=0vNTszsGe9xsKRxpYvhryin3rETsB0+1GZaEtf32eyw=; b=c7flDXWbqoo0TMwBPOkHnMVVpaA9PSqAfFD2jEZkXZh1hVrxv7uJmAcRW3NK61Mr9L TQT118dMVuK4GmbK/yjhwPoNYKkn2YDztlC2s/lP72Z00i8U0XJUmQSGIP5HTNIkQGBX ZlGDvk4rZ/DIzkQnzuoBohuyvWIhEEb7CH1Qc= 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=hHtbxP1bgl+tusyg1HM1C0XvL5AXnqnoMgTFpwoYjHauRwIjoH2ZiuBNQkg9uNVY3g LV71lk0lAi98WDqFueXyLrBle/aA8qsI5LHF/7ybHifChNPQ2NUwoDcN4U0dHPyQZHJD cQgGUccKnxGKK2ONtvNSWbwMlT/b4ATWI4nz8= MIME-Version: 1.0 Received: by 10.101.74.10 with SMTP id b10mr5965109anl.107.1307537811157; Wed, 08 Jun 2011 05:56:51 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Wed, 8 Jun 2011 05:56:51 -0700 (PDT) In-Reply-To: References: <6B039F9F-B66E-41A3-894E-8F1996A87209@checkpoint.com> Date: Wed, 8 Jun 2011 08:56:51 -0400 Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann Content-Type: multipart/alternative; boundary=0016368e1f85c3b3ab04a532de03 Cc: pkix@ietf.org, paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 12:57:33 -0000 --0016368e1f85c3b3ab04a532de03 Content-Type: text/plain; charset=ISO-8859-1 sorry, that should have been, the previous year. CAA was developed in the fall of 2010. On Wed, Jun 8, 2011 at 8:56 AM, Phillip Hallam-Baker wrote: > First off, I think that people need to stop using the -gate suffix. Just > because a competitor decided that they would attempt to apply it does not > mean it is justified. That is an old game and a rather silly one in our > industry. The relevant cautionary text here being John 8:7. > > What differentiates companies in our industry is not whether they are > breached, it is whether they give prompt, voluntary notice of breaches that > occur or not. The market leaders in the CA industry have a track record of > having done so. > > > As for CAA being a response to the Iranian attack, Ben, Rob and I developed > it a year earlier. > > The point of proposals like CAA is not whether they are 'necessary' or not, > it is whether they mitigate risk. I have never seen a security control > involving a human element that is guaranteed to be operated with 100% > accuracy every time. So whenever there are humans involved I like to have > strength in depth. > > There would be no problem here if browsers actually implemented revocation > checking either. But we have had that in PKIX specs for 15 years and it > still isn't deployed in hard fail mode. Which is rather sad when you > consider that about 70% of the complexity of PKI comes from the need for > revocation. > -- Website: http://hallambaker.com/ --0016368e1f85c3b3ab04a532de03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable sorry, that should have been, the previous year. CAA was developed in the f= all of 2010.

On Wed, Jun 8, 2011 at 8:56 = AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
First off, I think that people need to stop= using the -gate suffix. Just because a competitor decided that they would = attempt to apply it does not mean it is justified. That is an old game and = a rather silly one in our industry. The relevant cautionary text here being= John 8:7.

What differentiates companies in our industry is not wh= ether they are breached, it is whether they give prompt, voluntary notice o= f breaches that occur or not. The market leaders in the CA industry have a = track record of having done so.


As for CAA being a response to the Irani= an attack, Ben, Rob and I developed it a year earlier.

=
The point of proposals like CAA is not whether they are 'necessary= ' or not, it is whether they mitigate risk. I have never seen a securit= y control involving a human element that is guaranteed to be operated with = 100% accuracy every time. So whenever there are humans involved I like to h= ave strength in depth.=A0

There would be no problem here if browsers actually imp= lemented revocation checking either. But we have had that in PKIX specs for= 15 years and it still isn't deployed in hard fail mode. Which is rathe= r sad when you consider that about 70% of the complexity of PKI comes from = the need for revocation.



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

--0016368e1f85c3b3ab04a532de03-- From marsh@extendedsubset.com Wed Jun 8 09:58:34 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFA611E8124; Wed, 8 Jun 2011 09:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ap08nTqyKK-e; Wed, 8 Jun 2011 09:58:33 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id B205E11E8116; Wed, 8 Jun 2011 09:58:33 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1QUM5M-000CiO-Tx; Wed, 08 Jun 2011 16:58:29 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id DC712606D; Wed, 8 Jun 2011 16:58:25 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/rzfy4xvQ9qWn+YkqaFIScB8s43rtL+Ns= Message-ID: <4DEFAA31.4040709@extendedsubset.com> Date: Wed, 08 Jun 2011 11:58:25 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Yoav Nir References: <6B039F9F-B66E-41A3-894E-8F1996A87209@checkpoint.com> In-Reply-To: <6B039F9F-B66E-41A3-894E-8F1996A87209@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" , "tls@ietf.org" Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 16:58:34 -0000 On 06/08/2011 03:37 AM, Yoav Nir wrote: > > What did Comodo fail to do? If this question is seriously being asked by one as knowledgeable as Yoav :-), it suggests to me that the problem is being way over-thinked. So forgive me, I'm just going to re-state this bluntly: The entire value proposition of PKI is based on the trusted root CAs refusing to issue fraudulent certs and in this case Comodo, a trusted root, failed to refuse to issue certain fraudulent certs. > The RA is handing contact with the customer, so it's their job to > make sure that the customer is in fact the owner of the domain name > in the certificate request. These legal agreements and auditing procedures only amount to one thing: after the victim has been (possibly irreparably) harmed by the issuance of a fraudulent certificate, then some legal entity is in a technical violation of contract with some other legal entity. In this case, I've heard of no serious repurcussions other than the loss of image to the CA and the RAs. Certainly significant for Comodo, but most of the press coverage doesn't even mention the names of the hacked RAs. Is the CA suing any hacked RA for breach of contract? Are they even terminating their agreements? Are browser vendors removing any root CAs or blacklisting any sub-CAs due to this? What are the costs paid for this debacle as perceived by others with the authority to cause the immediate issuance of certs? Most importantly, will these costs always be perceived higher than the immediate gain of a corrupt transaction? This is not to suggest any corruption in this case of course, but it is surely not going unnoticed for the future that the CA, the RAs, and the individuals involved all demonstrated effective deniability. This seems like a good test case to either support or refute the arguments of those who claim that policies, auditing, and legal agreements between CAs/RAs/subCAs are an effective way to produce strong security. - Marsh From mrex@sap.com Wed Jun 8 19:44:25 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896C221F84EE; Wed, 8 Jun 2011 19:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.235 X-Spam-Level: X-Spam-Status: No, score=-9.235 tagged_above=-999 required=5 tests=[AWL=1.014, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KV8CRFiwzvA9; Wed, 8 Jun 2011 19:44:25 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id C5BB121F84ED; Wed, 8 Jun 2011 19:44:24 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p592i87e028403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Jun 2011 04:44:08 +0200 (MEST) From: Martin Rex Message-Id: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Date: Thu, 9 Jun 2011 04:44:07 +0200 (MEST) In-Reply-To: from "Peter Gutmann" at Jun 8, 11 06:56:23 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 02:44:25 -0000 Peter Gutmann wrote: > > Yoav Nir writes: > > > > CAA works if all root CAs and affiliates follow it. That's hundreds or > > thousands of entities. Any one of them that fails to comply might ignore > > the CAA record. > > That was my problem with it, any CA (and/or RA) that's already diligent > about cert issuance doesn't need CAA, and any one that isn't won't use > it anyway, so it doesn't address any existing problem. You're looking at CAA from the wrong angle. CAA is _not_ for the RP, i.e. not for _you_ (and me, and most others ...) It is only another means for a CA to detect attempts to subvert one of its RAs, so it's primary purpose is CYA for large commercial CAs. So a Server admin that has a CAA published is not really using it to _protect_ clients. It may reduce the likelyhood to get certs mis-issued, though, and is therefore well in the ballpark of what businesses are doing to protect against fraud (not protecting against it, just make it remain under a certain fraud loss threshold). -Martin From ynir@checkpoint.com Wed Jun 8 23:02:39 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D93B11E80A6; Wed, 8 Jun 2011 23:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.073 X-Spam-Level: X-Spam-Status: No, score=-10.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIqb6+dJ0n1O; Wed, 8 Jun 2011 23:02:38 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7640211E8074; Wed, 8 Jun 2011 23:02:37 -0700 (PDT) X-CheckPoint: {4DF06FFC-F-1B221DC2-FFFF} 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 p5962Prd000751; Thu, 9 Jun 2011 09:02:25 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 9 Jun 2011 09:02:25 +0300 From: Yoav Nir To: Marsh Ray Date: Thu, 9 Jun 2011 09:02:24 +0300 Thread-Topic: [TLS] [pkix] Proposing CAA as PKIX Working Group Item Thread-Index: Acwmas3vqVa1+wROSeCVYqt8EJtOAw== Message-ID: <5F3CE8C6-9D13-4BCB-A4C0-8D755D4BF027@checkpoint.com> References: <6B039F9F-B66E-41A3-894E-8F1996A87209@checkpoint.com> <4DEFAA31.4040709@extendedsubset.com> In-Reply-To: <4DEFAA31.4040709@extendedsubset.com> 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: "pkix@ietf.org" , "paul.hoffman@vpnc.org" , "tls@ietf.org" Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 06:02:39 -0000 On Jun 8, 2011, at 7:58 PM, Marsh Ray wrote: > On 06/08/2011 03:37 AM, Yoav Nir wrote: >>=20 >> What did Comodo fail to do? >=20 > If this question is seriously being asked by one as knowledgeable as=20 > Yoav :-), it suggests to me that the problem is being way over-thinked.=20 > So forgive me, I'm just going to re-state this bluntly: >=20 > The entire value proposition of PKI is based on the trusted root CAs=20 > refusing to issue fraudulent certs and in this case Comodo, a trusted=20 > root, failed to refuse to issue certain fraudulent certs. Similarly, the value proposition of the DMV is to not issue a driver's lice= nse with the name "Marsh Ray" to people who are not Marsh Ray. These days y= ou don't even have to know how to drive. There is an established "best practice" for how the DMV ascertains who you = are: they examine birth certificates, they check street address, etc. Suppose I go to some RA or CA, and ask for a certificate for www.yoavnir.co= m, what are they going to do to check? Obviously, they can check the whois database. This has: > Registrant: > Yoav Nir >=20 > Registered through: GoDaddy.com, Inc. (http://www.godaddy.com) > Domain Name: YOAVNIR.COM >=20 > Domain servers in listed order: > NS1.GISIGHT.CO.IL > NS2.GISIGHT.CO.IL >=20 >=20 > For complete domain details go to: > http://who.godaddy.com/whoischeck.aspx?Domain=3DYOAVNIR.COM So far, so good. The registrant name is indeed "Yoav Nir". But we're probab= ly doing this through web or email, so how can they know that I'm actually = the same "Yoav Nir"? Or a "Yoav Nir" at all? We can check through the lin= k to godaddy (I've removed some of the information): > Registrant: > Yoav Nir > Amir 1 N/A N/A Kibbutz Amir N/A,12140 Fax. +4.46954329=20 >=20 > Registered through: GoDaddy.com, Inc. (http://www.godaddy.com) > Domain Name: YOAVNIR.COM > Created on: 14-Sep-08 > Expires on: 14-Sep-12 > Last Updated on: 25-Jun-10 >=20 > Administrative Contact: > Nir, Yoav yoavnir@amir.org.il > Amir 1 N/A N/A Kibbutz Amir N/A,12140 Fax. +4.46954329=20 > Tel. +972.46954329 >=20 > Technical Contact: > Ltd., Interspace domreg@interspace.net > 19 Yad Harutzim St. Netanya null,42505 Tel. +972.732224444=20 This gives some new information. We have an administrative contact: "yoavni= r@amir.org.il" and a technical contact: "domreg@interspace.net" I have never actually bought an SSL certificate, so I don't know, but I'll = have to assume that part of the automated process involves email to one of = these addresses. There are also phone numbers, but I can't imagine a DV cer= tificate that costs $10-$40 involving an international phone call by a huma= n. That's where I would fail. I don't control these email addresses, and the s= ite belongs to another Yoav Nir who's in a totally different line of busine= ss. This is the simple check that a diligent CA can do. But this is as long as = the CA is a single entity.=20 I don't know of any best practices document that says anything about the di= vision of responsibility between the CA and RA. Is it OK to have only the R= A perform the whois check? Sure, but then what is the added value of the C= A? The reason I like CAA is that it gives an extra layer of security for t= he CA to perform even assuming that the RA has been subverted. The way things stand now, I don't see what Comodo could have done different= ly technically. Sure, we can say that they should not have had a business r= elationship with an RA that was so easily hackable. Similarly, Verisign sho= uld now have allowed rapidssl to use such bad practices. But at the time of= the attack, I don't see what check Comodo could have done. Others (like Peter Gutmann and Bruce Schneier) have written about this befo= re. The model for HTTPS security is what's broken, not a particular CA. The= re are just too many single points of failure. CAA is an attempt to make th= e existing model somewhat better, by adding another layer of security - a s= ecurity check that the CA can do after the RA has already approved the tran= saction. DANE is a more revolutionary solution that aims to replace or supp= lement the existing model. I think both have value, with CAA having value m= uch sooner. Yoav From turners@ieca.com Thu Jun 9 06:29:14 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79EEB11E80B7 for ; Thu, 9 Jun 2011 06:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.91 X-Spam-Level: X-Spam-Status: No, score=-101.91 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6gSpMO1FjaI for ; Thu, 9 Jun 2011 06:29:13 -0700 (PDT) Received: from nm16.access.bullet.mail.mud.yahoo.com (nm16.access.bullet.mail.mud.yahoo.com [66.94.237.217]) by ietfa.amsl.com (Postfix) with SMTP id CAEFF11E8081 for ; Thu, 9 Jun 2011 06:29:06 -0700 (PDT) Received: from [66.94.237.126] by nm16.access.bullet.mail.mud.yahoo.com with NNFMP; 09 Jun 2011 13:29:03 -0000 Received: from [66.94.237.100] by tm1.access.bullet.mail.mud.yahoo.com with NNFMP; 09 Jun 2011 13:29:03 -0000 Received: from [127.0.0.1] by omp1005.access.mail.mud.yahoo.com with NNFMP; 09 Jun 2011 13:29:03 -0000 X-Yahoo-Newman-Id: 883336.54150.bm@omp1005.access.mail.mud.yahoo.com Received: (qmail 89084 invoked from network); 9 Jun 2011 13:29:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307626143; bh=YIS9xS6gLf4P1aQQidarQKO9s07Cx9jjMu+OSu1uXfA=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=5ozt3YVe14tKNu9ReGaXSc1JKzcY88D4JBJ9LJCF+6FdDhRGS/dt6EC/zMBDKBOyOPfmHnJsSpeEVHcWWrBQq1QSyaPDKwPjivqSDTrMTj6vnSjQ1YRRX1ReXfwPmOEqc0uN8anCv7csz4mEXHuhFUnVdyNV3D1HVCi6XvLwmPI= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: UvNuqUgVM1kQNxFiAujcy7DmyQp0xrpI5xsQiCXUDpv94s0 nigWj7YKffLoalSZs2f.a1IuArD1IGtDsRKcP7uanQA6ELUHgER1bEwC3cBK K.4F2egvYQia7AHJGS92fUAoGrngzqriLvbQwqTnWzNmSKHYFN1vPBWimcC7 CdCX5qDMB3Mt5SZsGiSsm9R3yXqFptU2.FXswWMQ8Ol8hs7H6NQwpO85Zh04 83EZ1.tHJb14mSbDTeq37VpKXVymNnqyDpKYfPegC4tHm8NMVQeTnuwpXaKd 5WNfz_QNvEria8K7ZmJf81nTTayr5bZT7FKKG8M2jYnicrULOFbghJokgIWY vHXhGQdJx0CS5M9WRDcnILJE6Xis3p.NHvbuWZqCx X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.local (turners@96.231.120.246 with plain) by smtp115.biz.mail.mud.yahoo.com with SMTP; 09 Jun 2011 06:29:02 -0700 PDT Message-ID: <4DF0CA9D.1030006@ieca.com> Date: Thu, 09 Jun 2011 09:29:01 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Final (hopefully) issues with DTLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 13:29:14 -0000 Does anybody else have thoughts about this? I'd really like to be able to put this draft to bed. spt On 5/23/11 9:19 AM, Eric Rescorla wrote: > Following up on Prague, here is the new text for the 2MSL and the > record sequence number issues: > > > > MSL: > 4.1. > Note that because DTLS records may be reordered, a record from epoch > 1 may be received after epoch 2 has begun. In general, > implementations SHOULD discard packets from earlier epochs, but if > packet loss causes noticeable problems MAY choose to retain keying > material from previous epochs for up to the default MSL specified for > TCP [TCP] to allow for packet reordering. (Note: the intention here > is that implementors use the current guidance from the IETF for MSL, > not that they attempt to interrogate the MSL the system TCP stack is > using.) Until the handshake has completed, implementations MUST > accept packets from the old epoch. > > ... > > 4.2.4. > In addition, for at least twice the default MSL defined for [TCP], > when in the FINISHED state, the node which transmits the last flight > (the server in an ordinary handshake or the client in a resumed > handshake) MUST respond to a retransmit of the peer's last flight > with a retransmit of the last flight. This avoids deadlock conditions > > > > > Record Sequence Number: > When responding to a HelloVerifyRequest the client MUST use the same > parameter values (version, random, session_id, cipher_suites, > compression_method) as it did in the original ClientHello. The > server SHOULD use those values to generate its cookie and verify that > they are correct upon cookie receipt. The server MUST use the same > version number in the HelloVerifyRequest that it would use when > sending a ServerHello. Upon receipt of the ServerHello, the client > MUST verify that the server version values match. In order to avoid > sequence number duplication in case of multiple HelloVerifyRequests, > the server MUST use the record sequence number in the ClientHello as > the record sequence number in the HelloVerifyRequest. > > ... > > When the second ClientHello is received, the server can verify that > the Cookie is valid and that the client can receive packets at the > given IP address. In order to avoid sequence number duplication in > case of multiple cookie exchanges, the server SHOULD use the record > sequence number in the ClientHello as the record sequence number in > its initial ServerHello. Subsequent ServerHellos will only be sent > after the server has created state and MUST increment normally. > > I believe this matches what I said in Prague, but any objections to > this in concept or the way I've written it up. > > > Finally, I've been rethinking the issue of the interaction of the > ChangeCipherSpec and the handshake sequence numbers. In Prague I > suggested not changing this and just putting a note in the spec that > one had to be careful, but at this point I am thinking it might be > better to simple suck up the change and put a message sequence number > in the CCS. This removes the need to consult the handshake state > machine in order to deal with reordering, though not in order to > determine whether the CCS is at the appropriate place in the handshake > (in order to detect misbehaving or malicious behavior early). The > downside for this is that it's a difference from TLS, but it seems > like fairly easy code--though I admit I haven't tried to code it up. I > don't think either way represents a security issue, but doing it this > way means that we won't need to be as careful in the future about > having the state machine be completely deterministic prior to the CCS, > which seems like the Right Thing. Comments? > > -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From jsalowey@cisco.com Tue Jun 14 09:40:54 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0120211E811E for ; Tue, 14 Jun 2011 09:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 509pR1Uommvz for ; Tue, 14 Jun 2011 09:40:52 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id AAFAE11E80C9 for ; Tue, 14 Jun 2011 09:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=4608; q=dns/txt; s=iport; t=1308069652; x=1309279252; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=T6+c8XK3SiPzQnY5Ut1igfLfwxeqoPZe6KEaOn/d5jA=; b=kDMpLPVyXnrkTi2q3KOJY0noMlRWMKkSdwme7AFrEvBbMbWMkqmhTMGg fmNbDqpXWyAUGu8mFk0JH81rhdCZ6/DNRyBf4t7dp+KWqfpyv32LXgABH goNSyys7Gx1SzP44qPXLN+Dy609+niirnVww9ugW7/sY9Xj9Y97CEMrwA c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAM+O902rRDoI/2dsb2JhbABSplN3iHOiNZ5hhiQEhxWKM4RXizA X-IronPort-AV: E=Sophos;i="4.65,365,1304294400"; d="scan'208";a="713322477" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 14 Jun 2011 16:40:52 +0000 Received: from [10.33.249.205] ([10.33.249.205]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5EGepqs004886; Tue, 14 Jun 2011 16:40:51 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <4DF0CA9D.1030006@ieca.com> Date: Tue, 14 Jun 2011 09:41:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9ACC73EC-6834-465B-A5DD-A0DFAE80BD40@cisco.com> References: <4DF0CA9D.1030006@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1084) Cc: tls@ietf.org Subject: Re: [TLS] Final (hopefully) issues with DTLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 16:40:54 -0000 The open issue is with respect to the version number that Nikos raised. = Eric is working on text along the lines of Nikos' recommendation of = fixing the version number. Joe=20 On Jun 9, 2011, at 6:29 AM, Sean Turner wrote: > Does anybody else have thoughts about this? I'd really like to be = able to put this draft to bed. >=20 > spt >=20 > On 5/23/11 9:19 AM, Eric Rescorla wrote: >> Following up on Prague, here is the new text for the 2MSL and the >> record sequence number issues: >>=20 >>=20 >>=20 >> MSL: >> 4.1. >> Note that because DTLS records may be reordered, a record from = epoch >> 1 may be received after epoch 2 has begun. In general, >> implementations SHOULD discard packets from earlier epochs, but if >> packet loss causes noticeable problems MAY choose to retain keying >> material from previous epochs for up to the default MSL specified = for >> TCP [TCP] to allow for packet reordering. (Note: the intention = here >> is that implementors use the current guidance from the IETF for = MSL, >> not that they attempt to interrogate the MSL the system TCP stack = is >> using.) Until the handshake has completed, implementations MUST >> accept packets from the old epoch. >>=20 >> ... >>=20 >> 4.2.4. >> In addition, for at least twice the default MSL defined for [TCP], >> when in the FINISHED state, the node which transmits the last = flight >> (the server in an ordinary handshake or the client in a resumed >> handshake) MUST respond to a retransmit of the peer's last flight >> with a retransmit of the last flight. This avoids deadlock = conditions >>=20 >>=20 >>=20 >>=20 >> Record Sequence Number: >> When responding to a HelloVerifyRequest the client MUST use the = same >> parameter values (version, random, session_id, cipher_suites, >> compression_method) as it did in the original ClientHello. The >> server SHOULD use those values to generate its cookie and verify = that >> they are correct upon cookie receipt. The server MUST use the = same >> version number in the HelloVerifyRequest that it would use when >> sending a ServerHello. Upon receipt of the ServerHello, the = client >> MUST verify that the server version values match. In order to = avoid >> sequence number duplication in case of multiple = HelloVerifyRequests, >> the server MUST use the record sequence number in the ClientHello = as >> the record sequence number in the HelloVerifyRequest. >>=20 >> ... >>=20 >> When the second ClientHello is received, the server can verify = that >> the Cookie is valid and that the client can receive packets at the >> given IP address. In order to avoid sequence number duplication = in >> case of multiple cookie exchanges, the server SHOULD use the = record >> sequence number in the ClientHello as the record sequence number = in >> its initial ServerHello. Subsequent ServerHellos will only be sent >> after the server has created state and MUST increment normally. >>=20 >> I believe this matches what I said in Prague, but any objections to >> this in concept or the way I've written it up. >>=20 >>=20 >> Finally, I've been rethinking the issue of the interaction of the >> ChangeCipherSpec and the handshake sequence numbers. In Prague I >> suggested not changing this and just putting a note in the spec that >> one had to be careful, but at this point I am thinking it might be >> better to simple suck up the change and put a message sequence number >> in the CCS. This removes the need to consult the handshake state >> machine in order to deal with reordering, though not in order to >> determine whether the CCS is at the appropriate place in the = handshake >> (in order to detect misbehaving or malicious behavior early). The >> downside for this is that it's a difference from TLS, but it seems >> like fairly easy code--though I admit I haven't tried to code it up. = I >> don't think either way represents a security issue, but doing it this >> way means that we won't need to be as careful in the future about >> having the state machine be completely deterministic prior to the = CCS, >> which seems like the Right Thing. Comments? >>=20 >> -Ekr >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From labon58@gmail.com Wed Jun 15 00:49:39 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A4611E80DD for ; Wed, 15 Jun 2011 00:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0psorx6-8tIJ for ; Wed, 15 Jun 2011 00:49:39 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A19A11E809B for ; Wed, 15 Jun 2011 00:49:39 -0700 (PDT) Received: by pwi5 with SMTP id 5so232650pwi.31 for ; Wed, 15 Jun 2011 00:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=mN394VIHgPHGmrNKc1KZHDlNUWzJ/Zn9ZcNHMhCKONo=; b=irnewz/Eo8c1UG/sFcoVZDlmN7PLd8HtdkHNiZIVG4K5fwvezVLAWHSoX8UWTY7lU5 l0QyLwOtLenAlOwBxqErm+NYdErtHR2nWHoXyM1yqpX93lm1ygFHGnKtcq8dOAZVSIyl LwGQ7tCtFAZKu3GNdohJXuyPg0kqDVIp7B5eg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; b=mtJUFjz/LplII7es64epo/uTaBtTQF/XI5IuKVbntJRNxiYchLLkrpe4dL6SlvW9gA 1jKBBQ8mTGfB2zsXVBqQYI8lXvi+cTSbZs2TKzANSxqkvrlreQt3IblGAUDNv13elqVL 6KHnBRZBwcqsn6RqwbtKLMsLMlKOQClPxjHRw= Received: by 10.68.15.167 with SMTP id y7mr81665pbc.296.1308124178573; Wed, 15 Jun 2011 00:49:38 -0700 (PDT) Received: from PC6528 ([211.252.151.26]) by mx.google.com with ESMTPS id k4sm131552pbl.59.2011.06.15.00.49.35 (version=SSLv3 cipher=OTHER); Wed, 15 Jun 2011 00:49:37 -0700 (PDT) From: "Byoung-Jin Han" To: , , Date: Wed, 15 Jun 2011 16:49:28 +0900 Message-ID: <003001cc2b30$c3cd54a0$4b67fde0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwrL5DRWzPl/XekTnmJSVqFkB7w0wAAGq0Q Content-Language: ko Cc: tls@ietf.org Subject: [TLS] FW: New Version Notification for draft-bjhan-tls-seed-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 07:49:39 -0000 Dear All, This is Byoung-Jin Han from KISA(Korea Internet & Security Agency), = Korea. I was submitted "draft-bjhan-tls-seed" vision "00". http://www.ietf.org/id/draft-bjhan-tls-seed-00.txt This I-D describes the use of the SEED cipher suites to TLS.=20 Please review the new I-D. Any comments would be appreciated. Thank you. Best Regards, Byoung-Jin Han. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Wednesday, June 15, 2011 4:41 PM To: labon58@gmail.com Cc: dhshin@kisa.or.kr; hcjung@kisa.or.kr; yjwon@kisa.or.kr; = labon58@gmail.com Subject: New Version Notification for draft-bjhan-tls-seed-00.txt A new version of I-D, draft-bjhan-tls-seed-00.txt has been successfully = submitted by Byoungjin Han and posted to the IETF repository. Filename: draft-bjhan-tls-seed Revision: 00 Title: Addition of SEED Cipher Suites to Transport Layer Security = (TLS) Creation date: 2011-06-15 WG ID: Individual Submission Number of pages: 9 Abstract: This document proposes the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the SEED encryption algorithm as a block cipher algorithm. = =20 The IETF Secretariat From tgindin@us.ibm.com Thu Jun 9 05:11:09 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9852311E809A; Thu, 9 Jun 2011 05:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHJ7IDvoDkNe; Thu, 9 Jun 2011 05:11:07 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 637BA11E807C; Thu, 9 Jun 2011 05:11:05 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p59BeVEH006700; Thu, 9 Jun 2011 07:40:31 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p59CAuxu105006; Thu, 9 Jun 2011 08:10:56 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p598Aiph006468; Thu, 9 Jun 2011 05:10:44 -0300 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p598AicL006465; Thu, 9 Jun 2011 05:10:44 -0300 In-Reply-To: References: <6B039F9F-B66E-41A3-894E-8F1996A87209@checkpoint.com> To: Phillip Hallam-Baker MIME-Version: 1.0 X-KeepSent: B299299E:1FCA02D8-852578A9:0052F9E2; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Tom Gindin Message-ID: Date: Thu, 9 Jun 2011 08:10:54 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 06/09/2011 08:10:55, Serialize complete at 06/09/2011 08:10:55 Content-Type: text/plain; charset="US-ASCII" X-Mailman-Approved-At: Wed, 15 Jun 2011 09:04:12 -0700 Cc: pkix , paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 12:11:09 -0000 This check seems to be primarily useful when the CA gives high (arguably too high) levels of trust to multiple RA's, and the CA is more carefully operated than some and perhaps all of its RA's. Is that situation unique to Comodo, or are they the extreme case of a common arrangement when there are independent RA's? This is a reasonable suggestion if there are other CA's half as vulnerable as Comodo. Tom Gindin P.S. - The opinions above are mine, and not necessarily those of my employer From: Phillip Hallam-Baker To: Peter Gutmann Cc: pkix@ietf.org, paul.hoffman@vpnc.org, tls@ietf.org Date: 06/08/2011 08:58 AM Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item Sent by: pkix-bounces@ietf.org sorry, that should have been, the previous year. CAA was developed in the fall of 2010. On Wed, Jun 8, 2011 at 8:56 AM, Phillip Hallam-Baker wrote: First off, I think that people need to stop using the -gate suffix. Just because a competitor decided that they would attempt to apply it does not mean it is justified. That is an old game and a rather silly one in our industry. The relevant cautionary text here being John 8:7. What differentiates companies in our industry is not whether they are breached, it is whether they give prompt, voluntary notice of breaches that occur or not. The market leaders in the CA industry have a track record of having done so. As for CAA being a response to the Iranian attack, Ben, Rob and I developed it a year earlier. The point of proposals like CAA is not whether they are 'necessary' or not, it is whether they mitigate risk. I have never seen a security control involving a human element that is guaranteed to be operated with 100% accuracy every time. So whenever there are humans involved I like to have strength in depth. There would be no problem here if browsers actually implemented revocation checking either. But we have had that in PKIX specs for 15 years and it still isn't deployed in hard fail mode. Which is rather sad when you consider that about 70% of the complexity of PKI comes from the need for revocation. -- Website: http://hallambaker.com/ _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From paul@xelerance.com Wed Jun 22 13:25:39 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BC411E8152; Wed, 22 Jun 2011 13:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjR-D4tDDjDf; Wed, 22 Jun 2011 13:25:37 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA1511E8157; Wed, 22 Jun 2011 13:25:25 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 08EE5C661; Wed, 22 Jun 2011 16:25:23 -0400 (EDT) Date: Wed, 22 Jun 2011 16:25:22 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <201010041437.o94EbTHT029454@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 X-Mailman-Approved-At: Tue, 28 Jun 2011 08:01:26 -0700 Cc: dnsop@ietf.org, tls@ietf.org Subject: Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 20:25:39 -0000 On Mon, 4 Oct 2010, Phillip Hallam-Baker wrote: > 2) Sanction CAs that issue unauthorized certificates What would you say a valid sanction would be for a CA that issues a bad certificate for 10 major websites like Mozilla and Yahoo? What should the sanction be for a CA whose reseller's subCAs issues such bad certificates? What would the sanctions be for non-FQDN EV certs issued? What would the current total sanction be for Comodo, a player who has someone as honourable as you working for them based on last year's events plus EV violations detected via the SSL observatory data? How could an external party review the set of unknown serials revoked by Comodo to determine the kind/amount of sanction? Would Comodo's "licencse" have been revoked, or would the sanctions have been limited by money? If so, would the money be in absolute value or percantage of profit/turnover? What would or could Comodo have done differently if such a sanction had been applied? There is really only one sanction everyone can determine by themselves to apply to any CA, the decision to trust them more or less then themselves. If the latter, DNSSEC with DANE is an excellent choice. Feel free to interpret DANE as each TLS owner's "sanction". Paul