From benl@google.com Thu Nov 1 02:10:37 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FFA21F854A for ; Thu, 1 Nov 2012 02:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.402, 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 cnXJX+4qYW9D for ; Thu, 1 Nov 2012 02:10:36 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id A8AC321F8543 for ; Thu, 1 Nov 2012 02:10:35 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so127505wib.13 for ; Thu, 01 Nov 2012 02:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=HxhHT3OGXNz5pa/X2DbiKBlevZP++Cc4txW5q9C4vok=; b=C1JwmEKqOtE/xGjU/hv3qC8kXJQJFROuYi5W5aTcfKLtUsm6Kcdosvc1BktsUVI6IP Kpc7BU1sNPOb/JbNM9jIMVQr+fPjOBk4BQU1OI1uYWj5kuNcqVTqiiqUSLWMzFaKfoAQ M0W7S23i6R9kg0FFb9tkAlXkVMTrhQF8NhtLXlZgFykpFKkpUWnhJDvRxRh9gV23t1OL +JtSCOYt0i8ecjIXkbO1gug8Vt10bhvGI2kpWexuPu5ILJjO/gIGoKm/aXFLbrh1E8VO 5vBCTqTEY04354CE78eZ6+0rv2/S67lhvOKuw2JomE3YRncYlEscXkjzidgJ1ohkTTA2 Y4vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=HxhHT3OGXNz5pa/X2DbiKBlevZP++Cc4txW5q9C4vok=; b=VevfrHb2yhTNThTAEvYlmtfg4oGg5Stf3es1KL92MWWCgiKeqlFEf73r85DtxCLUs7 M++fVM+CcLqBYD1whmdgpGZJbWJUpjntiw4kfEVxoF18gPChGKs2MTXx9VrUjrr61sZq WjoWZuAhwRKtBZODARlBQDQbvb/Xz4PKJu2oZFz/2SKYJHH0Wj/MYMq5MT35fzCGmwbS S0LDveApUJ0Qug1KcTLMjIQtXCKJ1QM6siO9QyAvT8gwTQfa7nLmnFF3YM2VRANZKkd9 D81tREFsQo2s1eo8AqChhi7z3jsfJgREWIECoDSbdEjfBaOLMpQUkEDLacQthAhTsHmg mz9w== MIME-Version: 1.0 Received: by 10.180.80.33 with SMTP id o1mr889240wix.14.1351761028429; Thu, 01 Nov 2012 02:10:28 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Thu, 1 Nov 2012 02:10:28 -0700 (PDT) In-Reply-To: <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Thu, 1 Nov 2012 09:10:28 +0000 Message-ID: From: Ben Laurie To: Rick Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnxCCQ21a/8bPnaXddlUflBXbzwwcrCtd8pGorh2OFx/fcPlFiexgy/47mzQu7+0rSd3V1ML6SEMT4cDF5IFZvyBgtZr5SGPua3EmUAtwD+1rh4RpTuvN58d8+Pghn25apvJi3ehgTUZnYLc4rruxSqvdZC1DqjBeaVa5Hfy1hbZ5QjZRwZXZwH/c9Wt1zC/+sPtxgp Cc: "therightkey@ietf.org" , Rob Stradling , Paul Hoffman Subject: Re: [therightkey] Other solutions to the problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 09:10:37 -0000 On 31 October 2012 23:57, Rick Andrews wrote: >> -----Original Message----- >> From: Ben Laurie [mailto:benl@google.com] >> Sent: Monday, October 29, 2012 3:10 AM >> To: Rick Andrews >> Cc: Rob Stradling; therightkey@ietf.org; Paul Hoffman >> Subject: Re: [therightkey] Other solutions to the problem >> >> On 26 October 2012 22:31, Rick Andrews >> wrote: >> >> -----Original Message----- >> >> From: Ben Laurie [mailto:benl@google.com] >> >> Sent: Friday, October 26, 2012 1:51 AM >> >> To: Rob Stradling >> >> Cc: Rick Andrews; therightkey@ietf.org; Paul Hoffman >> >> Subject: Re: [therightkey] Other solutions to the problem >> >> >> >> On 26 October 2012 09:24, Rob Stradling >> >> wrote: >> >> > On 26/10/12 00:58, Rick Andrews wrote: >> >> > >> >> > >> >> >> AFAICT, for CT to really work it will require participation from >> >> every CA >> >> >> whose roots are in browsers. I think you're underestimating how >> hard >> >> it will >> >> >> be to achieve that. >> >> > >> >> > >> >> > Rick, >> >> > >> >> > Ultimately, assuming the RFC5878 TLS extension gains widespread >> >> support in >> >> > server and client software, CT won't _require_ participation from >> any >> >> CA. >> >> > Each certificate holder will be able to configure their server to >> >> send their >> >> > certificate's CT proof to each client. >> > >> > I see, so the certificate holder can submit their newly-minted >> certificate to a log server to get a CT proof. Instead of requiring the >> participation of every CA, you now require the participation of every >> certificate holder. >> >> No, it is an option. > > I understand that. I was trying to point out that for CT to be effective,= you either need all CAs to participate, or for every CA that doesn't parti= cipate, their customers who want protection have to participate directly. I= feel that's a pretty high bar to surmount. Its only software. The process of participating in CT for a server operator= is: 1. Run command line tool once, giving it your certificate as input and an SCT file as output. 2. Add one line of configuration to your server config. Not exactly rocket science. If people _really_ find it hard, we could build it into the servers so there was no manual step at all. >> >You might say that not every certificate holder will need or want CT, >> but I would guess that the number that would want the protection would >> be far greater than the number of CAs. >> >> Given that the plan is browsers will refuse non-CTed certs, I imagine >> most holder of certificates used by the public will want CT. > > Do you have agreements with the major browser vendors to do this? It's po= ssible that not all of them will be on board. In practice, only one major browser needs to participate to give herd immunity. Obviously it would be nice if they all did, but it is not an urgent problem. >> >> > But with participation from the CAs, it should be possible to >> realize >> >> the CT >> >> > dream far sooner. And (even in a future world where RFC5878 is >> >> supported >> >> > everywhere) if the CA takes care of CT proof distribution, then >> that >> >> makes >> >> > life easier for the certificate holder. >> >> > >> >> > >> >> >> Further, no one has yet brought up the privacy issue. CAs sell a >> lot >> >> of >> >> >> certificates to companies for their internal use. Some of them >> may >> >> object to >> >> >> publishing all their internal domain names. >> >> > >> >> > >> >> > This has been a concern for Comodo too, so I spoke to AGL about it >> a >> >> few >> >> > weeks ago. AIUI, the plan is that CT clients will have a user- >> >> configurable >> >> > whitelist (empty by default) of domain names for which CT proofs >> will >> >> not be >> >> > required. Participating CAs should allow customers to opt-out >> from >> >> having >> >> > their certs automatically logged with CT. >> > >> > I believe in your plan each browser will be a CT client. Aside from >> the fact that the white list is an attractive target for hackers, I >> don't see how the average user is going to know how to configure this >> white list. I'm reminded of Adam's arguments against Convergence >> (http://www.imperialviolet.org/2011/09/07/convergence.html). >> >> This is why I think the best solution is to issue private certs >> through a name constrained intermediate which is logged. > > I agree. I'm glad we agree on something! From hallam@gmail.com Thu Nov 1 04:22:48 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A6E21F8442 for ; Thu, 1 Nov 2012 04:22:48 -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 fm3PpiZuNfzv for ; Thu, 1 Nov 2012 04:22:47 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 22B9D21F8413 for ; Thu, 1 Nov 2012 04:22:47 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so2619592oag.31 for ; Thu, 01 Nov 2012 04:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i5RrbpDh/gK/Yo/n2rj/wPWKX4KoCPII5/Qiiutuoyw=; b=I21e7r/ltPK6MWJQSFF4Efe5zbt6onIiuSqn0M8kEZpgW831EBd5ZrVczGl2NRJYgs qLBO8P47V9NMJ2plpvPqR+kiFU6vwqSEJ7Ro1wyqHDviq60xdzJj7ebgXxcP2uPbo3OM 03nZnRNpp0yGuy2e7SIAq7sQlnsGzB39QxUrCc6YVRQp5PmYU1u9/oosI7p9kQYt/qEO LXiXUtrJNfQi68q7UuzbnjriKaac7GMbVTrwiBoEeuRuPoIPjrWuI73KSyM6expw6QlZ E4KTl4+sYhk2XSsEhyaQIRCbanWsb9IFa4W33OD3/i8lDOrr8Zo3oCBXAr5qoOb3IyCD 0lVQ== MIME-Version: 1.0 Received: by 10.60.14.198 with SMTP id r6mr33113967oec.115.1351768966736; Thu, 01 Nov 2012 04:22:46 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Thu, 1 Nov 2012 04:22:46 -0700 (PDT) In-Reply-To: References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Thu, 1 Nov 2012 07:22:46 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=e89a8fb1f72c14ab6e04cd6d3d61 Cc: "therightkey@ietf.org" , Rob Stradling , Paul Hoffman , Rick Andrews Subject: Re: [therightkey] Other solutions to the problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 11:22:48 -0000 --e89a8fb1f72c14ab6e04cd6d3d61 Content-Type: text/plain; charset=ISO-8859-1 Zero net admin steps is probably a necessary criteria. What you think not hard might as well be rocket science to most. On Thu, Nov 1, 2012 at 5:10 AM, Ben Laurie wrote: > On 31 October 2012 23:57, Rick Andrews wrote: > >> -----Original Message----- > >> From: Ben Laurie [mailto:benl@google.com] > >> Sent: Monday, October 29, 2012 3:10 AM > >> To: Rick Andrews > >> Cc: Rob Stradling; therightkey@ietf.org; Paul Hoffman > >> Subject: Re: [therightkey] Other solutions to the problem > >> > >> On 26 October 2012 22:31, Rick Andrews > >> wrote: > >> >> -----Original Message----- > >> >> From: Ben Laurie [mailto:benl@google.com] > >> >> Sent: Friday, October 26, 2012 1:51 AM > >> >> To: Rob Stradling > >> >> Cc: Rick Andrews; therightkey@ietf.org; Paul Hoffman > >> >> Subject: Re: [therightkey] Other solutions to the problem > >> >> > >> >> On 26 October 2012 09:24, Rob Stradling > >> >> wrote: > >> >> > On 26/10/12 00:58, Rick Andrews wrote: > >> >> > > >> >> > > >> >> >> AFAICT, for CT to really work it will require participation from > >> >> every CA > >> >> >> whose roots are in browsers. I think you're underestimating how > >> hard > >> >> it will > >> >> >> be to achieve that. > >> >> > > >> >> > > >> >> > Rick, > >> >> > > >> >> > Ultimately, assuming the RFC5878 TLS extension gains widespread > >> >> support in > >> >> > server and client software, CT won't _require_ participation from > >> any > >> >> CA. > >> >> > Each certificate holder will be able to configure their server to > >> >> send their > >> >> > certificate's CT proof to each client. > >> > > >> > I see, so the certificate holder can submit their newly-minted > >> certificate to a log server to get a CT proof. Instead of requiring the > >> participation of every CA, you now require the participation of every > >> certificate holder. > >> > >> No, it is an option. > > > > I understand that. I was trying to point out that for CT to be > effective, you either need all CAs to participate, or for every CA that > doesn't participate, their customers who want protection have to > participate directly. I feel that's a pretty high bar to surmount. > > Its only software. The process of participating in CT for a server > operator is: > > 1. Run command line tool once, giving it your certificate as input and > an SCT file as output. > > 2. Add one line of configuration to your server config. > > Not exactly rocket science. If people _really_ find it hard, we could > build it into the servers so there was no manual step at all. > > >> >You might say that not every certificate holder will need or want CT, > >> but I would guess that the number that would want the protection would > >> be far greater than the number of CAs. > >> > >> Given that the plan is browsers will refuse non-CTed certs, I imagine > >> most holder of certificates used by the public will want CT. > > > > Do you have agreements with the major browser vendors to do this? It's > possible that not all of them will be on board. > > In practice, only one major browser needs to participate to give herd > immunity. Obviously it would be nice if they all did, but it is not an > urgent problem. > > >> >> > But with participation from the CAs, it should be possible to > >> realize > >> >> the CT > >> >> > dream far sooner. And (even in a future world where RFC5878 is > >> >> supported > >> >> > everywhere) if the CA takes care of CT proof distribution, then > >> that > >> >> makes > >> >> > life easier for the certificate holder. > >> >> > > >> >> > > >> >> >> Further, no one has yet brought up the privacy issue. CAs sell a > >> lot > >> >> of > >> >> >> certificates to companies for their internal use. Some of them > >> may > >> >> object to > >> >> >> publishing all their internal domain names. > >> >> > > >> >> > > >> >> > This has been a concern for Comodo too, so I spoke to AGL about it > >> a > >> >> few > >> >> > weeks ago. AIUI, the plan is that CT clients will have a user- > >> >> configurable > >> >> > whitelist (empty by default) of domain names for which CT proofs > >> will > >> >> not be > >> >> > required. Participating CAs should allow customers to opt-out > >> from > >> >> having > >> >> > their certs automatically logged with CT. > >> > > >> > I believe in your plan each browser will be a CT client. Aside from > >> the fact that the white list is an attractive target for hackers, I > >> don't see how the average user is going to know how to configure this > >> white list. I'm reminded of Adam's arguments against Convergence > >> (http://www.imperialviolet.org/2011/09/07/convergence.html). > >> > >> This is why I think the best solution is to issue private certs > >> through a name constrained intermediate which is logged. > > > > I agree. > > I'm glad we agree on something! > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > -- Website: http://hallambaker.com/ --e89a8fb1f72c14ab6e04cd6d3d61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Zero net admin steps is probably a necessary criteria. What you think not h= ard might as well be rocket science to most.

=
On Thu, Nov 1, 2012 at 5:10 AM, Ben Laurie <= span dir=3D"ltr"><b= enl@google.com> wrote:
On 3= 1 October 2012 23:57, Rick Andrews <Rick_Andrews@symantec.com> wrote:
>> -----Original Message-----
>> From: Ben Laurie [mailto:benl@g= oogle.com]
>> Sent: Monday, October 29, 2012 3:10 AM
>> To: Rick Andrews
>> Cc: Rob Stradling; therigh= tkey@ietf.org; Paul Hoffman
>> Subject: Re: [therightkey] Other solutions to the problem
>>
>> On 26 October 2012 22:31, Rick Andrews <Rick_Andrews@symantec.com>
>> wrote:
>> >> -----Original Message-----
>> >> From: Ben Laurie [mailto:benl@google.com]
>> >> Sent: Friday, October 26, 2012 1:51 AM
>> >> To: Rob Stradling
>> >> Cc: Rick Andrews; therightkey@ietf.org; Paul Hoffman
>> >> Subject: Re: [therightkey] Other solutions to the problem=
>> >>
>> >> On 26 October 2012 09:24, Rob Stradling <rob.stradling@comodo.com>
>> >> wrote:
>> >> > On 26/10/12 00:58, Rick Andrews wrote:
>> >> > <snip>
>> >> >
>> >> >> AFAICT, for CT to really work it will require pa= rticipation from
>> >> every CA
>> >> >> whose roots are in browsers. I think you're = underestimating how
>> hard
>> >> it will
>> >> >> be to achieve that.
>> >> >
>> >> >
>> >> > Rick,
>> >> >
>> >> > Ultimately, assuming the RFC5878 TLS extension gains= widespread
>> >> support in
>> >> > server and client software, CT won't _require_ p= articipation from
>> any
>> >> CA.
>> >> > Each certificate holder will be able to configure th= eir server to
>> >> send their
>> >> > certificate's CT proof to each client.
>> >
>> > I see, so the certificate holder can submit their newly-minte= d
>> certificate to a log server to get a CT proof. Instead of requirin= g the
>> participation of every CA, you now require the participation of ev= ery
>> certificate holder.
>>
>> No, it is an option.
>
> I understand that. I was trying to point out that for CT to be effecti= ve, you either need all CAs to participate, or for every CA that doesn'= t participate, their customers who want protection have to participate dire= ctly. I feel that's a pretty high bar to surmount.

Its only software. The process of participating in CT for a ser= ver operator is:

1. Run command line tool once, giving it your certificate as input and
an SCT file as output.

2. Add one line of configuration to your server config.

Not exactly rocket science. If people _really_ find it hard, we could
build it into the servers so there was no manual step at all.

>> >You might say that not every certificate holder will need or w= ant CT,
>> but I would guess that the number that would want the protection w= ould
>> be far greater than the number of CAs.
>>
>> Given that the plan is browsers will refuse non-CTed certs, I imag= ine
>> most holder of certificates used by the public will want CT.
>
> Do you have agreements with the major browser vendors to do this? It&#= 39;s possible that not all of them will be on board.

In practice, only one major browser needs to participate to give herd=
immunity. Obviously it would be nice if they all did, but it is not an
urgent problem.

>> >> > But with participation from the CAs, it should be po= ssible to
>> realize
>> >> the CT
>> >> > dream far sooner. =A0And (even in a future world whe= re RFC5878 is
>> >> supported
>> >> > everywhere) if the CA takes care of CT proof distrib= ution, then
>> that
>> >> makes
>> >> > life easier for the certificate holder.
>> >> >
>> >> >
>> >> >> Further, no one has yet brought up the privacy i= ssue. CAs sell a
>> lot
>> >> of
>> >> >> certificates to companies for their internal use= . Some of them
>> may
>> >> object to
>> >> >> publishing all their internal domain names.
>> >> >
>> >> >
>> >> > This has been a concern for Comodo too, so I spoke t= o AGL about it
>> a
>> >> few
>> >> > weeks ago. =A0AIUI, the plan is that CT clients will= have a user-
>> >> configurable
>> >> > whitelist (empty by default) of domain names for whi= ch CT proofs
>> will
>> >> not be
>> >> > required. =A0Participating CAs should allow customer= s to opt-out
>> from
>> >> having
>> >> > their certs automatically logged with CT.
>> >
>> > I believe in your plan each browser will be a CT client. Asid= e from
>> the fact that the white list is an attractive target for hackers, = I
>> don't see how the average user is going to know how to configu= re this
>> white list. I'm reminded of Adam's arguments against Conve= rgence
>> (http://www.imperialviolet.org/2011/09/07/convergence= .html).
>>
>> This is why I think the best solution is to issue private certs >> through a name constrained intermediate which is logged.
>
> I agree.

I'm glad we agree on something!
___________________________________= ____________
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey



--
= Website: http://hallambaker.com/
--e89a8fb1f72c14ab6e04cd6d3d61-- From benl@google.com Thu Nov 1 04:26:39 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BA421F84AE for ; Thu, 1 Nov 2012 04:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.675 X-Spam-Level: X-Spam-Status: No, score=-102.675 tagged_above=-999 required=5 tests=[AWL=0.302, 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 hJRSQeHTqV44 for ; Thu, 1 Nov 2012 04:26:38 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 67D9B21F8449 for ; Thu, 1 Nov 2012 04:26:38 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so205582wib.13 for ; Thu, 01 Nov 2012 04:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=KZsvCxZ7Pypdyj6mo4viX2ycRaEaC+y4FfQ/G/wL1kY=; b=EZ5C6q/MWt16cZ+ULjymFw42tbMD4X1Q4qZs5Mk4QdpuLoGhfpkdAL5tTwJg/puUVE 8xZig1blcuAcHT9LAAj4ZyFNPnnjqtN/zlE+HGxF6lhaBOy9E4QVjUz3cAutqeD/DOH4 akyWy/qSJKaDgNB1zX7Ph2i///HUUH5UbDeS17odDAVhtSbtOG89YFonm4ThSmqgsyyB W1WHI7TAg8oz/OvMR+CxnpX1xjemZgeEea1SQBhF4zPTlmm0CUyQhyeYIHpWYsurunsU Th1AAhMLFmOUpdSJiTl2AD1VtekuFx0sfx1iMn4k36Nvq2fGUjwy4FAspihPPtOC4fNx idjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=KZsvCxZ7Pypdyj6mo4viX2ycRaEaC+y4FfQ/G/wL1kY=; b=bDkZQ/NWsuHwkJLKhfuzxGAMU6mDNWVYmwCAIVOxyeh6tvTjwAZj5cIhCzCBAUZOeG fhGWYveKIMCd1omgOtF8OfGakpqKU1UlTXj4Tb9OWJYt0YrHBkpGamYlX3CyY7lVYR6B LE5kAvQxJ8RponQFWsjIcHC2eDKRgkgLUwFHHqsndr+LGwMMDH5hBjzjUfJO9l5kqwuC XXNdzFayXBLZQHBpCijvH6rhlYVdAGBGl+V+Z9rtBOvyiv0SFfFWvqrM5PyZ2N/TvxgT VOXwln4FsMCZbxMRtEhmCjAGycOW+7+XVIaA/XshDDRLZmYCZWXRr0PXHxpEUQMUVMkJ r11A== MIME-Version: 1.0 Received: by 10.180.100.101 with SMTP id ex5mr1396239wib.16.1351769197067; Thu, 01 Nov 2012 04:26:37 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Thu, 1 Nov 2012 04:26:36 -0700 (PDT) In-Reply-To: References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Thu, 1 Nov 2012 11:26:36 +0000 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlgz0wEhRXyKEAk5Hj5xRwCDd1n/z4GPUD4+g+xtkGnk8Bc1JMT6owbAxJIz3ySzHuQCciZp9wSQmR0Wyh4x3M2LVMW2w5mjWYhVXNUA68PVb20fdpvgqYQubTj2HBHbAmKss12JVaj3DMVAMmgwf9BRfhsse223RuRtkzlicLh9myCONyXih0VdYi4wmJA7+yzbiyu Cc: "therightkey@ietf.org" , Rob Stradling , Paul Hoffman , Rick Andrews Subject: Re: [therightkey] Other solutions to the problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 11:26:39 -0000 On 1 November 2012 11:22, Phillip Hallam-Baker wrote: > Zero net admin steps is probably a necessary criteria. What you think not > hard might as well be rocket science to most. Maybe, but the rocket science involved in getting a cert in the first place is far worse. > > > On Thu, Nov 1, 2012 at 5:10 AM, Ben Laurie wrote: >> >> On 31 October 2012 23:57, Rick Andrews wrote: >> >> -----Original Message----- >> >> From: Ben Laurie [mailto:benl@google.com] >> >> Sent: Monday, October 29, 2012 3:10 AM >> >> To: Rick Andrews >> >> Cc: Rob Stradling; therightkey@ietf.org; Paul Hoffman >> >> Subject: Re: [therightkey] Other solutions to the problem >> >> >> >> On 26 October 2012 22:31, Rick Andrews >> >> wrote: >> >> >> -----Original Message----- >> >> >> From: Ben Laurie [mailto:benl@google.com] >> >> >> Sent: Friday, October 26, 2012 1:51 AM >> >> >> To: Rob Stradling >> >> >> Cc: Rick Andrews; therightkey@ietf.org; Paul Hoffman >> >> >> Subject: Re: [therightkey] Other solutions to the problem >> >> >> >> >> >> On 26 October 2012 09:24, Rob Stradling >> >> >> wrote: >> >> >> > On 26/10/12 00:58, Rick Andrews wrote: >> >> >> > >> >> >> > >> >> >> >> AFAICT, for CT to really work it will require participation from >> >> >> every CA >> >> >> >> whose roots are in browsers. I think you're underestimating how >> >> hard >> >> >> it will >> >> >> >> be to achieve that. >> >> >> > >> >> >> > >> >> >> > Rick, >> >> >> > >> >> >> > Ultimately, assuming the RFC5878 TLS extension gains widespread >> >> >> support in >> >> >> > server and client software, CT won't _require_ participation from >> >> any >> >> >> CA. >> >> >> > Each certificate holder will be able to configure their server to >> >> >> send their >> >> >> > certificate's CT proof to each client. >> >> > >> >> > I see, so the certificate holder can submit their newly-minted >> >> certificate to a log server to get a CT proof. Instead of requiring the >> >> participation of every CA, you now require the participation of every >> >> certificate holder. >> >> >> >> No, it is an option. >> > >> > I understand that. I was trying to point out that for CT to be >> > effective, you either need all CAs to participate, or for every CA that >> > doesn't participate, their customers who want protection have to participate >> > directly. I feel that's a pretty high bar to surmount. >> >> Its only software. The process of participating in CT for a server >> operator is: >> >> 1. Run command line tool once, giving it your certificate as input and >> an SCT file as output. >> >> 2. Add one line of configuration to your server config. >> >> Not exactly rocket science. If people _really_ find it hard, we could >> build it into the servers so there was no manual step at all. >> >> >> >You might say that not every certificate holder will need or want CT, >> >> but I would guess that the number that would want the protection would >> >> be far greater than the number of CAs. >> >> >> >> Given that the plan is browsers will refuse non-CTed certs, I imagine >> >> most holder of certificates used by the public will want CT. >> > >> > Do you have agreements with the major browser vendors to do this? It's >> > possible that not all of them will be on board. >> >> In practice, only one major browser needs to participate to give herd >> immunity. Obviously it would be nice if they all did, but it is not an >> urgent problem. >> >> >> >> > But with participation from the CAs, it should be possible to >> >> realize >> >> >> the CT >> >> >> > dream far sooner. And (even in a future world where RFC5878 is >> >> >> supported >> >> >> > everywhere) if the CA takes care of CT proof distribution, then >> >> that >> >> >> makes >> >> >> > life easier for the certificate holder. >> >> >> > >> >> >> > >> >> >> >> Further, no one has yet brought up the privacy issue. CAs sell a >> >> lot >> >> >> of >> >> >> >> certificates to companies for their internal use. Some of them >> >> may >> >> >> object to >> >> >> >> publishing all their internal domain names. >> >> >> > >> >> >> > >> >> >> > This has been a concern for Comodo too, so I spoke to AGL about it >> >> a >> >> >> few >> >> >> > weeks ago. AIUI, the plan is that CT clients will have a user- >> >> >> configurable >> >> >> > whitelist (empty by default) of domain names for which CT proofs >> >> will >> >> >> not be >> >> >> > required. Participating CAs should allow customers to opt-out >> >> from >> >> >> having >> >> >> > their certs automatically logged with CT. >> >> > >> >> > I believe in your plan each browser will be a CT client. Aside from >> >> the fact that the white list is an attractive target for hackers, I >> >> don't see how the average user is going to know how to configure this >> >> white list. I'm reminded of Adam's arguments against Convergence >> >> (http://www.imperialviolet.org/2011/09/07/convergence.html). >> >> >> >> This is why I think the best solution is to issue private certs >> >> through a name constrained intermediate which is logged. >> > >> > I agree. >> >> I'm glad we agree on something! >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey > > > > > -- > Website: http://hallambaker.com/ > From paul.hoffman@vpnc.org Thu Nov 1 08:14:58 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7855221F8C9E for ; Thu, 1 Nov 2012 08:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDDeGg1YTwlr for ; Thu, 1 Nov 2012 08:14:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D29ED21F8C9C for ; Thu, 1 Nov 2012 08:14:57 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qA1FEu0R091470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 1 Nov 2012 08:14:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Thu, 1 Nov 2012 08:14:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> To: "therightkey@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 15:14:58 -0000 On Nov 1, 2012, at 2:10 AM, Ben Laurie wrote: > Its only software. The process of participating in CT for a server = operator is: >=20 > 1. Run command line tool once, giving it your certificate as input and > an SCT file as output. >=20 > 2. Add one line of configuration to your server config. >=20 > Not exactly rocket science. If people _really_ find it hard, we could > build it into the servers so there was no manual step at all. As someone who has to trust every CA in the root pile in my browsers and = OSs, I find it frightening that a CA who can say "this is your bank's = certificate" cannot handle new requirements for how to say that. If = adopting a simple protocol like this causes an ossified CA too many = problems, maybe I don't trust that CA to be able to issue certificates = for my bank, much less to be able to know which certificates that they = are actually issuing. --Paul Hoffman= From hallam@gmail.com Thu Nov 1 09:29:37 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1ECB21F8E2C for ; Thu, 1 Nov 2012 09:29:37 -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 kcvSW-55qwqk for ; Thu, 1 Nov 2012 09:29:32 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC2921F8A50 for ; Thu, 1 Nov 2012 09:29:32 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so2941954obq.31 for ; Thu, 01 Nov 2012 09:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p2VEFpfrKsqbwWH/eyk9EP60zeVeHHgafhL31TV/OR0=; b=dTSRp64pRpbQli1S+D79cl0dV1w4T5l48svDtc2cV4vlyC2OObwULjB3ESrctTCTMc +PdF/LCRxIRJ+O46Ms7osTExIbWP9mQUrGrFaFnqV6zhl8EhXeUrqGHWeADD1pNGQlyL f52p7EFub9RKe6unayhlF99u2+4AOfEpAPt98aP+4ad4vdstBMGDo9KQUEkT6vlA9WUA 7jPv9AdLdhuPP0d2UaEeXVdGFjybAi1DPhbg0ug5HyceQotecRc3cyEDu3FgTMwp/FQk jKmCCXdVSUz6VYMw9mX+HvrWxtj+sZS9AbFVB4U8jFWWcuRJvp21vfWyzByOK0dbELg8 pOiA== MIME-Version: 1.0 Received: by 10.182.145.35 with SMTP id sr3mr33263457obb.98.1351787371836; Thu, 01 Nov 2012 09:29:31 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Thu, 1 Nov 2012 09:29:31 -0700 (PDT) In-Reply-To: <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> Date: Thu, 1 Nov 2012 12:29:31 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=f46d044630781c335e04cd7186be Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 16:29:37 -0000 --f46d044630781c335e04cd7186be Content-Type: text/plain; charset=ISO-8859-1 This is about barely capable sysadmins. Different problem. On Thu, Nov 1, 2012 at 11:14 AM, Paul Hoffman wrote: > On Nov 1, 2012, at 2:10 AM, Ben Laurie wrote: > > > Its only software. The process of participating in CT for a server > operator is: > > > > 1. Run command line tool once, giving it your certificate as input and > > an SCT file as output. > > > > 2. Add one line of configuration to your server config. > > > > Not exactly rocket science. If people _really_ find it hard, we could > > build it into the servers so there was no manual step at all. > > As someone who has to trust every CA in the root pile in my browsers and > OSs, I find it frightening that a CA who can say "this is your bank's > certificate" cannot handle new requirements for how to say that. If > adopting a simple protocol like this causes an ossified CA too many > problems, maybe I don't trust that CA to be able to issue certificates for > my bank, much less to be able to know which certificates that they are > actually issuing. > > --Paul Hoffman > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > -- Website: http://hallambaker.com/ --f46d044630781c335e04cd7186be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is about barely capable sysadmins.=A0

Different pro= blem.


On= Thu, Nov 1, 2012 at 11:14 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Nov 1, 2012, at 2:10 AM, Ben Laurie <<= a href=3D"mailto:benl@google.com">benl@google.com> wrote:

> Its only software. The process of participating in CT for a server ope= rator is:
>
> 1. Run command line tool once, giving it your certificate as input and=
> an SCT file as output.
>
> 2. Add one line of configuration to your server config.
>
> Not exactly rocket science. If people _really_ find it hard, we could<= br> > build it into the servers so there was no manual step at all.

As someone who has to trust every CA in the root pile in my browsers and OS= s, I find it frightening that a CA who can say "this is your bank'= s certificate" cannot handle new requirements for how to say that. If = adopting a simple protocol like this causes an ossified CA too many problem= s, maybe I don't trust that CA to be able to issue certificates for my = bank, much less to be able to know which certificates that they are actuall= y issuing.

--Paul Hoffman
_______________________________________________
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey



-- Website: http://hallambaker.com/<= br>
--f46d044630781c335e04cd7186be-- From llynch@civil-tongue.net Thu Nov 1 09:38:34 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B257321F8D73 for ; Thu, 1 Nov 2012 09:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TE4P5AsBAS7 for ; Thu, 1 Nov 2012 09:38:34 -0700 (PDT) Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC2921F8D66 for ; Thu, 1 Nov 2012 09:38:34 -0700 (PDT) Received: from hiroshima.bogus.com (localhost [127.0.0.1]) by hiroshima.bogus.com (8.14.3/8.14.3) with ESMTP id qA1GcTDT069304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 1 Nov 2012 09:38:29 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Received: from localhost (llynch@localhost) by hiroshima.bogus.com (8.14.3/8.14.3/Submit) with ESMTP id qA1GcSw8069301; Thu, 1 Nov 2012 09:38:28 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Date: Thu, 1 Nov 2012 09:38:28 -0700 (PDT) From: Lucy Lynch X-X-Sender: llynch@hiroshima.bogus.com To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="===============7172665379058522590==" Cc: "therightkey@ietf.org" , Paul Hoffman Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 16:38:34 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============7172665379058522590== Content-Type: TEXT/Plain; format=flowed; charset=US-ASCII On Thu, 1 Nov 2012, Phillip Hallam-Baker wrote: > This is about barely capable sysadmins. I'm a barely capable sysadmin and the steps Ben outlined seem both reasonable and do-able to me. I also like the option to build it into the server where smart hands can build it into the default options for configuration - - Lucy > Different problem. > > > On Thu, Nov 1, 2012 at 11:14 AM, Paul Hoffman wrote: > >> On Nov 1, 2012, at 2:10 AM, Ben Laurie wrote: >> >>> Its only software. The process of participating in CT for a server >> operator is: >>> >>> 1. Run command line tool once, giving it your certificate as input and >>> an SCT file as output. >>> >>> 2. Add one line of configuration to your server config. >>> >>> Not exactly rocket science. If people _really_ find it hard, we could >>> build it into the servers so there was no manual step at all. >> >> As someone who has to trust every CA in the root pile in my browsers and >> OSs, I find it frightening that a CA who can say "this is your bank's >> certificate" cannot handle new requirements for how to say that. If >> adopting a simple protocol like this causes an ossified CA too many >> problems, maybe I don't trust that CA to be able to issue certificates for >> my bank, much less to be able to know which certificates that they are >> actually issuing. >> >> --Paul Hoffman >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey >> > > > > --===============7172665379058522590== Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey --===============7172665379058522590==-- From paul.hoffman@vpnc.org Thu Nov 1 09:46:23 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C3621F9078 for ; Thu, 1 Nov 2012 09:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyX-uGHLZyUN for ; Thu, 1 Nov 2012 09:46:23 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 256B121F9077 for ; Thu, 1 Nov 2012 09:46:23 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qA1GkLhI095475 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 1 Nov 2012 09:46:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Thu, 1 Nov 2012 09:46:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <59E2ABDF-EF90-4BBF-BC45-048BF4C2B848@vpnc.org> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD! 62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> To: "therightkey@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 16:46:23 -0000 On Nov 1, 2012, at 9:29 AM, Phillip Hallam-Baker = wrote: > This is about barely capable sysadmins.=20 >=20 > Different problem. =46rom the perspective of the relying party (me, caring about making a = secure connection to my bank), the problems are indistinguishable. A CA = who retains a sysadmin who is barely capable deserves less trust than = one who retains sysadmins who are capable. My bank, when trying to decide which CAs might get removed from the root = piles in the future, should also see the problems as indistinguishable. = That is, I would hope that my bank would pick a CA who is capable and = non-ossified so that, when the incapable and ossified CAs are removed = from the root piles, my bank doesn't need to get a new cert. I would not mind if adoption of certificate transparency hastens the = shedding of barely-capable CAs; the one-time hassle for some users would = be far outweighed by the longer-term benefit to the security of the = Internet. --Paul Hoffman= From Rick_Andrews@symantec.com Thu Nov 1 10:08:20 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AE421F8CF0 for ; Thu, 1 Nov 2012 10:08:20 -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 JDqEYxTfOnLW for ; Thu, 1 Nov 2012 10:08:20 -0700 (PDT) Received: from ecl1mtaoutpex02.symantec.com (ecl1mtaoutpex02.symantec.com [166.98.1.210]) by ietfa.amsl.com (Postfix) with ESMTP id D6B1D21F8C72 for ; Thu, 1 Nov 2012 10:08:19 -0700 (PDT) X-AuditID: a66201d2-b7fe86d000001f43-4a-5092ac811828 Received: from ecl1mtahubpin02.ges.symantec.com (ecl1mtahubpin02.ges.symantec.com [10.48.69.202]) by ecl1mtaoutpex02.symantec.com (Symantec Brightmail Gateway out) with SMTP id 2B.AA.08003.18CA2905; Thu, 1 Nov 2012 17:08:17 +0000 (GMT) Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by ecl1mtahubpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1TTyFc-0001DT-VO; Thu, 01 Nov 2012 17:08:17 +0000 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.147]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Thu, 1 Nov 2012 10:08:16 -0700 From: Rick Andrews To: Paul Hoffman , "therightkey@ietf.org" Date: Thu, 1 Nov 2012 10:08:14 -0700 Thread-Topic: [therightkey] Barely-capable CAs Thread-Index: Ac24Q6rnBZhjId8GTD6hebiSwYMWPwADrt8w Message-ID: <544B0DD62A64C1448B2DA253C0114146069F66FC37@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> In-Reply-To: <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsXCZeB6SrdxzaQAg9mLeCxurf/CavHxwk8W ByaPJUt+Mnl8nn2VOYApissmJTUnsyy1SN8ugSvjwuaJjAU/eCt2Pn3C0sDYzt3FyMkhIWAi sfzCZhYIW0ziwr31bF2MXBxCAu8YJSa3nmWFcF4xSpxqvwBWJSSwklHi0NJkEJtNQE9iy+Mr 7CC2iECkxOOZF5lAbBYBFYmt16aAxYUFdCUm7DzEBFGjJ/FnzxIWCNtI4tb/A2A1vAJREpcW djNBLJvLLTFx+VZGkASngI3EuhNNYEWMQOd9P7UGbBCzgLjErSfzmSDOFpBYsuc8M4QtKvHy 8T9WiHpRiTvt6xkh6nUkFuz+xAZha0ssW/iaGWKxoMTJmU9YJjCKzUIydhaSlllIWmYhaVnA yLKKUSY1OccwtyQxv7SkILXCwEivuDI3ERhNyXrJ+bmbGIERtSyJ8dIOxvuHdQ8xCnAwKvHw bmmfFCDEmlgGVHmIUYKDWUmE9/gKoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHe26VRAUIC6Ykl qdmpqQWpRTBZJg5OqQZGfafkMH2hmieGPAe2r/apFn9z6F+JEvPrrx9tT8gVPVzfsnfXuqv1 Wnu2vU2dkXRGMiLHNENLOd5qzhHz3cKzZp76rhh54dWmfWv9X4fnuvvebDNnjXx58eeyLMa7 EWapfbaKu3dbNvm/DVpwjE/6i8WXb/3x19+2GO4obed+9Oy+rHYXt6KQEktxRqKhFnNRcSIA IInggqQCAAA= Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 17:08:20 -0000 > -----Original Message----- > From: therightkey-bounces@ietf.org [mailto:therightkey- > bounces@ietf.org] On Behalf Of Paul Hoffman > Sent: Thursday, November 01, 2012 8:15 AM > To: therightkey@ietf.org > Subject: [therightkey] Barely-capable CAs >=20 > On Nov 1, 2012, at 2:10 AM, Ben Laurie wrote: >=20 > > Its only software. The process of participating in CT for a server > operator is: > > > > 1. Run command line tool once, giving it your certificate as input > and > > an SCT file as output. > > > > 2. Add one line of configuration to your server config. > > > > Not exactly rocket science. If people _really_ find it hard, we could > > build it into the servers so there was no manual step at all. >=20 > As someone who has to trust every CA in the root pile in my browsers > and OSs, I find it frightening that a CA who can say "this is your > bank's certificate" cannot handle new requirements for how to say that. > If adopting a simple protocol like this causes an ossified CA too many > problems, maybe I don't trust that CA to be able to issue certificates > for my bank, much less to be able to know which certificates that they > are actually issuing. Paul, I find your statements to be oversimplifications: 1) That the CT protocol is simple: I've been trying to make the point on th= is list that it may be conceptually simple but pretty difficult to implemen= t to the scale that is required. 2) That CAs can't handle new requirements: I'm not convinced that CT is the= silver bullet that some appear to claim it is. If you were referring to my= statements on this list, please don't interpret my criticism as inability = to handle new requirements. I think a debate on the merits is healthy. -Rick From hallam@gmail.com Thu Nov 1 10:22:37 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429CD21F9125 for ; Thu, 1 Nov 2012 10:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPZBxqw6IhNR for ; Thu, 1 Nov 2012 10:22:36 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5201721F9127 for ; Thu, 1 Nov 2012 10:22:36 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so3025027oag.31 for ; Thu, 01 Nov 2012 10:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RGKEbEdLwyR7fY36sTCdYqIjlAA4huew6TwsmH3N9gc=; b=IYOM+nwK/JSoTQbZ3nkZAoQ9kv6y6Mo7tcssAlLT9SRHeTnId01T9lkppijVdvmX4N QF4pd3iRj49dtu9QRE0t1pflI1G23iRLcVPfPnRgZOH8vHC5yQmKsdQTbCO8cssA9kMT PwJqTYBSMFCHh7vmj1LthRo0356u/n4tBG5ieVmqdHbDQZdeakSydubZJsIhbhrpCwFy nyoQwGo4ex+YjjBtWSJ+mvIKIqFZ28vYSMFmUJVTS2Qu2U8nW/mA1C4co759tC2DTK13 MjcQ1fqG3r+jNgOWw4BTsb8z7gyYBpnmyYWxKWZ/S5UZOmDzrBW+oEjv97h0VduFYnM5 B5TA== MIME-Version: 1.0 Received: by 10.60.7.41 with SMTP id g9mr34176133oea.18.1351790555871; Thu, 01 Nov 2012 10:22:35 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Thu, 1 Nov 2012 10:22:35 -0700 (PDT) In-Reply-To: References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> Date: Thu, 1 Nov 2012 13:22:35 -0400 Message-ID: From: Phillip Hallam-Baker To: Lucy Lynch Content-Type: multipart/alternative; boundary=e89a8fb20592e4b95604cd7243d5 Cc: "therightkey@ietf.org" , Paul Hoffman Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 17:22:37 -0000 --e89a8fb20592e4b95604cd7243d5 Content-Type: text/plain; charset=ISO-8859-1 >From my perspective it is much cheaper for me to build a tool that does the job right and give it to you than to follow the usual approach of yet more poorly designed and documented stuff that might work or might not. Having worked in Web security over 20 years now, I have still to see a case where a system was breached because of a really subtle design flaw. Every security issue I have seen has been really simple once it has been identified and isolated. Computer systems are hard to run and harder to secure because of the volume of complexity rather than the degree of complexity. Each individual step is trivial in itself but the cumulative effect is very large. I am sitting next to the print edition of the Oxford English Dictionary which is 20 volumes of dense print. It is something like 200Mb in total. That was the pinacle of achievement of Victorian research taking several decades and thousands of authors. Modern operating systems and applications are much larger. And because we design and build them in the wrong way it only takes one mistake for them to fail. One way that real world sysops defend themselves against complexity is to refuse to learn anything that is new. Judging the deployability of a protocol change based on whether IETF participants are able to do so and willing to invest the necessary effort skews the sample badly. If it were left to us we would have been using IPv6 for over a decade already. On Thu, Nov 1, 2012 at 12:38 PM, Lucy Lynch wrote: > On Thu, 1 Nov 2012, Phillip Hallam-Baker wrote: > > This is about barely capable sysadmins. >> > > I'm a barely capable sysadmin and the steps Ben outlined seem both > reasonable and do-able to me. I also like the option to build it into the > server where smart hands can build it into the default options for > configuration - > > - Lucy > > > Different problem. >> >> >> On Thu, Nov 1, 2012 at 11:14 AM, Paul Hoffman >> wrote: >> >> On Nov 1, 2012, at 2:10 AM, Ben Laurie wrote: >>> >>> Its only software. The process of participating in CT for a server >>>> >>> operator is: >>> >>>> >>>> 1. Run command line tool once, giving it your certificate as input and >>>> an SCT file as output. >>>> >>>> 2. Add one line of configuration to your server config. >>>> >>>> Not exactly rocket science. If people _really_ find it hard, we could >>>> build it into the servers so there was no manual step at all. >>>> >>> >>> As someone who has to trust every CA in the root pile in my browsers and >>> OSs, I find it frightening that a CA who can say "this is your bank's >>> certificate" cannot handle new requirements for how to say that. If >>> adopting a simple protocol like this causes an ossified CA too many >>> problems, maybe I don't trust that CA to be able to issue certificates >>> for >>> my bank, much less to be able to know which certificates that they are >>> actually issuing. >>> >>> --Paul Hoffman >>> ______________________________**_________________ >>> therightkey mailing list >>> therightkey@ietf.org >>> https://www.ietf.org/mailman/**listinfo/therightkey >>> >>> >> >> >> > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > > -- Website: http://hallambaker.com/ --e89a8fb20592e4b95604cd7243d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >From my perspective it is much cheaper for me to build a tool that does the= job right and give it to you than to follow the usual approach of yet more= poorly designed and documented stuff that might work or might not.

Having worked in Web security over 20 years now, I have stil= l to see a case where a system was breached because of a really subtle desi= gn flaw. Every security issue I have seen has been really simple once it ha= s been identified and isolated.

Computer systems are hard to run and harder to secure b= ecause of the volume of complexity rather than the degree of complexity. Ea= ch individual step is trivial in itself but the cumulative effect is very l= arge. I am sitting next to the print edition of the Oxford English Dictiona= ry which is 20 volumes of dense print. It is something like 200Mb in total.= That was the pinacle of achievement of Victorian research taking several d= ecades and thousands of authors. Modern operating systems and applications = are much larger. And because we design and build them in the wrong way it o= nly takes one mistake for them to fail.

One way that real world sysops defend themselves agains= t complexity is to refuse to learn anything that is new.


Judging the deployability of a protocol change based = on whether IETF participants are able to do so and willing to invest the ne= cessary effort skews the sample badly. If it were left to us we would have = been using IPv6 for over a decade already.



On Thu, Nov 1, 2012 at 12:38 PM, Lucy Lynch <llynch@civil-tongue.n= et> wrote:
On Thu, 1 Nov 2012, Philli= p Hallam-Baker wrote:

This is about barely capable sysadmins.

I'm a barely capable sysadmin and the steps Ben outlined seem both reas= onable and do-able to me. I also like the option to build it into the serve= r where smart hands can build it into the default options for configuration= -

- Lucy


Different problem.


On Thu, Nov 1, 2012 at 11:14 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

On Nov 1, 2012, at 2:10 AM, Ben Laurie <benl@google.com> wrote:

Its only software. The process of participating in CT for a server
operator is:

1. Run command line tool once, giving it your certificate as input and
an SCT file as output.

2. Add one line of configuration to your server config.

Not exactly rocket science. If people _really_ find it hard, we could
build it into the servers so there was no manual step at all.

As someone who has to trust every CA in the root pile in my browsers and OSs, I find it frightening that a CA who can say "this is your bank= 9;s
certificate" cannot handle new requirements for how to say that. If adopting a simple protocol like this causes an ossified CA too many
problems, maybe I don't trust that CA to be able to issue certificates = for
my bank, much less to be able to know which certificates that they are
actually issuing.

--Paul Hoffman
_______________________________________________
therightkey mailing list
therightkey@ietf.= org
https://www.ietf.org/mailman/listinfo/therightkey





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




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

--e89a8fb20592e4b95604cd7243d5-- From stephen.farrell@cs.tcd.ie Thu Nov 1 11:00:59 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E9D21F9106 for ; Thu, 1 Nov 2012 11:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5J8X-hLVaiv for ; Thu, 1 Nov 2012 11:00:59 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 69DEC21F8F29 for ; Thu, 1 Nov 2012 11:00:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BD8EDBE2B; Thu, 1 Nov 2012 18:00:37 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wpc0noUDGzdW; Thu, 1 Nov 2012 18:00:37 +0000 (GMT) Received: from [10.87.48.4] (unknown [86.44.75.237]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F0C55BE29; Thu, 1 Nov 2012 18:00:36 +0000 (GMT) Message-ID: <5092B8C4.3070607@cs.tcd.ie> Date: Thu, 01 Nov 2012 18:00:36 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Lucy Lynch , "therightkey@ietf.org" , Paul Hoffman Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 18:01:00 -0000 On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote: > Having worked in Web security over 20 years now, I have still to see a case > where a system was breached because of a really subtle design flaw. Bleichenbacher? S. From paul.hoffman@vpnc.org Thu Nov 1 11:01:42 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DCD21F9186 for ; Thu, 1 Nov 2012 11:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJo-BW8zGYIw for ; Thu, 1 Nov 2012 11:01:41 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6160921F9122 for ; Thu, 1 Nov 2012 11:01:41 -0700 (PDT) Received: from sn84.proper.com (sn84.proper.com [75.101.18.84]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qA1I1cWe098134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 1 Nov 2012 11:01:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <544B0DD62A64C1448B2DA253C0114146069F66FC37@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Thu, 1 Nov 2012 11:01:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069F66FC37@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> To: "therightkey@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 18:01:42 -0000 On Nov 1, 2012, at 10:08 AM, Rick Andrews = wrote: >> As someone who has to trust every CA in the root pile in my browsers >> and OSs, I find it frightening that a CA who can say "this is your >> bank's certificate" cannot handle new requirements for how to say = that. >> If adopting a simple protocol like this causes an ossified CA too = many >> problems, maybe I don't trust that CA to be able to issue = certificates >> for my bank, much less to be able to know which certificates that = they >> are actually issuing. >=20 > Paul, I find your statements to be oversimplifications: >=20 > 1) That the CT protocol is simple: I've been trying to make the point = on this list that it may be conceptually simple but pretty difficult to = implement to the scale that is required. Required by whom? Your scale arguments have, I believe, been that we = need the same number of CAs in the root pile as we do now, and that we = need dozens of auditors for the relying parties to choose from. For me = as a relying part, neither of those are true. If I'm wrong about my interpretation of your scale arguments, by all = means start a new thread on this list with a concise statement of what = you think is required for scaling.=20 > 2) That CAs can't handle new requirements: That's silly: I believe that many CAs can handle the new requirements = just fine. > I'm not convinced that CT is the silver bullet that some appear to = claim it is. Now you're putting words in other people's mouths, not a great tactic in = the IETF. The term "silver bullet" has not appeared on this list, and I = don't remember anyone using anything at all similar when describing = certificate transparency. > If you were referring to my statements on this list, please don't = interpret my criticism as inability to handle new requirements. I didn't. > I think a debate on the merits is healthy. Yes, that's why we are all here. --Paul Hoffman= From hallam@gmail.com Thu Nov 1 11:13:31 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E7E21F8E65 for ; Thu, 1 Nov 2012 11:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.505 X-Spam-Level: X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=0.093, 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 GNHwXMV1BDIs for ; Thu, 1 Nov 2012 11:13:30 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF89E21F8E41 for ; Thu, 1 Nov 2012 11:13:30 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so3062542obq.31 for ; Thu, 01 Nov 2012 11:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/E9XaP/2UxBsXiIxRcspQUBoHOEV3cujffvE2GwfTQI=; b=Tb5tHSy7sxpefTrZpmSa623gKNsrr9HokN2qAr4+XerL9QzLbYsBlzWUgGdzVsoipT 72OA+RDN2yazzBmSzT/PUSeRKYV2o+9nlcbFm0aY0/RMg54B//rhLQiL3uxdmAt7QkoI +ccdQ3d0XE5n8oFFkN8a/fIlhKXUDvRzCfij+dgPGR0nYA8oZQc42gJzohruEJugKFzT qU1cxNPhJMvg0ZzoCnQ1DPz90xarxfs8VDlVIp5K0ZENvtveuqsS+GsmdXJcMaSqW8kK K6P8xy+sQDqj6l/NgFi6Ijcsy/oLAdCvLWSpXS+ReTiRCWCyEDGvI8tZA/fQfkXtvjhE vbzQ== MIME-Version: 1.0 Received: by 10.182.54.103 with SMTP id i7mr33616534obp.62.1351793610222; Thu, 01 Nov 2012 11:13:30 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Thu, 1 Nov 2012 11:13:30 -0700 (PDT) In-Reply-To: <5092B8C4.3070607@cs.tcd.ie> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> <5092B8C4.3070607@cs.tcd.ie> Date: Thu, 1 Nov 2012 14:13:30 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=14dae93a113df26af104cd72f953 Cc: Lucy Lynch , "therightkey@ietf.org" , Paul Hoffman Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 18:13:31 -0000 --14dae93a113df26af104cd72f953 Content-Type: text/plain; charset=ISO-8859-1 Which depended on a subtle mistake in the SSL 3.0 protocol. Specifically, it gave a different report depending on whether the text decrypted or not. Rather ironically here, the specific flaw in SSL 3.0 that made the attack possible was one that the designer of 3.0 had actually played a major part in raising in the civil field. Paul Kocher's other work being exploiting differences in the physical behavior of devices running crypto (timing, behavior in fault situation, radiation). Now if Netscape had not been so chronically mismanaged as to only allow Paul two weeks to review the spec and to only give Knight 10 days to write Javascript, well the history of Web Security might have been rather different. On Thu, Nov 1, 2012 at 2:00 PM, Stephen Farrell wrote: > > > On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote: > > Having worked in Web security over 20 years now, I have still to see a > case > > where a system was breached because of a really subtle design flaw. > > Bleichenbacher? > > S. > -- Website: http://hallambaker.com/ --14dae93a113df26af104cd72f953 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Which depended on a subtle mistake in the SSL 3.0 protocol. Specifically, i= t gave a different report depending on whether the text decrypted or not.
Rather ironically here, the specific flaw in SSL 3.0 that= made the attack possible was one that the designer of 3.0 had actually pla= yed a major part in raising in the civil field. Paul Kocher's other wor= k being exploiting differences in the physical behavior of devices running = crypto (timing, behavior in fault situation, radiation).

Now if Netscape had not been so chronically mismanaged = as to only allow Paul two weeks to review the spec and to only give Knight = 10 days to write Javascript, well the history of Web Security might have be= en rather different.




On Thu, Nov 1, 2012 at 2:00 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote:
> Having worked in Web security over 20 years now, I have still to see a= case
> where a system was breached because of a really subtle design flaw.
Bleichenbacher?

S.



-- Website: http://hallambaker.com/<= br>
--14dae93a113df26af104cd72f953-- From benl@google.com Thu Nov 1 11:35:13 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707DB21F92D8 for ; Thu, 1 Nov 2012 11:35:13 -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 OI4ZpG4EY7Zu for ; Thu, 1 Nov 2012 11:35:12 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5C67D21F92D6 for ; Thu, 1 Nov 2012 11:35:12 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so1411199wey.31 for ; Thu, 01 Nov 2012 11:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=eS4MzQuThURyRIo9XjpWEirl9cD6VW2OqYSCrffKWDU=; b=Qx87YEkv7iqWAIfkqRYpT4tJDG9KAFyWCa6UF0Lc0A6CvNrz4Fg5ACg4G7tUaiERmm QRMi7Z8pBguF8YUQYS1TxP1Lj46Z4CMp56OJSrWMFx/Ra4UueqvCsGnMjvCsGrsAlN4+ YN8S8HeJsYG9NJzFLpIY2SlS1TgQNxi4TMiCc5kA8l8wKnYwhBDcaiW6gKlV6tcYHGjZ 9Aaa9CvPI0XsAriR6/VROSs0c9oO9w+XiwhLtBZU0Ztz+2QsXUloNtstxy4RU3Gg726j gDDkV8cenvWzwJ7/IS3uvNV2+mLLWOjTu7XP8GWi5hMLrbeIrppjYtyCcpTROBnsnLRh Vr1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=eS4MzQuThURyRIo9XjpWEirl9cD6VW2OqYSCrffKWDU=; b=C7P5c6aXWjPU0uVeO1iTJ66oeI6609xtG8OXZlOJnt7Ah92BAOqmsoMQx9q+xNBt2k NAmD0GDvpNCiE4A8iw1fMPqNlA6lxZ6X4PlvURqnpyO8tRuUSix7EoIM5opt+1+XhGbW zZLxleyJli79rysBj0XwtiVnwhPkGgouJ26A4rRZHGBzTjXVwUTYO5HVVwbX8ab2pom6 XCiVd3e4X4404unLUtbTwaqfAjHxz3CMxhq+2dCgHRU7pzafLmxPlAlWWJ99FAKQWosH p4kGw3OV6e9YoGyXiGNLrFD6JoMxim8ZAEgk8eZdqRMfYlKqaYK8GcpfAaMG3rJuP4SK M4Ig== MIME-Version: 1.0 Received: by 10.216.193.220 with SMTP id k70mr21848110wen.35.1351794911397; Thu, 01 Nov 2012 11:35:11 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Thu, 1 Nov 2012 11:35:11 -0700 (PDT) In-Reply-To: <5092B8C4.3070607@cs.tcd.ie> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> <5092B8C4.3070607@cs.tcd.ie> Date: Thu, 1 Nov 2012 18:35:11 +0000 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQk+U4uchRjxaN/2TlNWIWY12c+t9XIBGSYUPY+qNrOULmCcY9z9wREFZGFd4OwSBqlB3U4I6lePEV3yllxDhdt/PgZtJgHk0uaFR1p1X7cpepnGRovdrsbBdiIRbUo0bk/aRTc/qbtrJ8mHD9CTU5nUIFSjCloV5/xBVsXg2w9LKMGUuQIB/Mj7RNMICChtsE8GueDa Cc: Lucy Lynch , Phillip Hallam-Baker , "therightkey@ietf.org" , Paul Hoffman Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 18:35:13 -0000 On 1 November 2012 18:00, Stephen Farrell wrote: > > > On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote: >> Having worked in Web security over 20 years now, I have still to see a case >> where a system was breached because of a really subtle design flaw. > > Bleichenbacher? TLS renegotiation? > > S. > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey From hallam@gmail.com Thu Nov 1 11:38:48 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4781A21F92EE for ; Thu, 1 Nov 2012 11:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.515 X-Spam-Level: X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=0.083, 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 IA7Ca3cEVooF for ; Thu, 1 Nov 2012 11:38:47 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 83E8D21F9304 for ; Thu, 1 Nov 2012 11:38:47 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so3111358oag.31 for ; Thu, 01 Nov 2012 11:38:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bM+q2mTdmO1xgLrohDEV5mvhIHjA58AjoRbUsbK9WPk=; b=pKuZmpfCETSGw+a602EMpzPaV1gxBAmlbXGHLvMh0FKydJpmODuMjPJE9jQ8FkMKDN LsPk1u/UchZyH+Lc4I0KjVk9PUvOcmz5e+5ATk8O86VaQng528qgyiskxzF3coK2GEiu q/cOWD+XWEDjyE6EQRYyhL5bJ6QqM9T961rY8I6X963otqmDt6icp5Xpp61yBvAwq8fl ZDiW0ZkIS8PiJoRz5+plMj+AaG2FAEYTFZj1GnL+htVxieKyEdJYej2Yng6VxppjhFHf B1LZNx1jCyCP/qzxCzQ8ae3z+pXd7zDnfNHL8reNyfkhJTsocVOS6TjdazQweOFTCMiq 7DZg== MIME-Version: 1.0 Received: by 10.60.14.198 with SMTP id r6mr34182349oec.115.1351795127203; Thu, 01 Nov 2012 11:38:47 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Thu, 1 Nov 2012 11:38:47 -0700 (PDT) In-Reply-To: References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> <5092B8C4.3070607@cs.tcd.ie> Date: Thu, 1 Nov 2012 14:38:47 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=e89a8fb1f72c5db5b304cd735486 Cc: Lucy Lynch , Paul Hoffman , "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 18:38:48 -0000 --e89a8fb1f72c5db5b304cd735486 Content-Type: text/plain; charset=ISO-8859-1 Again, does it appear so subtle after it has been discovered? Would the flaw have been discovered sooner if there was not so much dead code? On Thu, Nov 1, 2012 at 2:35 PM, Ben Laurie wrote: > On 1 November 2012 18:00, Stephen Farrell > wrote: > > > > > > On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote: > >> Having worked in Web security over 20 years now, I have still to see a > case > >> where a system was breached because of a really subtle design flaw. > > > > Bleichenbacher? > > TLS renegotiation? > > > > > S. > > _______________________________________________ > > therightkey mailing list > > therightkey@ietf.org > > https://www.ietf.org/mailman/listinfo/therightkey > -- Website: http://hallambaker.com/ --e89a8fb1f72c5db5b304cd735486 Content-Type: text/html; charset=ISO-8859-1 Again, does it appear so subtle after it has been discovered?

Would the flaw have been discovered sooner if there was not so much dead code?


On Thu, Nov 1, 2012 at 2:35 PM, Ben Laurie <benl@google.com> wrote:
On 1 November 2012 18:00, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>
>
> On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote:
>> Having worked in Web security over 20 years now, I have still to see a case
>> where a system was breached because of a really subtle design flaw.
>
> Bleichenbacher?

TLS renegotiation?

>
> S.
> _______________________________________________
> therightkey mailing list
> therightkey@ietf.org
> https://www.ietf.org/mailman/listinfo/therightkey



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

--e89a8fb1f72c5db5b304cd735486-- From rob.stradling@comodo.com Thu Nov 1 11:52:43 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5219621F9393 for ; Thu, 1 Nov 2012 11:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 bZnznokh0kAv for ; Thu, 1 Nov 2012 11:52:42 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id EE56021F9327 for ; Thu, 1 Nov 2012 11:52:41 -0700 (PDT) Received: (qmail 2924 invoked from network); 1 Nov 2012 18:52:40 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 1 Nov 2012 18:52:40 -0000 Received: (qmail 31209 invoked by uid 1000); 1 Nov 2012 18:52:40 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 01 Nov 2012 18:52:40 +0000 Message-ID: <5092C4F7.1060908@comodo.com> Date: Thu, 01 Nov 2012 18:52:39 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Paul Hoffman References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD! 62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> <59E2ABDF-EF90-4BBF-BC45-048BF4C2B848@vpnc.org> In-Reply-To: <59E2ABDF-EF90-4BBF-BC45-048BF4C2B848@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 18:52:43 -0000 On 01/11/12 16:46, Paul Hoffman wrote: > On Nov 1, 2012, at 9:29 AM, Phillip Hallam-Baker wrote: > >> This is about barely capable sysadmins. >> >> Different problem. > >>From the perspective of the relying party (me, caring about making a secure connection to my bank), the problems are indistinguishable. A CA who retains a sysadmin who is barely capable Paul, this is about barely capable sysadmins _at your bank_, not at the CA. (Ben wrote "The process of participating in CT for a _server operator_ is...") > deserves less trust than one who retains sysadmins who are capable. Obviously I agree that CAs should retain capable sysadmins. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nico@cryptonector.com Thu Nov 1 12:26:01 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E50D21F9260 for ; Thu, 1 Nov 2012 12:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5l2Uamt4A1Z for ; Thu, 1 Nov 2012 12:26:01 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1A90021F91E7 for ; Thu, 1 Nov 2012 12:26:01 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 9A6F57E4062 for ; Thu, 1 Nov 2012 12:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=KCAFRHP/NBrDUq/FupFg jbptDQA=; b=CKBHN2rKlhNf65PuXad5zGMCBCOYM/spWB+BmbTJmXSQ+tqoyfQF jW8FORo2x4MlTkKIV3BKI6Sx084K7v3GbQaK+RI6OOrE7Wj3xr9k7I6ZkEdih/Mf O6QE5ItkXuhVLgetgUNo5t2fDD0ow2X7ZsFhyrPfgx/ZRmx+S0vlCRw= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id 80DB67E405D for ; Thu, 1 Nov 2012 12:26:00 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so1949165pbb.31 for ; Thu, 01 Nov 2012 12:26:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.86.101 with SMTP id o5mr225352paz.15.1351797960096; Thu, 01 Nov 2012 12:26:00 -0700 (PDT) Received: by 10.68.128.234 with HTTP; Thu, 1 Nov 2012 12:26:00 -0700 (PDT) In-Reply-To: References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> Date: Thu, 1 Nov 2012 14:26:00 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: "therightkey@ietf.org" , Paul Hoffman Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 19:26:01 -0000 On Thu, Nov 1, 2012 at 11:29 AM, Phillip Hallam-Baker wrote: > This is about barely capable sysadmins. And the barely capable management that fails to make up for barely capable sysadmins by, e.g., hiring actually capable sysadmins or engaging consultants to help with occasional operations changes like CT. Nico -- From benl@google.com Thu Nov 1 12:52:29 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED8921F9580 for ; Thu, 1 Nov 2012 12:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.736 X-Spam-Level: X-Spam-Status: No, score=-102.736 tagged_above=-999 required=5 tests=[AWL=0.241, 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 LuG7laJzLk-G for ; Thu, 1 Nov 2012 12:52:28 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 261F721F94B6 for ; Thu, 1 Nov 2012 12:52:27 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so578071wib.13 for ; Thu, 01 Nov 2012 12:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=BX0ZCCSLKt3JffhLwfnXUWAk8JPzlqrA517Mvtz/Sqg=; b=Nk3Efqhvy4YCgPCBz36Td9fM/YtPiBWPlZTA5BeWfWZRFNYWEiYTB+AJYAacttdnDX KW2jej/0FwhIn+K1VWghNMZujAytR9tTi1HPWYgStkzSqeSFmL7113HJFPD1d3YhEBBh Is3wjLCT+j0x20PhdGqG6lLraVXHLu+V6rMpqGK6VtBS2mey2PVvddqe7jyzIoyUPg6r J+tMl9yOWwQEu/Qxqb44h5xELLBgy+SRmRY8Q956L6I7ssTSDS3bJLW40C+KqCE1RS9B 6152gUEUeHr6BwcwEjStz0dRG9RU4lwNwf2Cp4EhATOVMXENe4aF9hK5AKLbiqalQaWn ak0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=BX0ZCCSLKt3JffhLwfnXUWAk8JPzlqrA517Mvtz/Sqg=; b=j7GJ+7uhmTlSZhM//iX4FUiWR3SQ8Hr597Rue40NnF3GI8tXaTf310blGQeyXNezGR of8R88Xp6dPZhsVWyTFmwXPY3XwxpdWORLw3eVEdyOZXnAMs010wmu59a+wwcwbl7Kfi wCfwSWIbvQ1cQd4edT4iatVdke6fUYb3e5cAeq6y01fCbAV4f3pcWwUhQnyLsY/r/3HH sIN3QXxmgu7TWUAlxONLdPBIuCFvnIpYs9qBN+vxWBS2z8bzKLpMUpZRtv2RCtYCBOFz SKRmnWy6sYX6ezGwSySUbyp5gOe1QNEcZLR/iQi5EWbbsR5uHtTG2sIh6mQVQXT8JjP8 L9vQ== MIME-Version: 1.0 Received: by 10.181.11.167 with SMTP id ej7mr3408657wid.11.1351799547002; Thu, 01 Nov 2012 12:52:27 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Thu, 1 Nov 2012 12:52:26 -0700 (PDT) In-Reply-To: References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> <5092B8C4.3070607@cs.tcd.ie> Date: Thu, 1 Nov 2012 19:52:26 +0000 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnPqRYHZzc7Lh0KGCNR3hluuO9ea4Ma3G7txoUtHPx6OnEuq+FdtLKNWICudpWmiRbE/bjezBpnd09SSe2TTmaDNibQ4LV7so0Zf99plDQ27M635FL7rc+NmAhsQv6CJ3RGNKL95d14/lOzEh3eFsrNigXyBuAye2gUxd+Tx51RwuOQc3m63ClQyKFrslbHCcH6deX2 Cc: Lucy Lynch , Paul Hoffman , "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 19:52:29 -0000 On 1 November 2012 18:38, Phillip Hallam-Baker wrote: > Again, does it appear so subtle after it has been discovered? Well, I find I have to remind myself how it works. So ... yeah. Also, I assumed Bliechanbacher was the exponent 3 thing, which was also pretty subtle. > > Would the flaw have been discovered sooner if there was not so much dead > code? I don't think dead code had any influence on either of these. > > > On Thu, Nov 1, 2012 at 2:35 PM, Ben Laurie wrote: >> >> On 1 November 2012 18:00, Stephen Farrell >> wrote: >> > >> > >> > On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote: >> >> Having worked in Web security over 20 years now, I have still to see a >> >> case >> >> where a system was breached because of a really subtle design flaw. >> > >> > Bleichenbacher? >> >> TLS renegotiation? >> >> > >> > S. >> > _______________________________________________ >> > therightkey mailing list >> > therightkey@ietf.org >> > https://www.ietf.org/mailman/listinfo/therightkey > > > > > -- > Website: http://hallambaker.com/ > From paul.hoffman@vpnc.org Thu Nov 1 12:54:43 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF35B21F959D for ; Thu, 1 Nov 2012 12:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYj-EOovmCOe for ; Thu, 1 Nov 2012 12:54:41 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFE921F959C for ; Thu, 1 Nov 2012 12:54:40 -0700 (PDT) Received: from sn84.proper.com (sn84.proper.com [75.101.18.84]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qA1JsJeK001869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Nov 2012 12:54:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <5092C4F7.1060908@comodo.com> Date: Thu, 1 Nov 2012 12:54:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD! 62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> <59E2ABDF-EF90-4BBF-BC45-048BF4C2B848@vpnc.org> <5092C4F7.106! 0908@comodo.com> To: Rob Stradling X-Mailer: Apple Mail (2.1499) Cc: therightkey@ietf.org Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 19:54:43 -0000 On Nov 1, 2012, at 11:52 AM, Rob Stradling = wrote: > On 01/11/12 16:46, Paul Hoffman wrote: >> On Nov 1, 2012, at 9:29 AM, Phillip Hallam-Baker = wrote: >>=20 >>> This is about barely capable sysadmins. >>>=20 >>> Different problem. >>=20 >>> =46rom the perspective of the relying party (me, caring about making = a secure connection to my bank), the problems are indistinguishable. A = CA who retains a sysadmin who is barely capable >=20 > Paul, this is about barely capable sysadmins _at your bank_, not at = the CA. >=20 > (Ben wrote "The process of participating in CT for a _server operator_ = is...") OK, maybe I'm confused here, or maybe you are. If my bank has a = certificate issued by a CA who is actively participating in CT, there is = no requirement on the bank at all, correct? --Paul Hoffman= From rob.stradling@comodo.com Thu Nov 1 13:00:06 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BA421F9493 for ; Thu, 1 Nov 2012 13:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 cwNGaxfGBWYg for ; Thu, 1 Nov 2012 13:00:06 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id F3ED621F948B for ; Thu, 1 Nov 2012 13:00:05 -0700 (PDT) Received: (qmail 23765 invoked from network); 1 Nov 2012 20:00:04 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 1 Nov 2012 20:00:04 -0000 Received: (qmail 28949 invoked by uid 1000); 1 Nov 2012 20:00:03 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 01 Nov 2012 20:00:03 +0000 Message-ID: <5092D4C1.2000701@comodo.com> Date: Thu, 01 Nov 2012 20:00:01 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Paul Hoffman References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD! 62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> <59E2ABDF-EF90-4BBF-BC45-048BF4C2B848@vpnc.org> <5092C4F7.106! 0908@comodo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 20:00:07 -0000 On 01/11/12 19:54, Paul Hoffman wrote: > On Nov 1, 2012, at 11:52 AM, Rob Stradling wrote: > >> On 01/11/12 16:46, Paul Hoffman wrote: >>> On Nov 1, 2012, at 9:29 AM, Phillip Hallam-Baker wrote: >>> >>>> This is about barely capable sysadmins. >>>> >>>> Different problem. >>> >>>> From the perspective of the relying party (me, caring about making a secure connection to my bank), the problems are indistinguishable. A CA who retains a sysadmin who is barely capable >> >> Paul, this is about barely capable sysadmins _at your bank_, not at the CA. >> >> (Ben wrote "The process of participating in CT for a _server operator_ is...") > > OK, maybe I'm confused here, or maybe you are. If my bank has a certificate issued by a CA who is actively participating in CT, there is no requirement on the bank at all, correct? If by "actively participating" you mean that the CA has embedded the CT proof in the cert, then yes, there is no requirement on the bank. If the CA instead embeds the CT proof in OCSP Responses relating to the cert, then there is no requirement on the bank apart from to use OCSP Stapling. If the CA is not participating in either of these 2 ways, then there is a requirement on the bank (aka the "server operator"), which may or may not be rocket science, depending on your opinion. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From hallam@gmail.com Thu Nov 1 13:01:04 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523EF21F95C8 for ; Thu, 1 Nov 2012 13:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.076, 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 HGHpx5hPjSBC for ; Thu, 1 Nov 2012 13:01:03 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEF221F95C7 for ; Thu, 1 Nov 2012 13:01:03 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so3172669obq.31 for ; Thu, 01 Nov 2012 13:01:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=to9sAZYtEfkJHgnnDWDQN1K25s8qrNG/2GX2ih2s6aI=; b=qwQvyLsnUJJ2RV+Djn9EccoTFhj1SYVBG2N6bsT/gASQS4Kwxt5/7hIbZ99VcQS9tH 4EQAvetjtS03lSGfJ8fJvxvmpU94A8sw+NPmZWSe5Y8h0rHiLyIxJh2qpJmVQsUJYFIX B6y+VFnBfG3wT4V9VUhP2gk4CmgS964REFXFXJt3USmONwqjAtHS/iMuMatA9b9NYHMl jkwspc0DFKDoBgGLg5PITxEGsVHadAIZS712CGOOVpEn9FxIHznMpXFoaQedaLhbWz55 CclwFuQ/diI3/Xy2wsG4Xb1C1T+VfQeRfQOBeU0cwEnelAfqiz0T1LxBuX8feMTc3cxG gVoQ== MIME-Version: 1.0 Received: by 10.60.36.73 with SMTP id o9mr1043613oej.23.1351800063124; Thu, 01 Nov 2012 13:01:03 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Thu, 1 Nov 2012 13:01:03 -0700 (PDT) In-Reply-To: References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> <5092B8C4.3070607@cs.tcd.ie> Date: Thu, 1 Nov 2012 16:01:03 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=14dae9c099b891e50304cd747a60 Cc: Lucy Lynch , Paul Hoffman , "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 20:01:04 -0000 --14dae9c099b891e50304cd747a60 Content-Type: text/plain; charset=ISO-8859-1 OK so some examples do exist. But really what proportion of real world compromises do not involve something bone headed like using a 512 bit key for DKIM signatures? What I am saying here is not 'don't do CT', I am saying that we have to make the ease of administration a high priority in the design. On Thu, Nov 1, 2012 at 3:52 PM, Ben Laurie wrote: > On 1 November 2012 18:38, Phillip Hallam-Baker wrote: > > Again, does it appear so subtle after it has been discovered? > > Well, I find I have to remind myself how it works. So ... yeah. > > Also, I assumed Bliechanbacher was the exponent 3 thing, which was > also pretty subtle. > > > > > Would the flaw have been discovered sooner if there was not so much dead > > code? > > I don't think dead code had any influence on either of these. > > > > > > > On Thu, Nov 1, 2012 at 2:35 PM, Ben Laurie wrote: > >> > >> On 1 November 2012 18:00, Stephen Farrell > >> wrote: > >> > > >> > > >> > On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote: > >> >> Having worked in Web security over 20 years now, I have still to see > a > >> >> case > >> >> where a system was breached because of a really subtle design flaw. > >> > > >> > Bleichenbacher? > >> > >> TLS renegotiation? > >> > >> > > >> > S. > >> > _______________________________________________ > >> > therightkey mailing list > >> > therightkey@ietf.org > >> > https://www.ietf.org/mailman/listinfo/therightkey > > > > > > > > > > -- > > Website: http://hallambaker.com/ > > > -- Website: http://hallambaker.com/ --14dae9c099b891e50304cd747a60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OK so some examples do exist. But really what proportion of real world comp= romises do not involve something bone headed like using a 512 bit key for D= KIM signatures?

What I am saying here is not 'don= 9;t do CT', I am saying that we have to make the ease of administration= a high priority in the design.


On Thu, Nov 1= , 2012 at 3:52 PM, Ben Laurie <benl@google.com> wrote:
On 1 November 2012 18:38, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> Again, does it appear so subtle after it has been discovered?

Well, I find I have to remind myself how it works. So ... yeah.

Also, I assumed Bliechanbacher was the exponent 3 thing, which was
also pretty subtle.

>
> Would the flaw have been discovered sooner if there was not so much de= ad
> code?

I don't think dead code had any influence on either of these.

>
>
> On Thu, Nov 1, 2012 at 2:35 PM, Ben Laurie <benl@google.com> wrote:
>>
>> On 1 November 2012 18:00, Stephen Farrell <stephen.farrell@cs.tcd.ie>
>> wrote:
>> >
>> >
>> > On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote:
>> >> Having worked in Web security over 20 years now, I have s= till to see a
>> >> case
>> >> where a system was breached because of a really subtle de= sign flaw.
>> >
>> > Bleichenbacher?
>>
>> TLS renegotiation?
>>
>> >
>> > S.
>> > _______________________________________________
>> > therightkey mailing list
>> > therightkey@ietf.org<= /a>
>> > https://www.ietf.org/mailman/listinfo/therightkey >
>
>
>
> --
> Website: http://= hallambaker.com/
>



--
= Website: http://hallambaker.com/
--14dae9c099b891e50304cd747a60-- From rob.stradling@comodo.com Thu Nov 1 13:06:33 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C5421F946C for ; Thu, 1 Nov 2012 13:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 qGoXznfKl3xP for ; Thu, 1 Nov 2012 13:06:33 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id DBF7221F947B for ; Thu, 1 Nov 2012 13:06:31 -0700 (PDT) Received: (qmail 25017 invoked from network); 1 Nov 2012 20:06:30 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 1 Nov 2012 20:06:30 -0000 Received: (qmail 9123 invoked by uid 1000); 1 Nov 2012 20:06:30 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 01 Nov 2012 20:06:30 +0000 Message-ID: <5092D644.5020909@comodo.com> Date: Thu, 01 Nov 2012 20:06:28 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> <5092B8C4.3070607@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lucy Lynch , Stephen Farrell , Ben Laurie , Paul Hoffman , "therightkey@ietf.org" Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 20:06:34 -0000 On 01/11/12 20:01, Phillip Hallam-Baker wrote: > OK so some examples do exist. But really what proportion of real world > compromises do not involve something bone headed like using a 512 bit > key for DKIM signatures? > > What I am saying here is not 'don't do CT', I am saying that we have to > make the ease of administration a high priority in the design. I would say that "ease of administration" for server operators is one of the main reasons why Ben is interested in getting CAs to participate! ;-) > On Thu, Nov 1, 2012 at 3:52 PM, Ben Laurie > wrote: > > On 1 November 2012 18:38, Phillip Hallam-Baker > wrote: > > Again, does it appear so subtle after it has been discovered? > > Well, I find I have to remind myself how it works. So ... yeah. > > Also, I assumed Bliechanbacher was the exponent 3 thing, which was > also pretty subtle. > > > > > Would the flaw have been discovered sooner if there was not so > much dead > > code? > > I don't think dead code had any influence on either of these. > > > > > > > On Thu, Nov 1, 2012 at 2:35 PM, Ben Laurie > wrote: > >> > >> On 1 November 2012 18:00, Stephen Farrell > > > >> wrote: > >> > > >> > > >> > On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote: > >> >> Having worked in Web security over 20 years now, I have still > to see a > >> >> case > >> >> where a system was breached because of a really subtle design > flaw. > >> > > >> > Bleichenbacher? > >> > >> TLS renegotiation? > >> > >> > > >> > S. > >> > _______________________________________________ > >> > therightkey mailing list > >> > therightkey@ietf.org > >> > https://www.ietf.org/mailman/listinfo/therightkey > > > > > > > > > > -- > > Website: http://hallambaker.com/ > > > > > > > -- > Website: http://hallambaker.com/ > > > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From rob.stradling@comodo.com Thu Nov 1 13:13:10 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DA721F89D0 for ; Thu, 1 Nov 2012 13:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 1usul1oBseFn for ; Thu, 1 Nov 2012 13:13:03 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id AF0EA21F85AE for ; Thu, 1 Nov 2012 13:13:02 -0700 (PDT) Received: (qmail 26303 invoked from network); 1 Nov 2012 20:12:53 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 1 Nov 2012 20:12:53 -0000 Received: (qmail 10663 invoked by uid 1000); 1 Nov 2012 20:12:53 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 01 Nov 2012 20:12:53 +0000 Message-ID: <5092D7C4.6020009@comodo.com> Date: Thu, 01 Nov 2012 20:12:52 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> <5092B8C4.3070607@cs.tcd.ie> <5092D644.5020909@comodo.com> In-Reply-To: <5092D644.5020909@comodo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" , Lucy Lynch , Ben Laurie , Paul Hoffman , Stephen Farrell Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 20:13:11 -0000 On 01/11/12 20:06, Rob Stradling wrote: > On 01/11/12 20:01, Phillip Hallam-Baker wrote: >> OK so some examples do exist. But really what proportion of real world >> compromises do not involve something bone headed like using a 512 bit >> key for DKIM signatures? >> >> What I am saying here is not 'don't do CT', I am saying that we have to >> make the ease of administration a high priority in the design. > > I would say that "ease of administration" for server operators is one of > the main reasons why Ben is interested in getting CAs to participate! ;-) I'm not saying that CA participation in CT will magically make administration easy. ;-) I am suggesting that having no extra steps to perform is probably _easier_ than having some extra steps to perform. >> On Thu, Nov 1, 2012 at 3:52 PM, Ben Laurie > > wrote: >> >> On 1 November 2012 18:38, Phillip Hallam-Baker > > wrote: >> > Again, does it appear so subtle after it has been discovered? >> >> Well, I find I have to remind myself how it works. So ... yeah. >> >> Also, I assumed Bliechanbacher was the exponent 3 thing, which was >> also pretty subtle. >> >> > >> > Would the flaw have been discovered sooner if there was not so >> much dead >> > code? >> >> I don't think dead code had any influence on either of these. >> >> > >> > >> > On Thu, Nov 1, 2012 at 2:35 PM, Ben Laurie > > wrote: >> >> >> >> On 1 November 2012 18:00, Stephen Farrell >> > >> >> wrote: >> >> > >> >> > >> >> > On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote: >> >> >> Having worked in Web security over 20 years now, I have still >> to see a >> >> >> case >> >> >> where a system was breached because of a really subtle design >> flaw. >> >> > >> >> > Bleichenbacher? >> >> >> >> TLS renegotiation? >> >> >> >> > >> >> > S. >> >> > _______________________________________________ >> >> > therightkey mailing list >> >> > therightkey@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/therightkey >> > >> > >> > >> > >> > -- >> > Website: http://hallambaker.com/ >> > >> >> >> >> >> -- >> Website: http://hallambaker.com/ >> >> >> >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey >> > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From paul.hoffman@vpnc.org Thu Nov 1 13:34:03 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D9221F9497 for ; Thu, 1 Nov 2012 13:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjaVqJSuvsVl for ; Thu, 1 Nov 2012 13:34:02 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5CF21F8B10 for ; Thu, 1 Nov 2012 13:34:02 -0700 (PDT) Received: from sn84.proper.com (sn84.proper.com [75.101.18.84]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qA1KXx7G003287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 1 Nov 2012 13:34:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <5092D4C1.2000701@comodo.com> Date: Thu, 1 Nov 2012 13:33:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD! 62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> <59E2ABDF-EF90-4BBF-BC45-048BF4C2B848@vpnc.org> <5092C4F7.106! 0908@comodo.com> <5! 092D4C1.2000701@comodo.com> To: "therightkey@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 20:34:03 -0000 On Nov 1, 2012, at 1:00 PM, Rob Stradling = wrote: > If by "actively participating" you mean that the CA has embedded the = CT proof in the cert, then yes, there is no requirement on the bank. That's one definition of "actively participating", but there are others, = such as publishing a list that the auditors pick up. > If the CA instead embeds the CT proof in OCSP Responses relating to = the cert, then there is no requirement on the bank apart from to use = OCSP Stapling. This confuses me. If the CA is putting the CT proof in its OCSP = responses, why does the bank have to do anything? > If the CA is not participating in either of these 2 ways, then there = is a requirement on the bank (aka the "server operator"), which may or = may not be rocket science, depending on your opinion. If the CA is not participating, why should that CA be in the trust pile = of software that relies on CT? --Paul Hoffman= From rob.stradling@comodo.com Thu Nov 1 14:55:59 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC7021F974B for ; Thu, 1 Nov 2012 14:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 Yaopy3P6X2Tp for ; Thu, 1 Nov 2012 14:55:59 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id EAFCE21F9627 for ; Thu, 1 Nov 2012 14:55:58 -0700 (PDT) Received: (qmail 25952 invoked from network); 1 Nov 2012 21:55:57 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 1 Nov 2012 21:55:57 -0000 Received: (qmail 19948 invoked by uid 1000); 1 Nov 2012 21:55:55 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 01 Nov 2012 21:55:55 +0000 Message-ID: <5092EFEA.90202@comodo.com> Date: Thu, 01 Nov 2012 21:55:54 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Paul Hoffman References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD! 62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> <59E2ABDF-EF90-4BBF-BC45-048BF4C2B848@vpnc.org> <5092C4F7.106! 0908@comodo.com> <5! 092D4C1.2000701@comodo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 21:55:59 -0000 On 01/11/12 20:33, Paul Hoffman wrote: > On Nov 1, 2012, at 1:00 PM, Rob Stradling wrote: > >> If by "actively participating" you mean that the CA has embedded the CT proof in the cert, then yes, there is no requirement on the bank. > > That's one definition of "actively participating", but there are others, such as publishing a list that the auditors pick up. What sort of list did you have in mind? Would this list be "transparent"? (i.e. if the CA were to publish an inaccurate or incomplete list, would the auditor definitely notice?) >> If the CA instead embeds the CT proof in OCSP Responses relating to the cert, then there is no requirement on the bank apart from to use OCSP Stapling. > > This confuses me. If the CA is putting the CT proof in its OCSP responses, why does the bank have to do anything? Because not all clients do online OCSP checks. Because far too many online OCSP checks fail due to the Responder being unreachable. Because OCSP Stapling is not currently enabled by default in (at least) Apache and nginx. >> If the CA is not participating in either of these 2 ways, then there is a requirement on the bank (aka the "server operator"), which may or may not be rocket science, depending on your opinion. > > If the CA is not participating, why should that CA be in the trust pile of software that relies on CT? AFAIK, this is the first time it's been suggested that CT should require CA participation. I think it's an idea we should consider seriously. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From rob.stradling@comodo.com Thu Nov 1 15:08:11 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FE121F899F for ; Thu, 1 Nov 2012 15:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 OEouYqBdK-xI for ; Thu, 1 Nov 2012 15:08:10 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 27C6921F898D for ; Thu, 1 Nov 2012 15:08:10 -0700 (PDT) Received: (qmail 29343 invoked from network); 1 Nov 2012 22:08:08 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 1 Nov 2012 22:08:08 -0000 Received: (qmail 3343 invoked by uid 1000); 1 Nov 2012 22:08:08 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 01 Nov 2012 22:08:08 +0000 Message-ID: <5092F2C7.6060407@comodo.com> Date: Thu, 01 Nov 2012 22:08:07 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Paul Hoffman References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD! 62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> <59E2ABDF-EF90-4BBF-BC45-048BF4C2B848@vpnc.org> <5092C4F7.106! 0908@comodo.com> <5! 092D4C1.2000701@comodo.com> <5092EFEA.90202@comodo.com> In-Reply-To: <5092EFEA.90202@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 22:08:11 -0000 On 01/11/12 21:55, Rob Stradling wrote: > On 01/11/12 20:33, Paul Hoffman wrote: >> On Nov 1, 2012, at 1:00 PM, Rob Stradling >> wrote: >> >>> If by "actively participating" you mean that the CA has embedded the >>> CT proof in the cert, then yes, there is no requirement on the bank. >> >> That's one definition of "actively participating", but there are >> others, such as publishing a list that the auditors pick up. > > What sort of list did you have in mind? > > Would this list be "transparent"? > (i.e. if the CA were to publish an inaccurate or incomplete list, > would the auditor definitely notice?) Ah, perhaps you've got this agenda item in mind: "JSON format for CAs to report recent certificate issuance, Phill Hallam-Baker – 10 mins" I think Phill coined the term "weak transparency" for this sort of thing. I'd only been thinking about Ben's "strong transparency" sunlight-02 proposal in this thread so far. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From mrex@sap.com Fri Nov 2 12:09:05 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE1E1F0C61 for ; Fri, 2 Nov 2012 12:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.989 X-Spam-Level: X-Spam-Status: No, score=-9.989 tagged_above=-999 required=5 tests=[AWL=0.260, 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 6NYCUv4HlP0H for ; Fri, 2 Nov 2012 12:09:05 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id A9AA51F0C59 for ; Fri, 2 Nov 2012 12:09:04 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id qA2J8lV1006038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Nov 2012 20:08:47 +0100 (MET) In-Reply-To: <5092B8C4.3070607@cs.tcd.ie> To: Stephen Farrell Date: Fri, 2 Nov 2012 20:08:46 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121102190846.6D32F1A323@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Lucy Lynch , Phillip Hallam-Baker , "therightkey@ietf.org" , Paul Hoffman Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 19:09:05 -0000 Stephen Farrell wrote: > > > On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote: > > Having worked in Web security over 20 years now, I have still to see a case > > where a system was breached because of a really subtle design flaw. > > Bleichenbacher? Debian OpenSSL CPRNG goof? -Martin From jon@callas.org Fri Nov 2 17:52:44 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670C41F0C91 for ; Fri, 2 Nov 2012 17:52:44 -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 TePiVD851aNc for ; Fri, 2 Nov 2012 17:52:44 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 449A61F0C5F for ; Fri, 2 Nov 2012 17:52:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 634F012AD309 for ; Fri, 2 Nov 2012 17:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Er8gKKWHa3E for ; Fri, 2 Nov 2012 17:52:41 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id E44C812AD2FE for ; Fri, 2 Nov 2012 17:52:40 -0700 (PDT) Received: from [10.0.23.14] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Fri, 02 Nov 2012 17:52:41 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 02 Nov 2012 17:52:41 -0700 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jon Callas In-Reply-To: <5092B8C4.3070607@cs.tcd.ie> Date: Fri, 2 Nov 2012 17:52:39 -0700 Message-Id: References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> <5092B 8C4.3070607@cs.tcd.ie> To: therightkey@ietf.org X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 00:52:44 -0000 On Nov 1, 2012, at 11:00 AM, Stephen Farrell = wrote: >=20 >=20 > On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote: >> Having worked in Web security over 20 years now, I have still to see = a case >> where a system was breached because of a really subtle design flaw.=20= >=20 > Bleichenbacher? Maybe. By the time Bleichenbacher was actually an issue, a number of us = had been screaming for years. I suppose you can say that it was really = subtle because the people concerned about it weren't listened to. But = that has its own ick factor, too. Everything that people don't believe = is subtle. Is it subtle that you shouldn't be using 1024 bit RSA keys? = 512? Jon From jon@callas.org Fri Nov 2 17:58:01 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC671F0C92 for ; Fri, 2 Nov 2012 17:58: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 dgBRyv0Cctaq for ; Fri, 2 Nov 2012 17:58:00 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 380A01F0C5F for ; Fri, 2 Nov 2012 17:58:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id BE9FD12AD3E8 for ; Fri, 2 Nov 2012 17:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfTl0G-Fuybz for ; Fri, 2 Nov 2012 17:57:59 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 0BE6F12AD3DD for ; Fri, 2 Nov 2012 17:57:59 -0700 (PDT) Received: from [10.0.23.14] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Fri, 02 Nov 2012 17:57:59 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 02 Nov 2012 17:57:59 -0700 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jon Callas In-Reply-To: <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> Date: Fri, 2 Nov 2012 17:57:58 -0700 Message-Id: <58705F8D-28D3-48F2-8D05-E04363259AE9@callas.org> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> To: "therightkey@ietf.org" X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 00:58:01 -0000 On Nov 1, 2012, at 8:14 AM, Paul Hoffman wrote: > As someone who has to trust every CA in the root pile in my browsers = and OSs, I find it frightening that a CA who can say "this is your = bank's certificate" cannot handle new requirements for how to say that. = If adopting a simple protocol like this causes an ossified CA too many = problems, maybe I don't trust that CA to be able to issue certificates = for my bank, much less to be able to know which certificates that they = are actually issuing. I'm mostly with Paul on this. I think that a CA that doesn't see CT as = an incredible boon to be ossified to say the least. I'd add that this = can be something the market solves -- move your business to one that = gets it. I can't say enough good things about CT because I think it lets everyone = win without being the TSA of the Internet. I can go on, but really, CT = is almost all upside. The only real downside is that it puts stresses on = genuinely private PKIs, but it's only a stress, and arguably the few of = those that really exist can opt out. Ben has pointed out that the same = sorts of problems that CT would put on such things are induced by the = SSL Observatory and similar efforts. Jon From hallam@gmail.com Fri Nov 2 19:10:57 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DD21F0C9F for ; Fri, 2 Nov 2012 19:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.529 X-Spam-Level: X-Spam-Status: No, score=-3.529 tagged_above=-999 required=5 tests=[AWL=0.069, 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 1XHTcIB5CDqx for ; Fri, 2 Nov 2012 19:10:57 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id D13031F0C9C for ; Fri, 2 Nov 2012 19:10:56 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so4517116oag.31 for ; Fri, 02 Nov 2012 19:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vNgqmIQn7O7vWBta9DFhLHHDL71k2ds8s6d+ly4OzkM=; b=whCbmUCh+JqirQRQlKPfR3NyDj0qRBoFGdkqwfncx6oEd2AaLOH5WiVBH/Y18v0ipc xwnSNPlcqmjTe+Y2jdOAuc0nvyygy/II+APVt42CB4gJTx4eJcgk/mu1CGK0R0A8fvNR 92xu4S4W3rAZtSri0YOmYvSbjibOSDBqA7Z0ha2hQBA2U2KZI4GToJhuYAi+W2qKkWNz Ki1T0kHGO1oLD5aWhLfmcOqdcMmisNLYng50fHqJEJ0F5ycVtW9aUValS38qDy80zEMl Bpvoih3w2uvcSUtEMQ15XLhwZIJqb09E9+SXB/y++lsEWDIp47MmOLsKX1bwRJ0vvjF9 2nsw== MIME-Version: 1.0 Received: by 10.182.95.205 with SMTP id dm13mr2948041obb.9.1351908656432; Fri, 02 Nov 2012 19:10:56 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Fri, 2 Nov 2012 19:10:56 -0700 (PDT) In-Reply-To: References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> <5092B8C4.3070607@cs.tcd.ie> Date: Fri, 2 Nov 2012 22:10:56 -0400 Message-ID: From: Phillip Hallam-Baker To: Jon Callas Content-Type: multipart/alternative; boundary=14dae93b63203c44a104cd8dc313 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Barely-capable CAs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 02:10:57 -0000 --14dae93b63203c44a104cd8dc313 Content-Type: text/plain; charset=ISO-8859-1 My original point was that adding additional complexity into the system is never simple. It is not just the small increment of complexity added that is the issue, it is how it interacts with all the existing increments of complexity. Network admin is very hard because the tools provided are total crap. It would be very easy for parts of the network to give feedback such as 'which port is hogging bandwidth by jabbering away in NETBIOS' but they don't. Net admins tend to be very suspicious of changes to configurations for good reason, they have been burned many times before by 'simple' changes. As for people warning about bugs... well yes, I told netscape about the flaw in their PRNG over a year before someone decompiled the code and 'discovered' it. Jeff Schiller and Alan Schiffman had both been on at me about the pitfalls of RNGs. Jeff because the Kerberos people got burned that way. What it comes down to in part is that some of us have a very different model of how to write code than the rest of you. Cross site scripting, SQL injection, buffer overruns, simply cannot occur in my coding world because I would never use a scripting language that way or SQL or have code without pervasive bound checking. The NSA avoids errors like Bleichenbacher in the same way. Perhaps we can learn from them. In the meantime, if we want to get past the net admins we have to give them a royal road and not lecture them. On Fri, Nov 2, 2012 at 8:52 PM, Jon Callas wrote: > > On Nov 1, 2012, at 11:00 AM, Stephen Farrell > wrote: > > > > > > > On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote: > >> Having worked in Web security over 20 years now, I have still to see a > case > >> where a system was breached because of a really subtle design flaw. > > > > Bleichenbacher? > > Maybe. By the time Bleichenbacher was actually an issue, a number of us > had been screaming for years. I suppose you can say that it was really > subtle because the people concerned about it weren't listened to. But that > has its own ick factor, too. Everything that people don't believe is > subtle. Is it subtle that you shouldn't be using 1024 bit RSA keys? 512? > > Jon > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > -- Website: http://hallambaker.com/ --14dae93b63203c44a104cd8dc313 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My original point was that adding additional complexity into the system is = never simple. It is not just the small increment of complexity added that i= s the issue, it is how it interacts with all the existing increments of com= plexity.

Network admin is very hard because the tools provided are to= tal crap. It would be very easy for parts of the network to give feedback s= uch as 'which port is hogging bandwidth by jabbering away in NETBIOS= 9; but they don't.=A0

Net admins tend to be very suspicious of changes to con= figurations for good reason, they have been burned many times before by = 9;simple' changes.

As for people warning about= bugs... well yes, I told netscape about the flaw in their PRNG over a year= before someone decompiled the code and 'discovered' it. Jeff Schil= ler and Alan Schiffman had both been on at me about the pitfalls of RNGs. J= eff because the Kerberos people got burned that way.


What it comes down to in part is that so= me of us have a very different model of how to write code than the rest of = you. Cross site scripting, SQL injection, buffer overruns, simply cannot oc= cur in my coding world because I would never use a scripting language that = way or SQL or have code without pervasive bound checking.

The NSA avoids errors like=A0Bleichenbacher in the sam= e way. Perhaps we can learn from them.

In the meantime, if we want to get past the net admins w= e have to give them a royal road and not lecture them.


On Fri, Nov 2, 2012 at 8:52 PM, Jon Call= as <jon@callas.org> wrote:

On Nov 1, 2012, at 11:00 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

>
>
> On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote:
>> Having worked in Web security over 20 years now, I have still to s= ee a case
>> where a system was breached because of a really subtle design flaw= .
>
> Bleichenbacher?

Maybe. By the time Bleichenbacher was actually an issue, a numb= er of us had been screaming for years. I suppose you can say that it was re= ally subtle because the people concerned about it weren't listened to. = But that has its own ick factor, too. Everything that people don't beli= eve is subtle. Is it subtle that you shouldn't be using 1024 bit RSA ke= ys? 512?

=A0 =A0 =A0 =A0 Jon

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



--
= Website: http://hallambaker.com/
--14dae93b63203c44a104cd8dc313-- From stephen.farrell@cs.tcd.ie Tue Nov 13 05:10:13 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A486B21F8449 for ; Tue, 13 Nov 2012 05:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CQDj55oJJoz for ; Tue, 13 Nov 2012 05:10:13 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DA46621F81FF for ; Tue, 13 Nov 2012 05:10:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6910BBE3B for ; Tue, 13 Nov 2012 13:09:39 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xy9jVTQwz4c for ; Tue, 13 Nov 2012 13:09:35 +0000 (GMT) Received: from [IPv6:2001:770:10:203:fc16:33b:6a79:3b11] (unknown [IPv6:2001:770:10:203:fc16:33b:6a79:3b11]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1B47EBE38 for ; Tue, 13 Nov 2012 13:09:35 +0000 (GMT) Message-ID: <50A2468F.7070305@cs.tcd.ie> Date: Tue, 13 Nov 2012 13:09:35 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: "therightkey@ietf.org" X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [therightkey] certrans BoF outcome X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 13:10:13 -0000 Hi all, Last week's BoF went very well from my point of view, so first some thanks... Thanks to Paul for chairing and to Adam for a great slide-free presentation and to Phill for his presentation. (As an aside, few/zero slides at BoFs like this one seems like a fine plan in general.) Thanks also to Wes Hardaker for taking notes, which are posted [1] to the meeting materials. Let Paul or I know if there are any changes needed to those. And last but not least thanks to all who took part in the constructive and interesting discussion. In terms of outcome, the way forward is that Ben will continue working on his sunlight draft to bring it to the point where he thinks its ready to be an experimental-track RFC. When he and I are happy with that, I'll AD sponsor it, which means it'll get an IETF last call after which it can go to the IESG for evaluation, all going well. Around then we can re-visit whether forming a WG is appropriate, my feeling from last week is that that may well be the case. If so, we can discuss then if another BoF or just crafting a charter and forging ahead is the way to do that. We can continue to use this list for all that work, so if you have comments on the sunlight draft [2] please send those so that Ben can see them and take them into account. There's probably a bit of thought needed about how much to try get done in the experimental track RFC and I'll chat with Ben about that and one of us will summarise that to the list so folks know what to expect when this does pop out for an IETF LC. I hope we can get that plan sent to the list in the next week-ish. There were also some new issues that were raised at the BoF (see the notes [1]) and more discussion of those on this list would also be good. (But do start new threads for those please.) Regards, Stephen. [1] http://www.ietf.org/proceedings/85/minutes/minutes-85-certrans [2] http://tools.ietf.org/html/draft-laurie-pki-sunlight From benl@google.com Wed Nov 14 07:48:23 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C362021F865D for ; Wed, 14 Nov 2012 07:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.826 X-Spam-Level: X-Spam-Status: No, score=-102.826 tagged_above=-999 required=5 tests=[AWL=0.151, 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 zWkmSA8mX0pI for ; Wed, 14 Nov 2012 07:48:23 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3970421F8651 for ; Wed, 14 Nov 2012 07:48:23 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so625826vbb.31 for ; Wed, 14 Nov 2012 07:48:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=LOfCzzh4wkPSUhMbYcpEb2lHWUZsdW/aCI7JLU0iMBs=; b=KJKwfTnsZMaPTvVEWCzrMDHpAgZw0l9CnZDqMgFpb7o0+AIkWwYDCYABfHQ7gvGtbE 90JcWjAGBi64W4tw4tvGGrtoCzs7iLXJxOYGgm1m+aMn/5Rjrj6JA4f/QBiwmluUrk0Z mKnXKOMROAWJh62MrO7pKWcolOTrKaaOuNF06XjoBJHleUjPG8RrV44kGPnleNi6Fibj auts2Nzn9UEApjG6BBdH0o3PINWaTmPxr9ZopyqjkfavDSSfhwKzlcq0B5REYGvE6uUM OnhxdONOFVc8mJODiexM+IZxG9XmYqTcP2c0iKQjFGOu2rbN7lalqNAVND35Ptw7GNbG L9Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=LOfCzzh4wkPSUhMbYcpEb2lHWUZsdW/aCI7JLU0iMBs=; b=hBM2kiIu3IuKcGe76gPcvZW5H4fd7GPTjBUlPL1jf4soVLi9Xc1jNgb0bBzJMGNxv9 w+UFBVE9+LZxcIV/6Lfijr5FmfxISbxOlAEiNJXOYaHjkaCeU8XZ/ntXmO9qfRhr7WhY aHq+sj2qwfrX69ZfUSfDESi+tTRmFXJpjAkAWWZJhuIzIb3YnlGVnEDYpc+jFQ7KdsJ3 kBDihXP5noE1X3k3uZyTENkXLfmFDj74JiILnM+oy0vDCYJ+zceV/VkzFRQlTpF7zhSh WLtmVnmP58foXpf3JTjdAtNVkPFipvdfcoY/fF/jwoIIJ1CoyH+/Zl6rHI+9DPhtZvyG T+Og== MIME-Version: 1.0 Received: by 10.220.155.132 with SMTP id s4mr11456480vcw.15.1352908102445; Wed, 14 Nov 2012 07:48:22 -0800 (PST) Received: by 10.220.228.6 with HTTP; Wed, 14 Nov 2012 07:48:22 -0800 (PST) Date: Wed, 14 Nov 2012 15:48:22 +0000 Message-ID: From: Ben Laurie To: IETF DANE WG list , therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlEiqacq3OyDGhN8M6DtSwCH+1pl7U/HQTgzxhtSnf0UPnC8BQs5eI5kWK3AQPKSR/4FbNyf3nLoqusyHjT2Ur/9v7EsrIK+KHeb30qTREFWsz2gdEn8LAf5LFyOfi6puFkQTAzoiVF9n7VkY9oEG9P5YMwbEKl8dqpVWRWVCsv0Wh7NT3qegqFc6rqenTLeTfUsFSQ Subject: [therightkey] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 15:48:23 -0000 At the CT BoF the question was raised: what about DANE? Which is a good question. So, I think Google is prepared to contemplate running a CT log for DANE, but this leaves some questions... a) What would we log? DNSSEC keys as well as certs? Only DNSSEC keys? Something else? b) How do we prevent the log getting spammed out of existence as soon as it becomes useful? c) When someone observes badness in the log, what do they do about it? I do not intend to drive the answers to these questions, but if someone supplies them I will certainly consider running a DANE log. From benl@google.com Wed Nov 14 08:05:25 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8BE21F85AB for ; Wed, 14 Nov 2012 08:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.856 X-Spam-Level: X-Spam-Status: No, score=-102.856 tagged_above=-999 required=5 tests=[AWL=0.121, 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 3x8oLpv6kVAD for ; Wed, 14 Nov 2012 08:05:25 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1421221F858E for ; Wed, 14 Nov 2012 08:05:24 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so676180vcb.31 for ; Wed, 14 Nov 2012 08:05:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=16eQkrzCvoE2YFMNv9RYd7RL1zlUNQEEyYN/YZGDBYs=; b=poIbQVXcTwtzdiCSc6QNBE5BIJwqJit2VUnU7yAYVLZ+Q3NimUgABAFNJsaScqAqi+ r0QiCqYjTAob5aOf+YZfO7FvJEf/oRwcDP6Q9V4H0J1TqFac3xpz+QoyH8TMfmU5DXRo R0eo5iMwjosi6ANVP3uviwkxmmQpr+sTl9nH3GXacTUFvtCoOlkSXfjzIBU7cQkN8CRh 9glm7gkvPE+aAVD7ZkGxarIvUR/PNYowtZs195IG/aw0y02zpfjdhsLFjjrUqTHD8gad PztXTY9fKJ80fDfR8or+brhPcJnrbTyr572GzDthidfipmmwQXFuVaSMub4xI5xLyK5J nGmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=16eQkrzCvoE2YFMNv9RYd7RL1zlUNQEEyYN/YZGDBYs=; b=QhBnozKrHHtYISvd2It5XILNeVo7UICe0eltQOG3C83UhaMM+jRyO700Pko34qFdFs 0Lyiz/asezw/sHg6DmvH4cf+p01Ya+F9EB2co1X2q/stXz4ncxS34rEyjlw2K/GCxAuA rVsfAbY63VVhZCaN0CCbuuPWBeTm171U6gANFL/KvWBcD3p8qx4+MosLgIhLKQqTaXqb JuiDI0bOrqNk0zGOq9UjiUJPouumqS91Ylo2L4w1usPVCQwm6ZY+HchzzBgk8ALEbXCu bs22KJVdAa3+8Bb1kT06eyyF3iRN6UIUPCNcgThBo1aIjQPLy60iwYaZOozOHjPsCkv1 o7Wg== MIME-Version: 1.0 Received: by 10.220.8.138 with SMTP id h10mr11461766vch.35.1352909124522; Wed, 14 Nov 2012 08:05:24 -0800 (PST) Received: by 10.220.228.6 with HTTP; Wed, 14 Nov 2012 08:05:24 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Nov 2012 16:05:24 +0000 Message-ID: From: Ben Laurie To: Tony Finch Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmAcF+7PjxuI5E4M06SXam+KK4cfzb/Td0v2Fz4FdPfJG96AizgCQSsMl2Gx1s/MVc3FfjVdkoX2tMlBaC1RRqI8WIYtkoXouWmLAv0tjaoglnnZ9D5z3KzTqIbOoBG3o4Zl9cjXLJTvut97YTb4K6vQvsPXVdfDfnAq38UiE4oRsthPUMZ23ddH68iIr7U7FWQfCRe Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 16:05:26 -0000 On 14 November 2012 16:02, Tony Finch wrote: > Ben Laurie wrote: > >> At the CT BoF the question was raised: what about DANE? >> >> Which is a good question. So, I think Google is prepared to >> contemplate running a CT log for DANE, but this leaves some >> questions... > > What problem would CT for DANE be aiming to fix? By all means add that to the list of questions :-) But I assume the same problem CT already fixes: misissuance of certs (which in the DNSSEC world I guess mostly boils down to bad delegation). > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. > Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, > occasionally poor at first. From fanf2@hermes.cam.ac.uk Wed Nov 14 08:02:10 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9AF21F862C; Wed, 14 Nov 2012 08:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.134 X-Spam-Level: X-Spam-Status: No, score=-5.134 tagged_above=-999 required=5 tests=[AWL=1.465, 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 o-Y+sdpsnRIV; Wed, 14 Nov 2012 08:02:10 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF5121F8574; Wed, 14 Nov 2012 08:02:10 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:36011) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1TYfPl-0007Jq-Wy (Exim 4.72) (return-path ); Wed, 14 Nov 2012 16:02:09 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TYfPl-0006wk-6D (Exim 4.72) (return-path ); Wed, 14 Nov 2012 16:02:09 +0000 Date: Wed, 14 Nov 2012 16:02:09 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Ben Laurie In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch X-Mailman-Approved-At: Wed, 14 Nov 2012 08:28:14 -0800 Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 16:02:11 -0000 Ben Laurie wrote: > At the CT BoF the question was raised: what about DANE? > > Which is a good question. So, I think Google is prepared to > contemplate running a CT log for DANE, but this leaves some > questions... What problem would CT for DANE be aiming to fix? Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From warren@kumari.net Wed Nov 14 08:28:39 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328F721F85EB; Wed, 14 Nov 2012 08:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObEtRaAZcd+X; Wed, 14 Nov 2012 08:28:38 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3BB21F8620; Wed, 14 Nov 2012 08:28:38 -0800 (PST) Received: from [192.168.2.103] (unknown [209.133.29.2]) by vimes.kumari.net (Postfix) with ESMTPSA id AE7E41B404E9; Wed, 14 Nov 2012 11:28:37 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: Date: Wed, 14 Nov 2012 11:28:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> References: To: Tony Finch X-Mailer: Apple Mail (2.1499) Cc: Ben Laurie , therightkey@ietf.org, Warren Kumari , IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 16:28:39 -0000 On Nov 14, 2012, at 11:02 AM, Tony Finch wrote: > Ben Laurie wrote: >=20 >> At the CT BoF the question was raised: what about DANE? >>=20 >> Which is a good question. So, I think Google is prepared to >> contemplate running a CT log for DANE, but this leaves some >> questions... >=20 > What problem would CT for DANE be aiming to fix? >=20 If I run example.com and someone managed to generate / publish a TLSA = record for that I'd sure like to know about it.=20 Yes, I should be able to simply check myself (and presumably a malicious = actor wouldn't submit it to the log :-)), but it seem like it couldn't = hurt[0] Also, as a relying party, if I'm checking / relying on CT this gives me = additional information - if the cert / TLSSA record do not match the = published stuff in the log I may have evidence that shenanigans are = afoot. Yes, there is a fair bit of detail still to be worked out (what do you = *do* if they don't match? what if a DANE user simply doesn't want to = publish and the world moves to enforced CT?), the "it seems like it = can't hurt" feels scary, and so needs more thought, but to me CT and = DANE seem complementary, not competing technologies=85 W [0]: Famous last words! > Tony. > --=20 > f.anthony.n.finch http://dotat.at/ > Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at = first. > Rough, becoming slight or moderate. Showers, rain at first. Moderate = or good, > occasionally poor at first. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 -- Do not meddle in the affairs of dragons, for you are crunchy and taste = good with ketchup.=20 From paul@nohats.ca Wed Nov 14 08:31:15 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A94921F85EB; Wed, 14 Nov 2012 08:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wR8pmpskohVS; Wed, 14 Nov 2012 08:31:15 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 27ACA21F85A5; Wed, 14 Nov 2012 08:31:15 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id A08DE82B69; Wed, 14 Nov 2012 11:30:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 970D4804AA; Wed, 14 Nov 2012 11:30:31 -0500 (EST) Date: Wed, 14 Nov 2012 11:30:31 -0500 (EST) From: Paul Wouters To: Ben Laurie In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Tony Finch , therightkey@ietf.org, IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 16:31:15 -0000 On Wed, 14 Nov 2012, Ben Laurie wrote: >>> At the CT BoF the question was raised: what about DANE? >>> >>> Which is a good question. So, I think Google is prepared to >>> contemplate running a CT log for DANE, but this leaves some >>> questions... >> >> What problem would CT for DANE be aiming to fix? > > By all means add that to the list of questions :-) > > But I assume the same problem CT already fixes: misissuance of certs > (which in the DNSSEC world I guess mostly boils down to bad > delegation). Does that make sense though? With RRSIG validity times and TTL's you can set your "damange period" as small as you want. There is no issue like with certificates where your credentials can be abused for up to 12 months. The only use I could see is as an alternative mechanism to transfer these records into the application that does not require a clean DNS transport. I think CT is a bandaid for PKIX that does not apply to DANE. I think the problem with DANE/DNSSEC right now is the additional latency and dns transport issues (hotspots, VPN, etc) but I don't think CT is very well suited to address those. Paul From benl@google.com Wed Nov 14 08:35:32 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37B421F84F8 for ; Wed, 14 Nov 2012 08:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.876 X-Spam-Level: X-Spam-Status: No, score=-102.876 tagged_above=-999 required=5 tests=[AWL=0.101, 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 HYzEXS5EcNqI for ; Wed, 14 Nov 2012 08:35:32 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D41CA21F845E for ; Wed, 14 Nov 2012 08:35:31 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so710261vcb.31 for ; Wed, 14 Nov 2012 08:35:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nOgr9Y0B/Lm9ouBvldPDv4hrw5yMlNz93n+LO8bRs+I=; b=SGxwFCbhtQzwf51Lh5UkTHTfvib6cW0VwiRnbsPMYsHE+BXhoyRbxffBgJsz5dMqO0 CFTXPAFmifC5ZgzLDqOFQtZIKCq+5JNY11OR9y/iu6l/3/AtVMA9GEMTMtAdqE/bMzWS ZfuvSL8OgJHaK1WGXn3p/DGXUVwhCe+UxuEJEHg+J1X3nuVqPWbZ94N/6Co/i38hLRGN 8pwShU578fET2cEN1Y+4M2UFDD+9AUUofi4Ww/kpST8jBrIDruVtih3PA/+85cqSSgGk ZXS6JA7rk67wkzs+E5GpK4NujsQ5FUc72MmEAq7rgvh8Lsrv4GpXMPQMLXxp1jHWj7jX adaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=nOgr9Y0B/Lm9ouBvldPDv4hrw5yMlNz93n+LO8bRs+I=; b=YZX9qIzdPKS70MCxTZ0/dtGOZbM6S5SMlRydyZwyxZ2InGWHwKeKceuhqahPNvHKKN DWxGjjLdIVAEj+wGAABsvVXwJawqiLzQeSo9g7xn4Y7niqL9yo1wu4Fl9v4B5cdB6pt3 9JY+/ERsxqwMN1kkaC6zNxkbFLueLmKz3YiCTFmy8mXZQBUzmse6fjTGIvocuXcAisgl sEBxddzkD6qMdcL+Zm+J4iHNMlvg1bVzmGeGs1l8yVrTv8NaO7siPkeuZ0iW3Ifdh2w4 G46RKwksgPuXU+tnxZSiWmEFemxqsPQaFqOaFGmz0dzqlgZcixsBCxNi86yUuv8z09ts ZE9A== MIME-Version: 1.0 Received: by 10.52.175.167 with SMTP id cb7mr2624498vdc.58.1352910931286; Wed, 14 Nov 2012 08:35:31 -0800 (PST) Received: by 10.220.228.6 with HTTP; Wed, 14 Nov 2012 08:35:31 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Nov 2012 16:35:31 +0000 Message-ID: From: Ben Laurie To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmDpuZ999Pb+UsqgLwJueKmGcdCvXPMpk7KoGokEfglPX7psblzkvd0SAeoLJfg8HAoM01j2jHMyVn3spfq0hlqc2yAjWFUQmGYtgqOlWWxRaHObo1sqzEC7EMCW2dIo4Q1IUExOnUnttxsEQO1tKS4V/va8QZtvIaNTmpghi6fBlZNH88gG907EjCSPEJvdg3wKais Cc: Tony Finch , therightkey@ietf.org, IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 16:35:33 -0000 On 14 November 2012 16:30, Paul Wouters wrote: > On Wed, 14 Nov 2012, Ben Laurie wrote: > >>>> At the CT BoF the question was raised: what about DANE? >>>> >>>> Which is a good question. So, I think Google is prepared to >>>> contemplate running a CT log for DANE, but this leaves some >>>> questions... >>> >>> >>> What problem would CT for DANE be aiming to fix? >> >> >> By all means add that to the list of questions :-) >> >> But I assume the same problem CT already fixes: misissuance of certs >> (which in the DNSSEC world I guess mostly boils down to bad >> delegation). > > > Does that make sense though? With RRSIG validity times and TTL's you > can set your "damange period" as small as you want. There is no issue > like with certificates where your credentials can be abused for up to > 12 months. > > The only use I could see is as an alternative mechanism to transfer these > records into the application that does not require a clean DNS transport. > > I think CT is a bandaid for PKIX that does not apply to DANE. > > I think the problem with DANE/DNSSEC right now is the additional latency > and dns transport issues (hotspots, VPN, etc) but I don't think CT is > very well suited to address those. a) Why would an attacker use your validity times? b) Weren't you amongst those asking for CT to support DANE during the BoF? I disagree that CT is a bandaid for anything, BTW - it is a useful mechanism in its own right. From tom@ritter.vg Wed Nov 14 08:37:39 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277CB21F84B6 for ; Wed, 14 Nov 2012 08:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 V2P5k35V4ZpE for ; Wed, 14 Nov 2012 08:37:38 -0800 (PST) Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B99021F857E for ; Wed, 14 Nov 2012 08:37:38 -0800 (PST) Received: by mail-yh0-f44.google.com with SMTP id 56so122986yhq.31 for ; Wed, 14 Nov 2012 08:37:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pwbgCmqI5i/G/yrvqjWD8+UAEBxmRFvbiMO2k7lA71g=; b=Tf6fFpkEA4z1Hv/PiWddOF0DGXCLgHDWgCxdyOYMshhdIuo3WdNzCy6HsGRh91mzeU GuVmCBt1+xg5fBBsjA5GnD8LQXmHvgZgZe26ZZmIRPOdrfuKrBLvbJPgIp3UrqwpkdJR fopYGJ8p/dAcHNW9E1TCYCosfs2CkABp3LpHY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=pwbgCmqI5i/G/yrvqjWD8+UAEBxmRFvbiMO2k7lA71g=; b=mDVBbRzNM0NF8BrdYsmjGn+VagQZj9JkmIA6vHe1rXkzBIZnZrMRsw5pgE2/2yd4jA ZirxaxWJNecu5acFDU/xdyVE0EZauQtynAzaK/nV/buZ5Sm5acX7fKS6roSobeS2fYzQ gk7HsZ89wnC+I5piKfXeJk/ZAlycRUnuWKN2hNQexv6AsUoWWN9L6SYlV6WuXzmV7e1u dd1PkI32kRpvwSaIurYR8pqc8di1V7z74EvWWD3+KBa3jXRaLfWuYOwmunzMqmjNf7pK NoA0yTTBk8jnQaDOAEIOqnqGnYpNJqowJKTmJJKcz3bmy+IqxOnDwWiYjuDcbWMEC043 dLCQ== Received: by 10.58.221.228 with SMTP id qh4mr32457359vec.49.1352911057898; Wed, 14 Nov 2012 08:37:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.151.178 with HTTP; Wed, 14 Nov 2012 08:37:17 -0800 (PST) In-Reply-To: References: From: Tom Ritter Date: Wed, 14 Nov 2012 11:37:17 -0500 Message-ID: To: Paul Wouters Content-Type: multipart/alternative; boundary=047d7bdc7a9a04ced304ce772724 X-Gm-Message-State: ALoCoQmIWg2IWNKgm3lZDbmaoBIhZzNr8C8nMORJwwcpMnyOGDsrHFDudmWwiyaRMvnbGSqgrWOl Cc: therightkey@ietf.org, Ben Laurie , IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 16:37:39 -0000 --047d7bdc7a9a04ced304ce772724 Content-Type: text/plain; charset=ISO-8859-1 On 14 November 2012 11:30, Paul Wouters wrote: > I think CT is a bandaid for PKIX that does not apply to DANE. > Perhaps not DANE - but DNSSEC. PKIX allows N CAs to issue unlimited trusted certs for your domain. DNSSEC allows 1 TLD to issue unlimited trusted signing keys for your domain. Maybe it's the KSK that should go into a log? -tom --047d7bdc7a9a04ced304ce772724 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 14 November 2012 11:30, Paul Wouters <paul@nohats.ca> wrote:=
I think CT is a bandaid for PKIX that does not apply to D= ANE.

Perhaps not DANE - but DNSSEC. = =A0PKIX allows N CAs to issue unlimited trusted certs for your domain. =A0D= NSSEC allows 1 TLD to issue unlimited trusted signing keys for your domain.= =A0Maybe it's the KSK that should go into a log?

-tom
--047d7bdc7a9a04ced304ce772724-- From fanf2@hermes.cam.ac.uk Wed Nov 14 09:02:47 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2C421F8680; Wed, 14 Nov 2012 09:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.623 X-Spam-Level: X-Spam-Status: No, score=-5.623 tagged_above=-999 required=5 tests=[AWL=0.977, 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 j4cq1a3DEgQe; Wed, 14 Nov 2012 09:02:46 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id EE37521F85FD; Wed, 14 Nov 2012 09:02:45 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:56726) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1TYgMN-00007K-rr (Exim 4.72) (return-path ); Wed, 14 Nov 2012 17:02:43 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TYgMN-00074g-Lf (Exim 4.72) (return-path ); Wed, 14 Nov 2012 17:02:43 +0000 Date: Wed, 14 Nov 2012 17:02:43 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Warren Kumari In-Reply-To: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> Message-ID: References: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: therightkey@ietf.org, Ben Laurie , IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:02:47 -0000 Warren Kumari wrote: > > If I run example.com and someone managed to generate / publish a TLSA > record for that I'd sure like to know about it. Right. But in PKIX a mis-issued certificate has nothing to do with your own infrastructure, whereas with DANE it implies that your infrastructure (or the infrastructure of your DNS service providers) has been compromised. I'm a bit worried about the operational implications: PKIX CT is extra work for CAs, but DANE CT is extra work for everyone. So I'm skeptical that the cost/benefit tradeoff is positive. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From benl@google.com Wed Nov 14 09:07:59 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76EF21F86C9 for ; Wed, 14 Nov 2012 09:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.884 X-Spam-Level: X-Spam-Status: No, score=-102.884 tagged_above=-999 required=5 tests=[AWL=0.093, 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 j1fiI+S7p6pC for ; Wed, 14 Nov 2012 09:07:59 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E4EE621F86A5 for ; Wed, 14 Nov 2012 09:07:58 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so749901vcb.31 for ; Wed, 14 Nov 2012 09:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HwILyQRrXBtL6Byx0W+CAPICoPjQVvZIQ4MmEwITe6k=; b=Ag1A4mOqDtmhn0WPFlxf4a09ShDkXvmVfrytXweckYDXqBdBxhlGORjDKgrfknsuIm oXINLjKXAmlkYywZcyaudZFpSgyMbRETfvtKGIWIvxo1KeWai8IKjoNEEr9H4RF4i9ix O9wnY/9ZjBSJ9lOay/Trz1yWebAHacijkd/uX0c7bVtwus9M/xThJ47ubICR9/jPjqeq IiM3VL1wM1VnBJ84g+TmDqgeI4F8Fln2KwfZ75GD8HR/utOpgNjLXG8GcUMPltPiB3po cUE92Exo5HO+lwPS5fDr4mCZ7wTWrrHWFbIwAE5UiQFTW4MmMW8VfU0xcXbHk6+MtuZM 2ihA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=HwILyQRrXBtL6Byx0W+CAPICoPjQVvZIQ4MmEwITe6k=; b=W8fHKLwn8YKyyaUn3cXmYPWohkajDOJ9j+acIA6LMHv3E7yZ0vH69QqAdPPeq0C2eN 8Y4F7zaYArxiceMGjyvZ2oc9EextV7DhwjdIXZL2z3cHw2k6dNwZif1FT6dhcKaKt9Z0 Mvb4tk+jIM4eGGw+ATeBGTXRMR1E1ZE+muLf1fGpaEeKpaiWDNtJloueKeI41HXxVZ5d 7+wsVXj78R0j8rHD8dg+DWrxX/K2gGKsBHXQ6AQ5LU9perJJ/MOAjbTwLaH5OETRr4vs icXQWeMCoQSkWg5uJa4ogKU6rtgvEUTEscLIGv88SxLtKNpHNQVgXSpahtX8xrH3W8F3 ddKQ== MIME-Version: 1.0 Received: by 10.220.155.132 with SMTP id s4mr11792136vcw.15.1352912878344; Wed, 14 Nov 2012 09:07:58 -0800 (PST) Received: by 10.220.228.6 with HTTP; Wed, 14 Nov 2012 09:07:58 -0800 (PST) In-Reply-To: References: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> Date: Wed, 14 Nov 2012 17:07:58 +0000 Message-ID: From: Ben Laurie To: Tony Finch Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm4anWP2qtNCIsAWqKgHJ7rmEwAbIzuQUEk2fgQe6OJ5dBH8ul3NCzi2bp/jTrcSKJgNA3tWKrUITTnns0pFhREg+6JR5Knc2OzlS0v4zExggJxCtDyV5LtX587mWt8b9zeUjrAWTU8gFz7SmZzP7zSCvma5LthqZJl5TjxtK13yt0eUpen8iJn9TrKFH7EQBa43ehw Cc: therightkey@ietf.org, Warren Kumari , IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:07:59 -0000 On 14 November 2012 17:02, Tony Finch wrote: > Warren Kumari wrote: >> >> If I run example.com and someone managed to generate / publish a TLSA >> record for that I'd sure like to know about it. > > Right. But in PKIX a mis-issued certificate has nothing to do with your > own infrastructure, whereas with DANE it implies that your infrastructure > (or the infrastructure of your DNS service providers) has been > compromised. Isn't the infrastructure of your DNS service providers nothing to do with your own infrastructure? Not to mention your TLD's infrastructure, and that of all of their registrars (and, presumably, DNS service providers)? > I'm a bit worried about the operational implications: PKIX CT is extra > work for CAs, but DANE CT is extra work for everyone. Only everyone who uses keys, and they've already signed up for quite a lot of work. > So I'm skeptical that the cost/benefit tradeoff is positive. I am unconvinced by your argument. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. > Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, > occasionally poor at first. From shuque@upenn.edu Wed Nov 14 09:29:52 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC7821F86FF; Wed, 14 Nov 2012 09:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8aHPVXuoox0; Wed, 14 Nov 2012 09:29:51 -0800 (PST) Received: from mopeypopo.net.isc.upenn.edu (www.huque.com [IPv6:2607:f470:2:1::a:2]) by ietfa.amsl.com (Postfix) with ESMTP id B978A21F8754; Wed, 14 Nov 2012 09:29:51 -0800 (PST) Received: by mopeypopo.net.isc.upenn.edu (Postfix, from userid 500) id 9B56AA5002; Wed, 14 Nov 2012 12:29:50 -0500 (EST) Date: Wed, 14 Nov 2012 12:29:50 -0500 From: Shumon Huque To: Ben Laurie Message-ID: <20121114172950.GA13499@isc.upenn.edu> References: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: University of Pennsylvania User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Tony Finch , therightkey@ietf.org, IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:29:52 -0000 On Wed, Nov 14, 2012 at 05:07:58PM +0000, Ben Laurie wrote: > On 14 November 2012 17:02, Tony Finch wrote: > > Warren Kumari wrote: > >> > >> If I run example.com and someone managed to generate / publish a TLSA > >> record for that I'd sure like to know about it. > > > > Right. But in PKIX a mis-issued certificate has nothing to do with your > > own infrastructure, whereas with DANE it implies that your infrastructure > > (or the infrastructure of your DNS service providers) has been > > compromised. > > Isn't the infrastructure of your DNS service providers nothing to do > with your own infrastructure? Not to mention your TLD's > infrastructure, and that of all of their registrars (and, presumably, > DNS service providers)? One critical difference is that with DANE, I can query the DNSSEC delegation chain myself and detect whether my TLD has installed a bogus DS record and take action. I cannot today detect a bogus X.509 cert by myself. I think this makes a CT like scheme less necessary for DANE. -- Shumon Huque University of Pennsylvania. From tom@ritter.vg Wed Nov 14 09:51:29 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF1221F860C for ; Wed, 14 Nov 2012 09:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 SMlRodkzkPhP for ; Wed, 14 Nov 2012 09:51:26 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CA24D21F85CE for ; Wed, 14 Nov 2012 09:51:25 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so777367vbb.31 for ; Wed, 14 Nov 2012 09:51:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=p+6q9B26GioLatIMK2lqBbTg1B3K1eKUgCq3tA0FnMM=; b=uiBl5vWpvoz+L3SQiVeq/pmizJYMMnNWFfUkeQpkK8FVmVTnD3BiWmizzGaBwpRWBG j4H5H12x8d/9Mbf+fQQfuIZz/CsndmtUkqnO/Jpgu4qyqm+Oe8vT9hIvUS+WpYPbBKnn 7Yw3jLxm1ffRduHmVSYRc6bd8R7crnCnVe2iQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=p+6q9B26GioLatIMK2lqBbTg1B3K1eKUgCq3tA0FnMM=; b=OARtxIzo/YmG3V0ULSf/IIIqsuWYdN/Ul/6rD1+TOPI3yXKENflvoQi4xNyGEc9PJz VlEAMgbZslpqIbHiehTrPsZmH5mboNFZlFRkagadYGz3OCMECXqwO52N+Ech9rJpH6yj eYuCuCVRiY3oCuBrdd8jbJLcwZeVB25su951xQ13ql/0HUCZJV5oWj2XrRMgPb2fvJ6E ozcjZz2gWYOxo4mPaLoUB4yKTZHMvSh2Zl79aOyXSb5PFMVgtwcaOZDzyYp4YUnR3Fza 1fWhH8bZuHmLIjRDrmUnfM4pHZ9cmweTCvSjdH85ZmgSBDExx4cg5pBJ0cHGW4QT0Omm MMFw== Received: by 10.220.227.199 with SMTP id jb7mr11865187vcb.26.1352915485056; Wed, 14 Nov 2012 09:51:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.151.178 with HTTP; Wed, 14 Nov 2012 09:51:04 -0800 (PST) In-Reply-To: <20121114172950.GA13499@isc.upenn.edu> References: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> <20121114172950.GA13499@isc.upenn.edu> From: Tom Ritter Date: Wed, 14 Nov 2012 12:51:04 -0500 Message-ID: To: Shumon Huque Content-Type: multipart/alternative; boundary=14dae9cdca9be5de6304ce782edd X-Gm-Message-State: ALoCoQn7Gi416YCtNNZqwYha+jD+k1E1b6fkf5P5QLtKTjqruWTq3UlZ2QXNhcr4x1/fDEXngbi6 Cc: therightkey , Ben Laurie , IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:51:29 -0000 --14dae9cdca9be5de6304ce782edd Content-Type: text/plain; charset=ISO-8859-1 On 14 November 2012 12:29, Shumon Huque wrote: > One critical difference is that with DANE, I can query the DNSSEC > delegation chain myself and detect whether my TLD has installed a > bogus DS record and take action. I cannot today detect a bogus > X.509 cert by myself. I think this makes a CT like scheme less necessary > for DANE. I can query my server on port 443 and see if there is a bogus certificate. The lack of a bogus certificate in a response to a single query does not mean there is not a valid attacker-controlled signature chain an attacker could send to attack a user - whether that signature chain is of PKIX signatures or DNSSEC signatures. -tom --14dae9cdca9be5de6304ce782edd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 14 November 2012 12:29, Shumon Huque <shuque@upenn.edu> wr= ote:
One critical difference is that with DANE, I can query th= e DNSSEC
delegation chain myself and detect whether my TLD has installed a
bogus DS record and take action. I cannot today detect a bogus
X.509 cert by myself. I think this makes a CT like scheme less necessary for DANE.

I can query my server on port 443= and see if there is a bogus certificate. =A0The lack of a bogus certificat= e in a response to a single query does not mean there is not a valid attack= er-controlled signature chain an attacker could send to attack a user - whe= ther that signature chain is of PKIX signatures or DNSSEC signatures.

-tom
--14dae9cdca9be5de6304ce782edd-- From benl@google.com Wed Nov 14 09:56:32 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FE521F8531 for ; Wed, 14 Nov 2012 09:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.897 X-Spam-Level: X-Spam-Status: No, score=-102.897 tagged_above=-999 required=5 tests=[AWL=0.080, 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 Cx8GZDXj2vgw for ; Wed, 14 Nov 2012 09:56:32 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 98B4921F8530 for ; Wed, 14 Nov 2012 09:56:25 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so812257vcb.31 for ; Wed, 14 Nov 2012 09:56:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/5IJtKVvHU5cnswul0O+m6SBCqI2HN4iAQtNWEMFqaY=; b=WM6o+CIIifNnNW+ZYpw9ZhtQQNL62mxnaKN1zmAbE3vX1zlZRy2/edFd156AinMkL0 JljxwPhH6eUn4Jy2pdq7yCpf+5Qd7dGtHQy3+XaHTGsERrWnfqtzfzy69PmrfjJYnWac 0pNDYky8+UB0GmkRau0oLryCdSOdQKpbXN99GmfjCuyw+TuCH96WS1aLT5+6vsxdAa9k fSmup7hbOuIxgJvM5MaxPHYR3tQhxDECUiZITzIzxAO6W2twSw4Oo0rfUGsR9eqyqGvQ JM1ds1ln59AorJmyIuZjvmo2lwezC4GekWnii2cOU0wTEQbC3TNM8Nmb1lTYSUzYMtpj 0iCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=/5IJtKVvHU5cnswul0O+m6SBCqI2HN4iAQtNWEMFqaY=; b=Y3QrLz3XUx9Uu3mkJgfH8CMYgN3aAWykRSfAJBY2RWKAVwD7qX7dNwc4CRpJ9c3+sd CSEclKoRtbFDL2GnDyyp1DxX1fRoD8uwfplI2J9NMhEbwCh7Au2Td0yhdM9MwnuHumHw NDB7mEk/P2+8V+PImaNdSvuZXtTcBNg8YPHlnxZGKtDspdJVk/BSSYUdYHeQRL1/HCCG q+MM/feJAFh1Rawb8YrtD/GHpdM1BcDDDDUvYbZA+O5mUZjJ8mTZw6iNP6+Zyyge9Z4h ubJClOS94QqkX+Hhc1ziemG3Zu7U08cYvTzI9ya5eFpzk5Ugh+1LJ/hr0scN3dNvoKWi 7dkg== MIME-Version: 1.0 Received: by 10.220.155.132 with SMTP id s4mr11984047vcw.15.1352915784929; Wed, 14 Nov 2012 09:56:24 -0800 (PST) Received: by 10.220.228.6 with HTTP; Wed, 14 Nov 2012 09:56:24 -0800 (PST) In-Reply-To: <20121114172950.GA13499@isc.upenn.edu> References: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> <20121114172950.GA13499@isc.upenn.edu> Date: Wed, 14 Nov 2012 17:56:24 +0000 Message-ID: From: Ben Laurie To: Shumon Huque Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlhqrZdduKzd3hTcyZzMCLROjs4+UdL7WdZdqHdbXeb/MbQ3h/TWxkHHvIi9aBMvjtxkyeyrZPwM/EiBtxZDykRbFLthzm4P3l0UdtFnmt9ErBMwj64NFsolaWlNIYZK71wlHB26/YL5ve+sATOJQP0irp6mtxQEnhjhlaM5yrpHDTt/xDP/3ETUwKtofbMV4J6Myeq Cc: Tony Finch , therightkey@ietf.org, IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:56:33 -0000 On 14 November 2012 17:29, Shumon Huque wrote: > On Wed, Nov 14, 2012 at 05:07:58PM +0000, Ben Laurie wrote: >> On 14 November 2012 17:02, Tony Finch wrote: >> > Warren Kumari wrote: >> >> >> >> If I run example.com and someone managed to generate / publish a TLSA >> >> record for that I'd sure like to know about it. >> > >> > Right. But in PKIX a mis-issued certificate has nothing to do with your >> > own infrastructure, whereas with DANE it implies that your infrastructure >> > (or the infrastructure of your DNS service providers) has been >> > compromised. >> >> Isn't the infrastructure of your DNS service providers nothing to do >> with your own infrastructure? Not to mention your TLD's >> infrastructure, and that of all of their registrars (and, presumably, >> DNS service providers)? > > One critical difference is that with DANE, I can query the DNSSEC > delegation chain myself and detect whether my TLD has installed a > bogus DS record and take action. I cannot today detect a bogus > X.509 cert by myself. I think this makes a CT like scheme less necessary > for DANE. You can't detect a bogus X.509 cert because you can't connect to the server serving it, presumably. What magic allows you to perform this trick for DNS but not HTTPS? > > -- > Shumon Huque > University of Pennsylvania. From carl@redhoundsoftware.com Wed Nov 14 09:57:19 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FAF21F8673 for ; Wed, 14 Nov 2012 09:57:19 -0800 (PST) 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 XgrGP4slOA+9 for ; Wed, 14 Nov 2012 09:57:19 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1341B21F853A for ; Wed, 14 Nov 2012 09:57:18 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so813596vcb.31 for ; Wed, 14 Nov 2012 09:57:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=WjyuB3a70C1HKNfJGt1Nz5G1dE77aapWIRROn4WOwb4=; b=FxvJbmNYIRH/R+Wb7U7zLnZt7RkWkIPWenm6986MyTVw9swJtNLpu+27ydSU3p+GY0 xZVY66uKafcNJdNsdjRRdRALVbScSnWfrPpeVCYwXHmkWOOVjYGReO8/iMudOnl8I6CF 1bsmj5oSg8LKrejE423aMaq/6bXcxkUbKaXlr6pyumZNYWAW1Y/+jZbZzjDIjTKsU1GE Tyv2O+WdxgzfwBoJbJqP0mpPNgii5cV8NGXOZpIUNfzg1OY+r/w4XKxU0eK2a/z39ICh lgB5RRHctkrqXCmwkCz2nWhBvb5Xd+xIiKCHyfalVRx6P0NsSxuFVkT8VRZr0l/KNndx osFA== Received: by 10.52.68.7 with SMTP id r7mr2929334vdt.96.1352915838381; Wed, 14 Nov 2012 09:57:18 -0800 (PST) Received: from [192.168.2.3] (pool-173-79-132-206.washdc.fios.verizon.net. [173.79.132.206]) by mx.google.com with ESMTPS id d4sm11476492vew.7.2012.11.14.09.57.14 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 09:57:17 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Wed, 14 Nov 2012 12:57:06 -0500 From: Carl Wallace To: Paul Wouters , Ben Laurie Message-ID: Thread-Topic: [dane] [therightkey] DANE and CT In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQnJ5IzOYt581lK6VU9sZEBXX83f6PcXlqCP+CVl0Eye7bjqmAL6iUKeF9efikVZxNRXF0Tn Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:57:19 -0000 On 11/14/12 11:30 AM, "Paul Wouters" wrote: >I think CT is a bandaid for PKIX that does not apply to DANE. I thought the point was that DANE would not be allowed to do "an end run" around CT so logging DANE stuff was necessary, not that DANE necessarily had the same needs as the web PKI. From shuque@upenn.edu Wed Nov 14 10:14:39 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5179F21F8758; Wed, 14 Nov 2012 10:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJazXCjdpGG0; Wed, 14 Nov 2012 10:14:38 -0800 (PST) Received: from mopeypopo.net.isc.upenn.edu (www.huque.com [IPv6:2607:f470:2:1::a:2]) by ietfa.amsl.com (Postfix) with ESMTP id B3A7721F86A8; Wed, 14 Nov 2012 10:14:38 -0800 (PST) Received: by mopeypopo.net.isc.upenn.edu (Postfix, from userid 500) id E70B3A5002; Wed, 14 Nov 2012 13:14:37 -0500 (EST) Date: Wed, 14 Nov 2012 13:14:37 -0500 From: Shumon Huque To: Ben Laurie Message-ID: <20121114181437.GA26508@isc.upenn.edu> References: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> <20121114172950.GA13499@isc.upenn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: University of Pennsylvania User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Tony Finch , therightkey@ietf.org, IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 18:14:39 -0000 On Wed, Nov 14, 2012 at 05:56:24PM +0000, Ben Laurie wrote: > On 14 November 2012 17:29, Shumon Huque wrote: > > On Wed, Nov 14, 2012 at 05:07:58PM +0000, Ben Laurie wrote: > >> On 14 November 2012 17:02, Tony Finch wrote: > >> > Warren Kumari wrote: > >> >> > >> >> If I run example.com and someone managed to generate / publish a TLSA > >> >> record for that I'd sure like to know about it. > >> > > >> > Right. But in PKIX a mis-issued certificate has nothing to do with your > >> > own infrastructure, whereas with DANE it implies that your infrastructure > >> > (or the infrastructure of your DNS service providers) has been > >> > compromised. > >> > >> Isn't the infrastructure of your DNS service providers nothing to do > >> with your own infrastructure? Not to mention your TLD's > >> infrastructure, and that of all of their registrars (and, presumably, > >> DNS service providers)? > > > > One critical difference is that with DANE, I can query the DNSSEC > > delegation chain myself and detect whether my TLD has installed a > > bogus DS record and take action. I cannot today detect a bogus > > X.509 cert by myself. I think this makes a CT like scheme less necessary > > for DANE. > > You can't detect a bogus X.509 cert because you can't connect to the > server serving it, presumably. What magic allows you to perform this > trick for DNS but not HTTPS? For the DANE/DNSSEC case, I'm detecting an attack on the DNSSEC authentication chain, not the existence of a fraudulently issued certificate on some attacker's server. If the DNSSEC chain is intact, then presumably DANE aware clients will properly authenticate the TLSA record before accepting the server certificate. I admit that's a mighty presumption today, but we'll see ... -- Shumon Huque University of Pennsylvania. From fneves@registro.br Wed Nov 14 10:49:03 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C4E21F8626; Wed, 14 Nov 2012 10:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ei4wsYCdJxfo; Wed, 14 Nov 2012 10:49:02 -0800 (PST) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by ietfa.amsl.com (Postfix) with ESMTP id 8780421F8622; Wed, 14 Nov 2012 10:49:02 -0800 (PST) Received: by clone.registro.br (Postfix, from userid 1000) id 27B25E0446; Wed, 14 Nov 2012 16:48:59 -0200 (BRST) Date: Wed, 14 Nov 2012 16:48:59 -0200 From: Frederico A C Neves To: Ben Laurie Message-ID: <20121114184859.GB18212@registro.br> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Mailman-Approved-At: Wed, 14 Nov 2012 13:26:00 -0800 Cc: therightkey@ietf.org, Paul Wouters , IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 18:49:03 -0000 On Wed, Nov 14, 2012 at 04:35:31PM +0000, Ben Laurie wrote: > On 14 November 2012 16:30, Paul Wouters wrote: > > On Wed, 14 Nov 2012, Ben Laurie wrote: ... > >>> What problem would CT for DANE be aiming to fix? > >> > >> > >> By all means add that to the list of questions :-) > >> > >> But I assume the same problem CT already fixes: misissuance of certs > >> (which in the DNSSEC world I guess mostly boils down to bad > >> delegation). > > > > > > Does that make sense though? With RRSIG validity times and TTL's you > > can set your "damange period" as small as you want. There is no issue > > like with certificates where your credentials can be abused for up to > > 12 months. > > > > The only use I could see is as an alternative mechanism to transfer these > > records into the application that does not require a clean DNS transport. > > > > I think CT is a bandaid for PKIX that does not apply to DANE. > > > > I think the problem with DANE/DNSSEC right now is the additional latency > > and dns transport issues (hotspots, VPN, etc) but I don't think CT is > > very well suited to address those. > > a) Why would an attacker use your validity times? What do you mean? What is your attack scenario? This thread quickly starts to move to a marshy soil. Fred From chris@randomnonce.org Wed Nov 14 18:09:56 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B3A21F844A for ; Wed, 14 Nov 2012 18:09:56 -0800 (PST) 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 M9VL1FNLThwV for ; Wed, 14 Nov 2012 18:09:55 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7F421F8448 for ; Wed, 14 Nov 2012 18:09:54 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so508316bku.31 for ; Wed, 14 Nov 2012 18:09:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=/ykS42L/XfBunuuP7ON/hekCTMJXY1kMyMvOyzP3c60=; b=mMJJeHRUyEerYXUo8f2XMEvTBLHVU2HWzESfvW1Q7hXvactgcviF9mhqCz6E6ms4kS DrYnI7m6+V0VmPb9haqAagxHqXxWuscDO82JPhZKrizD0jB+/g//4n/wKw5hmR6lrax8 lzH+EjCRkDIZ1lKEhUe53NQPWnxC/MxpwPJkYqFn7oAgkqME+b1BE6p9jTa5HwsuBZPT aBv6XeAKoCmk9KbCFKV/yVlsL/5L6N1lYAZGdUmv6YJRGTi40cfJxU7d2sfkNJksYJh/ BjJNMjvVOeTiPbKaA6ikxwJsBOuj1vAXF9sURobUyOuKbxt2HEfRUk/D0TnUNKRq+GBI XzQA== MIME-Version: 1.0 Received: by 10.204.9.139 with SMTP id l11mr7754358bkl.133.1352945393927; Wed, 14 Nov 2012 18:09:53 -0800 (PST) Received: by 10.205.125.132 with HTTP; Wed, 14 Nov 2012 18:09:53 -0800 (PST) X-Originating-IP: [62.220.135.129] Date: Thu, 15 Nov 2012 02:09:53 +0000 Message-ID: From: Chris Richardson To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkriSabx5lwmZnVGYvOSR+sD3H0+mXhIXWOMdFl+x6R6w0Qrvr9tnHjuBBR1KmN+giDZxDR Subject: [therightkey] draft-laurie-pki-sunlight-02 X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 02:09:56 -0000 I have a few questions and comments on this document: A general comment: What should a log do if it receives multiple submissions of the same certificate? It MUST detect and reject duplicates? SHOULD detect? What if it receives a certificate containing an embedded SCT from itself? MUST/SHOULD/MAY reject? Section 1.1 fixes the hash algorithm as SHA-256. It makes no mention of acceptable digital signature algorithms. http://www.certificate-transparency.org/sizes indicates the thinking is ECC. Is RSA an acceptable signature algorithm? Section 2.1: Shouldn't Version be covered by the signature in a SignedCertificateTimestamp? I'd think it would be beneficial to be able to verify that the signature was intended for the same version as is claimed in the unsigned portion. Section 2.2 (minor edit): upon first read, the units of old_tree_size wasn't clear (leaf count? bytes?) The description of tree_size is explicit on the units ("number of entries"). I would appreciate it if old_tree_size had similar text. Section 2.3 (minor edit): the last bullet uses the term tree_signature, when the rest of the text uses tree_head_signature. Regards, Chris From hallam@gmail.com Thu Nov 15 05:02:07 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8B821F88E0; Thu, 15 Nov 2012 05:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.237 X-Spam-Level: X-Spam-Status: No, score=-4.237 tagged_above=-999 required=5 tests=[AWL=-0.639, 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 sFtW-injI08v; Thu, 15 Nov 2012 05:02:06 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 33E7721F88D4; Thu, 15 Nov 2012 05:02:06 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so1676685oag.31 for ; Thu, 15 Nov 2012 05:02:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f2HC2wPzdPE8COkfgKDDQS9YFTBNN8ou70CmYFGivFk=; b=q6HbvIdWM6owz6bUflnaK1uLDQ2amg+e+xPIH2awssG8rFQ0d/UppcoYTLKGFpDoHh +BCYpS73a/+wLL0NNv4QDrMvNP2YQf+uf+LWyJsYGVoYRXzs7DPTZWSkyPwxyLcjPsJt yjtjZm+5nue8BQS+4pX8eNha49WylTOqrrgmynQcVIUkfrtS6vR5GnZLpvsEWgmO6WAg 1dLZpwJOUS70l10hr9XNHkNKAuZ1MTscYqSc2OddEnQqACPtFVAYFkrgwSpjsvbcol67 +UtJOKaUiASTjwm0GPDcTbRWgTcESKa9vs1lEfyS+PSpoe1B9LbReeVLgth4Uo/Y8nLR MMaw== MIME-Version: 1.0 Received: by 10.60.26.38 with SMTP id i6mr769234oeg.23.1352984525441; Thu, 15 Nov 2012 05:02:05 -0800 (PST) Received: by 10.76.27.103 with HTTP; Thu, 15 Nov 2012 05:02:04 -0800 (PST) In-Reply-To: References: Date: Thu, 15 Nov 2012 08:02:04 -0500 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=e89a8fb2007c068a1004ce884299 Cc: therightkey@ietf.org, Ben Laurie , IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 13:02:07 -0000 --e89a8fb2007c068a1004ce884299 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 14, 2012 at 11:02 AM, Tony Finch wrote: > Ben Laurie wrote: > > > At the CT BoF the question was raised: what about DANE? > > > > Which is a good question. So, I think Google is prepared to > > contemplate running a CT log for DANE, but this leaves some > > questions... > > What problem would CT for DANE be aiming to fix? > I see a number of issues that need fixing: 1) Domain hijacking DANE certificates are only as secure as the DNS names they are attached to. DNS hijacking occurs at a rate well in excess of 10,000 names a year and is probably much much higher if we could get better numbers. At present the DNS name owner (and it is the owner, regardless of what idiot lawyers claim) has to rely on their registrar to be competent and on the processes at the registry and to a certain extent on the honesty of other registrars. This whole area is essentially opaque, there is no documentation for most of the processes on which businesses are forced to rely. 2) Root jacking Russia and China are just not going to be recognizing the ICANN roots dudes. They have been telling everyone who will listen that they are going to fork the root and they have a big enough fraction of the population of the planet to make it stick. So people can do the ostrich head in the sand thing or they can anticipate this attack and think about ways to neutralize it. 3) Demonstrate continuity In the case that a DNS name changes hands I do not necessarily want to be sending the new information the confidential data I would have sent the old one. Lacking the ability to establish an external validation of the source, this means I am much more interested in determining the lineage of credentials. Or it could just be that the DANE people have created an absolutely perfect system that is beyond any possible reproach and the fact that nobody seems to be implementing it beyond limited scale trials and plugins is due to the inability of everyone else to fully appreciate their awesomeness. -- Website: http://hallambaker.com/ --e89a8fb2007c068a1004ce884299 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Nov 14, 2012 at 11:02 AM, Tony F= inch <dot@dotat.at> wrote:
Ben Laurie <benl@go= ogle.com> wrote:

> At the CT BoF the question was raised: what about DANE?
>
> Which is a good question. So, I think Google is prepared to
> contemplate running a CT log for DANE, but this leaves some
> questions...

What problem would CT for DANE be aiming to fix?

I see a number of issues that need fixing:

1) Domain hijacking

DANE certificates are= only as secure as the DNS names they are attached to. DNS hijacking occurs= at a rate well in excess of 10,000 names a year and is probably much much = higher if we could get better numbers.

At present the DNS name owner (and it is the owner, reg= ardless of what idiot lawyers claim) has to rely on their registrar to be c= ompetent and on the processes at the registry and to a certain extent on th= e honesty of other registrars. This whole area is essentially opaque, there= is no documentation for most of the processes on which businesses are forc= ed to rely.


2) Root jacking

Russia and China are just not going to be recognizing the ICANN roots dude= s. They have been telling everyone who will listen that they are going to f= ork the root and they have a big enough fraction of the population of the p= lanet to make it stick.

So people can do the ostrich head in the sand thing or = they can anticipate this attack and think about ways to neutralize it.


3) Demonstrate continuity

In the case that a DNS name changes hands I do not necessari= ly want to be sending the new information the confidential data I would hav= e sent the old one. Lacking the ability to establish an external validation= of the source, this means I am much more interested in determining the lin= eage of credentials.


Or it could just be that the DANE people= have created an absolutely perfect system that is beyond any possible repr= oach and the fact that nobody seems to be implementing it beyond limited sc= ale trials and plugins is due to the inability of everyone else to fully ap= preciate their awesomeness.
=A0

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

--e89a8fb2007c068a1004ce884299-- From benl@google.com Thu Nov 15 06:32:27 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E9721F88E9 for ; Thu, 15 Nov 2012 06:32:27 -0800 (PST) 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 7fvP3qCqbGHO for ; Thu, 15 Nov 2012 06:32:27 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D53F921F88D1 for ; Thu, 15 Nov 2012 06:32:26 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id u46so653240wey.31 for ; Thu, 15 Nov 2012 06:32:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UwTOQDIaRxvWKXGhYIj6DObeYJlDU7HiJnj6Tb30qvQ=; b=MMqBPJpCi2RlKEH7o8VWKp1hTNrQjtaYMnjOO/bGDJjSFstuSsGwuJum+IjK+EJG+S LUGi60pSq184TyrfHWp2KRFCPmdcRCZpdpHoQBk2fUUI56dVGojMbu5FIsyFbROQB/d1 mS/cTKs4nOLH3GLdoh2WNVnYo3kTjBgWbXmdf5JlaaofG8ylKLv9P88E3n4KxWfWWLFd 4wRFdL4Lm7KByCTUARuqHCSbh0sxKEdvOCeqrbMFF6Ukm9uYUivLGLzvath7FcKkjAip uE5CMN8ipRqXtN2pCpRo4c0Zt1/UL8sQAdhizXS8q7aXbSznbAqeobjYBoHyqDryABst aHbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=UwTOQDIaRxvWKXGhYIj6DObeYJlDU7HiJnj6Tb30qvQ=; b=Gs7hHqekSWqPnCsLDJlZq2lYRbF5CJAx/nj0FguPbPXFUcwE4eOVyV+ZL9Y6XCda/H fDLC8tsKig7A2L6FRscOG0JqgrBQTpfRoEMcPz3sLRjljKubK38TUCJWw85erpI78zWK 5ya6Vu5hcc/so/UdTiLMpgHZ2Rmb5HrUyc3OXgCnr7CpbjuOoTUALu4Amm5olWFB5SBt 2ZWGW3oKhmI53yG2dvWWbqfTL9c45imT5UxShEzJHNB81OdtZ41AVN4Ltg3px66dZoZC IdfCc0dK5XqxPFs8oyKIf4qzqVuBIE7IpfgKpelRVwuLhLyUN+e8pdaqPW6Oc/jXpt6x uBAA== MIME-Version: 1.0 Received: by 10.180.96.226 with SMTP id dv2mr147311wib.1.1352989945947; Thu, 15 Nov 2012 06:32:25 -0800 (PST) Received: by 10.194.51.100 with HTTP; Thu, 15 Nov 2012 06:32:25 -0800 (PST) In-Reply-To: References: Date: Thu, 15 Nov 2012 14:32:25 +0000 Message-ID: From: Ben Laurie To: Chris Richardson Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkizxBxAX8cEctcxDetg8G54mfcFPEcsLMDlwotgV9CBZvPyIodi3BuNz9fBLzHRbP8sjzsvQvtu/7QYyAHvKS6NoHlyVtD355HS+VUJdJXbjoO4JVmxjsKlhiOU4BO7VZ+h2GdpNtSdr0tIkPKU9pHVwOwO4oQz5qjvTYTEYtDUPqgZlV06EEBYmf99Ydefk6hgDxg Cc: therightkey@ietf.org Subject: Re: [therightkey] draft-laurie-pki-sunlight-02 X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 14:32:27 -0000 On 15 November 2012 02:09, Chris Richardson wrote: > I have a few questions and comments on this document: > > A general comment: What should a log do if it receives multiple > submissions of the same certificate? It MUST detect and reject > duplicates? SHOULD detect? What if it receives a certificate > containing an embedded SCT from itself? MUST/SHOULD/MAY reject? MAY return the same SCT as last time - this is already fixed in the next version (which I couldn't submit coz of cutoff dates). > Section 1.1 fixes the hash algorithm as SHA-256. It makes no mention > of acceptable digital signature algorithms. > http://www.certificate-transparency.org/sizes indicates the thinking > is ECC. Is RSA an acceptable signature algorithm? Yes, but obviously expensive, since a certificate should usually contain more than one SCT. > > Section 2.1: Shouldn't Version be covered by the signature in a > SignedCertificateTimestamp? I'd think it would be beneficial to be > able to verify that the signature was intended for the same version as > is claimed in the unsigned portion. Yes, this is already fixed, also. > Section 2.2 (minor edit): upon first read, the units of old_tree_size > wasn't clear (leaf count? bytes?) The description of tree_size is > explicit on the units ("number of entries"). I would appreciate it if > old_tree_size had similar text. OK. > Section 2.3 (minor edit): the last bullet uses the term > tree_signature, when the rest of the text uses tree_head_signature. Oops. I'm travelling this week, but will try to get an update out next week. > > Regards, > Chris > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey From paul.hoffman@vpnc.org Thu Nov 15 07:46:44 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842FA21F857C; Thu, 15 Nov 2012 07:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Op16P9xGt52T; Thu, 15 Nov 2012 07:46:44 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E25E721F8573; Thu, 15 Nov 2012 07:46:43 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAFFke8E064981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Nov 2012 08:46:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <20121114181437.GA26508@isc.upenn.edu> Date: Thu, 15 Nov 2012 07:46:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> <20121114172950.GA13499@isc.upenn.edu> <20121114181437.GA26508@isc.upenn.edu> To: Shumon Huque X-Mailer: Apple Mail (2.1499) Cc: therightkey@ietf.org, Ben Laurie , IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 15:46:44 -0000 On Nov 14, 2012, at 10:14 AM, Shumon Huque wrote: > For the DANE/DNSSEC case, I'm detecting an attack on the DNSSEC=20 > authentication chain, not the existence of a fraudulently issued=20 > certificate on some attacker's server. >=20 > If the DNSSEC chain is intact, then presumably DANE aware clients=20 > will properly authenticate the TLSA record before accepting the server=20= > certificate. I admit that's a mighty presumption today, but we'll see = ... This is an excellent summary of the scenario. However, that's not exactly what Ben is asking about. CT-for-PKIX is = about "did a trusted CA issue a certificate it should not have". = CT-for-DNSSEC is about "did a server in the hierarchy above the leaf = include a DS it should not have". In the latter case, those rogue DS = records might not be detectable to the party with the leaf record. For example, assume the domain name example.newtld. The owner of example = has put DS record A in the newtld zone. If the owner of newtld goes = rogue and shows DS record B to a limited number of requests (such as to = a particular geographic region or set of network addresses), the party = with the private key associated with B can spoof example, and the owner = of example would not know unless he could see B. --Paul Hoffman= From shuque@upenn.edu Thu Nov 15 10:43:25 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A743521F8552; Thu, 15 Nov 2012 10:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ma1zTvxpOHyY; Thu, 15 Nov 2012 10:43:25 -0800 (PST) Received: from mopeypopo.net.isc.upenn.edu (www.huque.com [IPv6:2607:f470:2:1::a:2]) by ietfa.amsl.com (Postfix) with ESMTP id 149F921F8563; Thu, 15 Nov 2012 10:43:25 -0800 (PST) Received: by mopeypopo.net.isc.upenn.edu (Postfix, from userid 500) id 3C2C7A5003; Thu, 15 Nov 2012 13:43:24 -0500 (EST) Date: Thu, 15 Nov 2012 13:43:24 -0500 From: Shumon Huque To: Paul Hoffman Message-ID: <20121115184324.GA21572@isc.upenn.edu> References: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> <20121114172950.GA13499@isc.upenn.edu> <20121114181437.GA26508@isc.upenn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: University of Pennsylvania User-Agent: Mutt/1.5.21 (2010-09-15) Cc: therightkey@ietf.org, Ben Laurie , IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:43:25 -0000 On Thu, Nov 15, 2012 at 07:46:47AM -0800, Paul Hoffman wrote: > On Nov 14, 2012, at 10:14 AM, Shumon Huque wrote: > > > For the DANE/DNSSEC case, I'm detecting an attack on the DNSSEC > > authentication chain, not the existence of a fraudulently issued > > certificate on some attacker's server. > > > > If the DNSSEC chain is intact, then presumably DANE aware clients > > will properly authenticate the TLSA record before accepting the server > > certificate. I admit that's a mighty presumption today, but we'll see ... > > This is an excellent summary of the scenario. > > However, that's not exactly what Ben is asking about. CT-for-PKIX is about "did a trusted CA issue a certificate it should not have". CT-for-DNSSEC is about "did a server in the hierarchy above the leaf include a DS it should not have". In the latter case, those rogue DS records might not be detectable to the party with the leaf record. > > For example, assume the domain name example.newtld. The owner of example has put DS record A in the newtld zone. If the owner of newtld goes rogue and shows DS record B to a limited number of requests (such as to a particular geographic region or set of network addresses), the party with the private key associated with B can spoof example, and the owner of example would not know unless he could see B. > > --Paul Hoffman Good point. An auditable log of DS/SEP key chains would seem to be useful for this. -- Shumon Huque University of Pennsylvania. From paul@nohats.ca Thu Nov 15 12:11:41 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE0821F850B; Thu, 15 Nov 2012 12:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k29YbIooC63y; Thu, 15 Nov 2012 12:11:41 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3167721F8530; Thu, 15 Nov 2012 12:11:40 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id E363A82B75; Thu, 15 Nov 2012 15:10:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A6BC182B5B; Thu, 15 Nov 2012 15:10:51 -0500 (EST) Date: Thu, 15 Nov 2012 15:10:51 -0500 (EST) From: Paul Wouters To: Ben Laurie In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Tony Finch , therightkey@ietf.org, IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 20:11:41 -0000 On Wed, 14 Nov 2012, Ben Laurie wrote: >> I think CT is a bandaid for PKIX that does not apply to DANE. >> >> I think the problem with DANE/DNSSEC right now is the additional latency >> and dns transport issues (hotspots, VPN, etc) but I don't think CT is >> very well suited to address those. > > a) Why would an attacker use your validity times? Because there are DNSSEC keys to back the time slots used, and without it, the data can and should be rejected. > b) Weren't you amongst those asking for CT to support DANE during the BoF? I wanted CT to not exclude DANE, and thereby enforcing an artificial TLS certificate market where I have to pay $10-$150 a year to be "accepted" in browsers via CT. What I understood was that browser vendors that were looking at CT and DANE would specifically not be supoprted. The first thought was to have a DANE backed CT that could be configured, purely to get the DANE information (valid key + TTL/RRSIG info) into the browsers that don't support or want to support DNSSEC (chains). But the DANE/DNSSEC information does not need an publicly shared audit log. Its current up to date validity is available in the DNS at all times, cached and distributed. Paul From paul@nohats.ca Thu Nov 15 12:33:34 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F64421F892D; Thu, 15 Nov 2012 12:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCOHsaZzcdYe; Thu, 15 Nov 2012 12:33:34 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id DD5CA21F892B; Thu, 15 Nov 2012 12:33:33 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 85A3782B75; Thu, 15 Nov 2012 15:32:47 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6F22982B5B; Thu, 15 Nov 2012 15:32:47 -0500 (EST) Date: Thu, 15 Nov 2012 15:32:47 -0500 (EST) From: Paul Wouters To: Paul Hoffman In-Reply-To: Message-ID: References: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> <20121114172950.GA13499@isc.upenn.edu> <20121114181437.GA26508@isc.upenn.edu> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: therightkey@ietf.org, Shumon Huque , Ben Laurie , IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 20:33:34 -0000 On Thu, 15 Nov 2012, Paul Hoffman wrote: > On Nov 14, 2012, at 10:14 AM, Shumon Huque wrote: > >> For the DANE/DNSSEC case, I'm detecting an attack on the DNSSEC >> authentication chain, not the existence of a fraudulently issued >> certificate on some attacker's server. >> >> If the DNSSEC chain is intact, then presumably DANE aware clients >> will properly authenticate the TLSA record before accepting the server >> certificate. I admit that's a mighty presumption today, but we'll see ... > > This is an excellent summary of the scenario. > > However, that's not exactly what Ben is asking about. CT-for-PKIX is about "did a trusted CA issue a certificate it should not have". CT-for-DNSSEC is about "did a server in the hierarchy above the leaf include a DS it should not have". In the latter case, those rogue DS records might not be detectable to the party with the leaf record. > > For example, assume the domain name example.newtld. The owner of example has put DS record A in the newtld zone. If the owner of newtld goes rogue and shows DS record B to a limited number of requests (such as to a particular geographic region or set of network addresses), the party with the private key associated with B can spoof example, and the owner of example would not know unless he could see B. Interesting. I had not considered this because a big difference is that such rogue DNS records would not be contained/targetted. The forged DS created by the parent would quickly expose the parent, and I doubt the parents would want that reputation damage. Unless they are totalitarian governments, but unlike phb, I give up any kind of using the internet against advisaries that are physically in the path - it just ends up with you refusing to be lied to and not connecting, or going along with their lies and getting eavesdropped. But I'm not sure how CT would see the difference between me logging in to my registrar interface and updating the DS record, someone else using my credentials to do the same without my knowledge, or the registry going rogue. The way PKIX-CT does this is via some financial transaction pretending to convey trust and authority and a credit card audit trail. It fails for the common user precisely because it costs money, and today's criminals have more money to invest compared to the average internet user. I also don't see how TACK addresses this either, with their complicated pinning schemes that are just many different ways of shooting yourself in the foot, without adding anything to the DANE pinning method (apart from relying on verisign to not forfeit their root zone contract to sign custom data for anyone) So I think CT could be used as DNSSEC/DANE history audit log, but IMHO the main asset of something like CT based DANE is purely as a better transport layer for DNSSEC - not as a replacement for DANE/DNSSEC. DNSSEC points to the publisher, who is defined as always right (even if they are wrong because they are sloppy or have a gun pointed at their heads) Paul From danny@tcb.net Thu Nov 15 14:57:48 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7698D21F89FF for ; Thu, 15 Nov 2012 14:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBG879X2JvDu for ; Thu, 15 Nov 2012 14:57:48 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 1B26921F8A03 for ; Thu, 15 Nov 2012 14:57:48 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id A7F562168 for ; Thu, 15 Nov 2012 22:57:47 +0000 (UTC) Received: from [10.196.208.46] (unknown [209.133.29.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id B34E51A30; Thu, 15 Nov 2012 15:57:46 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Danny McPherson In-Reply-To: Date: Thu, 15 Nov 2012 17:57:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3CF77CCB-5549-4888-8024-7842BB5FFE17@tcb.net> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Nov 15 15:57:47 2012 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 50a5736b199631436569348 X-DSPAM-Factors: 27, 15+#+#+8, 0.40000, the+DNS, 0.40000, they+#+#+to, 0.40000, this+Thanks, 0.40000, secure+#+#+#+names, 0.40000, they+#+attached, 0.40000, 000+names, 0.40000, excess+of, 0.40000, could+get, 0.40000, Baker+#+DANE, 0.40000, to+DNS, 0.40000, names+they, 0.40000, much+#+if, 0.40000, probably+#+#+#+if, 0.40000, and+#+probably, 0.40000, 8+#+#+Phillip, 0.40000, excess+#+10, 0.40000, have+#+#+qualifying, 0.40000, much+#+#+#+could, 0.40000, much+#+#+we, 0.40000, in+excess, 0.40000, certificates+#+only, 0.40000, Hallam+#+wrote, 0.40000, attached+to, 0.40000, as+secure, 0.40000, 000+#+a, 0.40000, To*Phillip+#+hallam, 0.40000 Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 22:57:48 -0000 On Nov 15, 2012, at 8:02 AM, Phillip Hallam-Baker wrote: >=20 > DANE certificates are only as secure as the DNS names they are = attached to. DNS hijacking occurs at a rate well in excess of 10,000 = names a year and is probably much much higher if we could get better = numbers. PHB - do you have a citation qualifying this? Thanks,=20 -danny From hallam@gmail.com Thu Nov 15 16:14:22 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44BC1F0C6E; Thu, 15 Nov 2012 16:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.215 X-Spam-Level: X-Spam-Status: No, score=-4.215 tagged_above=-999 required=5 tests=[AWL=-0.617, 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 ZHgVPyk8YYKS; Thu, 15 Nov 2012 16:14:22 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CE4D71F0C44; Thu, 15 Nov 2012 16:14:21 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id ef5so2407659obb.31 for ; Thu, 15 Nov 2012 16:14:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mYoJVbnz/zJbjVxUvhDUtPO8cU18fottomDMknAjJRs=; b=KJg2AIgy/YK5Fy4D5W/g8XTyioAkNAT2/qUtdWakzhdELWqruaxAj/ryrn46tqCzDI MkmaMfMYiYOR5XrE8c6ACP9ZPjdjub6ZYq5pW/9+0v5nWPzgS5p99gjNcfmudc+IOc9w 7jLX2HL7kIY5YNhASYfiwxzwdS4Rf9I8/FGA1y7Wk1tey/LP5ox18ijb3RU/dLibhjes CMGSy6ucX8j7u5Hgbr1RmAQYooY2y3VAT0Cu3cwYHlAHSZS83MtFKDlpxUyrCuffEixw 2VuvoIVQIDUQsjZP4JZqWhJrhkxUEsj12ub9DbeJ+GvBfXoBYz4fTLOMq89DqTxC9Ovf Kcfw== MIME-Version: 1.0 Received: by 10.60.5.232 with SMTP id v8mr2437002oev.26.1353024861305; Thu, 15 Nov 2012 16:14:21 -0800 (PST) Received: by 10.76.27.103 with HTTP; Thu, 15 Nov 2012 16:14:21 -0800 (PST) In-Reply-To: <3CF77CCB-5549-4888-8024-7842BB5FFE17@tcb.net> References: <3CF77CCB-5549-4888-8024-7842BB5FFE17@tcb.net> Date: Thu, 15 Nov 2012 19:14:21 -0500 Message-ID: From: Phillip Hallam-Baker To: Danny McPherson Content-Type: multipart/alternative; boundary=e89a8ff253583af9ed04ce91a61f Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 00:14:22 -0000 --e89a8ff253583af9ed04ce91a61f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 15, 2012 at 5:57 PM, Danny McPherson wrote: > > On Nov 15, 2012, at 8:02 AM, Phillip Hallam-Baker wrote: > > > > > DANE certificates are only as secure as the DNS names they are attached > to. DNS hijacking occurs at a rate well in excess of 10,000 names a year > and is probably much much higher if we could get better numbers. > > PHB - do you have a citation qualifying this? > Not one I can share. But it seemed at the lower bound to me given the number of sites I use that have been hijacked recently. You folk should have much more accurate figures. Care to share? -- Website: http://hallambaker.com/ --e89a8ff253583af9ed04ce91a61f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Nov 15, 2012 at 5:57 PM, Danny M= cPherson <danny@tcb.net> wrote:

On Nov 15, 2012, at 8:02 AM, Phillip Hallam-Baker wrote:

>
> DANE certificates are only as secure as the DNS names they are attache= d to. DNS hijacking occurs at a rate well in excess of 10,000 names a year = and is probably much much higher if we could get better numbers.

PHB - do you have a citation qualifying this?
Not one I can share. But it seemed at the lower bound to me gi= ven the number of sites I use that have been hijacked recently.

You folk should have much more accurate figures. Care to sha= re?=A0



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

--e89a8ff253583af9ed04ce91a61f-- From danny@tcb.net Thu Nov 15 16:37:23 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5786C1F0C49 for ; Thu, 15 Nov 2012 16:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVGkgmuaoMqD for ; Thu, 15 Nov 2012 16:37:23 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id D9B9B1F0C44 for ; Thu, 15 Nov 2012 16:37:22 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 55EA92164 for ; Fri, 16 Nov 2012 00:37:22 +0000 (UTC) Received: from [10.196.208.46] (unknown [209.133.29.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 89E792109; Thu, 15 Nov 2012 17:37:21 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Danny McPherson In-Reply-To: Date: Thu, 15 Nov 2012 19:37:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7C668D44-1041-43D2-9C97-F8611C966F4D@tcb.net> References: <3CF77CCB-5549-4888-8024-7842BB5FFE17@tcb.net> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Nov 15 17:37:22 2012 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 50a58ac2199639445116962 X-DSPAM-Factors: 27, Nope+#+just, 0.40000, hence+#+query, 0.40000, Hallam+#+#+#+folk, 0.40000, registry+operator, 0.40000, most+of, 0.40000, of+#+issues, 0.40000, Subject*therightkey+#+#+and, 0.40000, figures+Care, 0.40000, at+#+14, 0.40000, have+#+#+accurate, 0.40000, Nope+we're, 0.40000, much+more, 0.40000, to+share, 0.40000, Hallam+#+wrote, 0.40000, To*Phillip+#+hallam, 0.40000, Mime-Version*Message+#+v1283, 0.40000, Cc*dane+ietf.org, 0.40000, with+#+registrars, 0.40000, Subject*therightkey+#+#+#+CT, 0.40000, Cc*therightkey+ietf.org, 0.40000, Cc*WG+#+dane, 0.40000, share+#+#+just, 0.40000, the+#+hence, 0.40000, 7+14, 0.40000, issues+#+#+#+the, 0.40000, the+#+#+most, 0.40000, Phillip+#+#+wrote, 0.40000 Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 00:37:23 -0000 On Nov 15, 2012, at 7:14 PM, Phillip Hallam-Baker wrote: >=20 > You folk should have much more accurate figures. Care to share?=20 Nope, we're just the registry operator, most of these issues are = resolved with the registrars, hence my query. Thanks,=20 -danny From benl@google.com Fri Nov 16 03:23:10 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF21221F84DD for ; Fri, 16 Nov 2012 03:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.906 X-Spam-Level: X-Spam-Status: No, score=-102.906 tagged_above=-999 required=5 tests=[AWL=0.071, 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 ShGNV1uL4pwQ for ; Fri, 16 Nov 2012 03:23:10 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 222B821F84D7 for ; Fri, 16 Nov 2012 03:23:10 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so2977731vbb.31 for ; Fri, 16 Nov 2012 03:23:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VyVjZGX1xf/YPBKCKB9aYoe6TiLuAuhNe3q4U+HVmfs=; b=AzeW2FladyRRDvs+VicQo0xXAP+YqLOwejlD4NFuBr8SfcZMrlbz74BuvHdmVMBnsp XgwjupbyJZUwJh52l4u68NK+1O3XqNOChkUAYlThrJzdUIhdqwx5xCShs3wQLgLNZ5PX Ljg7H+jzlaR5FP74b9D9TBBU6W6HRpWcHkH8A8PV2R38/yy3eswmv4cMx5+ZGjKSpL28 OaN5+OSlR8EJXzv5Bg0lCQM03r4+0v86UPkRLBD4TGitmQjLpleOHOUyZGvobFAN1VwR zYVh5EN66ZunB1dV+cp7dn27fRJf4chkjdcfHBkP56h+XImjYoH7uj9bxA7rtw00vlC+ HyiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=VyVjZGX1xf/YPBKCKB9aYoe6TiLuAuhNe3q4U+HVmfs=; b=PXT0Kbu/YRg4emU/Q+G4ln+BTA/9N13o343AaYs7ABsgowXRWgo8QS6/fN9RytY53k RZB0WTLbPS8UUiK/WjzMnZHNn7v5Z2nChD9h1HzLM8ouyGrjfsfJTB+e/Kb4tCudBIju pnDTJfnlCfJpJ16NfIPY5jmvB/kJNoghmnIrFam3+qI6prqxJGTb+IX/tqAE5kLNUD6f gvR53L3N9/SIQMb2zPCCYFhsgq/TBQ/K6H1AdxIHiuL+Il34vw7Y9CZT0tich+zV3ae5 pMKb4TZ1gIXrF2qDDaQrfnruvGTYRuIhtvH9Jmjup3VASi6ADviFc+Y5Sz65pl73QIwf KO+A== MIME-Version: 1.0 Received: by 10.52.100.5 with SMTP id eu5mr5152075vdb.34.1353064989438; Fri, 16 Nov 2012 03:23:09 -0800 (PST) Received: by 10.220.228.6 with HTTP; Fri, 16 Nov 2012 03:23:09 -0800 (PST) In-Reply-To: References: Date: Fri, 16 Nov 2012 11:23:09 +0000 Message-ID: From: Ben Laurie To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnEYfw5AjzJKPbLJHAcqbc6LlsFaXoPPI5G+QlJH4Iwb9qfMMOxtU6xWomoMb/V2jbgr1TVAsH5FxsBH/bfe/6+aF9gVPCrOqdkEWoSFugEIDIM7m1jvnTIAImYAamJya1RoJ3DJldFp61CxE8kFf/uR1l5UduMYj2+i77dH28LzkH3sMu7BdHlHqU4TGMvOCsWo8yj Cc: Tony Finch , therightkey@ietf.org, IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 11:23:11 -0000 On 15 November 2012 20:10, Paul Wouters wrote: > On Wed, 14 Nov 2012, Ben Laurie wrote: > >>> I think CT is a bandaid for PKIX that does not apply to DANE. >>> >>> I think the problem with DANE/DNSSEC right now is the additional latency >>> and dns transport issues (hotspots, VPN, etc) but I don't think CT is >>> very well suited to address those. >> >> >> a) Why would an attacker use your validity times? > > > Because there are DNSSEC keys to back the time slots used, and > without it, the data can and should be rejected. This argument is circular: clearly if no-one ever gets control of keys for your domain, you don't have a problem. Validity times are irrelevant. If someone does get control, they control validity times, no? >> b) Weren't you amongst those asking for CT to support DANE during the BoF? > > I wanted CT to not exclude DANE, and thereby enforcing an artificial TLS > certificate market where I have to pay $10-$150 a year to be "accepted" > in browsers via CT. What I understood was that browser vendors that > were looking at CT and DANE would specifically not be supoprted. The > first thought was to have a DANE backed CT that could be configured, > purely to get the DANE information (valid key + TTL/RRSIG info) into > the browsers that don't support or want to support DNSSEC (chains). > > But the DANE/DNSSEC information does not need an publicly shared audit > log. Its current up to date validity is available in the DNS at all > times, cached and distributed. You have a lot of faith in a mechanism that is not designed to provide a globally consistent view. How does DNS prevent bad actors from showing local views of the DNS? (Hint: it doesn't). This is precisely what CT does, and is exactly the value it adds to this kind of system. As for CT vs DANE, it is precisely because DNS does not provide a robust infrastructure that DANE cannot be allowed to override CT. This can be fixed by making DANE use some kind of equivalently strong transparency. I agree with others that this is probably better applied to DS records than to TLSA records. > > Paul From benl@google.com Fri Nov 16 03:26:15 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0DC21F84D5 for ; Fri, 16 Nov 2012 03:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.917 X-Spam-Level: X-Spam-Status: No, score=-102.917 tagged_above=-999 required=5 tests=[AWL=0.060, 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 IE2M7nr2mRTM for ; Fri, 16 Nov 2012 03:26:15 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B4E4D21F84D4 for ; Fri, 16 Nov 2012 03:26:14 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so2980676vbb.31 for ; Fri, 16 Nov 2012 03:26:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BK/vFT/22OGlLJISTBGsHLRFMB4mvzbhnbxQG8plVbQ=; b=Nvzu+Zng1+Teko5fVV1XyXJJ33MFtcQQLeAsmHNoZ4l6w00ews9Yt/qBSBrZlno6Ge cdoWORujyAVTDt+4vSnoOjDP7Nyddt7YipZCLxj2HgRMojYNFEA7Y9GbJc4Fo87iOeQc 4AAUVRCxoK1MGuFHoaDI++H/4XbLLPaBcAxxc4ujdiNQMkoHzW7JTyS75WRyCLhCpsYQ EQpvtzoJJU7mbsjrHDM2NRts9eKRrkKeTj5ZrIhCwN9P8myGWpGAQMu0QENUzm4+Dj83 MTVm77Kbqy3lSLsgO1FRll0vEQ6dhWbksahNzZGR7jUsMAnqRMwCkooZjiPnzFuThOLn sx/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=BK/vFT/22OGlLJISTBGsHLRFMB4mvzbhnbxQG8plVbQ=; b=PDvhw3Z0O7ppygfQtM/asDMB7mcr3zzar9GEsDHljwjwQvrDfmFXYnecmNv0IEXU+x Iw0CTxMsIM3WM+IvckmejPt/mxKZZetkqcMyFII+HGE73g6KC51KWby6jpW/SiNPC5N6 MQ6zM/Y86tyVy/EFbjqDXBahjKFiXjyDRhv0aHYvM7OhVQ8ihhK2phB3jsIq9uP6OENX tPEtqO8n4DNnYLGbVd+e/4pgXkfK22MZY8AuEYj+J4MzowL7Kd/Daq2nNUQuOPO4CE0U pEaUa76HX+16x2Mku7fZE+ZsgZm8cfwCWVelRfPq4iEJig5qKzXZ+stm+K28P///M20R Xv+A== MIME-Version: 1.0 Received: by 10.52.34.168 with SMTP id a8mr3188417vdj.49.1353065174158; Fri, 16 Nov 2012 03:26:14 -0800 (PST) Received: by 10.220.228.6 with HTTP; Fri, 16 Nov 2012 03:26:14 -0800 (PST) In-Reply-To: References: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> <20121114172950.GA13499@isc.upenn.edu> <20121114181437.GA26508@isc.upenn.edu> Date: Fri, 16 Nov 2012 11:26:14 +0000 Message-ID: From: Ben Laurie To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmNHWsAO3VyeSAHSGmH/e8zWT1PGhlvwhfEzk5xUntES6m2XDZ2x0ggnPwCOQV3GlDS0a95UkI2pZ5Vc6flOtM9hn8PicmSWFa/W4tnPZiMmhoXH0gpYAN+QcIe4sKOo0J0WOSZmbfZkbyPStLT8JEyg7Cegkk2cP+DTqQN707w/ZgIFCirO3QZ5bnLlh/dZymA5Zm3 Cc: therightkey@ietf.org, Shumon Huque , Paul Hoffman , IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 11:26:15 -0000 On 15 November 2012 20:32, Paul Wouters wrote: > On Thu, 15 Nov 2012, Paul Hoffman wrote: > >> On Nov 14, 2012, at 10:14 AM, Shumon Huque wrote: >> >>> For the DANE/DNSSEC case, I'm detecting an attack on the DNSSEC >>> authentication chain, not the existence of a fraudulently issued >>> certificate on some attacker's server. >>> >>> If the DNSSEC chain is intact, then presumably DANE aware clients >>> will properly authenticate the TLSA record before accepting the server >>> certificate. I admit that's a mighty presumption today, but we'll see ... >> >> >> This is an excellent summary of the scenario. >> >> However, that's not exactly what Ben is asking about. CT-for-PKIX is about >> "did a trusted CA issue a certificate it should not have". CT-for-DNSSEC is >> about "did a server in the hierarchy above the leaf include a DS it should >> not have". In the latter case, those rogue DS records might not be >> detectable to the party with the leaf record. >> >> For example, assume the domain name example.newtld. The owner of example >> has put DS record A in the newtld zone. If the owner of newtld goes rogue >> and shows DS record B to a limited number of requests (such as to a >> particular geographic region or set of network addresses), the party with >> the private key associated with B can spoof example, and the owner of >> example would not know unless he could see B. > > > Interesting. I had not considered this because a big difference is that > such rogue DNS records would not be contained/targetted. The forged DS > created by the parent would quickly expose the parent, and I doubt the > parents would want that reputation damage. Unless they are totalitarian > governments, but unlike phb, I give up any kind of using the internet > against advisaries that are physically in the path - it just ends up > with you refusing to be lied to and not connecting, or going along with > their lies and getting eavesdropped. > > But I'm not sure how CT would see the difference between me logging > in to my registrar interface and updating the DS record, someone else > using my credentials to do the same without my knowledge, or the registry > going rogue. The way PKIX-CT does this is via some financial transaction > pretending to convey trust and authority and a credit card audit trail. > It fails for the common user precisely because it costs money, and > today's criminals have more money to invest compared to the average > internet user. Incorrect: CT provides a globally verifiable audit trail - the exchange of money is irrelevant. CT does not see the difference between you logging in to your registrar interface and updating the DS record, someone else using your credentials to do the same without your knowledge, or the registry going rogue. What it does it make all of these visible to you. Then it is up to you (or anyone else) to spot the abuse and do something about it. > I also don't see how TACK addresses this either, with their complicated > pinning schemes that are just many different ways of shooting yourself > in the foot, without adding anything to the DANE pinning method (apart > from relying on verisign to not forfeit their root zone contract to sign > custom data for anyone) > > So I think CT could be used as DNSSEC/DANE history audit log, but IMHO > the main asset of something like CT based DANE is purely as a better > transport > layer for DNSSEC - not as a replacement for DANE/DNSSEC. CT does not replace DNSSEC (or PKIX), it does as you say: provides an audit log. > DNSSEC points to the publisher, who is defined as always right (even if > they are wrong because they are sloppy or have a gun pointed at their > heads) > > Paul > From paul@nohats.ca Fri Nov 16 10:50:19 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B74F21F84CC; Fri, 16 Nov 2012 10:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m5PaHJRy1JG; Fri, 16 Nov 2012 10:50:18 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2D08D21F84C6; Fri, 16 Nov 2012 10:50:18 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id F360682B74; Fri, 16 Nov 2012 13:49:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D779982B5B; Fri, 16 Nov 2012 13:49:26 -0500 (EST) Date: Fri, 16 Nov 2012 13:49:26 -0500 (EST) From: Paul Wouters To: Ben Laurie In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Tony Finch , therightkey@ietf.org, IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 18:50:19 -0000 On Fri, 16 Nov 2012, Ben Laurie wrote: >> Because there are DNSSEC keys to back the time slots used, and >> without it, the data can and should be rejected. > > This argument is circular: clearly if no-one ever gets control of keys > for your domain, you don't have a problem. Validity times are > irrelevant. > > If someone does get control, they control validity times, no? If someone obtains your private keys, there is no need to forge anything or issue any new certificates, they just run a copy of your private key/cert on their MITM box. CT can't help you there either. If attackers get your private DNSSEC keys (which shouldn't even be online, and surely much harder to obtain compared to the TLS private key) you are lost. > You have a lot of faith in a mechanism that is not designed to provide > a globally consistent view. How does DNS prevent bad actors from > showing local views of the DNS? (Hint: it doesn't). The root key protects me against that. And the TLD key. Sure, if I'm using some untrusted national TLD which might be overwriting my parent NS/DS set, again you are in a no-win situation. Best you can do is monitor your own zone, and possible carry your own domain's trust anchors with you. And these same players would simply prevent you from accessing the CT services as well. > This is precisely what CT does, and is exactly the value it adds to > this kind of system. > > As for CT vs DANE, it is precisely because DNS does not provide a > robust infrastructure that DANE cannot be allowed to override CT. So Diginotar will submit a new cert for me to the CT, and we're back at square one? > This > can be fixed by making DANE use some kind of equivalently strong > transparency. I agree with others that this is probably better applied > to DS records than to TLSA records. While I agree that it won't hurt to log and audit DS records to see if verisign or the USG really is signing their own records with the root or .com keys, I still believe those two parts are the most secure players I know to delegate some trust to. The real weak points of DNSSEC will be the dns operators of the zones and the registrar webgui's for making zone changes. In fact, I would probably rather trust the root key, then most CT audit people - and it would come with less false positives due to the middle man delays. Paul From paul@nohats.ca Fri Nov 16 10:54:10 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C404421F8AF0; Fri, 16 Nov 2012 10:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAmq-JGUEaEC; Fri, 16 Nov 2012 10:54:10 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 38FDD21F8AED; Fri, 16 Nov 2012 10:54:10 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 03D1782B74; Fri, 16 Nov 2012 13:53:25 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D952982B5B; Fri, 16 Nov 2012 13:53:25 -0500 (EST) Date: Fri, 16 Nov 2012 13:53:25 -0500 (EST) From: Paul Wouters To: Ben Laurie In-Reply-To: Message-ID: References: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> <20121114172950.GA13499@isc.upenn.edu> <20121114181437.GA26508@isc.upenn.edu> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: therightkey@ietf.org, Shumon Huque , Paul Hoffman , IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 18:54:10 -0000 > Incorrect: CT provides a globally verifiable audit trail - the > exchange of money is irrelevant. It is if Google CT only accepts submissions of CAs, and Chrome ships with the Google CT. It forces me to use CAs. > CT does not see the difference between you logging in to your > registrar interface and updating the DS record, someone else using > your credentials to do the same without your knowledge, or the > registry going rogue. What it does it make all of these visible to > you. Then it is up to you (or anyone else) to spot the abuse and do > something about it. Which is the exact problem of outsourcing trust vs trusting no one. People keep insisting they can do both. Adding another "cert patrol" warning box in my browser isn't going to make users more secure. So what happens if I update my TLS key? I need to live with a few hours of users getting told my site is hacked and clicking OK, or do we ignore the first few hours of a site being compromised? Paul From paul.hoffman@vpnc.org Fri Nov 16 11:06:53 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8264821F8688; Fri, 16 Nov 2012 11:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SXDOjtYWoR4; Fri, 16 Nov 2012 11:06:53 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 06BA121F850E; Fri, 16 Nov 2012 11:06:52 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAGJ6ocu014277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 16 Nov 2012 12:06:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Fri, 16 Nov 2012 11:06:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <70D44D23-477C-44AC-AE5F-7EAB7BFA0207@vpnc.org> References: To: Ben Laurie X-Mailer: Apple Mail (2.1499) Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 19:06:53 -0000 On Nov 16, 2012, at 3:23 AM, Ben Laurie wrote: > As for CT vs DANE, it is precisely because DNS does not provide a > robust infrastructure that DANE cannot be allowed to override CT. This > can be fixed by making DANE use some kind of equivalently strong > transparency. I agree with others that this is probably better applied > to DS records than to TLSA records. Proposal: we take this off the DANE list and keep it on therightkey = list, focused on DS instead of DANE. That is, a rogue zone with = additional / substitute DS records might affect more than DANE in the = future. --Paul Hoffman= From hallam@gmail.com Fri Nov 16 14:40:10 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147E721F845B; Fri, 16 Nov 2012 14:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.177 X-Spam-Level: X-Spam-Status: No, score=-4.177 tagged_above=-999 required=5 tests=[AWL=-0.579, 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 fjLHDZkdftYy; Fri, 16 Nov 2012 14:40:09 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3725A21F844A; Fri, 16 Nov 2012 14:40:09 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so3500523oag.31 for ; Fri, 16 Nov 2012 14:40:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iA/az03uAzTI4QvMsdI5V7vVvGge6K2DVf99LDBkw2I=; b=Am7GTgMt9Z4MmtIFilcy7tc34wtMtiQutmHVKBeCgOS7yY/4//AXABThLMxgOUnzLl EEl/hjfD6LCMyGwP1ZEdiI8bjyANpoJn8t2kNJS90Jocz8RUOAI59k+ykHGP7bi4lnSx nPL2taYz7IklQo9A4+8k44/3bmjTUnmTAeSrSBNX4k7E8dfk56Dnk5+FZbliDnZeORaP aWh2YLCTShIZqiTkt90iN85iTjM7qiW4EpnYeE0kRsSDJhn/eObqVnX9g9VhroiIhLYF 0QsZIasQ60XoeGjL4UB7+P/cyuGtMKyI9Dj/CX3iOBNxB8c+2rpXqKNR//hBmnLhDUws JMRQ== MIME-Version: 1.0 Received: by 10.182.95.205 with SMTP id dm13mr5260418obb.9.1353105607522; Fri, 16 Nov 2012 14:40:07 -0800 (PST) Received: by 10.76.27.103 with HTTP; Fri, 16 Nov 2012 14:40:07 -0800 (PST) In-Reply-To: <70D44D23-477C-44AC-AE5F-7EAB7BFA0207@vpnc.org> References: <70D44D23-477C-44AC-AE5F-7EAB7BFA0207@vpnc.org> Date: Fri, 16 Nov 2012 17:40:07 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=14dae93b63201479e604cea47310 Cc: therightkey@ietf.org, Ben Laurie , IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 22:40:10 -0000 --14dae93b63201479e604cea47310 Content-Type: text/plain; charset=ISO-8859-1 +1 Paul is right here, the big value in CT is probably applying it as a reinforcement against people screwing with the DS records or to ensure that DLV type schemes are not being futzed with. On Fri, Nov 16, 2012 at 2:06 PM, Paul Hoffman wrote: > On Nov 16, 2012, at 3:23 AM, Ben Laurie wrote: > > > As for CT vs DANE, it is precisely because DNS does not provide a > > robust infrastructure that DANE cannot be allowed to override CT. This > > can be fixed by making DANE use some kind of equivalently strong > > transparency. I agree with others that this is probably better applied > > to DS records than to TLSA records. > > Proposal: we take this off the DANE list and keep it on therightkey list, > focused on DS instead of DANE. That is, a rogue zone with additional / > substitute DS records might affect more than DANE in the future. > > --Paul Hoffman > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > -- Website: http://hallambaker.com/ --14dae93b63201479e604cea47310 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

Paul is right here, the big value in CT is probably a= pplying it as a reinforcement against people screwing with the DS records o= r to ensure that DLV type schemes are not being futzed with.=A0

On Fri, Nov 16, 2012 at 2:06 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Nov 16, 2012, at 3:23 AM, Ben Laurie <benl@google.com> wrote:

> As for CT vs DANE, it is precisely because DNS does not provide a
> robust infrastructure that DANE cannot be allowed to override CT. This=
> can be fixed by making DANE use some kind of equivalently strong
> transparency. I agree with others that this is probably better applied=
> to DS records than to TLSA records.

Proposal: we take this off the DANE list and keep it on therightkey l= ist, focused on DS instead of DANE. That is, a rogue zone with additional /= substitute DS records might affect more than DANE in the future.

--Paul Hoffman
_____________________= __________________________
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey



--
= Website: http://hallambaker.com/
--14dae93b63201479e604cea47310-- From cloos@jhcloos.com Fri Nov 16 17:05:52 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE6421F8AE4; Fri, 16 Nov 2012 17:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSGG1dzgyAEQ; Fri, 16 Nov 2012 17:05:52 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 7D35621F8A22; Fri, 16 Nov 2012 17:05:49 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id CD94840107; Sat, 17 Nov 2012 01:05:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1353114346; bh=O7YCXcXAEjGb8LMdpe2tJ4r+WSaDu5TWmTTib0Vu2Nw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=d4uEfrcwqkKwCu+nxxWqVmaoNqB74FwSXJ4APa80NPU13r23fmm0CslOYHCaSjMcf e25VaCpTT+2aK8wulqZSHVeDl/GZzNOZxqULBcCjBh11k9iKol4G64ZpWjoAyFCxsp VI+6EH1VFyI5tVs5qijwXwkJ/5zsn/dz5OqnaaJU= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 25E1460119; Sat, 17 Nov 2012 00:50:47 +0000 (UTC) From: James Cloos To: therightkey@ietf.org In-Reply-To: <70D44D23-477C-44AC-AE5F-7EAB7BFA0207@vpnc.org> (Paul Hoffman's message of "Fri, 16 Nov 2012 11:06:50 -0800") References: <70D44D23-477C-44AC-AE5F-7EAB7BFA0207@vpnc.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 16 Nov 2012 19:50:47 -0500 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:121117:therightkey@ietf.org::HQJLgewKY+T8MqBS:0000000000000000000000000000000000000000fnUbO X-Hashcash: 1:30:121117:paul.hoffman@vpnc.org::GuplIm+EdG17hjeM:000000000000000000000000000000000000000BmTai X-Hashcash: 1:30:121117:benl@google.com::YXtCvA0g/8x4kdNo:0zKyBB X-Hashcash: 1:30:121117:dane@ietf.org::ifU0jUUHziyVNRv6:000Hnjo2 Cc: Ben Laurie , Paul Hoffman , dane@ietf.org Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 01:05:52 -0000 >>>>> "PH" == Paul Hoffman writes: PH> Proposal: we take this off the DANE list and keep it on therightkey PH> list, focused on DS instead of DANE. +1 TLSA is only one relevant vector for dnssec attacks. Any such discussion should be more general. And tracking DS RRs feels like enough to provide tamper evidence, at least. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From benl@google.com Sat Nov 17 02:52:56 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722E421F8761 for ; Sat, 17 Nov 2012 02:52:56 -0800 (PST) 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 r2vfiSoOKGl9 for ; Sat, 17 Nov 2012 02:52:55 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 919D021F8596 for ; Sat, 17 Nov 2012 02:52:55 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id u46so1401802wey.31 for ; Sat, 17 Nov 2012 02:52:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2mzx1nMqYZ/lZoJyg7tSf1BZAqu7cS9y+b2Qqs8YoKk=; b=fhT9NJ5vg7Bnr5CS1Ct/JerDbDDXbP6ZlSIZl3yQQtmKbVRexn4+wnJDtFEhSCYYwO /9dLTgghtNv5XSrSLm47INeOaxc8BJJmgnTW8t1eQH0kE1cjZCPaMbtaqgB3slGgKfYk 7ZAj+wFAp4Hiqx65ziAOOusPlCfo09qgPxACxsbWqyQld4P34MBgQNkCViPgK5TH+9ez JgM4+fS3Wh515LdJVXoMszIGdW6O8Ik4VfM8YwaExkj5Zx8vYvfkUIbkayc80BWrIKG1 FYZlRZNS8XxloQw/tSqRs7+1IsPihDF8kTT2vgoTc5uRtT5ZoK8Qb+XmyysE78hyOjCl +uIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=2mzx1nMqYZ/lZoJyg7tSf1BZAqu7cS9y+b2Qqs8YoKk=; b=h6N9ZUdU17Swqz94ZLAd/idWAv82ro5WFF6k1HS2OagBk74jSQ6Qn/fiTqAVPQBjuo 5svapYyV7UWc7CjY9RPeO2Mhl2dsM/Gc24NVWIZBsS43p/oFyHdXcN/cczI0L+Q0pa8M 3CJgBcnN2UvKpf1SW6a0UOnBeMvTArAwWRnoBHKRCssUt6SC9SELJMSuO9hblg7myN6z /44BnEs85dWTyThRfBhBNNkFH0nOL/Y/nBI2STrfCJ/e4nfp6OhOc+8tTK4rBOgE5ISd +3pgwKaBamrZarodyujPcUjVW/Y2G7cbr5B6yjE7zsggGsQQGcEzn7usmo6Oe1FkC0lr orYw== MIME-Version: 1.0 Received: by 10.180.19.71 with SMTP id c7mr1726104wie.2.1353149574612; Sat, 17 Nov 2012 02:52:54 -0800 (PST) Received: by 10.194.51.100 with HTTP; Sat, 17 Nov 2012 02:52:54 -0800 (PST) In-Reply-To: <70D44D23-477C-44AC-AE5F-7EAB7BFA0207@vpnc.org> References: <70D44D23-477C-44AC-AE5F-7EAB7BFA0207@vpnc.org> Date: Sat, 17 Nov 2012 10:52:54 +0000 Message-ID: From: Ben Laurie To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk3hVK35et1cCvKLzAtijWwQwXINyLnbXfoXOChAEQ1bwaY0u79iTNxT3o+CAMwupDwqXwrtdLLAI28QFHVL573uLYZ8uE92heDH2p6/MjI5qgewuWzyh1tJvzKUXnWlsAX8kQUu/5q1tWYW+1yylUZBlOaI/7TOm9J/n4Qfd3vZCIRDXITJUSAtYf6dB8Is5F4qdN9 Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [therightkey] [dane] DANE and CT X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 10:52:56 -0000 On 16 November 2012 19:06, Paul Hoffman wrote: > On Nov 16, 2012, at 3:23 AM, Ben Laurie wrote: > >> As for CT vs DANE, it is precisely because DNS does not provide a >> robust infrastructure that DANE cannot be allowed to override CT. This >> can be fixed by making DANE use some kind of equivalently strong >> transparency. I agree with others that this is probably better applied >> to DS records than to TLSA records. > > Proposal: we take this off the DANE list and keep it on therightkey list, focused on DS instead of DANE. That is, a rogue zone with additional / substitute DS records might affect more than DANE in the future. +1 > > --Paul Hoffman From paul.hoffman@vpnc.org Sat Nov 17 08:01:11 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D50D21F8563 for ; Sat, 17 Nov 2012 08:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXijY0oDPpoI for ; Sat, 17 Nov 2012 08:01:11 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id F421121F8469 for ; Sat, 17 Nov 2012 08:01:10 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAHG18qV046575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 17 Nov 2012 09:01:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2B12532F-90DE-4265-9EDB-38F49B5CA951@vpnc.org> Date: Sat, 17 Nov 2012 08:01:10 -0800 To: "therightkey@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 16:01:11 -0000 CT-for-PKIX helps a web site administrator determine if a trusted CA = ever issued a certificate that should not have been issued. =20 CT-for-DNSSEC helps a DNS zone administrator determine whether a DNS = server in the hierarchy above the leaf zone ever included a DS record = that should not have been included. It would be good to have agreement on the above; feel free to offer = changes and see if the authors agree. Then we can talk about the = relationship between the two. --Paul Hoffman= From shuque@upenn.edu Sat Nov 17 10:18:42 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9070821F8473 for ; Sat, 17 Nov 2012 10:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pyde1bLcfs4 for ; Sat, 17 Nov 2012 10:18:41 -0800 (PST) Received: from mopeypopo.net.isc.upenn.edu (www.huque.com [IPv6:2607:f470:2:1::a:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF0B21F8BF5 for ; Sat, 17 Nov 2012 10:18:40 -0800 (PST) Received: by mopeypopo.net.isc.upenn.edu (Postfix, from userid 500) id 847AEA5003; Sat, 17 Nov 2012 13:18:39 -0500 (EST) Date: Sat, 17 Nov 2012 13:18:39 -0500 From: Shumon Huque To: Paul Hoffman Message-ID: <20121117181839.GA25913@isc.upenn.edu> References: <2B12532F-90DE-4265-9EDB-38F49B5CA951@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B12532F-90DE-4265-9EDB-38F49B5CA951@vpnc.org> Organization: University of Pennsylvania User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 18:18:42 -0000 On Sat, Nov 17, 2012 at 08:01:10AM -0800, Paul Hoffman wrote: > CT-for-PKIX helps a web site administrator determine if a trusted CA ever issued a certificate that should not have been issued. > > CT-for-DNSSEC helps a DNS zone administrator determine whether a DNS server in the hierarchy above the leaf zone ever included a DS record that should not have been included. > > It would be good to have agreement on the above; feel free to offer changes and see if the authors agree. Then we can talk about the relationship between the two. > Sounds reasonable to me. Does "CT" need to be renamed for DNSSEC? Since we're talking about transparency of delegation records/keys and not X.509 certificates. If C means "certification" in the general sense, then I suppose it might still be applicable since a (signed) DS record certifies the authenticity of the secure entry point key in a subordinate zone. -- Shumon Huque University of Pennsylvania. From rbarnes@bbn.com Sat Nov 17 11:32:48 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AD821F860A for ; Sat, 17 Nov 2012 11:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.69 X-Spam-Level: X-Spam-Status: No, score=-106.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqOXWXwvkjOc for ; Sat, 17 Nov 2012 11:32:48 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id E2F0B21F85FC for ; Sat, 17 Nov 2012 11:32:47 -0800 (PST) Received: from [128.89.253.151] (port=51969) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TZo8D-000EEs-3Z; Sat, 17 Nov 2012 14:32:45 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Richard L. Barnes" In-Reply-To: <20121117181839.GA25913@isc.upenn.edu> Date: Sat, 17 Nov 2012 14:32:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2B12532F-90DE-4265-9EDB-38F49B5CA951@vpnc.org> <20121117181839.GA25913@isc.upenn.edu> To: Shumon Huque X-Mailer: Apple Mail (2.1499) Cc: "therightkey@ietf.org" , Paul Hoffman Subject: Re: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 19:32:48 -0000 >> CT-for-PKIX helps a web site administrator determine if a trusted CA = ever issued a certificate that should not have been issued. =20 >>=20 >> CT-for-DNSSEC helps a DNS zone administrator determine whether a DNS = server in the hierarchy above the leaf zone ever included a DS record = that should not have been included. >>=20 >> It would be good to have agreement on the above; feel free to offer = changes and see if the authors agree. Then we can talk about the = relationship between the two. >>=20 >=20 > Sounds reasonable to me. >=20 > Does "CT" need to be renamed for DNSSEC? Since we're talking about=20 > transparency of delegation records/keys and not X.509 certificates.=20 > If C means "certification" in the general sense, then I suppose it > might still be applicable since a (signed) DS record certifies the > authenticity of the secure entry point key in a subordinate zone. "DST"? The definitions sound reasonable, but I'm at a loss as to why you would = bother with "CT-for-DNSSEC". The whole point of CT is that the space of = X.509 issuers is very large, and the certificates can be presented by = any server on the Internet. It's a hassle to check every, say, HTTPS = server on the Internet to see if a cert with your name is being = provided. In DNSSEC, the set of "issuers" is very small (parent domains), and the = DS records originate from a well-defined set of sources (authoritative = servers for those domains). Checking those servers is not that much = more difficult than checking a CT log, and doesn't require any new = protocol.= From paul.hoffman@vpnc.org Sat Nov 17 11:37:49 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BD921F8532 for ; Sat, 17 Nov 2012 11:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWwBA-gGvL6f for ; Sat, 17 Nov 2012 11:37:49 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 428C021F8687 for ; Sat, 17 Nov 2012 11:37:49 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAHJbe0o053229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 17 Nov 2012 12:37:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Sat, 17 Nov 2012 11:37:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2603023B-FBA3-433D-82BF-A742BC43FB66@vpnc.org> References: <2B12532F-90DE-4265-9EDB-38F49B5CA951@vpnc.org> <20121117181839.GA25913@isc.upenn.edu> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1499) Cc: therightkey@ietf.org Subject: Re: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 19:37:50 -0000 On Nov 17, 2012, at 11:32 AM, "Richard L. Barnes" = wrote: >>> CT-for-PKIX helps a web site administrator determine if a trusted CA = ever issued a certificate that should not have been issued. =20 >>>=20 >>> CT-for-DNSSEC helps a DNS zone administrator determine whether a DNS = server in the hierarchy above the leaf zone ever included a DS record = that should not have been included. >>>=20 >>> It would be good to have agreement on the above; feel free to offer = changes and see if the authors agree. Then we can talk about the = relationship between the two. >>>=20 >>=20 >> Sounds reasonable to me. >>=20 >> Does "CT" need to be renamed for DNSSEC? Since we're talking about=20 >> transparency of delegation records/keys and not X.509 certificates.=20= >> If C means "certification" in the general sense, then I suppose it >> might still be applicable since a (signed) DS record certifies the >> authenticity of the secure entry point key in a subordinate zone. >=20 > "DST"? >=20 > The definitions sound reasonable, but I'm at a loss as to why you = would bother with "CT-for-DNSSEC". The whole point of CT is that the = space of X.509 issuers is very large, and the certificates can be = presented by any server on the Internet. It's a hassle to check = every, say, HTTPS server on the Internet to see if a cert with your name = is being provided. >=20 > In DNSSEC, the set of "issuers" is very small (parent domains), and = the DS records originate from a well-defined set of sources = (authoritative servers for those domains). Checking those servers is = not that much more difficult than checking a CT log, and doesn't require = any new protocol. Maybe you missed the earlier discussion of this in the past few days. Rogue DS records might not be detectable to the party with the leaf = record. For example, assume the domain name example.newtld. The owner of = example has put DS record A in the newtld zone. If the owner of newtld = goes rogue and shows DS record B to a limited number of requests (such = as to a particular geographic region or set of network addresses), the = party with the private key associated with B can spoof example, and the = owner of example would not know unless he could see B. --Paul Hoffman= From carl@redhoundsoftware.com Sat Nov 17 13:50:18 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F13B21F8467 for ; Sat, 17 Nov 2012 13:50:18 -0800 (PST) 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 cAeTrzRIq+qg for ; Sat, 17 Nov 2012 13:50:17 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F34BC21F8466 for ; Sat, 17 Nov 2012 13:50:16 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so4345058vbb.31 for ; Sat, 17 Nov 2012 13:50:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=eZ/VA2COp16JjTdy+GORho+DyrpxWsMa6EuzEkWJ/mA=; b=OEAFLXc5nDNu6ajpTgjP3VWJBYch/senSyt6aiK8l/X49h4IvaqG/tLDKkAGGvkMmM PPfcRG77s4vCjnNNyo533whIlckSI3AFagreJJJRjUo4UJ/MZsuvLj4hmaFxVLGbUqoh 8TXvhJt7RtbXGjsPrm5WKsYo/0du/AR3bLE7o6/Buq5IbUZPtBRg1O202casIZ6h7y22 /GHh/mmMrurhhy+k0cp7SiHgJdlLOEfDB45BJC/O5mHIxUnJLRQA2O6HyW4esA5oxX8U 6JtKzuxzoRO65GEr8vuK6z7SxxLPFoA9kwFgkgjCoHtgm1wIFrsWkDGz0y2pmA4rPmmn sxfg== Received: by 10.59.6.39 with SMTP id cr7mr11009139ved.17.1353189016273; Sat, 17 Nov 2012 13:50:16 -0800 (PST) Received: from [192.168.2.6] (pool-173-79-110-220.washdc.fios.verizon.net. [173.79.110.220]) by mx.google.com with ESMTPS id l15sm3156046vdt.14.2012.11.17.13.50.13 (version=SSLv3 cipher=OTHER); Sat, 17 Nov 2012 13:50:15 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Sat, 17 Nov 2012 16:50:12 -0500 From: Carl Wallace To: Paul Hoffman , "Richard L. Barnes" Message-ID: Thread-Topic: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC In-Reply-To: <2603023B-FBA3-433D-82BF-A742BC43FB66@vpnc.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQl0QeORSZzbcrL7+4o8E8BfMrlz0zNvxMACUasJK2w8twI0z6bZ5dHgpJrB8LawszzqTB2J Cc: therightkey@ietf.org Subject: Re: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 21:50:18 -0000 On 11/17/12 2:37 PM, "Paul Hoffman" wrote: >On Nov 17, 2012, at 11:32 AM, "Richard L. Barnes" wrote: > >>>> CT-for-PKIX helps a web site administrator determine if a trusted CA >>>>ever issued a certificate that should not have been issued. >>>> >>>> CT-for-DNSSEC helps a DNS zone administrator determine whether a DNS >>>>server in the hierarchy above the leaf zone ever included a DS record >>>>that should not have been included. >>>> >>>> It would be good to have agreement on the above; feel free to offer >>>>changes and see if the authors agree. Then we can talk about the >>>>relationship between the two. >>>> >>> >>> Sounds reasonable to me. >>> >>> Does "CT" need to be renamed for DNSSEC? Since we're talking about >>> transparency of delegation records/keys and not X.509 certificates. >>> If C means "certification" in the general sense, then I suppose it >>> might still be applicable since a (signed) DS record certifies the >>> authenticity of the secure entry point key in a subordinate zone. >> >> "DST"? >> >> The definitions sound reasonable, but I'm at a loss as to why you would >>bother with "CT-for-DNSSEC". The whole point of CT is that the space of >>X.509 issuers is very large, and the certificates can be presented by >>any server on the Internet. It's a hassle to check every, say, HTTPS >>server on the Internet to see if a cert with your name is being provided. >> >> In DNSSEC, the set of "issuers" is very small (parent domains), and the >>DS records originate from a well-defined set of sources (authoritative >>servers for those domains). Checking those servers is not that much >>more difficult than checking a CT log, and doesn't require any new >>protocol. > >Maybe you missed the earlier discussion of this in the past few days. > >Rogue DS records might not be detectable to the party with the leaf >record. For example, assume the domain name example.newtld. The owner of >example has put DS record A in the newtld zone. If the owner of newtld >goes rogue and shows DS record B to a limited number of requests (such as >to a particular geographic region or set of network addresses), the party >with the private key associated with B can spoof example, and the owner >of example would not know unless he could see B. Who is intended to be able to contribute to the log? It seems like for this to provide the desired visibility, any client should be able to. For CT, at least, I thought this was not to be the case. From paul@nohats.ca Sat Nov 17 15:07:25 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD5921F84F3 for ; Sat, 17 Nov 2012 15:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TT39AIjV6a6C for ; Sat, 17 Nov 2012 15:07:25 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6195921F84F2 for ; Sat, 17 Nov 2012 15:07:25 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id E0BB182B75; Sat, 17 Nov 2012 18:06:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9639E804AA; Sat, 17 Nov 2012 18:06:36 -0500 (EST) Date: Sat, 17 Nov 2012 18:06:35 -0500 (EST) From: Paul Wouters To: Carl Wallace In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Richard L. Barnes" , therightkey@ietf.org, Paul Hoffman Subject: Re: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 23:07:26 -0000 On Sat, 17 Nov 2012, Carl Wallace wrote: >> Rogue DS records might not be detectable to the party with the leaf >> record. For example, assume the domain name example.newtld. The owner of >> example has put DS record A in the newtld zone. If the owner of newtld >> goes rogue and shows DS record B to a limited number of requests (such as >> to a particular geographic region or set of network addresses), the party >> with the private key associated with B can spoof example, and the owner >> of example would not know unless he could see B. > > Who is intended to be able to contribute to the log? It seems like for > this to provide the desired visibility, any client should be able to. For > CT, at least, I thought this was not to be the case. How do you authenticate that? You cannot use the DS/DNSKEY for authentication because then the CT audit log is useless to detect compromises. And you cannot say "The CA industry" either, which is the answer for the CT-PKIX version. If you make CT-DNSSEC go through the CA industry, it will cost $10/year or more to get in the audit log. Paul From paul.hoffman@vpnc.org Sat Nov 17 17:24:10 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D820921F86C1 for ; Sat, 17 Nov 2012 17:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+nt2ftUUiUi for ; Sat, 17 Nov 2012 17:24:10 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA7E21F84A1 for ; Sat, 17 Nov 2012 17:24:10 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAI1O50Q061708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 17 Nov 2012 18:24:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Sat, 17 Nov 2012 17:24:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <208851A7-84FB-4BF9-ACCE-18A931B146F6@vpnc.org> References: To: Paul Wouters X-Mailer: Apple Mail (2.1499) Cc: therightkey@ietf.org Subject: Re: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 01:24:11 -0000 On Nov 17, 2012, at 3:06 PM, Paul Wouters wrote: > On Sat, 17 Nov 2012, Carl Wallace wrote: >=20 >> Who is intended to be able to contribute to the log? It seems like = for >> this to provide the desired visibility, any client should be able to. = For >> CT, at least, I thought this was not to be the case. >=20 > How do you authenticate that? The submission includes the whole DNSSEC chain to the root, similar to = what it does for CT-for-PKIX. > You cannot use the DS/DNSKEY for > authentication because then the CT audit log is useless to detect > compromises. The purpose is to detect inclusion of DS keys that are not valid to the = end host, not to detect "compromise". You have been following this = mailing list, yes? > And you cannot say "The CA industry" either, which is the answer for = the > CT-PKIX version. OK, so maybe you haven't been following the mailing list or reading the = draft. In the CT-for-PKIX proposal, individuals can submit their own = certificate. > If you make CT-DNSSEC go through the CA industry, it > will cost $10/year or more to get in the audit log. Thank you, Strawman McBogusArg! --Paul Hoffman= From carl@redhoundsoftware.com Sat Nov 17 17:32:48 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF5921F85FC for ; Sat, 17 Nov 2012 17:32:48 -0800 (PST) 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 YHmRK6EzYgbt for ; Sat, 17 Nov 2012 17:32:48 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4C63721F8585 for ; Sat, 17 Nov 2012 17:32:47 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so4422778vbb.31 for ; Sat, 17 Nov 2012 17:32:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=95/2asxgFQRwes6PV4tYNMDDWIx6Aqb5bzNQacEav+s=; b=bkG5advnE699d19BtVZJiHNG8UcX/F03JG1XvLrxho+ziZfEjvc5ZOWXbwOIpBzImk VZWin4wxVNJz3Bzlc4RNJ6NlzqfTSs6t2bPZVLdGxx0n1c3bG/PO8P2Q+YCa9jDiSYdi nMSxfd2pQcNVxpBH2mHd2PBmV5BPQJ2VypX5YDcFb46GRWMZub95VTVaGtip4k1+sEtu FDRoXyyEVuHxBdsOeWJlg3cvGLTv4+KFwsBjOy19pNE+sqI2vT/m+TsehqlIVlonp0W/ GkQbS4DhT039lJ7WOj7LAuNDFif1DWuNp1xqxAIVg1l8GCwvmsPc1E0yj4zPsF9MQsZL sezw== Received: by 10.52.29.138 with SMTP id k10mr12211393vdh.53.1353202366577; Sat, 17 Nov 2012 17:32:46 -0800 (PST) Received: from [192.168.2.6] (pool-173-79-110-220.washdc.fios.verizon.net. [173.79.110.220]) by mx.google.com with ESMTPS id y7sm3441370vdt.1.2012.11.17.17.32.43 (version=SSLv3 cipher=OTHER); Sat, 17 Nov 2012 17:32:45 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Sat, 17 Nov 2012 20:32:42 -0500 From: Carl Wallace To: Paul Hoffman , Paul Wouters Message-ID: Thread-Topic: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC In-Reply-To: <208851A7-84FB-4BF9-ACCE-18A931B146F6@vpnc.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQlT7Vug/2DYoDNldlqY9ved+Nl8AQIGJ8MqqvyuhYAjlkSjeJP7ZkK92ED2uCPm/+tearI0 Cc: therightkey@ietf.org Subject: Re: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 01:32:49 -0000 On 11/17/12 8:24 PM, "Paul Hoffman" wrote: >>And you cannot say "The CA industry" either, which is the answer for the >> CT-PKIX version. > >OK, so maybe you haven't been following the mailing list or reading the >draft. In the CT-for-PKIX proposal, individuals can submit their own >certificate. Under this approach, how does the log come to have certificates that a legitimate owner would like to be made aware of? I understand the utility of including the CT in the certificate and having an individual submit their certificate (or the CA on their behalf) but locking down a log to these sorts of inputs would seem to limit their usefulness for detecting rogue certs. From paul@nohats.ca Sat Nov 17 19:58:37 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BBB21F85F7 for ; Sat, 17 Nov 2012 19:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4E1aCH-+nA5W for ; Sat, 17 Nov 2012 19:58:36 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3783521F84EE for ; Sat, 17 Nov 2012 19:58:36 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id CE27582B75; Sat, 17 Nov 2012 22:57:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BD523804AA; Sat, 17 Nov 2012 22:57:46 -0500 (EST) Date: Sat, 17 Nov 2012 22:57:46 -0500 (EST) From: Paul Wouters To: Carl Wallace In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: therightkey@ietf.org Subject: Re: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 03:58:37 -0000 On Sat, 17 Nov 2012, Carl Wallace wrote: >> OK, so maybe you haven't been following the mailing list or reading the >> draft. In the CT-for-PKIX proposal, individuals can submit their own >> certificate. > > Under this approach, how does the log come to have certificates that a > legitimate owner would like to be made aware of? I understand the utility > of including the CT in the certificate and having an individual submit > their certificate (or the CA on their behalf) but locking down a log to > these sorts of inputs would seem to limit their usefulness for detecting > rogue certs. But allowing anyone to submit "new" certificates, allows hackers to do the same. How is this authenticated? For the TLS cert, the "out of band" was via DNS its the MX record. Which has in fact reduced the security of the CA vouching system. With DNSSEC, and compromise there, it means even less. >From my remote participation, I understood the CT audits were restricted, and that only CAs could submit entries for the audit log, which is why when this was mentioned I channeled via jabber about "security through money", and that I thought this was an invalid approach. (especially for CT-DNSSEC, as publishing DS records is free, unlike getting a "recognised" PKIX certificate) On the lists I now hear anyone can submit, which also raises issues. Perhaps there are very different thoughts for CT-PKIX-CA versus CT-PKIX-selfsigned that I'm not aware of. CT-PKIX addresses an issue where there are 600 roots and you can't trust all of them (although TLSA solves that too). I'm still unsure what CT-DNSSEC would solve, as just pulling history from DNS does not add anything, and I have no idea how to authenticate to the CT-DNSSEC audit log to start an alternative path of trust, especially if you are defendining against a rogue root or rogue .com key being used secretly to sign alternative records, or a compromised DNSSEC private key. Paul From carl@redhoundsoftware.com Sun Nov 18 04:56:28 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F59621F8490 for ; Sun, 18 Nov 2012 04:56:28 -0800 (PST) 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 qInUobVW5D1e for ; Sun, 18 Nov 2012 04:56:27 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3D37921F8456 for ; Sun, 18 Nov 2012 04:56:27 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so4637482vbb.31 for ; Sun, 18 Nov 2012 04:56:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=yZyM7ZabWPD1VIhp5V1gE8itYfX4wpM9UxFBYqU0Usw=; b=WA3aqlSQ96lN91TiKkK6t1tbwsKcuYclucUTgsuEXLBv53yiDV0G2O62RAUdZA2qnp hqCRFt5CRTwXMf9uLafXy1aIypCsUGiisLVQF+IxgpXAwZ1dQQbBOhNcJtqDy2J63ecJ meD4BE3q0o7sFnyXPd5P+FU+FbCGEGt7p7uGc6ekezGV5fZ3pRnzeMTA+3aaqV1DFaJ/ imwixzDGSMaJr7BjRXO+9jZSLfosCcjzISq1CE0MIal7Wif1lKokOCWeGoNHoF6DOEdy yKFyDkR3MbmdZ0MjWaTSlqwX0SkS2GtyxNSNOLTxMctcLZxTUkiBs27FhnZX5WIqaxZ+ 8gyw== Received: by 10.52.177.130 with SMTP id cq2mr13208102vdc.102.1353243386591; Sun, 18 Nov 2012 04:56:26 -0800 (PST) Received: from [192.168.2.6] (pool-173-79-110-220.washdc.fios.verizon.net. [173.79.110.220]) by mx.google.com with ESMTPS id in19sm3701193vec.1.2012.11.18.04.56.22 (version=SSLv3 cipher=OTHER); Sun, 18 Nov 2012 04:56:25 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Sun, 18 Nov 2012 07:56:17 -0500 From: Carl Wallace To: Paul Wouters Message-ID: Thread-Topic: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQmDAAX1CXEeg/kDAjr21NHs872OMuREs9y3BGP9S+rMs7qlw0N+Je3//v9vEh4dMEg5mNf6 Cc: therightkey@ietf.org Subject: Re: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 12:56:28 -0000 On 11/17/12 10:57 PM, "Paul Wouters" wrote: >But allowing anyone to submit "new" certificates, allows hackers to do >the same. How is this authenticated? For CT, by chaining to a given set of roots. From benl@google.com Mon Nov 19 02:25:25 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BA221F8557 for ; Mon, 19 Nov 2012 02:25:25 -0800 (PST) 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 P7zUXJJXjO+O for ; Mon, 19 Nov 2012 02:25:24 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 04E9021F84CA for ; Mon, 19 Nov 2012 02:25:17 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so1985977wgb.13 for ; Mon, 19 Nov 2012 02:25:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qCGlkKJuByCnGEOeCIBZ9i756r+PcoXhavAoNDlWYKk=; b=hOdrRDIkfCg0tk8/VZrblT2kf51t1rhRpQXusmiWkFQgfusEwpMVkPhd78OCoVFRea XmayAaF1d8aDx1/C7QH6AWXGv/7vGKshzsFhUK01Io/cmz23ryWDlTA928JgQ4BPX4tg sUiKQtlnDmU21eJHeNAhm9GolILGAHYr9MTPpNb517akVZaSPtEUq/DhgbSuQ425im0O 49GoP1wlGIlBj0VUbRdJf58nJYtbp1Sam1Q8TENaXCHfH/W8seG86XxCy26SsfZxqdVQ 5a6zo6sutXOm7uPah/A84wA7rsiRlRMWfdz+BVrjUZXVTTrYmRnT2vMIHKgjmjCSz3Cc AS7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=qCGlkKJuByCnGEOeCIBZ9i756r+PcoXhavAoNDlWYKk=; b=COj+VWXEUDeTWj+McOh8NbSgdoNP+6OyENN8m7vVuVPSk0nO2rt/W+nL8UFgX5at3T PWE4THCP3F7Om6kdSNvzWozvcmZ/S+7Ntkr8+gM/Z7MxiSSEMous72wiFpMnr0auXbFk M8KemJ1y1mBa/bzVHPb6MHUOD2+HT8az3eDtyUWfnbtT0UbfH3te9aDrf+JIT0p2o0VT 8UvYOozEkYBeftAecqkSytA8c8ihv0KA/Cdo4p2qeq8hBC35vKypSmwgSlfzHhaWqSxE fDhsXeT5l8Hm2pF6I2L+os5if43K3DKQLg+2tZwHpCyGdsJkrad/ETmST+NW/IprEszA /dug== MIME-Version: 1.0 Received: by 10.180.24.193 with SMTP id w1mr8113812wif.22.1353320716807; Mon, 19 Nov 2012 02:25:16 -0800 (PST) Received: by 10.194.51.100 with HTTP; Mon, 19 Nov 2012 02:25:16 -0800 (PST) In-Reply-To: References: Date: Mon, 19 Nov 2012 10:25:16 +0000 Message-ID: From: Ben Laurie To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnUvrSi/rJ5mscYTJJel0dWHVWIogg5o230nkEwlYi+alL8GOt4KLqlyQKlLXulM6yToqVQSdQlB/vK+zKvkReR6kKwiTBfEftCHm9rQay/cD1JywCn+HhWbvmSTx9ewIBQ+WQYMPATHuMqa/t8dbvV5aNv53QGCXwkypdr3ggXBCCLD2evYscLQNFw1uY0VfeyWDzY Cc: therightkey@ietf.org, Carl Wallace Subject: Re: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 10:25:26 -0000 On 18 November 2012 03:57, Paul Wouters wrote: > On Sat, 17 Nov 2012, Carl Wallace wrote: > >>> OK, so maybe you haven't been following the mailing list or reading the >>> draft. In the CT-for-PKIX proposal, individuals can submit their own >>> certificate. >> >> >> Under this approach, how does the log come to have certificates that a >> legitimate owner would like to be made aware of? I understand the utility >> of including the CT in the certificate and having an individual submit >> their certificate (or the CA on their behalf) but locking down a log to >> these sorts of inputs would seem to limit their usefulness for detecting >> rogue certs. > > > But allowing anyone to submit "new" certificates, allows hackers to do > the same. How is this authenticated? Your questions confuse me. Have you read the draft? Or any of the various informal descriptions? > For the TLS cert, the "out of band" was via DNS its the MX record. Which > has in fact reduced the security of the CA vouching system. With DNSSEC, > and compromise there, it means even less. > > From my remote participation, I understood the CT audits were > restricted, and that only CAs could submit entries for the audit log, > which is why when this was mentioned I channeled via jabber about > "security through money", and that I thought this was an invalid approach. > (especially for CT-DNSSEC, as publishing DS records is free, unlike > getting a "recognised" PKIX certificate) > > On the lists I now hear anyone can submit, which also raises issues. > Perhaps there are very different thoughts for CT-PKIX-CA versus > CT-PKIX-selfsigned that I'm not aware of. > > CT-PKIX addresses an issue where there are 600 roots and you can't > trust all of them (although TLSA solves that too). I'm still unsure > what CT-DNSSEC would solve, as just pulling history from DNS does not > add anything, and I have no idea how to authenticate to the CT-DNSSEC > audit log to start an alternative path of trust, especially if you are > defendining against a rogue root or rogue .com key being used secretly > to sign alternative records, or a compromised DNSSEC private key. > > Paul > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey From benl@google.com Mon Nov 19 02:30:25 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B4E21F8499 for ; Mon, 19 Nov 2012 02:30:25 -0800 (PST) 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 ronKGd1xG7tC for ; Mon, 19 Nov 2012 02:30:24 -0800 (PST) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 496F521F8488 for ; Mon, 19 Nov 2012 02:30:24 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id fm10so1005792wgb.1 for ; Mon, 19 Nov 2012 02:30:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4KgIZbVEjmr6i5xtSjl6+MjNx0ufu4L5dW6isKT7JZE=; b=JRa34V8MZJt2D0DM+/JaIkS8DoXoayFZEZ6uXy9/eQbK0AGUHLjm+WWsbEGoeKhKWk 7fNN/UsquK9xIrLyfWDUYnvYCYh/I9mUtA98labS5/DPtNMgMOP4E+Dnitc2V0cq+uj3 eyGw58/qCeLCCywV5/gPxLW4jizQXBVFzqhF1paIMSI/FoF2bZn3PY8EmVpEFeqS7spw 2WlrA26tYUdLxM9FHXF25BDNzJWlkdrmSQomXgUH/M5GPZaksIFPH1jIERrr5p1SFprP 8HIx7lzCb55L1h9Dik/Ni+jO2h8tP3ZtkGZRSIK58UsBpNWs4+j+QV3zNCoP63BCrWOs fo7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=4KgIZbVEjmr6i5xtSjl6+MjNx0ufu4L5dW6isKT7JZE=; b=WfJzD2l3/otyEQFMpGAd0sh0WF8IAonBVNacdRSi48Shh3QGT8wxjKBZfZAHjCc/Vs A/K+Gsvynn3s8Ru+W0NXuGlbbf2NxpWLR+/GkUbhWmZvcB5l8jDdRmApv9wT7RUq96LR PxKJxrGrXrZwU6h33Zb1ZJy888QmHZqvP91wPw865AufT+tPXuiJcD/mnIAJRq8FAYE9 y2EGCOkLhFGUsjJb2/hkdcH4RXZrIw0XSW0qyvmD6rwWiTh9q02dAzAGm7g5GHpXBnzN t/PfxmtAx6QEwbL2NdRgpsj7escVWZ2D2t/+PIVV2tYg4vHyoEGr3ctfjPOcBG0TTPt6 jhaQ== MIME-Version: 1.0 Received: by 10.216.193.133 with SMTP id k5mr578655wen.74.1353321023157; Mon, 19 Nov 2012 02:30:23 -0800 (PST) Received: by 10.194.51.100 with HTTP; Mon, 19 Nov 2012 02:30:23 -0800 (PST) In-Reply-To: References: <208851A7-84FB-4BF9-ACCE-18A931B146F6@vpnc.org> Date: Mon, 19 Nov 2012 10:30:23 +0000 Message-ID: From: Ben Laurie To: Carl Wallace Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmTNTXCW85QJYonrpV1GDtLrH3xrbSeBSFASQHEvkxf6n/cbWPpl57tUARdALN85s4/mm8WfDotajVz4cXfhxFH613IptMYykQrw8DTT4Y3MjvwOXQv+zqhirMBv8zxh0hQIjpv/Y193NK7vRcKAqfbJSgyL+n7Ph+MUUZ7fpjNCdXa7Q4/L+FCpZ8qDaDfWBoPxu2X Cc: therightkey@ietf.org, Paul Wouters , Paul Hoffman Subject: Re: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 10:30:25 -0000 On 18 November 2012 01:32, Carl Wallace wrote: > On 11/17/12 8:24 PM, "Paul Hoffman" wrote: > >>>And you cannot say "The CA industry" either, which is the answer for the >>> CT-PKIX version. >> >>OK, so maybe you haven't been following the mailing list or reading the >>draft. In the CT-for-PKIX proposal, individuals can submit their own >>certificate. > > Under this approach, how does the log come to have certificates that a > legitimate owner would like to be made aware of? I understand the utility > of including the CT in the certificate and having an individual submit > their certificate (or the CA on their behalf) but locking down a log to > these sorts of inputs would seem to limit their usefulness for detecting > rogue certs. The idea is that the log contains all certificates the browser might otherwise say are valid. If the cert would not be validated by the browser anyway, there's no real point it being in the log - and so, for pragmatic reasons (i.e. spam prevention), our current plan is to not allow such certificates to be logged. From carl@redhoundsoftware.com Mon Nov 19 04:08:20 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D88221F85EB for ; Mon, 19 Nov 2012 04:08:20 -0800 (PST) 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 WsqsyewH3k53 for ; Mon, 19 Nov 2012 04:08:19 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4010F21F85D3 for ; Mon, 19 Nov 2012 04:08:18 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so2747738vcb.31 for ; Mon, 19 Nov 2012 04:08:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=Y2D0IC2TrapBTNcMJheSnXcN68Tx2GxBC39dtbeFPjg=; b=Id1eyyD+QVF4A3Zz+GXPsvdoDpQm0l6iK00y8MZc4IOkubd//ayuSaTC8ptsj6gxlj iIWmj2vhIh4hMMpoFGbwZCEu0N0DuWFGCK2O5vxcWtYOPCd7rL3oQom6SW7DL+2fBgY9 rK5ZaUZnYrPtht/cfxZ6td/+umnTN4JfUin6rESKXcj9xxFbYC1yarzYyz9w3o7fTktp MTwGTRyLHu477kuKBCq8zpNxya5ZHppBdPq0hDOzOHCmvuxYRkJ5WX9cZQEgc7WVu/Nh n6ed649ggqcQpPeBS3wi/dxg8Op1oknjgkIf+0Xn97XhwkZ5xqBkznYhVljdgkS2LMIh Jvtw== Received: by 10.220.239.9 with SMTP id ku9mr18375714vcb.52.1353326898349; Mon, 19 Nov 2012 04:08:18 -0800 (PST) Received: from [192.168.2.3] (pool-173-79-110-220.washdc.fios.verizon.net. [173.79.110.220]) by mx.google.com with ESMTPS id vl8sm5076023veb.9.2012.11.19.04.08.12 (version=SSLv3 cipher=OTHER); Mon, 19 Nov 2012 04:08:17 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Mon, 19 Nov 2012 06:49:28 -0500 From: Carl Wallace To: Ben Laurie Message-ID: Thread-Topic: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQmUr09ZEgdW+6OXVnSpfFoOkIiyN/dN3sH/R/4gOPZk8/vmPOOeVDWTznF2y/ZApbKAtoAe Cc: therightkey@ietf.org, Paul Wouters , Paul Hoffman Subject: Re: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 12:08:20 -0000 On 11/19/12 5:30 AM, "Ben Laurie" wrote: >On 18 November 2012 01:32, Carl Wallace wrote: >> On 11/17/12 8:24 PM, "Paul Hoffman" wrote: >> >>>>And you cannot say "The CA industry" either, which is the answer for >>>>the >>>> CT-PKIX version. >>> >>>OK, so maybe you haven't been following the mailing list or reading the >>>draft. In the CT-for-PKIX proposal, individuals can submit their own >>>certificate. >> >> Under this approach, how does the log come to have certificates that a >> legitimate owner would like to be made aware of? I understand the >>utility >> of including the CT in the certificate and having an individual submit >> their certificate (or the CA on their behalf) but locking down a log to >> these sorts of inputs would seem to limit their usefulness for detecting >> rogue certs. > >The idea is that the log contains all certificates the browser might >otherwise say are valid. If the cert would not be validated by the >browser anyway, there's no real point it being in the log - and so, >for pragmatic reasons (i.e. spam prevention), our current plan is to >not allow such certificates to be logged. That is only true for browsers that hard fail on missing/broken CT extensions. I've not followed why hard failing on this is expected to work but not for other existing mechanisms. We still have 15+ year olds extensions that don't cause hard failures. Pushing the extension into the certificate and only accepting certs that have it just makes this part of the issuance machinery. In any case, I have a hard time seeing why you would reject certificates signed by a public CA (or any other CA that is covered by the log). CA operators and legitimate domain owners should be interested in these and the signature check ought to be good enough for spam prevention unless things are more broken than is commonly reported. From benl@google.com Mon Nov 19 05:08:24 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF3F21F85EB for ; Mon, 19 Nov 2012 05:08:24 -0800 (PST) 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 V90JXdEHSEUw for ; Mon, 19 Nov 2012 05:08:23 -0800 (PST) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 281A921F855E for ; Mon, 19 Nov 2012 05:08:22 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id fm10so1076204wgb.1 for ; Mon, 19 Nov 2012 05:08:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KWTcRu8o+/FL0D4h0EWhVIVvDLp4ECPEH+oWjV0gJGw=; b=NSQgqzSt/3bEra73l2klal3a1sfwnHi4KODUtBwuMRMHzJ3yxP5exvIW1R7jgIwlJ1 KXYQL+P39hHtG9LWqZ+WaCsEeaHRy96VTVptqiUonnPXBg+nUqo0MYzwqgdLKBw6KZ1v 9zEXToq3pk8XoGSmrfhMtFndirH6bO0bZAn7sHe7iwIrFeYKk+uippwIN8Qf6ul092Ot Sqh542xq/yc9iQmr247Gpj3yIihZOd6R51XJ7tnGvZX1cPpOMy7dfPIpnDsp1T8j+dk4 jAcsreR8QaawbB02jLIubtOtHUq0aZRTGgW8A4Yqat5kEjgNH4uQoWb7DEwRlLjUtWwi gSyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=KWTcRu8o+/FL0D4h0EWhVIVvDLp4ECPEH+oWjV0gJGw=; b=lsyoHA5DZ6VmRdGnPnzWlnMIc07/FDFl55Co8ylM3Q9BTwl6so1fcWQvd2VeyrqwoI 2YwMxgPWMumH18hZPVFBuIdgOXgbhIP4+KY3HXPTn4lFlLl1OViFp2Oz8UaYL/YL6ggv eaN+2fZKk8iwwLgD7im68xXTD7skcEojBAe9QGRot1tTblEwGLY8aczUPD/K1WVcpoyU COLjAZpmkVOg7zaFfOremzD2R+jZXHWtNpXiuFP6r96WCjjkoacTirS/+ANu2rGenj+C 9uRwH+a73H1jkvzerXIq30Dr5nCsUygVHtTLp11pq8YIwW8/LCxqtCzggSES38PrbM3g wE6g== MIME-Version: 1.0 Received: by 10.180.14.2 with SMTP id l2mr3022392wic.2.1353330502001; Mon, 19 Nov 2012 05:08:22 -0800 (PST) Received: by 10.194.51.100 with HTTP; Mon, 19 Nov 2012 05:08:21 -0800 (PST) In-Reply-To: References: Date: Mon, 19 Nov 2012 13:08:21 +0000 Message-ID: From: Ben Laurie To: Carl Wallace Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnHjZuNQm+v3If99a5DopE1DR5D5CFInG6ACbpKeYWrtsXDU8hD2Vs0F+SwamtB5bi/sAwiAIPyWZkBS/jm4rlbKx3HwF+BFrgRerRSCRTyXnZwWYtmRyiN1uktqUf3J1mCjpxPN9/4RO92RI3reZ2qxFdRgjmIr0gQL8MFcrNgri/mufpqPNsSESGUrNG9uVm/jYJr Cc: therightkey@ietf.org, Paul Wouters , Paul Hoffman Subject: Re: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 13:08:24 -0000 On 19 November 2012 11:49, Carl Wallace wrote: > On 11/19/12 5:30 AM, "Ben Laurie" wrote: > >>On 18 November 2012 01:32, Carl Wallace wrote: >>> On 11/17/12 8:24 PM, "Paul Hoffman" wrote: >>> >>>>>And you cannot say "The CA industry" either, which is the answer for >>>>>the >>>>> CT-PKIX version. >>>> >>>>OK, so maybe you haven't been following the mailing list or reading the >>>>draft. In the CT-for-PKIX proposal, individuals can submit their own >>>>certificate. >>> >>> Under this approach, how does the log come to have certificates that a >>> legitimate owner would like to be made aware of? I understand the >>>utility >>> of including the CT in the certificate and having an individual submit >>> their certificate (or the CA on their behalf) but locking down a log to >>> these sorts of inputs would seem to limit their usefulness for detecting >>> rogue certs. >> >>The idea is that the log contains all certificates the browser might >>otherwise say are valid. If the cert would not be validated by the >>browser anyway, there's no real point it being in the log - and so, >>for pragmatic reasons (i.e. spam prevention), our current plan is to >>not allow such certificates to be logged. > > That is only true for browsers that hard fail on missing/broken CT > extensions. What is only true? That there's no point it being in the log if the browser would reject it anyway? I don't understand that. > I've not followed why hard failing on this is expected to > work but not for other existing mechanisms. We still have 15+ year olds > extensions that don't cause hard failures. Pushing the extension into the > certificate and only accepting certs that have it just makes this part of > the issuance machinery. The extension does not have to be in the certificate, it can also be in the TLS handshake. > In any case, I have a hard time seeing why you would reject certificates > signed by a public CA (or any other CA that is covered by the log). CA > operators and legitimate domain owners should be interested in these and > the signature check ought to be good enough for spam prevention unless > things are more broken than is commonly reported. We would not reject them. Why do you think we would? From carl@redhoundsoftware.com Mon Nov 19 05:20:51 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFED21F8564 for ; Mon, 19 Nov 2012 05:20:51 -0800 (PST) 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 bvSy-XBjfEX7 for ; Mon, 19 Nov 2012 05:20:51 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E8D6921F8598 for ; Mon, 19 Nov 2012 05:20:50 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so5520935vbb.31 for ; Mon, 19 Nov 2012 05:20:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=dytKEPz4Az3VpR5TIK2VRzZrMLjaq1XIxHZwCG9bgLE=; b=XE3QHoLhN+8XwslO37Nd807fHILZO47VXCMMIaEaln3X6eZCTCEM0ASBj4+elg9TpQ hVvmxLezHvQgItfPzcJY9x4V9RxgI/0c5AXVy75ADoSr9oJ5s4JfR/gkrMpZpp+28ghD P9BXY6ovw/hwmxBbpR/vJmcDZ1JB9Y7sk7gRL6eB4I9ZX42XovEbpJFYcGkJNeTFpinB UDSuVVfvzrrIA6jbn2Ox1saoQ4HGIHYmGWKTimFWwK5yFZDgCaFkXBK8poo3uoUCHK3b 0c88VrYMaYMmiK505/awPG2wEL5edu0sVuLv680WMVT3el5NWgAh9f4iLtfph9sxVCE2 TTRw== Received: by 10.52.72.104 with SMTP id c8mr14639103vdv.20.1353331250412; Mon, 19 Nov 2012 05:20:50 -0800 (PST) Received: from [192.168.2.3] (pool-173-79-110-220.washdc.fios.verizon.net. [173.79.110.220]) by mx.google.com with ESMTPS id g5sm5162019vez.6.2012.11.19.05.20.46 (version=SSLv3 cipher=OTHER); Mon, 19 Nov 2012 05:20:49 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Mon, 19 Nov 2012 08:20:42 -0500 From: Carl Wallace To: Ben Laurie Message-ID: Thread-Topic: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQlsFqX8lhKW8UnUGHtO0veu/tnIzShjJfR+j1pJTIVx4+BesE4Z8YBqR0WYoNjxOjiBisff Cc: therightkey@ietf.org, Paul Wouters , Paul Hoffman Subject: Re: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 13:20:52 -0000 On 11/19/12 8:08 AM, "Ben Laurie" wrote: >> In any case, I have a hard time seeing why you would reject certificates >> signed by a public CA (or any other CA that is covered by the log). CA >> operators and legitimate domain owners should be interested in these and >> the signature check ought to be good enough for spam prevention unless >> things are more broken than is commonly reported. > >We would not reject them. Why do you think we would? A misunderstanding I hope. If you are saying that browsers/observers can/would submit certificates that chain through a CA covered by the log then I have no issue. If (as I had come to think) the log is fed during issuance, then I think a significant part of the potential value is lost. Part of the problem in tracking this right now is the TBD in section 3 of the draft. I'll refrain from further comment until that text is present, since that should clarify things. From benl@google.com Mon Nov 19 05:34:17 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C6821F85D3 for ; Mon, 19 Nov 2012 05:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.92 X-Spam-Level: X-Spam-Status: No, score=-102.92 tagged_above=-999 required=5 tests=[AWL=0.057, 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 vAa39KTlheEO for ; Mon, 19 Nov 2012 05:34:16 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 49A7B21F85E0 for ; Mon, 19 Nov 2012 05:34:16 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hm6so1323559wib.13 for ; Mon, 19 Nov 2012 05:34:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W3V3BwbyNo+O9eTRwKVlX7HBtPNc7GikNH9HDktQPZo=; b=IJ0futPC/E1sbtA8Ts8sRUdwY/MxY6Xho6WbpQ1usPYkUSqplxo1ST582GXEoR0eN9 Ugty8ycVKL74ZI23sMXnN2zdUGxpaJJkRYpPgp0uqk5L3Zy9wan4BYHASKyujKy4+NZR j4/jlG9IsU+jT6H3m6BE3E2VZ7u8PIRDEIJOmJHDdA+h9xNrfw8UpDHXlm8cCSUZjoSb t8qFeOitbzu5Mv6q3Xg0+WRMytAgguSTZABBjpHoQUocXSzjOwMUpey1O4qd5k/WfhdS TDYLG3cNWBM6L7Vyqb+1GqCsFziQC43w4qVCMgZ+ma4fpoJ7AsSfndTbvm/QlmctQTld AMkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=W3V3BwbyNo+O9eTRwKVlX7HBtPNc7GikNH9HDktQPZo=; b=eHd5WJY+CKUqd9ppUGULM9IR7MKrftXxPCNiDxxuAckQh3jOzPRs21xfpNzvyvVHDh Kr6gZ+qUN+D5HqYHmcTyjz1HV1ijNpWGiR/uG6lHcmM+wtzxbxIoCnUeqfe9ZRs0haOS ogbvkxUNidhQ2A+YL9vy6knDw2/QetpE1DUrMI+xq+S1fvVaYjryvqpLlq0O0JF3V9RD 5jWoXmrbjYb14074cetX1K8vu9+PGzKFXwcTanilDmNvng8E2Dk5EJN7UkP+795VIKYQ TwsqoXHhpHkaIbV72sAfad3u4k7GnPaYxm4Ta2bQRssv3aQyrzcxgRq6i8PAF9PfQz2X +UPA== MIME-Version: 1.0 Received: by 10.216.193.133 with SMTP id k5mr803191wen.74.1353332055272; Mon, 19 Nov 2012 05:34:15 -0800 (PST) Received: by 10.194.51.100 with HTTP; Mon, 19 Nov 2012 05:34:15 -0800 (PST) In-Reply-To: References: Date: Mon, 19 Nov 2012 13:34:15 +0000 Message-ID: From: Ben Laurie To: Carl Wallace Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlDagjzuPS2e32kMVdxgWE/f+TiR8Ryh5SRmBdkfdUqhQ6RKsM+RW6GzqC9Ta6yNNaknyP0aHo++syOYL+rkeav1C+MRc/N2Gtr+mLjgyS5u4YRQKrrhidDLC+7mwSDrhJf11k5WKEp45lbK/W/2wEqpfrcmQO9QB8sq7gDH+GqkXk6zHpDZj4P+nKc9lKIenVOubXq Cc: therightkey@ietf.org, Paul Wouters , Paul Hoffman Subject: Re: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 13:34:17 -0000 On 19 November 2012 13:20, Carl Wallace wrote: > On 11/19/12 8:08 AM, "Ben Laurie" wrote: >>> In any case, I have a hard time seeing why you would reject certificates >>> signed by a public CA (or any other CA that is covered by the log). CA >>> operators and legitimate domain owners should be interested in these and >>> the signature check ought to be good enough for spam prevention unless >>> things are more broken than is commonly reported. >> >>We would not reject them. Why do you think we would? > > A misunderstanding I hope. If you are saying that browsers/observers > can/would submit certificates that chain through a CA covered by the log > then I have no issue. If (as I had come to think) the log is fed during > issuance, then I think a significant part of the potential value is lost. Anyone can submit to the log. The log (at least our log!) will accept any certificate chained through a public CA. > Part of the problem in tracking this right now is the TBD in section 3 of > the draft. I'll refrain from further comment until that text is present, > since that should clarify things. I will at least outline what will be in the messages soon. From benl@google.com Tue Nov 20 04:33:25 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A07321F84F1 for ; Tue, 20 Nov 2012 04:33:25 -0800 (PST) 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 gjEes5YcOjbA for ; Tue, 20 Nov 2012 04:33:24 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8094121F8594 for ; Tue, 20 Nov 2012 04:33:24 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so2548557wgb.13 for ; Tue, 20 Nov 2012 04:33:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=rvLuLOCG1UkBZmJ7ijWEs53RhlyoRwpJMMRQKFTI0Wg=; b=db8G5gLhlhY0F3i6i6iJChxnKude3RT6KCbidjYWfS40cUQ0Z8gM5or8XBsszSbDSG wPjg7HO2Jiwht+cIQa2tApIDOmIrsUjh+VDAzYCjiN5uEe9v5YlN2eURFwNloKwCftx3 jCWQWkDR7iccU8UZkTiB6LWXHTNtMZ72+vTGkAjYxIFpbXBhTlLQLzoLmox6F8LkZY+2 ZYa1xgNDsw/CdjHY21Exw03gOXTqff65a6kDJ5flYsVbDttqpLTKn2dDPHyteXmvR1XL VJOzROUfmFhNDjw6DI6o50Ihfip4Ak7ayXFlOWCR4JaFE7RutO5lSozYc3lLcO2fuaKz fJfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=rvLuLOCG1UkBZmJ7ijWEs53RhlyoRwpJMMRQKFTI0Wg=; b=SpYjHPQkCH9cuL5snJitWYm8xYWs4weQkcG03VQj+7nzGDci4pOA+RczA4w/tZZXUO C9NRQ0+bD+BRFmezBQt+ted5wyqEjkbz18uDKkEAaZAbNT0UMAUnZ8+wSdOeM23dlDTG 1qeyPY85kITe69KxycrfMKQBsmdXQkYcEXxFUvhPDtcOp5uJFmWncNohxRzurXK8k1Wz cveX+k2Hp/u0usKu5u/tFjFei/D3px8tOgFQqfrhEyI+GFeG0tiz3ShZhCK6LGkUTBT1 oYBKhv+DjNcRcf1bK8cP8xw6OV7rC3hwkS53JoFiILUuVghhoFeyBV4LCM/OTLF+8vAQ isGw== MIME-Version: 1.0 Received: by 10.216.203.210 with SMTP id f60mr5727258weo.69.1353414803233; Tue, 20 Nov 2012 04:33:23 -0800 (PST) Received: by 10.194.51.100 with HTTP; Tue, 20 Nov 2012 04:33:23 -0800 (PST) Date: Tue, 20 Nov 2012 12:33:23 +0000 Message-ID: From: Ben Laurie To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmLB1D631ziwyYsiCygeF0H4HKkn1uB+15bJBs7hZtpsbLrLbM20YcCS3KelywLRiQPyqPVpwwANXa5KbTYVsuOpMTmO6JLtUWmwUkIJutXPwd8jykqRjN+5wgaqs7MJrnfeSRyqhO/6RH6RoSy3dAxhAMShOJAYPqrOxFNxL0/fkTcrtBvm31nngbAT3oxT3+wEVFC Subject: [therightkey] What next for CT? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 12:33:25 -0000 Dear Group, Following the recent BoF and discussion with Stephen Farrell, the plan is to try to publish an experimental RFC for CT and, all going well, follow up later with a WG. In the experimental RFC we will cover the operation of the log, the log protocol and TLS client verification of CT. We will be specifically targetting the use of CT with PKI for HTTPS, and not other applications such as DNSSEC, self-signed certs, device certs, other TLS secured protocols, etc. Not that we exclude the possibility of using transparency logs for such things, of course, they just will not be covered by this initial RFC. The RFC will be broadly similar the existing I-D but will flesh out the protocols for interacting with the log, as far as they are currently defined. It will add RSA signatures for logs that would prefer to use it. It will not cover details of the audit process (that is, how clients verify that the timestamps they see really are included in the public log) as we think that will evolve quite rapidly for some time to come. The approximate timeline is that we hope to go to IETF last call around the end of the year. I intend to put out at least one more version for comment before that, though. As always, all comments are welcome. Cheers, Ben. From hallam@gmail.com Tue Nov 20 05:03:33 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C3221F861F for ; Tue, 20 Nov 2012 05:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.159 X-Spam-Level: X-Spam-Status: No, score=-4.159 tagged_above=-999 required=5 tests=[AWL=-0.561, 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 hOB1bo57Dv1Z for ; Tue, 20 Nov 2012 05:03:33 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C9A7C21F861E for ; Tue, 20 Nov 2012 05:03:32 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id ef5so6406637obb.31 for ; Tue, 20 Nov 2012 05:03:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XV3VAbj5yqwq4mGzZWPoDAlLIGtYiQbUDkL23B8lZ/I=; b=IEnAEEAJUvFAbJwpr0p1I/D265A2XOcvX3N5EqjaIloqOmlmHFtAy2jbyShIbXknnq HCS1oEeSyx11YzEWAmE5BCcZ0I7EnH7+GfyEV3XQj8Hp8ViZDRsGQlnrJdDJYKs3B9KQ F52hliPMGnj/UWyNXYwq5AjK9kZ3lQY7CKnCKvX27bbNqdhVPoQWVtTySBAGsw2P4Tny bvazH3+e6uH3x+Abmw/Kmwar8r9ZlYqqOhzett8uThymZBAVFojFOpJYrGrtscW4g6Go qa89ch8GFZ878xxb5Xcf0EPI6xQ5R8FgD8TBYy/ZV8arw8VkDjS7j6p8ihWt9rPHJjOC ad/w== MIME-Version: 1.0 Received: by 10.182.113.5 with SMTP id iu5mr13285188obb.36.1353416612327; Tue, 20 Nov 2012 05:03:32 -0800 (PST) Received: by 10.76.27.103 with HTTP; Tue, 20 Nov 2012 05:03:32 -0800 (PST) In-Reply-To: References: Date: Tue, 20 Nov 2012 08:03:32 -0500 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=f46d0447f1886931ca04ceecdc25 Cc: therightkey@ietf.org Subject: Re: [therightkey] What next for CT? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 13:03:33 -0000 --f46d0447f1886931ca04ceecdc25 Content-Type: text/plain; charset=ISO-8859-1 I think there should be two separate drafts. 1) Cover the technical spec describing how the notary log system works, the data formats etc. 2) Cover the use of the scheme in the context of PKIX. (1) is then reusable to other applications. Phill On Tue, Nov 20, 2012 at 7:33 AM, Ben Laurie wrote: > Dear Group, > > Following the recent BoF and discussion with Stephen Farrell, the plan > is to try to publish an experimental RFC for CT and, all going well, > follow up later with a WG. > > In the experimental RFC we will cover the operation of the log, the > log protocol and TLS client verification of CT. We will be > specifically targetting the use of CT with PKI for HTTPS, and not > other applications such as DNSSEC, self-signed certs, device certs, > other TLS secured protocols, etc. Not that we exclude the possibility > of using transparency logs for such things, of course, they just will > not be covered by this initial RFC. > > The RFC will be broadly similar the existing I-D but will flesh out > the protocols for interacting with the log, as far as they are > currently defined. It will add RSA signatures for logs that would > prefer to use it. > > It will not cover details of the audit process (that is, how clients > verify that the timestamps they see really are included in the public > log) as we think that will evolve quite rapidly for some time to come. > > The approximate timeline is that we hope to go to IETF last call > around the end of the year. > > I intend to put out at least one more version for comment before that, > though. > > As always, all comments are welcome. > > Cheers, > > Ben. > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > -- Website: http://hallambaker.com/ --f46d0447f1886931ca04ceecdc25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think there should be two separate drafts.=A0

1) Cover= the technical spec describing how the notary log system works, the data fo= rmats etc.
2) Cover the use of the scheme in the context of PKIX.=

(1) is then reusable to other applications.=A0

Phill

On Tue, Nov= 20, 2012 at 7:33 AM, Ben Laurie <benl@google.com> wrote:
Dear Group,

Following the recent BoF and discussion with Stephen Farrell, the plan
is to try to publish an experimental RFC for CT and, all going well,
follow up later with a WG.

In the experimental RFC we will cover the operation of the log, the
log protocol and TLS client verification of CT. We will be
specifically targetting the use of CT with PKI for HTTPS, and not
other applications such as DNSSEC, self-signed certs, device certs,
other TLS secured protocols, etc. Not that we exclude the possibility
of using transparency logs for such things, of course, they just will
not be covered by this initial RFC.

The RFC will be broadly similar the existing I-D but will flesh out
the protocols for interacting with the log, as far as they are
currently defined. It will add RSA signatures for logs that would
prefer to use it.

It will not cover details of the audit process (that is, how clients
verify that the timestamps they see really are included in the public
log) as we think that will evolve quite rapidly for some time to come.

The approximate timeline is that we hope to go to IETF last call
around the end of the year.

I intend to put out at least one more version for comment before that,
though.

As always, all comments are welcome.

Cheers,

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



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

--f46d0447f1886931ca04ceecdc25-- From stephen.farrell@cs.tcd.ie Tue Nov 20 05:07:37 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0E221F862C for ; Tue, 20 Nov 2012 05:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQe-wnljiFGh for ; Tue, 20 Nov 2012 05:07:36 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9692121F861F for ; Tue, 20 Nov 2012 05:07:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8ABFCBE25; Tue, 20 Nov 2012 13:07:08 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqPNpenfsFsq; Tue, 20 Nov 2012 13:07:06 +0000 (GMT) Received: from [IPv6:2001:770:10:203:1862:6345:cb62:ca56] (unknown [IPv6:2001:770:10:203:1862:6345:cb62:ca56]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4ECCDBE36; Tue, 20 Nov 2012 13:07:06 +0000 (GMT) Message-ID: <50AB807B.5010407@cs.tcd.ie> Date: Tue, 20 Nov 2012 13:07:07 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org, Ben Laurie Subject: Re: [therightkey] What next for CT? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 13:07:37 -0000 Hi Phill, Not sure what Ben thinks of that but I'd rather just AD sponsor one draft for now. A split like that would definitely make sense for the standards-track work that's envisaged to follow though. Do you think that's really a must-have at this stage? I guess I don't, as of now. Cheers, S. On 11/20/2012 01:03 PM, Phillip Hallam-Baker wrote: > I think there should be two separate drafts. > > 1) Cover the technical spec describing how the notary log system works, the > data formats etc. > 2) Cover the use of the scheme in the context of PKIX. > > (1) is then reusable to other applications. > > Phill > > On Tue, Nov 20, 2012 at 7:33 AM, Ben Laurie wrote: > >> Dear Group, >> >> Following the recent BoF and discussion with Stephen Farrell, the plan >> is to try to publish an experimental RFC for CT and, all going well, >> follow up later with a WG. >> >> In the experimental RFC we will cover the operation of the log, the >> log protocol and TLS client verification of CT. We will be >> specifically targetting the use of CT with PKI for HTTPS, and not >> other applications such as DNSSEC, self-signed certs, device certs, >> other TLS secured protocols, etc. Not that we exclude the possibility >> of using transparency logs for such things, of course, they just will >> not be covered by this initial RFC. >> >> The RFC will be broadly similar the existing I-D but will flesh out >> the protocols for interacting with the log, as far as they are >> currently defined. It will add RSA signatures for logs that would >> prefer to use it. >> >> It will not cover details of the audit process (that is, how clients >> verify that the timestamps they see really are included in the public >> log) as we think that will evolve quite rapidly for some time to come. >> >> The approximate timeline is that we hope to go to IETF last call >> around the end of the year. >> >> I intend to put out at least one more version for comment before that, >> though. >> >> As always, all comments are welcome. >> >> Cheers, >> >> Ben. >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey >> > > > > > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > From benl@google.com Tue Nov 20 05:14:31 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDA921F8595 for ; Tue, 20 Nov 2012 05:14:31 -0800 (PST) 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 hLq0yBCcZzi8 for ; Tue, 20 Nov 2012 05:14:30 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 64DFA21F8589 for ; Tue, 20 Nov 2012 05:14:30 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so2562836wgb.13 for ; Tue, 20 Nov 2012 05:14:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hWBXxGcSHdIxhXQGq7FOzG8TOaA8kym+roBzQ8AvlbE=; b=A9QQLyT0WVlQdrKt2g/9UHN+xXuyObp/W1eE926PjC/uWIqngyRgnOjJCVjnpb64rK dIOLSL8aZ8u9yv2dghaEJgE7vQ3Hqj0VnMUWPUDe8Gxkclz6q4vzwaWsd23KCK2GM3/s azgth6ZC0OR+z5EDz80BVz7TsPhhpcYR7xY/XqdvsYgM+SMyuLrJomaERiHt/S0JE/xR UaKH0fvTL3kpl99frcCTj9qwK4uZRIRoxKb7TwDDZ+qiokIfOtj1Ud9iiGMBzy9HIZZd ynt0e/7iEBjOuVxPQJUx7YdsYmGxoVX09iABfRkfP9jml4OE6RJ8TxNBptbmA8LQQHlN 4NiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=hWBXxGcSHdIxhXQGq7FOzG8TOaA8kym+roBzQ8AvlbE=; b=K1gF0xNA3YJm0VjJ5WN9iLZG58+1jWMStaPWMNdRAWZlqDrlkW4gk3EUAQgaWV1hSA rQzeOuyY7CfXW9q67Ft5w0LGBayRqhEmy4PCFsHyCv0ntoVJFpoftTGF5edz06yjf+Dq 0zayoTduZ0KoyC/T7lhgNO8X/rumUzUZvUYsjJEfVAOF0G7KlXrK989Xv8RbpwaN1FN4 Voj1108jRCDTiqpleMhPXCBzYfGPE14udw8pS8FpocgJ4Lj6hdPzbmj79/wvG+VS7rHl cmsvVaWstVaxcoALu79J0PG6BR+hquMinVjXYdtomCqIi8hfEY9Af00wGiQBEZjIDS4p RH1Q== MIME-Version: 1.0 Received: by 10.216.203.210 with SMTP id f60mr5779158weo.69.1353417269163; Tue, 20 Nov 2012 05:14:29 -0800 (PST) Received: by 10.194.51.100 with HTTP; Tue, 20 Nov 2012 05:14:29 -0800 (PST) In-Reply-To: <50AB807B.5010407@cs.tcd.ie> References: <50AB807B.5010407@cs.tcd.ie> Date: Tue, 20 Nov 2012 13:14:29 +0000 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlQ9EcDWQSAwkaj9liaZA1FZVfbPakH5PifimqFH0CGP0524yyssOP/jTXE/hUY18gwG4E+hVx9G79dbYZ1uCT1hdJiabO+wTxaQdjMDCEn4jia3+tLpIHWmIPbur2bjNlQG07zqhG1cwh6fL4+WGp89Nc+Cwi1mlu0mLWqCkdpxp6w82uJ4wh9gERecjhYHEZan453 Cc: therightkey@ietf.org, Phillip Hallam-Baker Subject: Re: [therightkey] What next for CT? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 13:14:31 -0000 On 20 November 2012 13:07, Stephen Farrell wrote: > > Hi Phill, > > Not sure what Ben thinks of that but I'd rather > just AD sponsor one draft for now. A split like > that would definitely make sense for the > standards-track work that's envisaged to follow > though. Do you think that's really a must-have > at this stage? I guess I don't, as of now. My view is that teasing the two parts apart is hard and so I agree it would be good for standards track, but don't want to do it for experimental. > > Cheers, > S. > > On 11/20/2012 01:03 PM, Phillip Hallam-Baker wrote: >> I think there should be two separate drafts. >> >> 1) Cover the technical spec describing how the notary log system works, the >> data formats etc. >> 2) Cover the use of the scheme in the context of PKIX. >> >> (1) is then reusable to other applications. >> >> Phill >> >> On Tue, Nov 20, 2012 at 7:33 AM, Ben Laurie wrote: >> >>> Dear Group, >>> >>> Following the recent BoF and discussion with Stephen Farrell, the plan >>> is to try to publish an experimental RFC for CT and, all going well, >>> follow up later with a WG. >>> >>> In the experimental RFC we will cover the operation of the log, the >>> log protocol and TLS client verification of CT. We will be >>> specifically targetting the use of CT with PKI for HTTPS, and not >>> other applications such as DNSSEC, self-signed certs, device certs, >>> other TLS secured protocols, etc. Not that we exclude the possibility >>> of using transparency logs for such things, of course, they just will >>> not be covered by this initial RFC. >>> >>> The RFC will be broadly similar the existing I-D but will flesh out >>> the protocols for interacting with the log, as far as they are >>> currently defined. It will add RSA signatures for logs that would >>> prefer to use it. >>> >>> It will not cover details of the audit process (that is, how clients >>> verify that the timestamps they see really are included in the public >>> log) as we think that will evolve quite rapidly for some time to come. >>> >>> The approximate timeline is that we hope to go to IETF last call >>> around the end of the year. >>> >>> I intend to put out at least one more version for comment before that, >>> though. >>> >>> As always, all comments are welcome. >>> >>> Cheers, >>> >>> Ben. >>> _______________________________________________ >>> therightkey mailing list >>> therightkey@ietf.org >>> https://www.ietf.org/mailman/listinfo/therightkey >>> >> >> >> >> >> >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey >> From hallam@gmail.com Tue Nov 20 05:17:24 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AE721F8596 for ; Tue, 20 Nov 2012 05:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.143 X-Spam-Level: X-Spam-Status: No, score=-4.143 tagged_above=-999 required=5 tests=[AWL=-0.545, 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 eTWuO0c63Q7Q for ; Tue, 20 Nov 2012 05:17:24 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4A921F84B6 for ; Tue, 20 Nov 2012 05:17:24 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id ef5so6420910obb.31 for ; Tue, 20 Nov 2012 05:17:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vwsZcYXCA3ABp4ch8WtJwgNzx7oQKGnj3vk3Xop1Mok=; b=sUlVbuTk32+H7LyFE5nlE9dLqks8/3y8w9QqLaIWWtHgxfaVD8IEu2mqHLE8rU9Ha7 zYo0miHp9kV9LcqKj9p8kb2ws0ZBHM2DPxnSSZeINOBxJBFaBcOfQirZDLmzb9Ag4d2N ZzQN29DH8ei0KicAyFvuhq29Z+Z34Tvwxg/izktdCbhrPnW/KBBavWinKbYTFZqYIuAG /70mkDgcAVTj5SwG+oss6qTO0Rvm2G5LUFh9sn+LlnRNgPX3fsRGxzkYgBXgQlhd7OUg LU4u4hld0q2npppdU/OzfPZrLLbGp2N/mR67lxSHV1gDIpMSkqxTOwrCqlntppF+4YMg 4mrg== MIME-Version: 1.0 Received: by 10.60.10.133 with SMTP id i5mr2050353oeb.24.1353417443688; Tue, 20 Nov 2012 05:17:23 -0800 (PST) Received: by 10.76.27.103 with HTTP; Tue, 20 Nov 2012 05:17:23 -0800 (PST) In-Reply-To: References: <50AB807B.5010407@cs.tcd.ie> Date: Tue, 20 Nov 2012 08:17:23 -0500 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=e89a8fb1f418f6c19504ceed0d93 Cc: therightkey@ietf.org, Stephen Farrell Subject: Re: [therightkey] What next for CT? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 13:17:25 -0000 --e89a8fb1f418f6c19504ceed0d93 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 20, 2012 at 8:14 AM, Ben Laurie wrote: > On 20 November 2012 13:07, Stephen Farrell > wrote: > > > > Hi Phill, > > > > Not sure what Ben thinks of that but I'd rather > > just AD sponsor one draft for now. A split like > > that would definitely make sense for the > > standards-track work that's envisaged to follow > > though. Do you think that's really a must-have > > at this stage? I guess I don't, as of now. > > My view is that teasing the two parts apart is hard and so I agree it > would be good for standards track, but don't want to do it for > experimental. My objective was to get the two parts teased apart rather than the presentation as separate documents. I think the exercise would improve the clarity of the spec. -- Website: http://hallambaker.com/ --e89a8fb1f418f6c19504ceed0d93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 20, 2012 at 8:14 AM, Ben Laurie <benl@google.com> wrote:
On 20 November 2012 13:07, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:=
>
> Hi Phill,
>
> Not sure what Ben thinks of that but I'd rather
> just AD sponsor one draft for now. A split like
> that would definitely make sense for the
> standards-track work that's envisaged to follow
> though. Do you think that's really a must-have
> at this stage? I guess I don't, as of now.

My view is that teasing the two parts apart is hard and so I agree it=
would be good for standards track, but don't want to do it for
experimental.

My objective was to get the t= wo parts teased apart rather than the presentation as separate documents.

I think the exercise would improve the clarity of t= he spec.
=A0
--
Website: htt= p://hallambaker.com/

--e89a8fb1f418f6c19504ceed0d93-- From benl@google.com Tue Nov 20 07:09:28 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC9321F874A for ; Tue, 20 Nov 2012 07:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.922 X-Spam-Level: X-Spam-Status: No, score=-102.922 tagged_above=-999 required=5 tests=[AWL=0.055, 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 T-cNcNp7IjBD for ; Tue, 20 Nov 2012 07:09:27 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6F90421F874F for ; Tue, 20 Nov 2012 07:09:26 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id hm9so845428wib.13 for ; Tue, 20 Nov 2012 07:09:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DCDTz8Kupqgahp7hjlA6Dee31eyxDS/h1UEtiwpPQyg=; b=QP3In5dXxy9++4MXKde/nwbKYEN+Hz8gJt59ZYHmAcz43av0unnScqScQ/q4doz4Hq 8FNUfu8JzgoVto4U6tjS1aFkKZh2PfdzTMTpDedHg40pPY+I9f97q0YGosCAVd/Wnbcj ZDVCVD5qcNqI3PgMes+CcdDW7bkXmCDp70qilXBa9p7nESB02mIYQsPwuObg/o9K9lTc YOLGlvDT6QM9WAiJwzYUHeC3jye7qr4eR246Uc1pPtPgVUGpdje5VJOK1kM3ZuoFqX0l jYb5dXkxaBfBzydIA7y5AKm+Nbhi46B2WE/ngMumkCwNXZrrJiXngVIMQuDVygfNgqzu vuJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=DCDTz8Kupqgahp7hjlA6Dee31eyxDS/h1UEtiwpPQyg=; b=c57va7zX91L1CMKyFwoi/HDTMUTS3/s0DK370LKl9zWk5WSVdyOUJQf7l9oSjJz43P l9mA478xwgPdUud9hebzYiRoVTCbYFuALZzogT8V0GLmZ4V0srJNApoOKmDpmYZdtMpN 1NPagqLg9d0I4vvXYDx8skM6jNucF88OtIxJ6p4BwJ4HIl44ckBiLQyJJ4I6x0gtOPbB ImvptmFb955edSo+q9r4svpae+7KdeJb2iECWpEO/zdiBYDfFVLKsV7YJaSAFRKS8w3P eD/Uk+LiGUWO43BxfoRQW16w1PDDm2JBtp1gM7VbVGgZYSfIeWV9sCTYKuGGLyVjWVfW 2ang== MIME-Version: 1.0 Received: by 10.180.87.201 with SMTP id ba9mr15014709wib.1.1353424164514; Tue, 20 Nov 2012 07:09:24 -0800 (PST) Received: by 10.194.51.100 with HTTP; Tue, 20 Nov 2012 07:09:24 -0800 (PST) In-Reply-To: References: <50AB807B.5010407@cs.tcd.ie> Date: Tue, 20 Nov 2012 15:09:24 +0000 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl8l0ginm3hsjHuqwwH1P4YFNEDGoiFzzNCyb2TEiaW0loqd+NkFSDToUeUkRNJUiHAkwJU+yEZ5/WF0vyfIreM7co/6Ml3Ay2uIy+AeVZkK16KPuFlV9WMTkF+r8lF+1UZqmTzcvbPr1KIZoSjxMdjyeIbsJdFYhf85M/74y/4qXYBtaA25PIBznnMSnFh+D18xcKW Cc: therightkey@ietf.org, Stephen Farrell Subject: Re: [therightkey] What next for CT? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 15:09:28 -0000 On 20 November 2012 13:17, Phillip Hallam-Baker wrote: > On Tue, Nov 20, 2012 at 8:14 AM, Ben Laurie wrote: >> >> On 20 November 2012 13:07, Stephen Farrell >> wrote: >> > >> > Hi Phill, >> > >> > Not sure what Ben thinks of that but I'd rather >> > just AD sponsor one draft for now. A split like >> > that would definitely make sense for the >> > standards-track work that's envisaged to follow >> > though. Do you think that's really a must-have >> > at this stage? I guess I don't, as of now. >> >> My view is that teasing the two parts apart is hard and so I agree it >> would be good for standards track, but don't want to do it for >> experimental. > > > My objective was to get the two parts teased apart rather than the > presentation as separate documents. > > I think the exercise would improve the clarity of the spec. Its still hard :-) I'll see what I can do, though. From tom@ritter.vg Tue Nov 20 15:47:32 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08BB21F8815 for ; Tue, 20 Nov 2012 15:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 ph8uzax3ycJh for ; Tue, 20 Nov 2012 15:47:31 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7962621F8819 for ; Tue, 20 Nov 2012 15:47:31 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so4867943vcb.31 for ; Tue, 20 Nov 2012 15:47:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jeeObW19s0Ph/pK0/32730FAAE49dEUcmSWVs52IYWA=; b=wpPyb3Q2flKGbP1hmw8pkUGmHt9CvjMM1/8HARDV/nxs282sphx2r5p515BGlMmx1a g3wib2Mg+aa9accgbAEFHXCCXUQW7/9kOqV96z5ewLCxRQaYbnGCfbWS+6I0fSx3iOp8 FS4uizJeBrMDeFgKjljXREHEV4x88g7fW57sU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=jeeObW19s0Ph/pK0/32730FAAE49dEUcmSWVs52IYWA=; b=CmEsiPXjSxyn03wbHH2P6yP0UM5zZYaiLogHuF+bMY3q4vGRcdlcUjz9wWMisI9Si+ HJNGjyagAnxsnuVYQeklTIgZlJS7NJDbMo6tt7Na3CuLzAUGTfXz82I/iyjaa5ooYDgF M7CHpiq9ua0sZ4fN3jPzHhqThuRyoVC3Eb3hHtSXmy94vbCIebWDIZ4H4r6VBJ/1Y1Fg wzLBjZKSRP/elPEiB0PulQSZF5Ibx/oE17YQDq1s5ftjQNgWeiGZD2hw2ASdBajSq2yj h5d4pl3hr+tLhqaKmmgBTL75GhLRyC/lgjB+9KRqHe+KB2h6XB59BB90PEYftxpXLPwo C/rg== Received: by 10.52.72.42 with SMTP id a10mr22920341vdv.48.1353455250631; Tue, 20 Nov 2012 15:47:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.227.65 with HTTP; Tue, 20 Nov 2012 15:47:09 -0800 (PST) In-Reply-To: References: From: Tom Ritter Date: Tue, 20 Nov 2012 18:47:09 -0500 Message-ID: To: Paul Wouters Content-Type: multipart/alternative; boundary=20cf307f362c6eec8704cef5db20 X-Gm-Message-State: ALoCoQmsdKjC2Yp3d0ot86cRC9LtWZ1Hp0R8g28WuEtP6JzUVWfVRcGRJZTUPimlry7QSI9sA24b Cc: therightkey , Carl Wallace Subject: Re: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 23:47:33 -0000 --20cf307f362c6eec8704cef5db20 Content-Type: text/plain; charset=ISO-8859-1 On 17 November 2012 22:57, Paul Wouters wrote: > CT-PKIX addresses an issue where there are 600 roots and you can't > trust all of them (although TLSA solves that too). I'm still unsure > what CT-DNSSEC would solve, as just pulling history from DNS does not > add anything, and I have no idea how to authenticate to the CT-DNSSEC > audit log to start an alternative path of trust, especially if you are > defendining against a rogue root or rogue .com key being used secretly > to sign alternative records, or a compromised DNSSEC private key. I'd like to state what I think CT-DNSSEC would solve, and how it would work. I'll use .com as my example root, and google as my example CT notary. Hopefully I don't screw up the DNSSEC part or the CT part too much... I submit an entry for the DS record for example.com to the .com operator. The operator in turn contacts google but preferably multiple notaries and says "This is the DS record for example.com" and google puts it into their log, and gives back a signed statement as proof of such. It then enters this proof in some new type of record, we'll call it DSProof. After the .com operator has the proof, it updates the DS and DSProof records. Now a user wants to connect securely to example.com. They query the A record for example.com, and get back the response plus the RRSIG, the signature for the A record. However, the client can't check the signature, it doesn't have the key. I'm unsure if in implementations this query happens in parallel, in the same query or what - but it reaches out and gets the ZSK for example.com, the KSK for example.com, and the DS record for example.com - so it has the complete chain of keys from example.com -> .com -> (root). At this point it can verify the entire chain of signatures. But when it retrieves the DS record for example.com it also retrieves the DSProof. The client can verify that the DSProof is valid and comes from the google notary (I'm not 100% sure if this is a signature of a merkle path ending in a signature but it functions like a signature.) The client ensures that the DSProof is valid and from the google notary, meaning it has an entry in the append-only merkel tree, which we can verify (and there are verifiers for it.) That gets into the CT side of things. At this point, everything under example.com - whether it's the A record or the TLSA record - is signed as normal, and the signatures under example.comchain to a key that has been entered into a public log. If a TLD wants to fraudulently sign a response for the A or TLSA record for a site, they will have to also enter the key into the notary. The operator of example.com will be able to see there is a DS record they did not authorize in the notary, and can start investigations or other mitigation processes. (Ideally the presence of the notaries will be the deterrent against the attack.) I think CT-DNSSEC is important. We've seen domain seizures before. The new gTLD program will open the internet to vast numbers of root operators, and not all of them will be competent or lack malice. Root keys will get stolen. Maybe it'll be .bugatti and not .bank but it will still happen. We should build this in now, while we can flesh it out pre-widespread deployment of DNSSEC. -tom --20cf307f362c6eec8704cef5db20 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 17 November 2012 22:57, Paul Wouters <paul@nohats.ca> wrote:=
CT-PKIX addresses an issue where there are 600 roots and you can't=
trust all of them (although TLSA solves that too). I'm still unsure
what CT-DNSSEC would solve, as just pulling history from DNS does not
add anything, and I have no idea how to authenticate to the CT-DNSSEC
audit log to start an alternative path of trust, especially if you are
defendining against a rogue root or rogue .com key being used secretly
to sign alternative records, or a compromised DNSSEC private key.

I'd like to state what I think CT-DNSSEC would s= olve, and how it would work. =A0I'll use .com as my example root, and g= oogle as my example CT notary. =A0Hopefully I don't screw up the DNSSEC= part or the CT part too much...

I submit an entry for the DS record for example.com to the .com operator. =A0= The operator in turn contacts google but=A0preferably=A0multiple notaries a= nd says "This is the DS record for example.com" and google puts it into their log, and = gives back a signed statement as proof of such. =A0It then enters this proo= f in some new type of record, we'll call it DSProof. =A0After the .com = operator has the proof, it updates the DS and DSProof records.

Now a user wants to connect securely to example.com. =A0They query the A record for example.com, and get back the response plus the RRS= IG, the signature for the A record. =A0However, the client can't check = the signature, it doesn't have the key. =A0I'm unsure if in impleme= ntations this query happens in=A0parallel, in the same query or what - but = it reaches out and gets the ZSK for example.= com, the KSK for example.com, and th= e DS record for example.com - so it has = the complete chain of keys from example.com<= /a> -> .com -> (root). =A0At this point it can verify the entire chai= n of signatures. =A0But when it retrieves the DS record for example.com it also retrieves the DSProof. =A0

The client can verify that the DSProof is valid and com= es from the google notary (I'm not 100% sure if this is a signature of = a merkle path ending in a signature but it functions like a signature.) =A0= The client ensures that the DSProof is valid and from the google notary, me= aning it has an entry in the=A0append-only merkel tree, which we can verify= (and there are=A0verifiers=A0for it.) =A0That gets into the CT side of thi= ngs.

At this point, everything under example.com - whether it's the A record or the TLSA record = - is signed as normal, and the signatures under example.com chain to a key that has been entered into a public log.= =A0If a TLD wants to=A0fraudulently=A0sign a response for the A or TLSA re= cord for a site, they will have to also enter the key into the notary. =A0T= he operator of example.com will be able = to see there is a DS record they did not authorize in the notary, and can s= tart investigations or other mitigation processes. =A0(Ideally the presence= of the notaries will be the deterrent against the attack.)

I think CT-DNSSEC is important. =A0We've seen domai= n seizures before. The new gTLD program will open the internet to vast numb= ers of root operators, and not all of them will be=A0competent or lack mali= ce. =A0Root keys will get stolen. =A0Maybe it'll be .bugatti and not .b= ank but it will still happen. =A0We should build this in now, while we can = flesh it out pre-widespread deployment of DNSSEC.

-tom
--20cf307f362c6eec8704cef5db20-- From benl@google.com Wed Nov 21 02:52:26 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1276021F85EA for ; Wed, 21 Nov 2012 02:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.925 X-Spam-Level: X-Spam-Status: No, score=-102.925 tagged_above=-999 required=5 tests=[AWL=0.052, 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 pabH0rLUq9L6 for ; Wed, 21 Nov 2012 02:52:15 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id A613F21F85F4 for ; Wed, 21 Nov 2012 02:52:14 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hm6so1472535wib.13 for ; Wed, 21 Nov 2012 02:52:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5qajsulyEqw7SDQ6B5wkkq6aPp5chU9PQqVL0Lg8UQE=; b=V2QYsf60b3Gg/eIELE0F9J1puiOvNi1AURjrqqaYbCwf07jG2VMtcRj7T4lSLyBZ9P DU3m8Sb4fBC1wYXAAnsye6JqrGDUnxDLoR5rCwGpWFa5W8hA0+E+dfHh2Ec3ClEKzdGX STd9iN1rl8UbYsylz8D5JN9W8csbDAXj8cC0qnAXhmaKP0QlbBwPfIpMj5rPmPl+Tpwe YRFM54E7uRlCD30ZH7mNMVeyqajwS01xkQXu5O4Orm3PEUJtqpOMlSLi3Pc8zfVwOftQ uz8RtRxnwO7eciH/acxFKhFrwacElNY24h7ckYR5Aw6yGMtSZeKnc5K4kgCdLN0Am0Y3 FP5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=5qajsulyEqw7SDQ6B5wkkq6aPp5chU9PQqVL0Lg8UQE=; b=VwejUnPDzeqEpscuyGoHwgQkoVslpwbJe/JvV9lUZR28upVgVwlHyXkbAde2vUc5mo Gj81ORBLz0ZsoJOMuQC0BwA3o63KxKmbf1fzi4ebM6p20cjmm4YwTlMavOIL/bPdRNvh 7oPx+kM84OSmnkFUnTELTNxmG5++mVEuLabfJSb+SbgssPY7xldPeRWri6UbJjdLIrNr soim9Wst4b6RRyORN+i/FZ3vUr8/rBdg2uklKt3dJCzzPyqyBoI/xoVztXPsdVdSVOjs TgIZ6zFddKIfL0Cygvv5KidEYHAAjw76ggJElzwkNEVqn5UmBRgGuYyFs7lijPFgrgaj yONQ== MIME-Version: 1.0 Received: by 10.180.89.234 with SMTP id br10mr19000495wib.2.1353495133439; Wed, 21 Nov 2012 02:52:13 -0800 (PST) Received: by 10.194.51.100 with HTTP; Wed, 21 Nov 2012 02:52:13 -0800 (PST) In-Reply-To: References: Date: Wed, 21 Nov 2012 10:52:13 +0000 Message-ID: From: Ben Laurie To: Tom Ritter Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkRXAwMK35y6hiMFieKWjzAG0kuUsfXcX4riPxl8Zd08YIM/Qv/DqEJCa26f1lJegKLWnXbxtcRe2lewyHuzy3fiIHV6X1c4nWCNV1gzNyAeqKxZrMd0arXl4BFkorM696mlMsw0+MlVe0UholdvK6z7QuoG9OzHAgh8ag0pH6MLv3Mv3FRCX4+e10JZcOVx0LGpyqu Cc: therightkey , Paul Wouters , Carl Wallace Subject: Re: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 10:52:27 -0000 On 20 November 2012 23:47, Tom Ritter wrote: > On 17 November 2012 22:57, Paul Wouters wrote: >> >> CT-PKIX addresses an issue where there are 600 roots and you can't >> trust all of them (although TLSA solves that too). I'm still unsure >> what CT-DNSSEC would solve, as just pulling history from DNS does not >> add anything, and I have no idea how to authenticate to the CT-DNSSEC >> audit log to start an alternative path of trust, especially if you are >> defendining against a rogue root or rogue .com key being used secretly >> to sign alternative records, or a compromised DNSSEC private key. > > > I'd like to state what I think CT-DNSSEC would solve, and how it would work. > I'll use .com as my example root, and google as my example CT notary. > Hopefully I don't screw up the DNSSEC part or the CT part too much... This looks about right to me, just one clarification. Also, as others have said, CT-DNSSEC is probably not the right name for it! > I submit an entry for the DS record for example.com to the .com operator. > The operator in turn contacts google but preferably multiple notaries and > says "This is the DS record for example.com" and google puts it into their > log, and gives back a signed statement as proof of such. It then enters > this proof in some new type of record, we'll call it DSProof. After the > .com operator has the proof, it updates the DS and DSProof records. > > Now a user wants to connect securely to example.com. They query the A > record for example.com, and get back the response plus the RRSIG, the > signature for the A record. However, the client can't check the signature, > it doesn't have the key. I'm unsure if in implementations this query > happens in parallel, in the same query or what - but it reaches out and gets > the ZSK for example.com, the KSK for example.com, and the DS record for > example.com - so it has the complete chain of keys from example.com -> .com > -> (root). At this point it can verify the entire chain of signatures. But > when it retrieves the DS record for example.com it also retrieves the > DSProof. > > The client can verify that the DSProof is valid and comes from the google > notary (I'm not 100% sure if this is a signature of a merkle path ending in > a signature but it functions like a signature.) In CT this is a signature from the log that is in effect a promise to include the cert in the log. This is so that the CT log server can respond immediately to a certificate request without having to generate a whole new tree. We did this in the interest of reliability and uptime (since there can only be one correct tree, it is required that all responses from a server farm are ordered, which is considerably more demanding than it is to store certificates for later ordering, in short). However, if DNSSEC servers are prepared to wait a while, sometimes, then we could make it an actual merkle path - this was the original design of CT, but CAs didn't like the delay. > The client ensures that the > DSProof is valid and from the google notary, meaning it has an entry in the > append-only merkel tree, which we can verify (and there are verifiers for > it.) That gets into the CT side of things. > > At this point, everything under example.com - whether it's the A record or > the TLSA record - is signed as normal, and the signatures under example.com > chain to a key that has been entered into a public log. If a TLD wants to > fraudulently sign a response for the A or TLSA record for a site, they will > have to also enter the key into the notary. The operator of example.com > will be able to see there is a DS record they did not authorize in the > notary, and can start investigations or other mitigation processes. > (Ideally the presence of the notaries will be the deterrent against the > attack.) > > I think CT-DNSSEC is important. We've seen domain seizures before. The new > gTLD program will open the internet to vast numbers of root operators, and > not all of them will be competent or lack malice. Root keys will get > stolen. Maybe it'll be .bugatti and not .bank but it will still happen. We > should build this in now, while we can flesh it out pre-widespread > deployment of DNSSEC. > > -tom > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > From paul@marvell.com Wed Nov 28 13:51:00 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A2521F84CC for ; Wed, 28 Nov 2012 13:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.985 X-Spam-Level: X-Spam-Status: No, score=-2.985 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40wDMfvC6GKx for ; Wed, 28 Nov 2012 13:50:59 -0800 (PST) Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) by ietfa.amsl.com (Postfix) with ESMTP id C061921F845A for ; Wed, 28 Nov 2012 13:50:59 -0800 (PST) Received: from sc-owa02.marvell.com ([199.233.58.137]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKULaHPSsSNOBh3/qeeFPkLWCzN/3nZXMk@postini.com; Wed, 28 Nov 2012 13:50:59 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Wed, 28 Nov 2012 13:46:24 -0800 From: Paul Lambert To: Ben Laurie , "therightkey@ietf.org" Date: Wed, 28 Nov 2012 13:46:23 -0800 Thread-Topic: Comments on Draft Thread-Index: Ac3HGz2Tg2Wyw1aaTFe3IwXuSQ14tQGk7ShQ Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D015ED1FBAA4@SC-VEXCH2.marvell.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 Subject: [therightkey] Comments on Draft X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 21:51:00 -0000 In the current draft, there may be some minor errors in the description of = the algorithms or confusion on my side on the nature of the notation. The notation would be much clearer if the merkle tree nodes were indexed by= the tuple representing the range of the hashed values covered by the node. I've attached below an alternate description of the trees showing the corre= spondence of the nodes to the range tuple and a short summary of the algori= thms using this notation. Paul PS - will publish associated Python code eventually =20 0,3 0,4 __|__ __|__=20 / \ / \ 0,2 2,3 0,2 2,4 / \ | / \ / \ 0,1 1,2 d2 0,1 1,2 2,3 3,4 | | | | | | d0 d1 d0 d1 d2 d3=20 =20 Each hash in the tree can be identified as a tuple representing the rang= e of values covered by the hash. =20 For a Merkle Hash Tree with n leaf nodes and each i,j node identified by mth(i,j): - the root hash, MTH =3D mth(0,n) - the leaf hash for data entry di with 0<=3Di 1, the audit path for the (m+1)th element d(m) in a list=20 of n > m elements is found by the recursive function: =20 =20 PATH(m, D[0:n]) Where: PATH(m, D[k1,k2]) =3D {} for (k2-k1)=3D1 k =3D k1 + largestPower2(k2-k1) =20 PATH(m, D[k1:k2]) =3D PATH(m, D[k1:k]) : MTH(D[k:k2]) for m < k; and =20 PATH(m, D[k1:k2]) =3D PATH(m, D[k:k2]) : MTH(D[k1:k]) for m >=3D k, 0,7 ______|______ / \ =20 0,4 4,7 =20 __|__ __|__ / \ / \ 0,2 2,4 4,6 6,7 / \ / \ / \ | 0,1 1,2 2,3 3,4 4,5 5,6 d6 | | | | | | d0 d1 d2 d3 d4 d5 =20 =20 The audit path for d0 is [mth(1,2), mth(2,4), mth(4,7)]. The audit path for d3 is [mth(2,3), mth(0,2), mth(4,7)]. The audit path for d4 is [mth(5,6), mth(6,7), mth(0,4)]. The audit path for d6 is [mth(4,6), mth(0,4)]. From benl@google.com Thu Nov 29 07:45:21 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AFB21F89A2 for ; Thu, 29 Nov 2012 07:45:21 -0800 (PST) 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 JrjNgplCpSpu for ; Thu, 29 Nov 2012 07:45:21 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D33F421F88DF for ; Thu, 29 Nov 2012 07:45:20 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so7828252vbb.31 for ; Thu, 29 Nov 2012 07:45:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=snQyc6HF+8nqIU1msBaO/EMuD/ubIUrRd23VzK8h32k=; b=HsNjFQADy0prs8QPRMagVMvjpLIw5+sB+PoPG0/qKHHrHkFf5rzLmoan7NPBBoQbWm tE9A1Y7AaMZAVcGE/UseVa0/SrPv9GWhPFuklFtc6qed6Ae73QkxAeYwwwjjRdXBcUfY SLqzVKoZloEbq8I8gba6ExYlPwmseflv7hU1h/tTPvcptzeDK5doL1Ub6tZ82IknJpWx v04XQuRR73mdAlM+l/ohAGFhrjLIQ3M758Vgs8UbWMWC0NvD9qmRAnc5kvbTjL1Ue9w9 skUEYwWFzCjtyrcEnyjrjyn7rI7rgvqDXWlwIkBw/GhvJwQbg2D+9wqjkcPZsQxO7BDt 8Fpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=snQyc6HF+8nqIU1msBaO/EMuD/ubIUrRd23VzK8h32k=; b=ggizA4Nkf3nPcSp3P74gq9Xh9hTfeD6LSgH160AzkQ6GfoRUS23qYi2VxpQtenMLtX paFKvFalhZkXx3/k1XXIwBV+l4QVRnErMu5r0TNg7sJwfSNSrJ8IcAEcgz6d7qF3fjmB 861jQv0KPzKwU5VzhbCL3u8jsyHS3JkGcqo7aEdOct6TcPe2/kPBBo9BcvrDRLdIO1NO HOXWm/EvylDf2e1kVCKge6Q1+TXConqP1NMDWtj+Vlq7jEPNJeSagg/zT8Ctx6GGYhiK icx05DyRKqEwG81wFsSI/KfCFadXsY0EZTi5zG+weeY09hsIyJrM3WrEMNDEGlcjIRZQ YMWQ== MIME-Version: 1.0 Received: by 10.52.76.40 with SMTP id h8mr28078868vdw.123.1354203920073; Thu, 29 Nov 2012 07:45:20 -0800 (PST) Received: by 10.220.228.6 with HTTP; Thu, 29 Nov 2012 07:45:19 -0800 (PST) Date: Thu, 29 Nov 2012 15:45:19 +0000 Message-ID: From: Ben Laurie To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmoj6TezPY7Toido5hLh4sM6qee0LsrP8Y5DHQV9do1dYBLtDwVxVf85mVJOxD6kgxebhBDLlCnbZbsJGwfs5Ps7VlDYkpami0xUDMU+nicWGbcbdVyKjxif+Xc3lKYdnlLEhTpDu+P43EM1JU5/TW1KoiusxYbfnRZM+dK9YrfjCxyCAbx+j7SpKd2MXvJD9aO+WF2 Subject: [therightkey] Updated I-D available X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 15:45:21 -0000 https://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/?include_text=1 From paul@marvell.com Thu Nov 29 07:55:12 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487D921F8AB3 for ; Thu, 29 Nov 2012 07:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.886 X-Spam-Level: X-Spam-Status: No, score=-3.886 tagged_above=-999 required=5 tests=[AWL=0.901, BAYES_00=-2.599, FRT_LEVITRA=1.812, 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 x6BnSVQt2V13 for ; Thu, 29 Nov 2012 07:55:11 -0800 (PST) Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by ietfa.amsl.com (Postfix) with ESMTP id DE86421F8AAC for ; Thu, 29 Nov 2012 07:55:09 -0800 (PST) Received: from SC-OWA01.marvell.com ([199.233.58.136]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKULeFXaHpbmskB0atvtHPamRSGe1KQbNJ@postini.com; Thu, 29 Nov 2012 07:55:10 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Thu, 29 Nov 2012 07:55:08 -0800 From: Paul Lambert To: "therightkey@ietf.org" , Ben Laurie Date: Thu, 29 Nov 2012 07:55:08 -0800 Thread-Topic: Another suggested change Thread-Index: Ac3OSegM4D08l2TKTNyMIFV21vkhDQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [therightkey] Another suggested change X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 15:55:12 -0000 >Structure of the Merkle audit proof: > > struct { > opaque sha256_hash[32]; > } MerkleNode; > > struct { > Version version; > LogID id; > uint64 tree_size; > uint64 timestamp; <------------------------------ not >necessary > uint64 leaf_index; > MerkleNode audit_path<0..2^16-1>; > TreeHeadSignature tree_head_signature; <--- contains timestamp > } MerkleAuditProof; > > From benl@google.com Fri Nov 30 06:18:00 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1A821F89CE for ; Fri, 30 Nov 2012 06:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.071 X-Spam-Level: X-Spam-Status: No, score=-102.071 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_LEVITRA=1.812, 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 qw7uJrAfMtHF for ; Fri, 30 Nov 2012 06:18:00 -0800 (PST) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFCB21F8D31 for ; Fri, 30 Nov 2012 06:18:00 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id fl11so12445726vcb.15 for ; Fri, 30 Nov 2012 06:17:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dNMfm5n0cKjalHiYZMZxq1dMlD8yXSIysSOMCHj/F2M=; b=RhIJrLKwYR6IzVDocmn3XOhpBANdOpA1jqZpwVncGBOcetbDMD9tYZVEBiLdWbCLTQ kFASkdsHFfY2dLtAJ4tUmWop9m4A8qkzZfxSKBwBtNb3GoJa1AS/4IHOzPRwNAzWlUeS YHJNYU3sPwa9VZhpXuoc65sk8MeZhyG5dsdmlwsp6wboJ9NjRskKv2zVHgRiwZeXSWVq weWtZlY715aI77Fnwbjkt9R1C3aKVmJr7vbLn0OkwczmUyO5Cu4jiGXIZp3wWLXADruN m02asgIFYHWoFwkqmmy8a+NC1OEf2G0YolOGqkseS0dL1HnM6YVEA6nT3erAP1oYsHtS WsuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=dNMfm5n0cKjalHiYZMZxq1dMlD8yXSIysSOMCHj/F2M=; b=pjwak9o1ip0mXHhaaaE1RYHsZoi0BzWGGgPD3WCHqLYeIc2VlUDGHEQSRVrk7yIYQh RNPwzxcbzO/2JqWI5/VnXm9Vz6eBwzqSBegiRS7Y22S5Ddj2nuuF27sK6IFsacEPSdR9 ssE2nWQHjE03exXwHkXfmJ7TkRktaKUqEFzDWpNlbleqBC1mAu33z80zzGF4CUXyQOET ORERhhtAVBOid0S8pNSGY9tMLBaw6IhEb/1Aw70aMz11s+3jvBBTry67SXKSNpjmJ4K9 ql2vZqgzKAjVuegoHexoJwzzCYQcfAwyK0KFy08lLt+9hb4XOMS4nYxhQV37+3PsjZz0 eDDw== MIME-Version: 1.0 Received: by 10.52.174.71 with SMTP id bq7mr991436vdc.49.1354285079560; Fri, 30 Nov 2012 06:17:59 -0800 (PST) Received: by 10.220.228.6 with HTTP; Fri, 30 Nov 2012 06:17:59 -0800 (PST) In-Reply-To: References: Date: Fri, 30 Nov 2012 14:17:59 +0000 Message-ID: From: Ben Laurie To: Paul Lambert Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkdM2L5iwK7Qe9tHOTrW6129SdKCypJFsNpTIwiezBUOQkHDYFr3ZW9RFRjsEZdJgBRWMUSNw4ItEfJorXZM7eBxCfBxpcdF0Gj4UpDUbi6ZwJAkCUEx7bFqVKtk1I1kRlB1eqxMPum8cSpD/nQsmw1yx1HX8tf7HLZEpcnEiPaqovlKowL9S7GDsx169sod2wjISbS Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Another suggested change X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 14:18:00 -0000 On 29 November 2012 15:55, Paul Lambert wrote: > > > >>Structure of the Merkle audit proof: >> >> struct { >> opaque sha256_hash[32]; >> } MerkleNode; >> >> struct { >> Version version; >> LogID id; >> uint64 tree_size; >> uint64 timestamp; <------------------------------ not >>necessary >> uint64 leaf_index; >> MerkleNode audit_path<0..2^16-1>; >> TreeHeadSignature tree_head_signature; <--- contains timestamp >> } MerkleAuditProof; Not sure why you think the timestamp is not needed? >> >> > From ekasper@google.com Fri Nov 30 06:28:32 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF3B21F893D for ; Fri, 30 Nov 2012 06:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.165 X-Spam-Level: X-Spam-Status: No, score=-101.165 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_LEVITRA=1.812, 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 HZyJ0TAJi-1u for ; Fri, 30 Nov 2012 06:28:32 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id AC7FB21F8935 for ; Fri, 30 Nov 2012 06:28:31 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hj13so238758wib.13 for ; Fri, 30 Nov 2012 06:28:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Sk0CckzXGCBh59HK6yeutC7TCJ/3aTyRpa6uZ7I7UaU=; b=bbqyPUj8RSWK68UdQDLjaM86L6GKn7srQRJjg1FsdqAjrab4XPVPeEEzoDEyN21POL kN0st+sqlwePWF6FQeF2HFyAKUdF2uaYXCdgAyoaZMRFufr/zKmvp02Lgn3MXSoiDMYQ re5+BaxAdpePbzG4YVdAtFewRqUrUZxinxfPIFrvC9ODb4zBVcyVgpYQ8FutgcJU6RDJ EEgkdEkjMHEmRM9zrBgfKdc5olHwu6how+cL4HuLwhADAT7woLtQEtqgGEEJV1PURfJv qiKO+cBTo9uau2HwoZ0T30IeIwQRFU8gizA5GAX/Ja/hK+p17GYEe4C9IWEO9CwMpIQc JtBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Sk0CckzXGCBh59HK6yeutC7TCJ/3aTyRpa6uZ7I7UaU=; b=NzRkGdEy0Z9nOW8gSy9Jxy9hVQwRDUkQD74qEUtogA3BQSXBNkcdado9H+zRxwmd3E lcEMfPlZyu0zrZ6bbr1LUgfzX9/kmNtbykv3TfYxGOwPZjpQQM/5ou6uwphI0Nn3z+tw d5iy7yFAxZhQnOni7l8w4J4cvSZ37Ce1TbEbqPnHy89WdAERtZ6eqdJT75HNjmSHWeYX 20lKhTHMrhM4yyHTGKlBGkmZsgTvXGubgQNsvJrkSoVutAyn9BKbCFqJ2hCG5V/4aX0P OW/sZkq84n8AXCqBKBdvDHwOkamsQi0Q5JVgt5GcV75PXGlRJJkiUmzLuoQcS5FO0ZcK vr0g== MIME-Version: 1.0 Received: by 10.180.74.20 with SMTP id p20mr2378741wiv.0.1354285710458; Fri, 30 Nov 2012 06:28:30 -0800 (PST) Received: by 10.227.19.146 with HTTP; Fri, 30 Nov 2012 06:28:30 -0800 (PST) In-Reply-To: References: Date: Fri, 30 Nov 2012 15:28:30 +0100 Message-ID: From: Emilia Kasper To: Ben Laurie Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlGKDr1fTiz7X/C3lLibpQBlvPP7KESmFBqxeMJSfmxV5E+1x7EI9+T9/VQz3//6+iBX0E1EkJPHKQegtTAiSvguIC8XCkzCTG59kqWJ7RC14zNTVrekxLXIaHOSJJn9ssRbnJaEi9Zl7yYteayriRILkcwJqyLQR9UTYr9AExYu66BjtcjF3LGk5l5EoXjNeeu2XQH Cc: Paul Lambert , "therightkey@ietf.org" Subject: Re: [therightkey] Another suggested change X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 14:28:32 -0000 On Fri, Nov 30, 2012 at 3:17 PM, Ben Laurie wrote: > On 29 November 2012 15:55, Paul Lambert wrote: >> >> >> >>>Structure of the Merkle audit proof: >>> >>> struct { >>> opaque sha256_hash[32]; >>> } MerkleNode; >>> >>> struct { >>> Version version; >>> LogID id; >>> uint64 tree_size; >>> uint64 timestamp; <------------------------------ not >>>necessary >>> uint64 leaf_index; >>> MerkleNode audit_path<0..2^16-1>; >>> TreeHeadSignature tree_head_signature; <--- contains timestamp >>> } MerkleAuditProof; > > Not sure why you think the timestamp is not needed? I'm glad to see people verifying the sanity of the structures! I think I know where the confusion is - in TLS notation, digitally-signed struct { } is a signature on the data in the struct; it does not include the data itself. So TreeHeadSignature is a signature over timestamp and other bits, but you need to include all bits needed for verification separately. >>> >>> >> > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey From paul@marvell.com Fri Nov 30 09:27:41 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0418721F8ACC for ; Fri, 30 Nov 2012 09:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.337 X-Spam-Level: X-Spam-Status: No, score=-4.337 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, FRT_LEVITRA=1.812, 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 r8EIb1c4MHH9 for ; Fri, 30 Nov 2012 09:27:40 -0800 (PST) Received: from na3sys009aog132.obsmtp.com (na3sys009aog132.obsmtp.com [74.125.149.250]) by ietfa.amsl.com (Postfix) with ESMTP id 55CD921F8B3D for ; Fri, 30 Nov 2012 09:27:40 -0800 (PST) Received: from SC-OWA.marvell.com ([199.233.58.135]) (using TLSv1) by na3sys009aob132.postini.com ([74.125.148.12]) with SMTP ID DSNKULjsi54tN3GMuteIsVY1SkFNjuRZgPCs@postini.com; Fri, 30 Nov 2012 09:27:40 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Fri, 30 Nov 2012 09:27:38 -0800 From: Paul Lambert To: Ben Laurie Date: Fri, 30 Nov 2012 09:27:35 -0800 Thread-Topic: Another suggested change Thread-Index: Ac3PH/33OsNlds3kSf2OqqQ/0Sying== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Another suggested change X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 17:27:41 -0000 On 11/30/12 6:17 AM, "Ben Laurie" wrote: >On 29 November 2012 15:55, Paul Lambert wrote: >> >> >> >>>Structure of the Merkle audit proof: >>> >>> struct { >>> opaque sha256_hash[32]; >>> } MerkleNode; >>> >>> struct { >>> Version version; >>> LogID id; >>> uint64 tree_size; >>> uint64 timestamp; <------------------------------ not >>>necessary >>> uint64 leaf_index; >>> MerkleNode audit_path<0..2^16-1>; >>> TreeHeadSignature tree_head_signature; <--- contains >>>timestamp >>> } MerkleAuditProof; > >Not sure why you think the timestamp is not needed? There are two timestamps =8A one in the tree_head_signature and one on the Audit Proof. =20 The timestamp within tree_head_signature is very useful. Not sure the intent of the usage and benefit of the additional timestamp on MerkleAuditProof. Seems that the timestamp with the tree_head_signature would always be the definitive creation time. However =8A 03 no longer has the MerkelAuditProof structure The SignedCertificateTimestamp is similar and has two timestamps. Clarity on the need and utilization of two time values would be useful. Paul > >>> >>> >> From paul@marvell.com Fri Nov 30 17:40:11 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3270B21F8662 for ; Fri, 30 Nov 2012 17:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.187 X-Spam-Level: X-Spam-Status: No, score=-4.187 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FRT_LEVITRA=1.812, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjC7W--g+rEf for ; Fri, 30 Nov 2012 17:40:10 -0800 (PST) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDDC21F8A60 for ; Fri, 30 Nov 2012 17:40:10 -0800 (PST) Received: from sc-owa02.marvell.com ([199.233.58.137]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKULlf+J5+JxlJsOekQ/mThN5S1vBMhly6@postini.com; Fri, 30 Nov 2012 17:40:10 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Fri, 30 Nov 2012 17:39:28 -0800 From: Paul Lambert To: Emilia Kasper , Ben Laurie Date: Fri, 30 Nov 2012 17:39:29 -0800 Thread-Topic: [therightkey] Another suggested change Thread-Index: Ac3PZLPaSYj3VLcxQNu4kWSC0HShFA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Another suggested change X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 01:40:11 -0000 On 11/30/12 6:28 AM, "Emilia Kasper" wrote: >On Fri, Nov 30, 2012 at 3:17 PM, Ben Laurie wrote: >> On 29 November 2012 15:55, Paul Lambert wrote: >>> >>> >>> >>>>Structure of the Merkle audit proof: >>>> >>>> struct { >>>> opaque sha256_hash[32]; >>>> } MerkleNode; >>>> >>>> struct { >>>> Version version; >>>> LogID id; >>>> uint64 tree_size; >>>> uint64 timestamp; <------------------------------ not >>>>necessary >>>> uint64 leaf_index; >>>> MerkleNode audit_path<0..2^16-1>; >>>> TreeHeadSignature tree_head_signature; <--- contains >>>>timestamp >>>> } MerkleAuditProof; >> >> Not sure why you think the timestamp is not needed? > >I'm glad to see people verifying the sanity of the structures! > >I think I know where the confusion is - in TLS notation, >digitally-signed struct { } is a signature on the data in the struct; >it does not include the data itself. So TreeHeadSignature is a >signature over timestamp and other bits, but you need to include all >bits needed for verification separately. Thanks! Yes, I was confused by the struct usage as a definition of "input" to the signature =8A just need to read the text an not just the code :-) Paul PS - seems like we should have better ways to define protocols =8A PPS - still don't see that the audit path algorithm is correct, should be: k =3D k1 + largestPower2(k2-k1) PATH(m, D[n]) =3D PATH(m, D[k1:k]) : MTH(D[k:k2]) for m < k; and PATH(m, D[n]) =3D PATH(m, D[k:k2]) : MTH(D[k1:k]) for m >=3D k, > >>>> >>>> >>> >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey