From nobody Wed May 4 15:12:23 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934F812D516 for ; Wed, 4 May 2016 15:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3sXi3fSMbz6 for ; Wed, 4 May 2016 15:12:15 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1072912D56D for ; Wed, 4 May 2016 15:12:14 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id A92EAF991 for ; Wed, 4 May 2016 18:12:12 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id E6C541FFE1; Wed, 4 May 2016 18:12:12 -0400 (EDT) From: Daniel Kahn Gillmor To: "trans\@ietf.org" User-Agent: Notmuch/0.22+16~g87b7bd4 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 04 May 2016 18:12:09 -0400 Message-ID: <87wpn9322u.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [Trans] evaluating an SCT in the absence of the cert's issuer key X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 22:12:22 -0000 --=-=-= Content-Type: text/plain hey folks-- Why aren't we explicitly including the issuer_hash in the SignedCertificateTimestampDataV2 object? i notice that someone who has only: a) an X.509 end-entity certificate and b) what appears to be a corresponding SCT Can't actually evaluate the validity of the log signature on the SCT over the certificate. This missing data is the hash of the issuer's public key, which is included in the signed material but isn't otherwise available from either (a) or (b). (i'm assuming here that (b) is a TransItem with versioned_type set to either x509_sct_v2(3) or precert_sct_v2(4), with data set to a SignedCertificateTimestampDataV2) I understand that adding the issuer_hash will increase the size of the SCT by 32 octets, but without that information, someone evaluating the SCT has no way of knowing whether it is legitimate. In the TLS handshake case, it's likely that the TLS client can compute the issuer_hash by extracting the SPKI from the next cert in the offered x.509 chain. But in other cases (e.g. auditing, gossiping), there's no guarantee that the issuer cert (or issuer public key) is going to be passed alongside the SCT. Do we want to require people to pass the issuer cert (or issuer public key?) alongside the cert in order to be able to verify the signature on an SCT? If so, where is the best place to document that concern? Or have i misunderstood the data structures? I'm working from https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-14 the issuer key hash was re-introduced here, i think: https://trac.tools.ietf.org/wg/trans/trac/ticket/80 but there's no consideration there for how validators are expected to function in the absence of the full chain. Any thoughts? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXKnO5XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKDZsP/j6YpPhLWflN9KjVpl7WLAJu Y2/TZc1VzdHSRKskWM+Irfmi1ROsToOqepb0THqdaXqxqtQasv38qKa7Ij6ZEGEZ NNoYihw9v5rxqZp3vRR/4AokR62FvVNYp9ZvnOmVvEVekxsoPxqfr1ys/WQQtLnT CAFK4s7zmYmF0/D/08HDxmOcJoH8iMpMvL9EOZfdX83IS+cnomfFzrkqxI9L/CNC 1GNidZJisieZdZKmO1pjXKVB91Ul5sahA1EVX31QXVdIretNakGMDeF1mE4Thtbx N3otuamW8dz1frAuoUO/aA/Mbi7B0Cjj96RsG9ZQyLzJOSzm3Eo60D2WyaCMJFTS xbH1JkytYidnFjKrtvo0oTypR7n/wSFj5wxSPsS3d+9FDpumoEn1sH2MLvkO1fFB jltQ367HHnxAZCGgjIPDhG/4ry/CbTgFwm+jcRsDomBJAGx4fDKsU5ZCkyocmtNG Wpzuk8G4XupD3VSZMrb4BbRJJH44RkF7vSZAJ6ae/dSkk6WpUMO1WzFYV0uY8ojE 1nEe4twCCZUbMQk8+UDJbbiHDfitfiVDffkX25gfw7buRPGJYT/2vLu25/KkgeGr NJxvOP5/EeM59t3ONQZMBNd031z1twQmrR7FmcpcFk8NefxNPdhN7zQx59CKek42 DisGofoM/XotmmgN+Xs0 =zOg7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 5 06:04:17 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B7C12D610 for ; Thu, 5 May 2016 06:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.697 X-Spam-Level: X-Spam-Status: No, score=-3.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soItMayXbUsy for ; Thu, 5 May 2016 06:04:13 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0146012D5E8 for ; Thu, 5 May 2016 06:04:12 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id d62so83427222iof.2 for ; Thu, 05 May 2016 06:04:12 -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; bh=Mbzb/lkehgY6y91UixI/QkZryUd8wHew1/hr7gqdgfo=; b=LTTaal2ZJ7dTEMDfWeWAgxe1cGEs+Y0663JB2yzMSMC/9mNI6FhQOdrf/zkWmhx/lZ w0XiwvvN9KFWFOqdESeYnuSjPSILv/h6YSDs7AqLrh02zkdIIgt35l7YGNy5WEmhOBHS 9IoFGRRfAV2n99v65ND5EpohKbFtOvXVNPk4aTmhXr+RO0xPpIuQ+3b6UCSRqI1tsCpO ufYEmO94lG4xiAGNB3Z8NSRDaAWclJob8jSd6NZFeVg196kkj8qUIrNQYmXGigXUvPsR 0bPqLmRwggXqKD/8Fv0w9JzIKFlILI5ftzxQUeC11oKuQcx1X9IbgE4EN2uK3xY28G2I IcoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Mbzb/lkehgY6y91UixI/QkZryUd8wHew1/hr7gqdgfo=; b=TT1QfRE0RYLXMYAM81fjaGWCPcF8n+C84NFgay+x4feb3pOJeM19Qf0EJ+VEmoxvp8 fEscwmEZzLugxt7TqK0T2uaF6dERXFlYlxEuiDEmvh2EoMI1MHzFfLraKMJTG2Li+fsh Rcro1nqSz1+kGK5yeok5prRnMPVvTT+MKipvA9HYZKyXU8+bwdYmeAwZQPfWNzC8NBy0 tUle7Ij5QFG/c51zzyiuptCUaalJIqzhnIC8P3D/gE+/sry/MPu/deHLUZWpNu8pM1nb qVI3EIpFAOhlETVnrWHFevfU1gU1+Y3Y1e05ilOkuh5kwkv8Q0hbZcYxP6CnsoyrPWwF 3LvQ== X-Gm-Message-State: AOPr4FXfK2jnq7h6dcD7eUOXbZqkbBiZzxu8TwdXbSSP/oCw5/BDTI3sUAZx5o9VZTH9qSUj3qLAkE8YotVWZb0l MIME-Version: 1.0 X-Received: by 10.107.26.201 with SMTP id a192mr17867044ioa.13.1462453449386; Thu, 05 May 2016 06:04:09 -0700 (PDT) Received: by 10.64.136.75 with HTTP; Thu, 5 May 2016 06:04:09 -0700 (PDT) In-Reply-To: <87wpn9322u.fsf@alice.fifthhorseman.net> References: <87wpn9322u.fsf@alice.fifthhorseman.net> Date: Thu, 5 May 2016 14:04:09 +0100 Message-ID: From: Ben Laurie To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] evaluating an SCT in the absence of the cert's issuer key X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 13:04:15 -0000 On 4 May 2016 at 23:12, Daniel Kahn Gillmor wrote: > hey folks-- > > Why aren't we explicitly including the issuer_hash in the > SignedCertificateTimestampDataV2 object? > > i notice that someone who has only: > > a) an X.509 end-entity certificate and > b) what appears to be a corresponding SCT > > Can't actually evaluate the validity of the log signature on the SCT > over the certificate. This missing data is the hash of the issuer's > public key, which is included in the signed material but isn't otherwise > available from either (a) or (b). > > (i'm assuming here that (b) is a TransItem with versioned_type set to > either x509_sct_v2(3) or precert_sct_v2(4), with data set to a > SignedCertificateTimestampDataV2) > > I understand that adding the issuer_hash will increase the size of the > SCT by 32 octets, but without that information, someone evaluating the > SCT has no way of knowing whether it is legitimate. > > In the TLS handshake case, it's likely that the TLS client can compute > the issuer_hash by extracting the SPKI from the next cert in the offered > x.509 chain. Likely? Isn't it certain (if the EE cert validates, that is)? > But in other cases (e.g. auditing, gossiping), there's no > guarantee that the issuer cert (or issuer public key) is going to be > passed alongside the SCT. > > Do we want to require people to pass the issuer cert (or issuer public > key?) alongside the cert in order to be able to verify the signature on > an SCT? If so, where is the best place to document that concern? That seems like a good idea. Presumably we'd need to add a new TransItem type to carry this information. > Or have i misunderstood the data structures? I'm working from > https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-14 > > the issuer key hash was re-introduced here, i think: > > https://trac.tools.ietf.org/wg/trans/trac/ticket/80 > > but there's no consideration there for how validators are expected to > function in the absence of the full chain. > > Any thoughts? > > --dkg > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > From nobody Thu May 5 06:18:02 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D045E12B03F for ; Thu, 5 May 2016 06:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHVWCh_IHthN for ; Thu, 5 May 2016 06:17:58 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A15D12D5FA for ; Thu, 5 May 2016 06:17:55 -0700 (PDT) Received: (qmail 8904 invoked by uid 1004); 5 May 2016 13:17:53 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Thu, 05 May 2016 14:17:53 +0100 Received: (qmail 27777 invoked by uid 1000); 5 May 2016 13:17:53 -0000 Received: from and0004.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 (AES128-SHA encrypted) ESMTPSA; Thu, 05 May 2016 14:17:53 +0100 To: Ben Laurie , Daniel Kahn Gillmor References: <87wpn9322u.fsf@alice.fifthhorseman.net> From: Rob Stradling Message-ID: <729c87d1-3dd8-5682-a8d8-53e766e3e042@comodo.com> Date: Thu, 5 May 2016 14:17:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] evaluating an SCT in the absence of the cert's issuer key X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 13:18:01 -0000 On 05/05/16 14:04, Ben Laurie wrote: > On 4 May 2016 at 23:12, Daniel Kahn Gillmor wrote: >> But in other cases (e.g. auditing, gossiping), there's no >> guarantee that the issuer cert (or issuer public key) is going to be >> passed alongside the SCT. >> >> Do we want to require people to pass the issuer cert (or issuer public >> key?) alongside the cert in order to be able to verify the signature on >> an SCT? If so, where is the best place to document that concern? > > That seems like a good idea. Presumably we'd need to add a new > TransItem type to carry this information. Makes sense. I think this should go into the gossip document rather than 6962-bis. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Thu May 5 11:05:02 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF64312D71E for ; Thu, 5 May 2016 11:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Scp2KlUvtje for ; Thu, 5 May 2016 11:04:59 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id D4E4D12D701 for ; Thu, 5 May 2016 11:04:56 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id C487FF991; Thu, 5 May 2016 14:04:55 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id D84BD2028B; Thu, 5 May 2016 14:04:55 -0400 (EDT) From: Daniel Kahn Gillmor To: Ben Laurie In-Reply-To: References: <87wpn9322u.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.22+16~g87b7bd4 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Thu, 05 May 2016 14:04:55 -0400 Message-ID: <878tzo2xfc.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] evaluating an SCT in the absence of the cert's issuer key X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 18:05:02 -0000 On Thu 2016-05-05 09:04:09 -0400, Ben Laurie wrote: >> In the TLS handshake case, it's likely that the TLS client can compute >> the issuer_hash by extracting the SPKI from the next cert in the offered >> x.509 chain. > > Likely? Isn't it certain (if the EE cert validates, that is)? well, there are always cases like: * web browser not configured with certificate chain (aka transvalid certs), and * user has clicked "accept" on the scary warning page for the cert in question I'd argue that even in that case, CT is still useful -- for example, a browser could consider make the clickthrough less scary/cumbersome/difficult if it had a valid SCT. But it won't be able to validate the SCT, so that's not an option. >> But in other cases (e.g. auditing, gossiping), there's no >> guarantee that the issuer cert (or issuer public key) is going to be >> passed alongside the SCT. >> >> Do we want to require people to pass the issuer cert (or issuer public >> key?) alongside the cert in order to be able to verify the signature on >> an SCT? If so, where is the best place to document that concern? > > That seems like a good idea. Presumably we'd need to add a new > TransItem type to carry this information. Is there a transaction in CT itself where you expect that to happen? Can you propose a change to the draft that would make that clear? Is the clumsiness of needing the issuer key in addition to the cert and SCT in order to validate the SCT worth the 32 octets in size it shaves off? --dkg From nobody Fri May 6 04:26:40 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAD912D5A1 for ; Fri, 6 May 2016 04:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ut_pAqiTG6HT for ; Fri, 6 May 2016 04:26:36 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1894B12D17A for ; Fri, 6 May 2016 04:26:36 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id o66so199421377ywc.3 for ; Fri, 06 May 2016 04:26:35 -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; bh=IGsbhKDR0J7IC3D3HGJpxbtOD1FS3kzTwtn2AXRMwhg=; b=bBrDNA8ZrR13Vc4eZTwXXU23l9t8tk4+pqgvW/NnDmrIkTQQLEniz7B7nh2UFLxC3b GtNALwenasMVZxWUOoRyEYDLSKBPxTBRwiIJ5cfnb2MwVH1S+9AUQ8NSx1YrGaeEqo7Z nHto5j7sGV7pffGwGoUgCYdpVzWMZHHg+WnlzLsJeLuR+VXvss2l6echTdWvQFqNQTtU AlqgNN1wkaXmuyJMF9umoc8oQ328mtKQ/JE8801e9l3/wOetAqzrCgdskIdSnA4EGqbw HIli3+fvIm/N6llRmzRuuAAlnKC5YgsV1TPg7I/aBTk9B0mUbtb2RcFC2oXe6pC5DuD4 WpSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=IGsbhKDR0J7IC3D3HGJpxbtOD1FS3kzTwtn2AXRMwhg=; b=epqMVGXsYvCn85T7hjHTAm9FPEiIMSKh+ZoKarbxLPPJtrWelZvlxFpQwI57YIygRH s+s+DUk8jp1uLA12bK/EOR2pzV8aqf9nyI+p25PVykHEjuv5TP/rkvWU5BWUSAer6je6 YWTlar2Uq2gwjPIAWHSHrq4dI201v2Avvxjoc9cC3WW6ZOOJXaulW5+cQGs6AWpbNT/g T8F7TdPPguFb5/OW5io6c50aCElRPHmZKQ8DAkxfT0MH1aWMrA9yxT8iW5ojmYRI4crH ieIibkoLfdJbVkLmdd8mdwUXH4LD1BhDB9QiRLmq2brDyA1kJ/PrLZbCKIQjJU3h5zTy RoUQ== X-Gm-Message-State: AOPr4FWLTh1suVAFO58v+E8TQMqfXdbS5o62CIVObV9AkqTTL66ybdOjWm9NwrV01XymKm0wJe0BI11iemq55RDy MIME-Version: 1.0 X-Received: by 10.129.155.5 with SMTP id s5mr11332046ywg.43.1462533995181; Fri, 06 May 2016 04:26:35 -0700 (PDT) Received: by 10.37.212.149 with HTTP; Fri, 6 May 2016 04:26:35 -0700 (PDT) In-Reply-To: <878tzo2xfc.fsf@alice.fifthhorseman.net> References: <87wpn9322u.fsf@alice.fifthhorseman.net> <878tzo2xfc.fsf@alice.fifthhorseman.net> Date: Fri, 6 May 2016 12:26:35 +0100 Message-ID: From: Eran Messeri To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=94eb2c0b897441b06e05322abbc8 Archived-At: Cc: "trans@ietf.org" , Ben Laurie Subject: Re: [Trans] evaluating an SCT in the absence of the cert's issuer key X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 11:26:38 -0000 --94eb2c0b897441b06e05322abbc8 Content-Type: text/plain; charset=UTF-8 On Thu, May 5, 2016 at 7:04 PM, Daniel Kahn Gillmor wrote: > On Thu 2016-05-05 09:04:09 -0400, Ben Laurie wrote: > >> In the TLS handshake case, it's likely that the TLS client can compute > >> the issuer_hash by extracting the SPKI from the next cert in the offered > >> x.509 chain. > > > > Likely? Isn't it certain (if the EE cert validates, that is)? > > well, there are always cases like: > > * web browser not configured with certificate chain (aka transvalid > certs), and > > * user has clicked "accept" on the scary warning page for the cert in > question > > I'd argue that even in that case, CT is still useful -- for example, a > browser could consider make the clickthrough less > scary/cumbersome/difficult if it had a valid SCT. But it won't be able > to validate the SCT, so that's not an option. > The SCT was obtained in the first place by submission of a cert and a chain to validate it. Can you further expand on the situations you see where a cert would be provided but not the chain? (I couldn't find anything about transvalid certs) > > >> But in other cases (e.g. auditing, gossiping), there's no > >> guarantee that the issuer cert (or issuer public key) is going to be > >> passed alongside the SCT. > >> > >> Do we want to require people to pass the issuer cert (or issuer public > >> key?) alongside the cert in order to be able to verify the signature on > >> an SCT? If so, where is the best place to document that concern? > > > > That seems like a good idea. Presumably we'd need to add a new > > TransItem type to carry this information. > > Is there a transaction in CT itself where you expect that to happen? > Can you propose a change to the draft that would make that clear? > > Is the clumsiness of needing the issuer key in addition to the cert and > SCT in order to validate the SCT worth the 32 octets in size it shaves > off? > The reason (I recall) for requiring the issuer key hash and TBSCertificate was to unify handling of precerts and X.509 certs, such that the SCT signature is over the same data structure for both cases. The concern you raise is very valid - the issuer cert would always have to accompany the leaf cert for clients/auditors to be able to verify the SCT's signature (note that get-entries returns, in addition to the log entry and the chain, the SCT issued). I agree we should make sure the protocol takes it into account - just not sure what type of clients will have a problem (TLS clients should get a full chain, auditors get everything from the log). > > --dkg > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --94eb2c0b897441b06e05322abbc8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 5, 2016 at 7:04 PM, Daniel Kahn Gillmor &= lt;dkg@fifthhors= eman.net> wrote:
On Thu 2016-05-05 09:04:09 -0400, Ben Laurie wrote:
>> In the TLS handshake case, it's likely that the TLS client can= compute
>> the issuer_hash by extracting the SPKI from the next cert in the o= ffered
>> x.509 chain.
>
> Likely? Isn't it certain (if the EE cert validates, that is)?

well, there are always cases like:

=C2=A0* web browser not configured with certificate chain (aka transvalid =C2=A0 =C2=A0certs), and

=C2=A0* user has clicked "accept" on the scary warning page for t= he cert in
=C2=A0 =C2=A0question

I'd argue that even in that case, CT is still useful -- for example, a<= br> browser could consider make the clickthrough less
scary/cumbersome/difficult if it had a valid SCT.=C2=A0 But it won't be= able
to validate the SCT, so that's not an option.
The = SCT was obtained in the first place by submission of a cert and a chain to = validate it. Can you further expand on the situations you see where a cert = would be provided but not =C2=A0the chain? (I couldn't find anything ab= out transvalid certs)=C2=A0

>>=C2=A0 But in other cases (e.g. auditing, gossiping), there's n= o
>> guarantee that the issuer cert (or issuer public key) is going to = be
>> passed alongside the SCT.
>>
>> Do we want to require people to pass the issuer cert (or issuer pu= blic
>> key?) alongside the cert in order to be able to verify the signatu= re on
>> an SCT?=C2=A0 If so, where is the best place to document that conc= ern?
>
> That seems like a good idea. Presumably we'd need to add a new
> TransItem type to carry this information.

Is there a transaction in CT itself where you expect that to happen?=
Can you propose a change to the draft that would make that clear?

Is the clumsiness of needing the issuer key in addition to the cert and
SCT in order to validate the SCT worth the 32 octets in size it shaves
off?
The reason (I recall) for requiring the issuer ke= y hash and TBSCertificate was to unify handling of precerts and X.509 certs= , such that the SCT signature is over the same data structure for both case= s.=C2=A0
The concern you raise is very valid - the issuer cert wo= uld always have to accompany the leaf cert for clients/auditors to be able = to verify the SCT's signature (note that get-entries returns, in additi= on to the log entry and the chain, the SCT issued).=C2=A0
I agree= we should make sure the protocol takes it into account - just not sure wha= t type of clients will have a problem (TLS clients should get =C2=A0a full = chain, auditors get everything from the log).

=C2=A0 =C2=A0 --dkg

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

--94eb2c0b897441b06e05322abbc8-- From nobody Thu May 12 06:01:36 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EF212D0DA for ; Thu, 12 May 2016 06:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nordu.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bbJ1psdqOn9 for ; Thu, 12 May 2016 06:01:27 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16F0812D0BA for ; Thu, 12 May 2016 06:01:26 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id u4CD0rWn013562 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 12 May 2016 15:00:53 +0200 Received: from kerio.nordu.net (kerio.nordu.net [109.105.113.41]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id u4CD0o6T002828 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 May 2016 13:00:53 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1463058053; bh=pQlbpoyU8+6ZomC6g34cmRwUPSnFMtfudtO8y5lAF9M=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=NSQaS47/EXOWVZxUlYsol8uh9z8P8i8fqK+XYBWQfiqh0JZeU4tYnJtCvJWGKutZz N9NA0CVbN/+oHnc+XEUMs+Jkr/8VKcYbsUWqOBFgbq3PqQkjA9UfS1qh9wxTfvfmQT +a34l6/EPQ3FMysoyAgEY5YKRM/itG6MqX50EKFY= X-Footer: bm9yZHUubmV0 Received: from flogsta ([193.10.5.129]) (authenticated user linus@nordu.net) by kerio.nordu.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Thu, 12 May 2016 15:00:49 +0200 From: Linus Nordberg To: Eran Messeri Organization: NORDUnet A/S References: <87wpn9322u.fsf@alice.fifthhorseman.net> <878tzo2xfc.fsf@alice.fifthhorseman.net> Date: Thu, 12 May 2016 15:00:47 +0200 In-Reply-To: (Eran Messeri's message of "Fri, 6 May 2016 12:26:35 +0100") Message-ID: <87k2izbfcw.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.113.41; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aQRp0RHU - 6b1a7ca8f58a - 20160512 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter02.sunet.se: 109.105.113.41 is neither permitted nor denied by domain linus@nordu.net) receiver=e-mailfilter02.sunet.se; client-ip=109.105.113.41; envelope-from=; helo=smtp1.nordu.net; identity=mailfrom Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] evaluating an SCT in the absence of the cert's issuer key X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 13:01:35 -0000 Eran Messeri wrote Fri, 6 May 2016 12:26:35 +0100: | > >> But in other cases (e.g. auditing, gossiping), there's no | > >> guarantee that the issuer cert (or issuer public key) is going to be | > >> passed alongside the SCT. | > >> | > >> Do we want to require people to pass the issuer cert (or issuer public | > >> key?) alongside the cert in order to be able to verify the signature on | > >> an SCT? If so, where is the best place to document that concern? | > > | > > That seems like a good idea. Presumably we'd need to add a new | > > TransItem type to carry this information. | > | > Is there a transaction in CT itself where you expect that to happen? | > Can you propose a change to the draft that would make that clear? | > | > Is the clumsiness of needing the issuer key in addition to the cert and | > SCT in order to validate the SCT worth the 32 octets in size it shaves | > off? | > | The reason (I recall) for requiring the issuer key hash and TBSCertificate | was to unify handling of precerts and X.509 certs, such that the SCT | signature is over the same data structure for both cases. | The concern you raise is very valid - the issuer cert would always have to | accompany the leaf cert for clients/auditors to be able to verify the SCT's | signature (note that get-entries returns, in addition to the log entry and | the chain, the SCT issued). | I agree we should make sure the protocol takes it into account - just not | sure what type of clients will have a problem (TLS clients should get a | full chain, auditors get everything from the log). The current incarnation of the CT gossip draft defines two modes of operations for HTTPS servers when taking part in SCT Feedback (draft-ietf-trans-gossip-02 section 8.1.3). In "simple mode" the HTTPS server doesn't have a set of trusted roots and won't deal with anything in the cert chain except the end-entity cert. The argument for this is that it requires less configuration which should increase the likelyhood of adoption. An argument against this, beside the issue brought up by dkg in this thread, is that "simple mode" won't protect against the double-CA-compromise attack. From nobody Fri May 13 07:56:55 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACEA12B00C for ; Fri, 13 May 2016 07:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.697 X-Spam-Level: X-Spam-Status: No, score=-3.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7vIHh7UMsZK for ; Fri, 13 May 2016 07:56:46 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5435D127058 for ; Fri, 13 May 2016 07:56:46 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id i75so130451482ioa.3 for ; Fri, 13 May 2016 07:56:46 -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; bh=NBtIwA05cuS21sLVF4zao+2sFLjZW06S7qzAYDl7+BQ=; b=mXjwIrkeP8GNavclJBA4YQQwY4HvBF2zv7FLPVWR3QgROeQCozNz5x4NO9fbkHkWpV H7laknjG/0EAlnKMTs7zopb55YYIQiytSeLIJj12KgL5bZKOOtexO74bJz/4ZAC1b+wd uNAfKyk46ZILFVq+lUVH8Pq8rTXib4M09A2k3mYgS4C3PWPu+o511a0bsX9Klanz3q3m 3ptS9oJL9rtfA/Ga7vK/0hcSExvBJvo1XK9Kw63uO+bEtAKuJJVESOB0lnWWim4y6GmY Me0Q0cisGvAb6crcxoRhKua79BwveuKdAPIU6anGeNSIXNpW+faVbLAfU4zH+0G81J9Y 6QJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=NBtIwA05cuS21sLVF4zao+2sFLjZW06S7qzAYDl7+BQ=; b=cW9ehIwjgZXIrD6Vb76gC49ltRQeNszyYrg6uLGjmqubrBGYb3CWZ9aTH7tdTACztY QTOEEbw1/j1UvBWc2pow7nk0+q44sl6YmDwRktga/NUb/AEyGikxNh+PisiAZwGoILX3 3L91qKSTiW1/Vtteo6Qk7thCnuGvFHruzqjJWQ5d8FxNMnP6YYIQoPZMkRhk8J6Gxy2t tbjvUYTK/YgyPF6cRBGvd/GRczIXJ7G0vzOUXuTk05tLUUWvEKu1oQSdp7HgBmfm2oEs jxtf0c+DN1OGLL6BXKpScAB/W5xCgG0Ko5dHJ90dgsywODstWWWi15QmmZYESN2Z2YDk p/EA== X-Gm-Message-State: AOPr4FUAs5Ich9GU5dgJ9Jiov0wM+WKKZ2bkfqHZS001jEnQMhJQbgpWJ7ovGx8JGHJY5iZfr78NYz5gTVhFndml MIME-Version: 1.0 X-Received: by 10.107.35.3 with SMTP id j3mr13806386ioj.119.1463151405525; Fri, 13 May 2016 07:56:45 -0700 (PDT) Received: by 10.64.136.75 with HTTP; Fri, 13 May 2016 07:56:44 -0700 (PDT) In-Reply-To: <87wpn9322u.fsf@alice.fifthhorseman.net> References: <87wpn9322u.fsf@alice.fifthhorseman.net> Date: Fri, 13 May 2016 15:56:44 +0100 Message-ID: From: Ben Laurie To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] evaluating an SCT in the absence of the cert's issuer key X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 14:56:54 -0000 On 4 May 2016 at 23:12, Daniel Kahn Gillmor wrote: > hey folks-- > > Why aren't we explicitly including the issuer_hash in the > SignedCertificateTimestampDataV2 object? > > i notice that someone who has only: > > a) an X.509 end-entity certificate and > b) what appears to be a corresponding SCT > > Can't actually evaluate the validity of the log signature on the SCT > over the certificate. This missing data is the hash of the issuer's > public key, which is included in the signed material but isn't otherwise > available from either (a) or (b). > > (i'm assuming here that (b) is a TransItem with versioned_type set to > either x509_sct_v2(3) or precert_sct_v2(4), with data set to a > SignedCertificateTimestampDataV2) > > I understand that adding the issuer_hash will increase the size of the > SCT by 32 octets, but without that information, someone evaluating the > SCT has no way of knowing whether it is legitimate. > > In the TLS handshake case, it's likely that the TLS client can compute > the issuer_hash by extracting the SPKI from the next cert in the offered > x.509 chain. But in other cases (e.g. auditing, gossiping), there's no > guarantee that the issuer cert (or issuer public key) is going to be > passed alongside the SCT. > > Do we want to require people to pass the issuer cert (or issuer public > key?) alongside the cert in order to be able to verify the signature on > an SCT? If so, where is the best place to document that concern? > > Or have i misunderstood the data structures? I'm working from > https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-14 > > the issuer key hash was re-introduced here, i think: > > https://trac.tools.ietf.org/wg/trans/trac/ticket/80 > > but there's no consideration there for how validators are expected to > function in the absence of the full chain. > > Any thoughts? Actually, it seems to me that the simplest answer is to allow lookups in logs based on SCT alone. Then the SCT can be validated using the retrieved chain. From nobody Mon May 16 12:54:36 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3651512D9E3 for ; Mon, 16 May 2016 12:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.728 X-Spam-Level: X-Spam-Status: No, score=-2.728 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FSL_HELO_HOME=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHxKxh5gddCQ for ; Mon, 16 May 2016 12:54:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0D3312D9E1 for ; Mon, 16 May 2016 12:54:32 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:33802 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1b2Ob1-000Oih-9T for trans@ietf.org; Mon, 16 May 2016 15:54:31 -0400 To: "trans@ietf.org" From: Stephen Kent Message-ID: <573A2577.1070106@bbn.com> Date: Mon, 16 May 2016 15:54:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] I'm baaaaack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 19:54:34 -0000 I've just returned from a month-long vacation and working my way through about 3K messages. I see that Ben has provided comments on the latest version of the threat analysis. I plan to read his comments and respond later this week. Steve From nobody Wed May 18 09:23:37 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6170E12D1B3 for ; Wed, 18 May 2016 09:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nordu.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPDZY-pJcTXV for ; Wed, 18 May 2016 09:23:32 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30F2A12D1AF for ; Wed, 18 May 2016 09:23:31 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id u4IGNOVn025885 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 May 2016 18:23:24 +0200 Received: from kerio.nordu.net (kerio.nordu.net [109.105.113.41]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id u4IGNHEC012489 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 May 2016 16:23:20 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1463588603; bh=QY8fbMaGA7evitDstkIaWIzc9YekzLnyGDp1VIL2mqE=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=C2LtolK164GtqGgptNNsPivcXWJeaDcpe30jxowB2Q8W0+b1EGtVpaIhT6fiJ8aHi jb556TA1+/PCsXlxgpWxiPYZzkotPdliExuYMZbIqoyZteTs/QcJJ2z2LfH/Ejbk0u L9WEs7+sL4H7okFhs2nP1nQp540Kur0uLa7EfcOc= X-Footer: bm9yZHUubmV0 Received: from flogsta ([193.10.5.129]) (authenticated user linus@nordu.net) by kerio.nordu.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Wed, 18 May 2016 18:23:16 +0200 From: Linus Nordberg To: Ben Laurie Organization: NORDUnet A/S References: <87wpn9322u.fsf@alice.fifthhorseman.net> Date: Wed, 18 May 2016 18:23:13 +0200 In-Reply-To: (Ben Laurie's message of "Fri, 13 May 2016 15:56:44 +0100") Message-ID: <87lh37mj2m.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.113.41; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aQTQnoSI - f0caf8161c3b - 20160518 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter02.sunet.se: 109.105.113.41 is neither permitted nor denied by domain linus@nordu.net) receiver=e-mailfilter02.sunet.se; client-ip=109.105.113.41; envelope-from=; helo=smtp1.nordu.net; identity=mailfrom Archived-At: Cc: "trans@ietf.org" , Daniel Kahn Gillmor Subject: Re: [Trans] evaluating an SCT in the absence of the cert's issuer key X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 16:23:35 -0000 Ben Laurie wrote Fri, 13 May 2016 15:56:44 +0100: | Actually, it seems to me that the simplest answer is to allow lookups | in logs based on SCT alone. Then the SCT can be validated using the | retrieved chain. That seems odd. From a logs point of view, an SCT is not a persistent object. I don't know about other implementations but catlfish would not be able to efficiently find an entry in the database given only an SCT. From nobody Wed May 18 10:30:42 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E6B12B051 for ; Wed, 18 May 2016 10:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOXax_RSO08X for ; Wed, 18 May 2016 10:30:39 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085BB12D565 for ; Wed, 18 May 2016 10:30:38 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id i75so74495534ioa.3 for ; Wed, 18 May 2016 10:30:38 -0700 (PDT) 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; bh=KZZtHEGN5SPS/KgZSdJwgPqpifmSLnIYGup5xWf/DmI=; b=BLoqL+QUOabpb+y6jl5utwEgf9N3OxpcbQTH6YQ4ciNMbPEqHQFH9MkEWaZRejuH97 2HeGfgwUMfmCMgmJidrxsytWTmWJGfPQd8DoGomVJ5UNGLbJvUo61Oq1Lo5DfWIrfXfZ 7hr0KW2vazbl7VAuey/ibyxvSdCSxhiUugL7auOnadG6RLNRyIm1M8vUpxZWVrReLCaD CcV+s1barFS7wvNCtkEu6AcTVJmv6D6mdj82r9klLz8jxTeVUjzRK2R2MxPG14bQVpiC KNz2HxHvOYkPYt55InAfeoI8QL3CKzidgRxlg6jc6LLoJCN0lsQJbMsdXJMw0F/YnX+F qOqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KZZtHEGN5SPS/KgZSdJwgPqpifmSLnIYGup5xWf/DmI=; b=R9GTx+dPkOngT2RJW1osXJt/Awq6MNFc+KwQJMC1IwXbQRAwEVIv72/jpqLdMc/hMB iAozTmMyweHY3jSmjP7USqJLCVcJR/6IvmiT5hWsY6DthEW0YRUabC8C1LmbheawPgxo 4GBp89RVl80F3i/2lKW9CzfZ4bOfKrTCcK0PeCCS1ZnSGflw7y0JbYWkj/D9mwoW9kgR LSzE/yhxqlbrPSb+STsBPVxspqYUQN3pM7PVyzln142Oh6ySSmVY5arCqWVecrpJ3ndQ iMLDPI2flfpLjKcwV8b/YvLXg9+8KnhMU43TrqFy1WZs5yKwphIwJeOqRNtSGlhdlY32 rfvA== X-Gm-Message-State: AOPr4FVdgcJJKCevq/9vdD8ANO2Usrl4Cb7bWyKYUfpXkY3CaeyWmFZX2kEDeVmYmKrvYIYOg1j7ZtYcw/82Eyu9 X-Received: by 10.107.26.85 with SMTP id a82mr6483952ioa.13.1463592638229; Wed, 18 May 2016 10:30:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.136.75 with HTTP; Wed, 18 May 2016 10:30:37 -0700 (PDT) In-Reply-To: <87lh37mj2m.fsf@nordberg.se> References: <87wpn9322u.fsf@alice.fifthhorseman.net> <87lh37mj2m.fsf@nordberg.se> From: Ben Laurie Date: Wed, 18 May 2016 18:30:37 +0100 Message-ID: To: Linus Nordberg Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" , Daniel Kahn Gillmor Subject: Re: [Trans] evaluating an SCT in the absence of the cert's issuer key X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 17:30:41 -0000 On 18 May 2016 at 17:23, Linus Nordberg wrote: > Ben Laurie wrote > Fri, 13 May 2016 15:56:44 +0100: > > | Actually, it seems to me that the simplest answer is to allow lookups > | in logs based on SCT alone. Then the SCT can be validated using the > | retrieved chain. > > That seems odd. From a logs point of view, an SCT is not a persistent > object. > > I don't know about other implementations but catlfish would not be able > to efficiently find an entry in the database given only an SCT. Are you saying there's some technical barrier to doing this, or just that as it stands you wouldn't be able to? It seems to me that the log could easily save SCTs it issued alongside the cert chains it issued them for. And that it could easily create an index based on those SCTs. Note that 6962-bis already requires you to return SCTs in some lookups... From nobody Thu May 19 07:44:07 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BE912D11E for ; Thu, 19 May 2016 07:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHphF9AZeq84 for ; Thu, 19 May 2016 07:44:02 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0768E12D1D2 for ; Thu, 19 May 2016 07:44:02 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id n129so234158448wmn.1 for ; Thu, 19 May 2016 07:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=roRAQC/d2KQiqEhIfxKkWnwqaos3oAcd3K8wj5xkoaE=; b=X/Etxon/xzfS69FG20BtrsCFBwQmcjyKx3uDbYnmUtFhulSzAAGqme+9cZB7109C08 tWQAEurCsf++B5bJUdHy+fmGIkucVeO6gtR4crfsBTHQbriEUt4n6v9RFYr3cghJw3rk Y3CEJaq8JKBgbU2Cl3cONBVMlj1ogGdAJ/KkZ7obJaip7S/hAJR76w2uywJjARZPdI4j vZ60qCu4ADXoRg0c0m0aZkP+Y+GjlP6i36gUBH5VoZyXxdx5DDLZ0qsOpY4Zgew0DCGT h3TkQVOCHWNhitJb6l6irNO7U25bhfZoSuQk/vESElhhfu1TARu2IS+uyDSI9LOsdTJA baYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=roRAQC/d2KQiqEhIfxKkWnwqaos3oAcd3K8wj5xkoaE=; b=d+z5dPjn4o6f6IIbJrddLFBjl+dhuZVWdGAkhN6qIkT3qW/y2Uk+0tW5JTBlwKvZLw g2nwJgjvdNBZ6RSsBq112s9kjhlqYkhzmkCWhAIjHAf8yquXlI/8fJVNoO6uZwAkvYgO egHETLFPuJpEfx8hkTzt3DaQyeAeaRiT6269B6+Hs3agYOUHr6eZUptiC6Ajk0wDXoZU oLbSI01wMvBht5WkZHXjyh7m2zMUMhxAJPCPqn/IRenPh3KjZq+FME6MYKKpI2ymLGAd QjZ5xOl7Dt0C0PweSJ2phWshRIFPdM0WGmSRh39Ee+neODEPyBxl1GailgJ9OCQuhtqM Yc0w== X-Gm-Message-State: AOPr4FWgpFFvzHQJDp4eRYZZfDOYzVdErys9lulvOxqNfjkKH1fwxvKfjefJp1r9Y9XqMw== X-Received: by 10.194.162.130 with SMTP id ya2mr13924661wjb.141.1463669040469; Thu, 19 May 2016 07:44:00 -0700 (PDT) Received: from tsf-476-wpa-6-059.epfl.ch (tsf-476-wpa-6-059.epfl.ch. [128.179.182.59]) by smtp.gmail.com with ESMTPSA id c7sm9310205wji.38.2016.05.19.07.43.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 19 May 2016 07:43:59 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_FAEBAD9A-961D-4266-97F3-6A7FB7B5197C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Bryan Ford In-Reply-To: <570FA14E.4010109@bbn.com> Date: Thu, 19 May 2016 16:43:58 +0200 Message-Id: <096DC698-534F-4632-B247-353A74564111@gmail.com> References: <570FA14E.4010109@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] slight timing whoops X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 14:44:06 -0000 --Apple-Mail=_FAEBAD9A-961D-4266-97F3-6A7FB7B5197C Content-Type: multipart/alternative; boundary="Apple-Mail=_7C90EF64-D108-44FB-9E6A-741154FE688D" --Apple-Mail=_7C90EF64-D108-44FB-9E6A-741154FE688D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Stephen, Finally catching up on the latest version of your new threat analysis = text... On Apr 14, 2016, at 3:55 PM, Stephen Kent wrote: > 3.2.1.1.1. Self-monitoring Subject >=20 > =20 >=20 > < add a second paragraph> >=20 > =20 >=20 > A malicious CA might revoke a bogus certificate to avoid having = browser=20 > vendors take punitive action against the CA and/or to persuade them = to not=20 > enter the bogus certificate on a vendor-maintained blacklist. = However, the CA=20 > might provide a =E2=80=9Cgood=E2=80=9D OCSP response (from a server = it operates) to a targeted=20 > user (browser instance) as a way to circumvent the remediation = nominally offered=20 > by revocation. No component of CT is tasked with detecting this = sort of misbehavior=20 > by a CA. (The misbehavior is analogous to a log offering split = views to different=20 > clients. The Audit element of CT is tasked with detecting this sort = of attack.) >=20 Just a nitpick: in the parenthetical about =E2=80=9Canalogous to a log = offering split view", may be worth adding a forward-reference to the = text below (or just the words =E2=80=9Cdescribed below=E2=80=9D) = containing the detailed discussion of that class of attack? > 3.3 Malicious, Colluding CAs >=20 > Section 3.2 examined attacks in which a single CA might issue a bogus = certificate. There is also the potential that two or more CAs might = collude to issue a bogus certificate in a fashion designed to foil the = remediation (but not detection) safeguards envisioned by CT. Their goal = would be trick a CT-aware browser into accepting a bogus certificate = because it was accompanied by a valid SCT, while evading certificate = revocation status indications. This section explores such scenarios. >=20 > In this attack two CAs that do not share a common path to a trust = anchor, collude to create a =E2=80=9Cdoppelganger=E2=80=9D (bogus) EE = certificate. The attack need not be initiated by trust anchors; any = subordinate pair of (not name-constrained) CAs can effect this attack = without the knowledge of superiors CAs (which are presumed to be = benign). The two CAs must have the same Subject name and the same public = key for the attack. (RFC 5280 doe not explicitly preclude the creation = of two CAs with the same name, so long as the parent CAs are distinct. I agree with David Cooper that describing this as =E2=80=9Ctwo CAs=E2=80=9D= is rather strange given the assumption that they have =E2=80=9Cthe same = Subject name and public key=E2=80=9D. I would call that =E2=80=9COne = Malicious CA with Two Certificate Chains=E2=80=9D or something like = that. > Requirements for Subject name uniqueness apply individually to each CA = but not across CA boundaries, as per Section 4.2.1.6. However, the = Security Considerations section of RFC 5280 warns that name collisions = could cause security problems.)=20 >=20 > Because the two CAs have the same name and make use of the same key, = each can issue the (bogus) doppelganger certificates. One of the CAs = would log the certificate and acquire an SCT for it, while the other = would not.=20 >=20 > Because the bogus certificate is logged, it is subject to detection as = such by a Monitor. Once the bogus certificate is detected it is = anticipated that action will be taken to render it invalid. The bogus = certificate itself might be revoked by the CA that issued and logged it, = an action that masks the malicious intent of that CA. A browser vendor = might add the bogus certificate to a blacklist maintained by the vendor, = e.g., because the CA failed to revoke the bogus certificate.=20 >=20 > If the CA that logged the bogus certificate is suspected of being = malicious, e.g., because it has a history of using bogus certificates, = the certificate of that CA might itself be revoked. This revocation = might be effected by the parent of that CA (which is not complicit), or = by a browser vendor using a blacklist. Whether the proposed attack can = achieve its goal depends on which revocation mechanism is employed, and = which certificate or certificates are revoked. The above next never explicitly describes what the actual relevant = attack is, or why exactly =E2=80=9Ctwo trust anchors=E2=80=9D make the = attack back bad and can foil the remediation procedures. It almost = does, but not quite. It needs to say something like, =E2=80=9CThe CA = that logged the bogus certificate may get detected and the certificate = revoked via that trust anchor, but the same certificate remains usable = and un-revoked via the other trust anchor through which the bogus = certificate was not logged or revoked.=E2=80=9D Or something like that. I guess the text in 3.3.1 does get to discussing this =E2=80=9Cmain = point", but only after the reader has waded through the several = paragraphs above, without having (yet) been made aware of the whole = reason for existence of this whole section. It=E2=80=99s probably best = to summarize the attack/implications (and perhaps forward-reference the = extended discussion below) in one quick sentence toward the beginning of = 3.3. > 3.3.1 Revocation of the Bogus Certificate >=20 > If the bogus (EE) certificate is revoked by the CA that issued and = logged it, browsers should treat that certificate as invalid. However, a = browser checking a CRL or OCSP response might not match this revocation = status data against the doppelganger issued by the second CA. This is = because revocation status checking is performed in the context of a = certification path (during path validation). The doppelgangers have = different certification paths and thus the revocation status data for = each might be acquired and managed independently. (RFC 5280 does not = provide implementation guidance for management of revocation data. It is = known that some relying party implementations maintain such information = on a per-certificate path basis, but others might not.) >=20 > [=E2=80=A6] >=20 > ------- >=20 > 3.4 Undetected Compromise of CAs or Logs > =20 > Sections 3.1 and 3.2 examined attacks in the context of non-malicious = and malicious CAs, and benign and misbehaving logs. Another class of = attacks might occur in the context of a non-malicious CA and/or a benign = log. Specifically these CT elements might be compromised and the = compromise might go undetected. Compromise of CAs and logs was noted in = Section 2, as was coercion of a CA. As noted there, a compromised CA is = essentially a malicious CA, and thus the discussions in Section 3.2 are = applicable. The case of an undetected compromise warrants some = additional discussion, since some relying parties may see signed objects = issued by the legitimate (non-malicious) CA, others may see signed = objects from its compromised counterpart, and some may see objects from = both. In the case of a compromised CA or log the adversary is presumed = to have access to the private key used by a CA to sign certificates, or = used by a log to sign SCTs and STHs. Because the compromise is = undetected, there will be no effort by a CA to have its certificate = revoked or by a log to shut down the log. > =20 > =20 > 3.4.1 Compromised CA, Benign Log > =20 > In the case of a compromised (non-malicious) CA, an attacker uses the = purloined private key to generate a bogus certificate (that the = compromised CA would not issue). If this certificate is submitted to a = (benign) log, then it subject to detection by a Monitor, as discussed in = 3.1.1.1. If the bogus certificate is submitted to a misbehaving log, = then an SCT can be generated, but there will be no entry for it, as = discussed in 3.1.1.2. If the bogus certificate is not logged, then there = will be no SCT, and the implications are as described in 3.1.2. =20 > =20 > This sort of attack may be most effective if the CA that is the victim = of the attack has issued a certificate for the targeted Subject. In = this case the bogus certificate will then have the same certification = path as the legitimate certificate, which may help hide the bogus = certificate. However, means of remedying the attack are independent of = this aspect, i.e., revocation can be effected irrespective of whether = the targeted Subject received its certificate from the compromised CA.=20= > =20 > A compromised (non-malicious) CA may be able to revoke the bogus = certificate if it is detected by a Monitor, and the targeted Subject has = been notified. It can do so only when the serial number of the bogus = certificate is made known to this CA. Also, the bogus certificate = cannot have been issued with an Authority Information Access (AIA) or = CRL Distribution Point (CRL DP) extension that enables only the = malicious twin to revoke the certificate. (The AIA extension in the = bogus certificate could be used to direct relying parties to an OCSP = server controlled by the malicious twin. The CRL DP extension could be = used to direct relying parties to a CRL controlled by the malicious = twin.) If the bogus certificate contains either extension, the = compromised CA cannot effectively revoke it, but it will also be = apparent that the bogus certificate It=E2=80=99s probably worth clarifying exactly how this is = =E2=80=9Capparent=E2=80=9D and to whom. e.g., something like, =E2=80=9Cal= so be apparent to anyone who checks the certificate against the = uncompromised log and finds the SCT missing=E2=80=9D, assuming that=E2=80=99= s what you had in mind. Inferable, but just best to be explicit. > was issued by the malicious twin. (The AIA or CRL DP extension would = provide a strong indication that the bogus certificate was not generated = by the compromised CA itself.) > =20 > If the serial number of the bogus certificate is the same as for a = valid, not-expired certificate issued by the CA (to the target or to = another Subject), then revocation poses a problem. This is because = revocation of the bogus nitpick: extra space between =E2=80=9Crevocation=E2=80=9D and =E2=80=9Cpos= es" > certificate will also invalidate a legitimate certificate. This = problem may cause the compromised CA to delay revocation, thus allowing = the bogus certificate to remain a danger for a longer time.=20 Wait - isn=E2=80=99t the basic assumption of this section that the = CA=E2=80=99s private key has been stolen? And in that case, shouldn=E2=80= =99t the CA=E2=80=99s public key itself be revoked and considered = untrustworthy, together with any certificate the CA has signed in the = past (or signs in the future) with that key? It seems like even if = there is a =E2=80=9Clegitimate certificate=E2=80=9D that was signed by = the same key, it should get revoked too! If that=E2=80=99s not the = case, then the =E2=80=9Cwhy=E2=80=9D needs to be clarified in the above = paragraph, and it needs to be stated in what situations a relying party = may still deem the =E2=80=9Clegitimate certificate=E2=80=9D trustworthy = despite being signed by a compromised CA key. > 3.4.2 Benign CA, Compromised Log > =20 > A benign CA does not issue bogus certificates, except as a result of = an accident or attack. So, in normal operation, it is not clear what = behavior by a compromised log would yield an attack. If a bogus = certificate is issued by a benign CA (under these circumstances) is = submitted to a compromised (non-malicious) log, then both an SCT and a = log entry will be created. Again, it is not clear what additional = adverse actions the compromised log would perform to further an attack = on CT. Although not quite as worrisome as other attacks in practice, there is a = DoS/censorship attack opportunity through equivocation here that might = be worth mentioning. In particular, the compromised log could provide = an SCT for a legitimate cert, and include the cert in a version of the = log it shows most people, but then the compromised log server (or an = evil twin of it) could send targeted relying parties a different log = history that doesn=E2=80=99t include the legitimate cert. As a result, = a web browser run by a targeted user will find the cert missing from the = log and inform the user that the web site may be insecure/compromised, = thus making the user (falsely) think the web site is broken rather than = the log server. =20 Of course, if the targeted user=E2=80=99s web browser can and does = gossip STHs with benign CT servers, the discrepancy between the log = server=E2=80=99s two histories will be detectable, and it will become = known that the log server is compromised. However, if the user=E2=80=99s = web browser is unable to gossip STHs with benign CT servers (e.g., = because the only trusted auditor(s) are blocked), or if the browser is = unwilling to gossip STHs for privacy reasons, or just doesn=E2=80=99t = want the state/storage costs of tracking and gossiping all = log-servers=E2=80=99 STH histories, then the attack might go undetected = and the user might persistently think the web site itself is compromised = or just broken. This might actually be a behavior desired by the = attacker (effectively block the website but make the user think it=E2=80=99= s the website=E2=80=99s fault) in some state-censorship type scenarios. > 3.4.3 Compromised CA, Compromised Log > =20 > As noted in 3.4.1, an evil twin CA may issue a bogus certificate that = contains the same Subject name as a legitimate certificate issued by the = compromised CA. Alternatively, the bogus certificate may contain a = different name but reuse a serial number from a valid, not revoked = certificate issued by that CA.=20 > =20 > The evil twin CA might submit a bogus certificate to the evil twin of = a compromised log. The operator of the evil I would make it explicit here that the =E2=80=9Cevil twin CA=E2=80=9D = and the =E2=80=9Cevil twin of a compromised log=E2=80=9D are very likely = to be one and the same, i.e., just the attacker himself. Perhaps just = =E2=80=9C=E2=80=A6of a compromised log (which may be the same = attacker)." > twin log can use the purloined private key to generate SCTs for = certificates that have not been logged by its legitimate counterpart. = These SCTs will appear valid relative to the public key associated with = the legitimate log. However, an STH issued by the legitimate log will = not correspond to a tree containing these SCTs. Thus thorough checking = of the SCTs issued by the evil twin log will identify this discrepancy.=20= "Thorough checking" by whom, against what reference point? Here it is = important to bring out the question (again) of whether the relying party = or parties targeted with this attack can, or do, gossip with = uncompromised CT entities in order to be able to do that cross-checking. = If the compromised CA and compromised server are giving those bad certs = and bad SCTs to a large body of users, at least some of whom check STH = inclusion proofs and gossip regularly with uncompromised CT log servers, = auditors, or monitors, then they will likely be able to notice the = discrepancy fairly quickly. However, if the evil twin CA+log is = attacking only a few users in a much more targeted fashion, and is in = sufficient control of the target users=E2=80=99 external connectivity to = prevent them from gossiping with legitimate CT parties (or if the = attacker simply happens to know that those users are running software = that disable gossip for privacy reasons), then no one will ever have the = opportunity to notice the discrepancy. I think this really needs to be = made explicit. =20 > An Auditor checking for log consistency might conclude that the = compromised log is acting maliciously, and is presenting a split view to = its clients. How does this Auditor actually obtain both =E2=80=9Cviews=E2=80=9D of = the compromised log? If the Auditor is obtaining log records directly = from the compromised log server, then presumably the log server will = send it only one of the two views. (Legitimate Auditors can be deceived = through equivocation just as easily as clients!) This text needs to = specify under what conditions the Auditor can notice the discrepancy: = e.g., if it obtains one view from the log server and learns about a = different view via gossip with other Auditors, Monitors, and/or relying = parties that can and choose to gossip with it. > In this fashion the compromised log may be shunned and forced to shut = down. However, if an attacker targets a set of TLS clients that do not = have access to the legitimate log, they may not be able to detect this = inconsistency. In this case CT would need to rely on a distributed = gossiping audit mechanism to detect the compromise (see Section 5.6). > =20 > In general, this sort of attack is analogous to a malicious CA = creating a bogus certificate and receiving an SCT (with no log entry) = from a misbehaving log (Section 4.2.1.2). The lack of a log entry = prevents detection of the bogus certificate by Monitors, and the = presence of the SCT prevents rejection by a CT-aware browser that = accepts SCTs from the compromised log. Cheers Bryan >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans = --Apple-Mail=_7C90EF64-D108-44FB-9E6A-741154FE688D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Stephen,

Finally catching up on the latest version of your new threat = analysis text...

On Apr 14, 2016, at 3:55 PM, Stephen Kent <kent@bbn.com> wrote:
3.2.1.1.1. = Self-monitoring Subject

 

< add a second paragraph>

 

   A malicious CA might revoke a bogus = certificate to avoid having browser 
   = vendors take punitive action against the CA and/or to persuade them to = not 
   enter the bogus certificate on a = vendor-maintained blacklist. However, the CA 
   = might provide a =E2=80=9Cgood=E2=80=9D OCSP response (from a server it = operates) to a targeted 
   = user (browser instance) as a way to circumvent the remediation nominally = offered 
   by revocation. No component of CT is tasked with = detecting this sort of misbehavior 
   = by a CA. (The misbehavior is analogous to a log offering split views to = different 
   clients. The Audit element of CT is tasked with = detecting this sort of attack.)

Just a = nitpick: in the parenthetical about =E2=80=9Canalogous to a log offering = split view", may be worth adding a forward-reference to the text below = (or just the words =E2=80=9Cdescribed below=E2=80=9D) containing the = detailed discussion of that class of attack?

3.3 = Malicious, Colluding CAs

Section 3.2 = examined attacks in which a single CA might issue a bogus certificate. = There is also the potential that two or more CAs might collude to issue = a bogus certificate in a fashion designed to foil the remediation (but = not detection) safeguards envisioned by CT. Their goal would be trick a = CT-aware browser into accepting a bogus certificate because it was = accompanied by a valid SCT, while evading certificate revocation status = indications. This section explores such scenarios.

In this = attack two CAs that do not share a common path to a trust anchor, = collude to create a =E2=80=9Cdoppelganger=E2=80=9D (bogus) EE = certificate. The attack need not be initiated by trust anchors; any = subordinate pair of (not name-constrained) CAs can effect this attack = without the knowledge of superiors CAs (which are presumed to be = benign). The two CAs must have the same Subject name and the same public = key for the attack. (RFC 5280 doe not explicitly preclude the creation = of two CAs with the same name, so long as the parent CAs are distinct. =

I agree with = David Cooper that describing this as =E2=80=9Ctwo CAs=E2=80=9D is rather = strange given the assumption that they have =E2=80=9Cthe same Subject = name and public key=E2=80=9D.  I would call that =E2=80=9COne = Malicious CA with Two Certificate Chains=E2=80=9D or something like = that.

Requirements = for Subject name uniqueness apply individually to each CA but not across = CA boundaries, as per Section 4.2.1.6. However, the Security = Considerations section of RFC 5280 warns that name collisions could = cause security problems.) 

Because the = two CAs have the same name and make use of the same key, each can issue = the (bogus) doppelganger certificates. One of the CAs would log the = certificate and acquire an SCT for it, while the other would not. 

Because the = bogus certificate is logged, it is subject to detection as such by a = Monitor. Once the bogus certificate is detected it is anticipated that = action will be taken to render it invalid. The bogus certificate itself = might be revoked by the CA that issued and logged it, an action that = masks the malicious intent of that CA. A browser vendor might add the = bogus certificate to a blacklist maintained by the vendor, e.g., because = the CA failed to revoke the bogus certificate. 

If the CA = that logged the bogus certificate is suspected of being malicious, e.g., = because it has a history of using bogus certificates, the certificate of = that CA might itself be revoked. This revocation might be effected by = the parent of that CA (which is not complicit), or by a browser vendor = using a blacklist. Whether the proposed attack can achieve its goal = depends on which revocation mechanism is employed, and which certificate = or certificates are revoked.

The = above next never explicitly describes what the actual relevant attack = is, or why exactly =E2=80=9Ctwo trust anchors=E2=80=9D make the attack = back bad and can foil the remediation procedures.  It almost does, = but not quite.  It needs to say something like, =E2=80=9CThe CA = that logged the bogus certificate may get detected and the certificate = revoked via that trust anchor, but the same certificate remains usable = and un-revoked via the other trust anchor through which the bogus = certificate was not logged or revoked.=E2=80=9D  Or something like = that.

I guess the text in 3.3.1 does = get to discussing this =E2=80=9Cmain point", but only after the reader = has waded through the several paragraphs above, without having (yet) = been made aware of the whole reason for existence of this whole section. =  It=E2=80=99s probably best to summarize the attack/implications = (and perhaps forward-reference the extended discussion below) in one = quick sentence toward the beginning of 3.3.

3.3.1 Revocation of the Bogus Certificate

If the bogus = (EE) certificate is revoked by the CA that issued and logged it, = browsers should treat that certificate as invalid. However, a browser = checking a CRL or OCSP response might not match this revocation status = data against the doppelganger issued by the second CA. This is because = revocation status checking is performed in the context of a = certification path (during path validation). The doppelgangers have = different certification paths and thus the revocation status data for = each might be acquired and managed independently. (RFC 5280 does not = provide implementation guidance for management of revocation data. It is = known that some relying party implementations maintain such information = on a per-certificate path basis, but others might not.)

[=E2=80=A6]

-------

3.4 = Undetected Compromise of CAs or Logs
 
Sections 3.1 and 3.2 examined attacks in the context of = non-malicious and malicious CAs, and benign and misbehaving logs. = Another class of attacks might occur in the context of a non-malicious = CA and/or a benign log. Specifically these CT elements might be = compromised and the compromise might go undetected. Compromise of CAs = and logs was noted in Section 2, as was coercion of a CA. As noted = there, a compromised CA is essentially a malicious CA, and thus the = discussions in Section 3.2 are applicable. The case of an undetected = compromise warrants some additional discussion, since some relying = parties may see signed objects issued by the legitimate (non-malicious) = CA, others may see signed objects from its compromised counterpart, and = some may see objects from both. In the case of a compromised CA or log = the adversary is presumed to have access to the private key used by a CA = to sign certificates, or used by a log to sign SCTs and STHs. Because = the compromise is undetected, there will be no effort by a CA to have = its certificate revoked or by a log to shut down the log.
 
 
3.4.1 Compromised CA, Benign Log
 
In the case of a compromised (non-malicious) CA, an attacker = uses the purloined private key to generate a bogus certificate (that the = compromised CA would not issue). If this certificate is submitted to a = (benign) log, then it subject to detection by a Monitor, as discussed in = 3.1.1.1. If the bogus certificate is submitted to a misbehaving log, = then an SCT can be generated, but there will be no entry for it, as = discussed in 3.1.1.2. If the bogus certificate is not logged, then there = will be no SCT, and the implications are as described in 3.1.2.  
 
This sort of attack may be most effective if the CA that is = the victim of the attack has issued  a certificate for = the targeted Subject. In this case the bogus certificate will then have = the same certification path as the legitimate certificate, which may = help hide the bogus certificate. However, means of remedying the attack = are independent of this aspect, i.e., revocation can  be effected = irrespective of whether the targeted Subject received its certificate = from the compromised CA. 
 
A compromised (non-malicious) CA may be able to revoke the = bogus certificate if it is detected by a Monitor, and the targeted = Subject has been notified. It can do so only when the serial number of = the bogus certificate is made known to this CA. Also, the bogus = certificate  cannot have been = issued with an Authority Information Access (AIA) or CRL Distribution = Point (CRL DP) extension that enables only the malicious twin to revoke = the certificate. (The AIA extension in the bogus certificate could be = used to direct relying parties to an OCSP server controlled by the = malicious twin. The CRL DP extension could be used to direct relying = parties to a CRL controlled by the malicious twin.)  If the bogus certificate contains either = extension, the compromised CA cannot effectively revoke it, but it will = also be apparent that the bogus certificate =

It=E2=80=99s = probably worth clarifying exactly how this is =E2=80=9Capparent=E2=80=9D = and to whom.  e.g., something like, =E2=80=9Calso be apparent to = anyone who checks the certificate against the uncompromised log and = finds the SCT missing=E2=80=9D, assuming that=E2=80=99s what you had in = mind.  Inferable, but just best to be explicit.

was issued by the malicious twin. (The AIA or CRL DP = extension would provide a strong indication that the bogus certificate = was not generated by the compromised CA itself.)
 
If the serial number of the bogus certificate is the same as = for a valid, not-expired certificate issued by the CA (to the target or = to another Subject), then revocation  poses a problem. = This is because revocation of the = bogus

nitpick: = extra space between =E2=80=9Crevocation=E2=80=9D and =E2=80=9Cposes"
=
certificate will also invalidate a legitimate certificate. = This problem may cause the compromised CA to delay revocation, thus = allowing the bogus certificate to remain a danger for a longer = time. 

Wait - isn=E2=80=99t the basic assumption of = this section that the CA=E2=80=99s private key has been stolen? =  And in that case, shouldn=E2=80=99t the CA=E2=80=99s public key = itself be revoked and considered untrustworthy, together with any = certificate the CA has signed in the past (or signs in the future) with = that key?  It seems like even if there is a =E2=80=9Clegitimate = certificate=E2=80=9D that was signed by the same key, it should get = revoked too!  If that=E2=80=99s not the case, then the =E2=80=9Cwhy=E2= =80=9D needs to be clarified in the above paragraph, and it needs to be = stated in what situations a relying party may still deem the = =E2=80=9Clegitimate certificate=E2=80=9D trustworthy despite being = signed by a compromised CA key.

3.4.2 Benign CA, Compromised Log
 
A benign CA does not issue bogus certificates, except as a = result of an accident or attack. So, in normal operation, it is not = clear what behavior by a compromised log would yield an attack. If a = bogus certificate is issued by a benign CA (under these circumstances) = is submitted to a compromised (non-malicious) log, then both an SCT and = a log entry will be created. Again, it is not clear what additional = adverse actions the compromised log would perform to further an attack = on CT.

Although = not quite as worrisome as other attacks in practice, there is a = DoS/censorship attack opportunity through equivocation here that might = be worth mentioning.  In particular, the compromised log could = provide an SCT for a legitimate cert, and include the cert in a version = of the log it shows most people, but then the compromised log server (or = an evil twin of it) could send targeted relying parties a different log = history that doesn=E2=80=99t include the legitimate cert.  As a = result, a web browser run by a targeted user will find the cert missing = from the log and inform the user that the web site may be = insecure/compromised, thus making the user (falsely) think the web site = is broken rather than the log server.  

Of course, if the targeted user=E2=80=99s web = browser can and does gossip STHs with benign CT servers, the discrepancy = between the log server=E2=80=99s two histories will be detectable, and = it will become known that the log server is compromised.  However, = if the user=E2=80=99s web browser is unable to gossip STHs with benign = CT servers (e.g., because the only trusted auditor(s) are blocked), or = if the browser is unwilling to gossip STHs for privacy reasons, or just = doesn=E2=80=99t want the state/storage costs of tracking and gossiping = all log-servers=E2=80=99 STH histories, then the attack might go = undetected and the user might persistently think the web site itself is = compromised or just broken.  This might actually be a behavior = desired by the attacker (effectively block the website but make the user = think it=E2=80=99s the website=E2=80=99s fault) in some state-censorship = type scenarios.

3.4.3 = Compromised CA, Compromised Log
 
As noted in 3.4.1, an evil twin CA may issue a bogus = certificate that contains the same Subject name as a legitimate = certificate issued by the compromised CA. Alternatively, the bogus = certificate may contain a different name but reuse a serial number from = a valid, not revoked certificate issued by that CA. 
 
The evil twin CA might submit a bogus certificate to the evil = twin of a compromised log. The operator of the evil =

I would make it = explicit here that the =E2=80=9Cevil twin CA=E2=80=9D and the =E2=80=9Cevi= l twin of a compromised log=E2=80=9D are very likely to be one and the = same, i.e., just the attacker himself.  Perhaps just =E2=80=9C=E2=80=A6= of a compromised log (which may be the same attacker)."

twin log can use the purloined private key to generate SCTs = for certificates that have not been logged by its legitimate = counterpart. These SCTs will appear valid relative to the public key = associated with the legitimate log. However, an STH issued by the = legitimate log will not correspond to a tree containing these SCTs. Thus = thorough checking of the SCTs issued by the evil twin log will identify = this discrepancy. 

"Thorough checking" by whom, against what = reference point?  Here it is important to bring out the question = (again) of whether the relying party or parties targeted with this = attack can, or do, gossip with uncompromised CT entities in order to be = able to do that cross-checking.  If the compromised CA and = compromised server are giving those bad certs and bad SCTs to a large = body of users, at least some of whom check STH inclusion proofs and = gossip regularly with uncompromised CT log servers, auditors, or = monitors, then they will likely be able to notice the discrepancy fairly = quickly.  However, if the evil twin CA+log is attacking only a few = users in a much more targeted fashion, and is in sufficient control of = the target users=E2=80=99 external connectivity to prevent them from = gossiping with legitimate CT parties (or if the attacker simply happens = to know that those users are running software that disable gossip for = privacy reasons), then no one will ever have the opportunity to notice = the discrepancy.  I think this really needs to be made = explicit.
 
An Auditor = checking for log consistency might conclude that the compromised log is = acting maliciously, and is presenting a split view to its clients. =

How does this = Auditor actually obtain both =E2=80=9Cviews=E2=80=9D of the compromised = log?  If the Auditor is obtaining log records directly from the = compromised log server, then presumably the log server will send it only = one of the two views.  (Legitimate Auditors can be deceived through = equivocation just as easily as clients!)  This text needs to = specify under what conditions the Auditor can notice the discrepancy: = e.g., if it obtains one view from the log server and learns about a = different view via gossip with other Auditors, Monitors, and/or relying = parties that can and choose to gossip with it.

In this fashion the compromised log may be shunned and forced = to shut down. However, if an attacker targets a set of TLS clients that = do not have access to the legitimate log, they may not be able to detect = this inconsistency. In this case CT would need to rely on a distributed = gossiping audit mechanism to detect the compromise (see Section = 5.6).
 
In general, this sort of attack is analogous to a malicious = CA creating a bogus certificate and receiving an SCT (with no log entry) = from a misbehaving log (Section 4.2.1.2). The lack of a log entry = prevents detection of the bogus certificate by Monitors, and the = presence of the SCT prevents rejection by a CT-aware browser that = accepts SCTs from the compromised log.

Cheers
Bryan


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

= --Apple-Mail=_7C90EF64-D108-44FB-9E6A-741154FE688D-- --Apple-Mail=_FAEBAD9A-961D-4266-97F3-6A7FB7B5197C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjA1MTkxNDQzNThaMCMGCSqGSIb3DQEJBDEWBBTc/c9ZfMQoH9VjtHSeXdW7XG+iajCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAMdM/sGhSagnjsKTmmDV222h44wfE++MoVc2ukPJLRgJkhXdTBHt3Sab7HppHbgrz d7jKS6LVCeO75Je4tzGYu4g6TnE6D033HrnJaIzrrpE/NpcIUCm8NAW2SzlvjGyqaf6IuEyG80ur ELHIQW1wiMgTK/JYberVw3D/r7j9wCUPy0XqrkyinLFymRiHjn6NEBtBcMHJGcdQZtn5RjDdnRS0 sqnHS0A6YcGh8rTMJ/N93lrZRbkQJwQQPJC0VODvMl1h+EfwpnEzEKYsJ6FRZxAlMnC8ormyyqCN LTd7gDZ4TJahreLgsv2hRaMAvFTRdcQzLDws6J3koadGSapFDQAAAAAAAA== --Apple-Mail=_FAEBAD9A-961D-4266-97F3-6A7FB7B5197C-- From nobody Thu May 19 07:57:35 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABDC12D103 for ; Thu, 19 May 2016 07:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nordu.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fI8EjbtZafMD for ; Thu, 19 May 2016 07:57:20 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAF8012D189 for ; Thu, 19 May 2016 07:57:10 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id u4JEv5FR000895 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 May 2016 16:57:05 +0200 Received: from kerio.nordu.net (kerio.nordu.net [109.105.113.41]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id u4JEv0Kq022978 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 May 2016 14:57:03 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1463669824; bh=OBmAl9RTgcBzm8DQjAq4/LOb052KwjCs0v70cqn+Ypw=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=Zh+62HL9KnwIxYNvVwVgrGCY4rI928qa9YOoz0pAd3KVh4nlNkJ5spccmAtV6hXhx Q7mf2nOuzuPtl/ROe66pRD2ZciOQi0AOM1dzcGmxBKwY40V1+G7h60Ly/UdL4OnORQ AK6r/gHGpUMptPEJWl/SIFMJpG1pEH8m50yalVJE= X-Footer: bm9yZHUubmV0 Received: from flogsta ([193.10.5.129]) (authenticated user linus@nordu.net) by kerio.nordu.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Thu, 19 May 2016 16:56:58 +0200 From: Linus Nordberg To: Ben Laurie Organization: NORDUnet A/S References: <87wpn9322u.fsf@alice.fifthhorseman.net> <87lh37mj2m.fsf@nordberg.se> Date: Thu, 19 May 2016 16:56:55 +0200 In-Reply-To: (Ben Laurie's message of "Wed, 18 May 2016 18:30:37 +0100") Message-ID: <874m9uf64o.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.113.41; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aQUeV54t - 14b7f9f024c6 - 20160519 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter02.sunet.se: 109.105.113.41 is neither permitted nor denied by domain linus@nordu.net) receiver=e-mailfilter02.sunet.se; client-ip=109.105.113.41; envelope-from=; helo=smtp1.nordu.net; identity=mailfrom Archived-At: Cc: "trans@ietf.org" , Daniel Kahn Gillmor Subject: Re: [Trans] evaluating an SCT in the absence of the cert's issuer key X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 14:57:23 -0000 Ben Laurie wrote Wed, 18 May 2016 18:30:37 +0100: | On 18 May 2016 at 17:23, Linus Nordberg wrote: | > Ben Laurie wrote | > Fri, 13 May 2016 15:56:44 +0100: | > | > | Actually, it seems to me that the simplest answer is to allow lookups | > | in logs based on SCT alone. Then the SCT can be validated using the | > | retrieved chain. | > | > That seems odd. From a logs point of view, an SCT is not a persistent | > object. | > | > I don't know about other implementations but catlfish would not be able | > to efficiently find an entry in the database given only an SCT. | | Are you saying there's some technical barrier to doing this, or just | that as it stands you wouldn't be able to? I was being inprecise. I should have said that it would require some redesign. | It seems to me that the log could easily save SCTs it issued alongside | the cert chains it issued them for. All SCT's for every chain, I presume, if there's going to be any point in offering a lookup with an SCT as input? This would complicate things at least in our design. I'm sure it could be solved at the price of more complexity. | And that it could easily create an index based on those SCTs. | Note that 6962-bis already requires you to return SCTs in some lookups... You meen get-entries? I don't see how that's relevant. An SCT can be generated given the data in leaf_input. No need to store it, unless you wanted to for caching of course (we do that on frontend nodes). There's a big difference between doing this and indexing on SCT's though. From nobody Thu May 19 10:07:35 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D4C12DB0F for ; Thu, 19 May 2016 10:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNW_QuOqc5XU for ; Thu, 19 May 2016 10:07:32 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2609C12DB27 for ; Thu, 19 May 2016 10:07:03 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id x189so84477011ywe.3 for ; Thu, 19 May 2016 10:07:03 -0700 (PDT) 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; bh=DQAm28wD9aaoQtuFPnzQftv7ZClGIZ13vlvOsC5+I0o=; b=oDsfkbaPiwx1j6T6w9WgZEw5d3Kgucf3K3u9uqQT/tOFDe3RRMIm44KywgPCoyODwA 8/yzOzjLjHLs+hOuuwezhSYNoY44EhNjNmKZWhVfB5OgKHVTSVSUoIvGfiGSUNCYF28A 4rPYXjaR7O0EBT6iUagyjvq6jHlbqkJE1C4qcjnua8juNPy4p+Sf7xr8SJNU+2g8jX8u 5kLxYimXXlGFNkFaBVEP0p4GHTeWpOyKZbnudbql4wH/OGvt88C6h9Jdr5TmZJGaEL4R eOn/lDEO9EJr+z45NAqAyF5mJv9y8mctJLpbtYrvJO+1nFonJqzyfH/Fejuv83nkSTQG 6QEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DQAm28wD9aaoQtuFPnzQftv7ZClGIZ13vlvOsC5+I0o=; b=B9Ov4zg5sUSqHC2Bo28734YD4t7WksWR7LWZq92CIvStg8UcMa0/yBYzDT28+9iG4F ntceMEoQmkfyyPd/qu0+QBB/IbU43hQth4t4X4zGT8X5v4hZnufQFo1QiLhtLu6yZKhf eF/Qocglg7kZeQvW2FLi5a0xVFYbQqFfPiiep1Di4K8WysJZpNQLprzonFQ3P3vAC3qL QSNMzpARVsPGokscQ2OepTL4ytfbrsJXgudUagLH5y72Y/ZGmibSMBNR6YEd1z0VKOyQ O7C3s+bnJRhdlkamNXGs9y+9iTXknru8M1qWwYi4b6JAh5fNwnBuV3Zb8F7dDmJQ41sE I7YA== X-Gm-Message-State: AOPr4FVBLnp1dR60MvhKgX0o950v9+lHjnP7y3J3Dh7k0PCyfsy4xvA0jibOCGK0Y7REwNWWpgL9V2wtkm7sMLge X-Received: by 10.129.92.4 with SMTP id q4mr7781638ywb.156.1463677622333; Thu, 19 May 2016 10:07:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.223.69 with HTTP; Thu, 19 May 2016 10:07:01 -0700 (PDT) In-Reply-To: <874m9uf64o.fsf@nordberg.se> References: <87wpn9322u.fsf@alice.fifthhorseman.net> <87lh37mj2m.fsf@nordberg.se> <874m9uf64o.fsf@nordberg.se> From: Eran Messeri Date: Thu, 19 May 2016 18:07:01 +0100 Message-ID: To: Linus Nordberg Content-Type: multipart/alternative; boundary=001a114d9344bf074e0533350049 Archived-At: Cc: "trans@ietf.org" , Ben Laurie , Daniel Kahn Gillmor Subject: Re: [Trans] evaluating an SCT in the absence of the cert's issuer key X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 17:07:34 -0000 --001a114d9344bf074e0533350049 Content-Type: text/plain; charset=UTF-8 Back to dkg's original question, I'd suggest gossiping the MerkleTreeLeaf (RFC6962) / TransItem containing TimestampedCertificateEntryDataV2 (RFC6962-bis). For each of the protocols, that's the data structure necessary to validate the signature in the SCT *and* to audit the log (because these data structures themselves are not signed they cannot be the only thing that's gossiped). IMHO gossiping only the SCT is not very useful, even if logs offer get-entry-by-sct: * A log could deny / drop such a request (as it's not signed), in which case the client's recourse is a download of the entire log. * Without the data covered by the signature, there's no meaningful auditing: the entity holding the SCT does not know which certificate hasn't been incorporated into the log. Re get-entry-by-sct, as it does complicate implementation, one option is to make this API optional (which is a particularly viable approach as it can be implemented by a log mirror based on data from a log that does not implement it). Eran On Thu, May 19, 2016 at 3:56 PM, Linus Nordberg wrote: > Ben Laurie wrote > Wed, 18 May 2016 18:30:37 +0100: > > | On 18 May 2016 at 17:23, Linus Nordberg wrote: > | > Ben Laurie wrote > | > Fri, 13 May 2016 15:56:44 +0100: > | > > | > | Actually, it seems to me that the simplest answer is to allow lookups > | > | in logs based on SCT alone. Then the SCT can be validated using the > | > | retrieved chain. > | > > | > That seems odd. From a logs point of view, an SCT is not a persistent > | > object. > | > > | > I don't know about other implementations but catlfish would not be able > | > to efficiently find an entry in the database given only an SCT. > | > | Are you saying there's some technical barrier to doing this, or just > | that as it stands you wouldn't be able to? > > I was being inprecise. I should have said that it would require some > redesign. > > > | It seems to me that the log could easily save SCTs it issued alongside > | the cert chains it issued them for. > > All SCT's for every chain, I presume, if there's going to be any point > in offering a lookup with an SCT as input? This would complicate things > at least in our design. I'm sure it could be solved at the price of more > complexity. > > > | And that it could easily create an index based on those SCTs. > > > | Note that 6962-bis already requires you to return SCTs in some lookups... > > You meen get-entries? I don't see how that's relevant. An SCT can be > generated given the data in leaf_input. No need to store it, unless you > wanted to for caching of course (we do that on frontend nodes). There's > a big difference between doing this and indexing on SCT's though. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a114d9344bf074e0533350049 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Back to dkg's original question, I'd suggest gossi= ping the MerkleTreeLeaf (RFC6962) / TransItem containing=C2=A0TimestampedCe= rtificateEntryDataV2 (RFC6962-bis).

For each of the protocols,= that's the data structure necessary to validate the signature in the S= CT *and* to audit the log (because these data structures themselves are not= signed they cannot be the only thing that's gossiped).

<= /div>
IMHO gossiping only the SCT is not very useful, even if logs offe= r get-entry-by-sct:=C2=A0
* A log could deny / drop such a reques= t (as it's not signed), in which case the client's recourse is a do= wnload of the entire log.
* Without the data covered by the s= ignature, there's no meaningful auditing: the entity holding the SCT do= es not know which certificate hasn't been incorporated into the log.

Re get-entry-by-sct, as it does complicate implement= ation, one option is to make this API optional (which is a particularly via= ble approach as it can be implemented by a log mirror based on data from a = log that does not implement it).

Eran

On Thu, May 19, 2016 at 3:56 PM, Linus Nordberg <linus@nordu.net><= /span> wrote:
Ben Laurie <benl@google.com> wrote
Wed, 18 May 2016 18:30:37 +0100:

| On 18 May 2016 at 17:23, Linus Nordberg <linus@nordu.net> wrote:
| > Ben Laurie <benl@google.com> wrote
| > Fri, 13 May 2016 15:56:44 +0100:
| >
| > | Actually, it seems to me that the simplest answer is to allow look= ups
| > | in logs based on SCT alone. Then the SCT can be validated using th= e
| > | retrieved chain.
| >
| > That seems odd. From a logs point of view, an SCT is not a persisten= t
| > object.
| >
| > I don't know about other implementations but catlfish would not = be able
| > to efficiently find an entry in the database given only an SCT.
|
| Are you saying there's some technical barrier to doing this, or just<= br> | that as it stands you wouldn't be able to?

I was being inprecise. I should have said that it would require some=
redesign.


| It seems to me that the log could easily save SCTs it issued alongside | the cert chains it issued them for.

All SCT's for every chain, I presume, if there's going to be= any point
in offering a lookup with an SCT as input? This would complicate things
at least in our design. I'm sure it could be solved at the price of mor= e
complexity.


| And that it could easily create an index based on those SCTs.


| Note that 6962-bis already requires you to return SCTs in some lookups...=

You meen get-entries? I don't see how that's relevant. An SC= T can be
generated given the data in leaf_input. No need to store it, unless you
wanted to for caching of course (we do that on frontend nodes). There's=
a big difference between doing this and indexing on SCT's though.

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

--001a114d9344bf074e0533350049-- From nobody Fri May 20 11:12:04 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBFD12B01C for ; Fri, 20 May 2016 11:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.625 X-Spam-Level: X-Spam-Status: No, score=-4.625 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, HTML_FONT_SIZE_HUGE=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnACta6v_a10 for ; Fri, 20 May 2016 11:11:59 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF3D12D5DF for ; Fri, 20 May 2016 11:11:58 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:49529 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1b3otu-0009pj-QJ; Fri, 20 May 2016 14:11:55 -0400 To: Ben Laurie , "trans@ietf.org" From: Stephen Kent Message-ID: <573F536A.3070303@bbn.com> Date: Fri, 20 May 2016 14:11:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------090005070301050202000600" Archived-At: Subject: [Trans] responses to your threat analysis review comments X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 18:12:03 -0000 This is a multi-part message in MIME format. --------------090005070301050202000600 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Ben, Thanks for taking the time to perform a thorough review of this doc. I have made a number of edits in response to your comments, as described below. Page 3 First para ends with a spurious ")". *Fixed* There are two classes of beneficiaries of CT: certificate Subjects and relying parties (RPs). In the initial focus context of CT, the Web PKI, Subjects are web sites and RPs are browsers employing HTTPS to access these web sites. CAs are also beneficiaries - they get to find out about key loss or abuse of their platform, for example. *Good point. I’ll change the text accordingly.*** it directs a replying party to an OCSP server Should be "relying". *Fixed* Page 4 Finally, if an RP were to check logs for individual certificates, that would disclose to logs the identity of web sites being visited by the RP, a privacy violation. Thus this attack model assumes that RPs will not check log entries. It is not clear that: a)All RPs care about privacy in this respect, *True, but it is still appropriate to note that log checking is a potential privacy violation for those that do perform checks, as DKG noted a while ago.* b)That checking logs is necessarily privacy violating (for example, we've announced an experimental DNS-based protocol for log checking, which we are implementing in Chrome), *The mechanism you describe minimizes the privacy problem, but since it is not part of the standard, it is not appropriate to assume it will be used by all RPs that confirm to the standard.* therefore it seems unwarranted to assume that RPs will not check log entries. *I have modified the sentence a bit to address your comments:* *Thus this attack model does not assume that all RPs will check log entries.*** Page 5 There is no agreed-upon Audit function design for CT at the time of this writing. As a result, the model merely notes where Auditing is needed to detect certain classes of attacks. Section 9.4 of 6962-bis-14 has a comprehensive design for auditing. *I revised the text to note that the audit functions we enumerated in our spec for a CT auditor have now been defined. They don't seem to be “comprehensive” i.e., they don’t detect split log views, so the fact that there additional work on auditing is ongoing also is noted.* Page 6 [ 4] SCT (embedded in pre-cert, if applicable) SCTs are not embedded in pre-certs. *Fixed the legend to refer to certificates, not pre-certificates.* Page 8 Spoofing enables an adversary to acquire information that a TLS-enabled client would not communicate if the client were aware of the spoofing. There are surely many other issues with spoofing - e.g. serving malware. *Fair point. I have revised the text to note delivery of malware, or delivery of misinformation from a website as well.* An adversary may achieve this in various ways, e.g., by causing a user to click on a link to the website, or by manipulation of the DNS response sent to a TLS client. If a link alone works, then the site is not spoofed with a mis-issued certificate, surely? *Good point. I removed the reference to clicking on a bogus link.* Also, MitM is probably the most common attack vector. *Maybe a user in a public WiFi context is susceptible to this sort of attack, but in many contexts a MITM attack is difficult to mount. Nonetheless, I will add MITM as an example here.* The elements of CT may themselves be targets of attacks, as described below. A criminal organization might compromise a CA and cause it to issue bogus certificates, or it may exert influence over a CA (or CA staff) to do so, e.g., through extortion or physical threat. (Even though the CA is not intentionally malicious in this case, the action is equivalent to a malicious CA, hence the use of the term "bogus" here.) A nation state may operate or influence a CA that is part of the large set of "root CAs" in browsers. A CA, acting in this fashion, is termed a "malicious" CA. A nation state also might compromise a CA in another country, to effect issuance of bogus certificates. In this case the (non-malicious) CA, upon detecting the compromise (perhaps because of CT) is expected to work with Subjects to remedy the mis-issuance. There's also social engineering, which is mentioned elsewhere, but I suspect should be here, too. *I added a mention of social engineering here.* It seems unlikely that a compromised, non-malicious, log would... This seems odd - a compromised non-malicious log is effectively uncompromised, isn't it? *If the log’s private key has been stolen so that an adversary can use the key to generate SCTs, then the log is compromised in that sense, even though it is not malicious.* Page 9. CT is not designed to detect and counter this type of locally-authorized interception. Actually CT is designed to detect it but it seems likely that browsers will explicitly ignore it. *I added this text in response to a message from Eran, but I have revised to text to not mention detection._* Page 10. (and elsewhere) is there really any difference between a benign third-part monitor and self-monitoring? Couldn't the doc be simplified by treating them as the same? *The taxonomy adopted for this document distinguishes between benign and malicious versions of CT system elements. When a Subject monitors its own behalf, that distinction does not apply, i.e., a self monitor is always viewed as benign. This drives at least part of the distinction you note.* (A misbehaving log also could create and report entries for bogus certificates that have not been issued by the indicated CA (hereafter called "fake") This is slightly confusing, as on the face of it, the log could not create such a cert, since it doesn't have the CA key. Later wording makes it clear that the idea is that the cert would not, in fact, be signed by a trusted CA. *I don't’ see a need to change the text here since, as you note, the next sentence explains that a fake entry would not be signed by the indicated CA.* 3.1.1.2.1/3.1.1.2.2 Since I think that benign third party and self monitors are essentially the same, it is odd that these two sections differ so much. *They are not the same when the 3^rd party Monitor is malicious, but I agree that there is no significant difference when the 3^rd party Monitor is benign.I consolidated these two sections.* Page 11. Note that independent of any mis-issuance on the part of the CA, a misbehaving Monitor could issue false warnings to a Subject that it protects. These could cause the Subject to report non-existent semantic problems to the issuing CA and cause the CA to do needless investigative work or perhaps incorrectly revoke and re-issue the Subject's certificate. This para is general, rather than to do with the section it is in, and hence should probably be somewhere else. *The paragraph describes a type of behavior by a misbehaving 3^rd party Monitor, so it belongs in a section that has such a title.* However, the CT architecture does not describe how such behavior by browsers can be deployed incrementally throughout the Internet. As a result, this attack model does not assume that browsers will reject a certificate that is not accompanied by an SCT. Given that incremental deployment is already under way, this seems unnecessarily dogmatic. *The text says that if a browser rejects a certificate because it lacks an SCT, then incremental deployment is problematic. Your assertion that CT is being incrementally deployed with respect to browsers is based on behavior that does not cause a certificate to be rejected under these circumstances.But, to make sure the issue is clear, I have revised the text as follows:* ** *However, **the CT architecture does not describe **how CT can be deployed incrementally if browsers reject all certificates not accompanied by an SCT. (A browser might “discriminate” againsuch certificates, e.g. via warnings or other UI signals. Because a user would be free to ignore of override such indications, incremental deployment is possible under these assumptions.) As a result, this attack model does not assume that browsers will reject a certificate that is not accompanied by an SCT.*** Page 13. For example, the CA could make excuses about inadequate proof that the certificate is bogus, or argue that it cannot quickly revoke the certificate because of legal concerns, etc. In this case, the CT mechanisms will have detected mis-issuance, but the information logged by CT does not help remedy the problem. (See Sections 4 and 6.) The logged information clearly _helps_, it just may not be all that is needed. *Fair point. I have modified the text to say “**the information logged by CT may not suffice to remedy the problem.”*** Page 14. 3.2.2.1 is essentially the same as 3.1.1.2, just refer to the previous text? *I could do that, but it’s just one paragraph and I think it’s a bit easier for a reader to see the text in context rather than have to flip back to the earlier section.* Page 15. Their goal would be trick a CT-aware browser into accepting a bogus certificate because it was accompanied by a valid SCT, while evading certificate revocation status indications. This section explores such scenarios. The attack as described only requires colluding CAs in the case where EE certs do not contain links to revocation information. When EE certs do contain such links, the attack described is simply an attack on certificate revocation, regardless of whether one or more CAs might have issued the doppelgangers. In either case, the attack is nothing to do with CT, which does not claim to do anything to help with integrity or correctness of revocation information. *The cited sentence notes that the goal of the attack is to cause a CT-aware browser to accept a certificate that, by CT goals, it ought not. In this sense, the attack is directly relevant to CT. I agree that the attack is one that exploits a residual vulnerability in revocation in general. However, this section describes the impact of that vulnerability in the context of CT, and thus seems relevant to the threat analysis.* Even if the bogus certificates contain an AIA extension pointing to an OCSP server the attack might still succeed. (As noted in the Section 1, RFC 5280 does not mandate inclusion this extension, but its presence is required by CABF requirements.) As noted in Section 3.2.1.1.1, a malicious CA could send a "good" OCSP response to a targeted browser instance, even if other parties are provided with a "revoked" response. Also note that a TLS server can supply an OCSP response to a browser as part of the TLS handshake [RFC6961], if requested by the browser. A TLS server posing as the entity named in the bogus certificate could acquire a "good" OCSP response from the colluding CAs to effect the attack. Only if the browser relies upon a trusted, third-party OCSP responder, one not part of the collusion, would the attack fail. All this is independent of the attack and of CT, and applies generally to revocation. *See my rationale above for inclusion of this discussion.* The analysis above also applies to the use of CRLs to disseminate certificate revocation status data. The doppelganger certificate could contain a CRL distribution point extension instead of an AIA extension. In that case a site supplying CRLs for the colluding CAs could supply different CRLs to different requestors, in an attempt to hide the revocation status of the doppelganger from targeted browsers instances. This is analogous to a split-view attack effected by a CT log. However, as noted in Section 3.2.1.1 and 3.2.1.1.1, no element of CT is responsible for detecting inconsistent reporting of certificate revocation status data. (Monitoring in the CT context tracks log entries made by CAs or Subjects. Auditing is designed to detect misbehavior by logs, not by CAs per se.) Likewise. *Ibid.* Page 20. This will happen only if the log performs syntactic checks in general, and if the log is capable of performing the checks applicable to the submitted (pre-)certificate. Anyone can detect syntactic mis-issuance, the log does not need to do it. *The threat analysis focuses on what the CT system says its elements will do, not what some outside entity not defined by the system might do.* For example: https://crt.sh/?cablint=1+week . Page 21. If the (pre-)certificate is submitted by the non-malicious issuing CA, and if the CA has a record of the certificate content Clearly there is a record in the log! *Good point. I’ve revised the text accordingly.* This analysis suggests that syntactic mis-issuance of a certificate can be avoided by a CA if it makes use of logs that are capable of performing these checks for the types of certificates that are submitted, The CA can obviously perform these checks itself, logs are not special in this regard. *This discussion is addressing the (not uncommon) situation in which a CA fails to perform the appropriate checks.Long ago you noted that this is a persistent problem and used that observation to justify the CT log language that provides leeway for a log to accept any certificate irrespective of whether it meets 5280 or any other certificate syntax criteria. So, it seems a bit disingenuous to suggest that a CA would be relied upon to perform these checks, in general.* Throughout this section there is talk about syntactic checking by logs, which is not a defined function of logs. *Syntax checking was proposed as an optional log function that you and your co-authors rejected. Thus this text notes that IF a log were to perform such checks, certain attacks could be detected on behalf of browsers (which also have a terrible track record of enforcing syntactic rules).* Unfortunately, experience suggests that many browsers do not perform thorough syntactic checks on certificates, and so it seems unlikely that browsers will be a reliable way to detect erroneous certificates. What is unfortunate is that a very large number of extant certs have syntax errors and so browsers can't usefully perform checks. *I see we agree on this aspect of the problem. I am surprised that you noted that CAs could be relied upon to perform syntax checking (your comment above) given the reality that you cited here!* Moreover, a protocol used by a browser to notify a Subject and/or CA of an erroneous certificate represents a DoS potential, and thus may not be appropriate. Subjects are already subject to DoS by virtue of serving web pages. This doesn't seem like a valid concern. *Adding additional DoS opportunities is rarely viewed as a good idea. The text says it “may not be appropriate” and I stand by that.* Such browsers would benefit from having such checks performed by a log and reported in the SCT. Browsers don't need help to perform syntax checks, it just isn't viable to do so. *I have revised the text as follows:* ** *Such browsers might benefit from having syntax checks performed by a log and reported in the SCT, although the pervasive nature of syntactically-defective certificates may limit the utility of such checks.*** Page 26. Thus, for now, CT does not seem to provide a way to remedy this form of attack, even though it provides a basis for detecting such attacks. CT doesn't claim to provide remedies for attacks, just information that reveals them. Once more, you are describing a flaw with the whole system, not a flaw in CT. *You’re right that CT does not claim to remedy attacks; it claims to facilitates remediation. So, I have revised the text as follows:* ** *Thus, for now, CT does not seem to provide a way to facilitate remediation of this form of attack, even though it provides a basis for detecting such attacks.*** Absent a well-defined mechanism that enables Monitors to verify that data from logs are reported in a consistent fashion, CT cannot claim to provide protection against logs that are malicious or may conspire with, or are victims of, attackers effecting certificate mis-issuance. The mechanism needs to protect the privacy of users with respect to which web sites they visit. It needs to scale to accommodate a potentially large number of self-monitoring Subjects and a vast number of browsers, if browsers are part of the mechanism. Even when an Audit mechanism is defined, it will be necessary to describe how the CT system will deal with a misbehaving or compromised log. For example, will there be a mechanism to alert all browsers to reject SCTs issued by such a log? Absent a description of a remediation strategy to deal with misbehaving or compromised logs, CT cannot ensure detection of mis-issuance in a wide range of scenarios. The absence of a standard to do a thing does not make the thing impossible. In practice, none of this actually seems to be a problem, nor in need of standardisation at this time. *6962-bis is targeted as a standard track document. Thus, when one evaluates the CT threat environment we should restrict our attention to what is standardized. We can’t speculate on behavior that MIGHT take place but is not specified in a standard, and cite that as a mitigating factor with respect to an attack or a privacy concern.* --------------090005070301050202000600 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Ben,

Thanks for taking the time to perform a thorough review of this doc.

I have made a number of edits in response to your comments, as described below.

Page 3

 

First para ends with a spurious ")".

 

Fixed

 

There are two classes of beneficiaries of CT: certificate Subjects

  and relying parties (RPs). In the initial focus context of CT, the
  Web PKI, Subjects are web sites and RPs are browsers employing HTTPS
  to access these web sites.

 

CAs are also beneficiaries - they get to find out about key loss or abuse of their platform, for example.

 

Good point. I’ll change the text accordingly.

 

      it directs a replying party to an OCSP

  server


Should be "relying".

 

Fixed

 

Page 4

 

Finally, if an RP were to check logs for
  individual certificates, that would disclose to logs the identity of
  web sites being visited by the RP, a privacy violation. Thus this
  attack model assumes that RPs will not check log entries.

 

It is not clear that:

 

a)      All RPs care about privacy in this respect,

 

True, but it is still appropriate to note that log checking is a potential privacy violation for those that do perform checks, as DKG noted a while ago.

 

b)     That checking logs is necessarily privacy violating (for example, we've announced an experimental DNS-based protocol for log checking, which we are implementing in Chrome),

 

The mechanism you describe minimizes the privacy problem, but since it is not part of the standard, it is not appropriate to assume it will be used by all RPs that confirm to the standard.

 

therefore it seems unwarranted to assume that RPs will not check log entries.

 

I have modified the sentence a bit to address your comments:

 

Thus this attack model does not assume that all RPs will check log entries.

 

 

 

Page 5

 

There is no
  agreed-upon Audit function design for CT at the time of this
  writing. As a result, the model merely notes where Auditing is
  needed to detect certain classes of attacks.


Section 9.4 of 6962-bis-14 has a comprehensive design for auditing.

 

I revised the text to note that the audit functions we enumerated in our spec for a CT auditor have now been defined. They don't seem to be “comprehensive” i.e., they don’t detect split log views, so the fact that there additional work on auditing is ongoing also is noted.

 

 

 

Page 6

 

[ 4] SCT (embedded in pre-cert, if applicable)


SCTs are not embedded in pre-certs.

 

Fixed the legend to refer to certificates, not pre-certificates.

 

Page 8

 

Spoofing
  enables an adversary to acquire information that a TLS-enabled
  client would not communicate if the client were aware of the
  spoofing.


There are surely many other issues with spoofing - e.g. serving malware.

 

Fair point. I have revised the text to note delivery of malware, or delivery of misinformation from a website as well.

 

An adversary
  may achieve this in various ways, e.g., by causing a user to click
  on a link to the website, or by manipulation of the DNS response
  sent to a TLS client.


If a link alone works, then the site is not spoofed with a mis-issued certificate, surely?

 

Good point. I removed the reference to clicking on a bogus link.

 

Also, MitM is probably the most common attack vector.

 

Maybe a user in a public WiFi context is susceptible to this sort of attack, but in many contexts a MITM attack is difficult to mount. Nonetheless, I will add MITM as an example here.

 

The elements of CT may themselves be targets of attacks, as
  described below. A criminal organization might compromise a CA and
  cause it to issue bogus certificates, or it may exert influence over
  a CA (or CA staff) to do so, e.g., through extortion or physical
  threat. (Even though the CA is not intentionally malicious in this
  case, the action is equivalent to a malicious CA, hence the use of
  the term "bogus" here.) A nation state may operate or influence a CA
  that is part of the large set of "root CAs" in browsers. A CA,
  acting in this fashion, is termed a "malicious" CA. A nation state
  also might compromise a CA in another country, to effect issuance of
  bogus certificates. In this case the (non-malicious) CA, upon
  detecting the compromise (perhaps because of CT) is expected to work
  with Subjects to remedy the mis-issuance.

 

There's also social engineering, which is mentioned elsewhere, but I suspect should be here, too.

 

I added a mention of social engineering here.

 

It seems unlikely that a
  compromised, non-malicious, log would...


This seems odd - a compromised non-malicious log is effectively uncompromised, isn't it?

 

If the log’s private key has been stolen so that an adversary can use the key to generate SCTs, then the log is compromised in that sense, even though it is not malicious.

 

Page 9.

 

CT is not designed to
  detect and counter this type of locally-authorized interception.



Actually CT is designed to detect it but it seems likely that browsers will explicitly ignore it.

 

I added this text in response to a message from Eran, but I have revised to text to not mention detection.

 

Page 10.

 

(and elsewhere) is there really any difference between a benign third-part monitor and self-monitoring? Couldn't the doc be simplified by treating them as the same?

 

The taxonomy adopted for this document distinguishes between benign and malicious versions of CT system elements. When a Subject monitors its own behalf, that distinction does not apply, i.e., a self monitor is always viewed as benign. This drives at least part of the distinction you note.

 

(A misbehaving log also could create and report entries
  for bogus certificates that have not been issued by the indicated CA
  (hereafter called "fake")

 

This is slightly confusing, as on the face of it, the log could not create such a cert, since it doesn't have the CA key. Later wording makes it clear that the idea is that the cert would not, in fact, be signed by a trusted CA.

 

I don't’ see a need to change the text here since, as you note, the next sentence explains that a fake entry would not be signed by the indicated CA.

 

3.1.1.2.1/3.1.1.2.2


Since I think that benign third party and self monitors are essentially the same, it is odd that these two sections differ so much.

 

They are not the same when the 3rd party Monitor is malicious, but I agree that there is no significant difference when the 3rd party Monitor is benign.  I consolidated these two sections.

 

Page 11.

 

Note that independent of any mis-issuance on the part of the CA, a
  misbehaving Monitor could issue false warnings to a Subject that it
  protects. These could cause the Subject to report non-existent
  semantic problems to the issuing CA and cause the CA to do needless
  investigative work or perhaps incorrectly revoke and re-issue the
  Subject's certificate.


This para is general, rather than to do with the section it is in, and hence should probably be somewhere else.

 

The paragraph describes a type of behavior by a misbehaving 3rd party Monitor, so it belongs in a section that has such a title.

 

However, the CT architecture does not describe how
  such behavior by browsers can be deployed incrementally throughout
  the Internet. As a result, this attack model does not assume that
  browsers will reject a certificate that is not accompanied by an
  SCT.


Given that incremental deployment is already under way, this seems unnecessarily dogmatic.

 

The text says that if a browser rejects a certificate because it lacks an SCT, then incremental deployment is problematic. Your assertion that CT is being incrementally deployed with respect to browsers is based on behavior that does not cause a certificate to be rejected under these circumstances.  But, to make sure the issue is clear, I have revised the text as follows:

 

However, the CT architecture does not describe how CT can be deployed incrementally if browsers reject all certificates not accompanied by an SCT. (A browser might “discriminate” again  such certificates, e.g. via warnings or other UI signals. Because a user would be free to ignore of override such indications, incremental deployment is possible under these assumptions.) As a result, this attack model does not assume that browsers will reject a certificate that is not accompanied by an SCT.

 

Page 13.

 

For example, the CA could make excuses about inadequate
  proof that the certificate is bogus, or argue that it cannot quickly
  revoke the certificate because of legal concerns, etc. In this case,
  the CT mechanisms will have detected mis-issuance, but the
  information logged by CT does not help remedy the problem. (See
  Sections 4 and 6.)


The logged information clearly _helps_, it just may not be all that is needed.

 

Fair point. I have modified the text to say “the information logged by CT may not suffice to remedy the problem.”

 

 

Page 14.

 

3.2.2.1 is essentially the same as 3.1.1.2, just refer to the previous text?

 

I could do that, but it’s just one paragraph and I think it’s a bit easier for a reader to see the text in context rather than have to flip back to the earlier section.

 

Page 15.

 

Their goal would be trick a CT-aware browser into accepting a
  bogus certificate because it was accompanied by a valid SCT, while
  evading certificate revocation status indications. This section
  explores such scenarios.


The attack as described only requires colluding CAs in the case where EE certs do not contain links to revocation information.

When EE certs do contain such links, the attack described is simply an attack on certificate revocation, regardless of whether one or more CAs might have issued the doppelgangers.

In either case, the attack is nothing to do with CT, which does not claim to do anything to help with integrity or correctness of revocation information.

 

The cited sentence notes that the goal of the attack is to cause a CT-aware browser to accept a certificate that, by CT goals, it ought not. In this sense, the attack is directly relevant to CT. I agree that the attack is one that exploits a residual vulnerability in revocation in general. However, this section describes the impact of that vulnerability in the context of CT, and thus seems relevant to the threat analysis.

 

Even if the bogus certificates contain an AIA extension pointing to
  an OCSP server the attack might still succeed. (As noted in the
  Section 1, RFC 5280 does not mandate inclusion this extension, but
  its presence is required by CABF requirements.)  As noted in Section
  3.2.1.1.1, a malicious CA could send a "good" OCSP response to a
  targeted browser instance, even if other parties are provided with a
  "revoked" response. Also note that a TLS server can supply an OCSP
  response to a browser as part of the TLS handshake [RFC6961], if
  requested by the browser. A TLS server posing as the entity named in
  the bogus certificate could acquire a "good" OCSP response from the
  colluding CAs to effect the attack. Only if the browser relies upon
  a trusted, third-party OCSP responder, one not part of the
  collusion, would the attack fail.



All this is independent of the attack and of CT, and applies generally to revocation.

 

See my rationale above for inclusion of this discussion.

 


  The analysis above also applies to the use of CRLs to disseminate
  certificate revocation status data. The doppelganger certificate
  could contain a CRL distribution point extension instead of an AIA
  extension. In that case a site supplying CRLs for the colluding CAs
  could supply different CRLs to different requestors, in an attempt
  to hide the revocation status of the doppelganger from targeted
  browsers instances. This is analogous to a split-view attack
  effected by a CT log. However, as noted in Section 3.2.1.1 and
  3.2.1.1.1, no element of CT is responsible for detecting
  inconsistent reporting of certificate revocation status data.
  (Monitoring in the CT context tracks log entries made by CAs or
  Subjects. Auditing is designed to detect misbehavior by logs, not by
  CAs per se.)


Likewise.

 

Ibid.

 

Page 20.

 

This will happen
  only if the log performs syntactic checks in general, and if the log
  is capable of performing the checks applicable to the submitted
  (pre-)certificate.


Anyone can detect syntactic mis-issuance, the log does not need to do it.

 

The threat analysis focuses on what the CT system says its elements will do, not what some outside entity
not defined by the system might do.

 

For example: https://crt.sh/?cablint=1+week.

 

Page 21.

 

If the (pre-)certificate is submitted by the non-malicious issuing
  CA, and if the CA has a record of the certificate content



Clearly there is a record in the log!

 

Good point. I’ve revised the text accordingly.

 

This analysis suggests that syntactic mis-issuance of a certificate
  can be avoided by a CA if it makes use of logs that are capable of
  performing these checks for the types of certificates that are
  submitted,


The CA can obviously perform these checks itself, logs are not special in this regard.

 

This discussion is addressing the (not uncommon) situation in which a CA fails to perform the appropriate checks.  Long ago you noted that this is a persistent problem and used that observation to justify the CT log language that provides leeway for a log to accept any certificate irrespective of whether it meets 5280 or any other certificate syntax criteria. So, it seems a bit disingenuous to suggest that a CA would be relied upon to perform these checks, in general.

 

Throughout this section there is talk about syntactic checking by logs, which is not a defined function of logs.

 

Syntax checking was proposed as an optional log function that you and your co-authors rejected. Thus this text notes that IF a log were to perform such checks, certain attacks could be detected on behalf of browsers (which also have a terrible track record of enforcing syntactic rules).

 

Unfortunately, experience suggests that
  many browsers do not perform thorough syntactic checks on
  certificates, and so it seems unlikely that browsers will be a
  reliable way to detect erroneous certificates.


What is unfortunate is that a very large number of extant certs have syntax errors and so browsers can't usefully perform checks.

 

I see we agree on this aspect of the problem. I am surprised that you noted that CAs could be relied upon to perform  syntax checking (your comment above) given the reality that you cited here!

 

Moreover, a protocol
  used by a browser to notify a Subject and/or CA of an erroneous
  certificate represents a DoS potential, and thus may not be
  appropriate.


Subjects are already subject to DoS by virtue of serving web pages. This doesn't seem like a valid concern.

 

Adding additional DoS opportunities is rarely viewed as a good idea. The text says it “may not be appropriate” and I stand by that.

 

Such browsers would benefit from
  having such checks performed by a log and reported in the SCT.


Browsers don't need help to perform syntax checks, it just isn't viable to do so.

 

I have revised the text as follows:

 

Such browsers might benefit from having syntax checks performed by a log and reported in the SCT, although the pervasive nature of syntactically-defective certificates may limit the utility of such checks.

 

Page 26.

 

Thus, for now, CT does not seem to provide a
  way to remedy this form of attack, even though it provides a basis
  for detecting such attacks.


CT doesn't claim to provide remedies for attacks, just information that reveals them. Once more, you are describing  a flaw with the whole system, not a flaw in CT.

 

You’re right that CT does not claim to remedy attacks; it claims to facilitates remediation. So, I have revised the text as follows:

 

Thus, for now, CT does not seem to provide a way to facilitate remediation of this form of attack, even though it provides a basis for detecting such attacks.

 

 Absent a well-defined mechanism that enables Monitors to verify that
  data from logs are reported in a consistent fashion, CT cannot claim
  to provide protection against logs that are malicious or may
  conspire with, or are victims of, attackers effecting certificate
  mis-issuance. The mechanism needs to protect the privacy of users
  with respect to which web sites they visit. It needs to scale to
  accommodate a potentially large number of self-monitoring Subjects
  and a vast number of browsers, if browsers are part of the
  mechanism. Even when an Audit mechanism is defined, it will be
  necessary to describe how the CT system will deal with a misbehaving
  or compromised log. For example, will there be a mechanism to alert
  all browsers to reject SCTs issued by such a log? Absent a
  description of a remediation strategy to deal with misbehaving or
  compromised logs, CT cannot ensure detection of mis-issuance in a
  wide range of scenarios.

 

The absence of a standard to do a thing does not make the thing impossible. In practice, none of this actually seems to be a problem, nor in need of standardisation at this time.

 

6962-bis is targeted as a standard track document. Thus, when one evaluates the CT threat environment we should restrict our attention to what is standardized. We can’t speculate on behavior that MIGHT take place but is not specified in a standard, and cite that as a mitigating factor with respect to an attack or a privacy concern.

 


--------------090005070301050202000600-- From nobody Tue May 24 03:25:24 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6486312DCDB for ; Tue, 24 May 2016 03:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fQOfv1TWsPv for ; Tue, 24 May 2016 03:25:21 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1CD212DCDC for ; Tue, 24 May 2016 03:25:17 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id z189so42285134itg.0 for ; Tue, 24 May 2016 03:25:17 -0700 (PDT) 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; bh=yZ2MFX0HSilhbyaIMBkem27RXKDVgtF9rHjA/Ry22Us=; b=DzuGkELCuZXFvqW5OVb6GKLaUlyye2BvUw7/eMbBDHQ8MupCwgQBuwm7u+1+ZhK764 H2haKCwDzuSTBXHzMgwd43AZdlOB2aS5ftBbNECfDSHJiEhPWGdKggv8lAZK0zIMqudP Q/hlJiPm1W/Nz+mq4N00Ghs8bd08KWHGif3vgUF8keH0BVWVO9+33bX6o6U1CkG02n9c pPlJQFprjcUSpSEHcuO1Tzj55HyFj80YX0DqRd6u/tOxuiahXXCdduPa9ESoyb9KT+WF 2Mmuh/ksf+H78H4T99WtKNvVp0r8CpM+qYfgIQIjFVhtiyp+Y7jOcGf8I6kRV4rSHEQz Mu3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yZ2MFX0HSilhbyaIMBkem27RXKDVgtF9rHjA/Ry22Us=; b=QH/8QvWDsoa9J3ao5jUbDUkQcIhfvFsRDa+TosokM6qfH1z6/GNUS77l4K51IbTAAM ANUzao3ki1zgi4Z7M8DCD8RY2jxAvmeE5AvlOjZ90+wqsUNl3wJpmKrZjstMAj65LheZ /BebEBAiMi4Yw6I0T8PpRayP7d6gtDd2VS4/72I2AQyUatvK1AikxFfta9KvFRa6GSRy rco9PgZ6LLl/ClBw8z+T+OUbWmbooUc7pd3nkP8gMpgbGZeOe214HN7aCpctGgFcnett 2DUK5tzFjJwrguUVaKMFfJE1uQ2C/RqKkEk7NTRaAIAeNmgCbxhIZZRj8jDdg8bw+Iz0 x0Xw== X-Gm-Message-State: ALyK8tLGtQ5wsya9yLcSn3Xll83CNJVxcOpsQlOZ9t23Yc4EaQvJiVkHqEXhUfe3htp4OGYqP0OfbvaPnd960Dq6 X-Received: by 10.36.46.75 with SMTP id i72mr11026772ita.91.1464085516381; Tue, 24 May 2016 03:25:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.136.75 with HTTP; Tue, 24 May 2016 03:25:15 -0700 (PDT) In-Reply-To: <874m9uf64o.fsf@nordberg.se> References: <87wpn9322u.fsf@alice.fifthhorseman.net> <87lh37mj2m.fsf@nordberg.se> <874m9uf64o.fsf@nordberg.se> From: Ben Laurie Date: Tue, 24 May 2016 11:25:15 +0100 Message-ID: To: Linus Nordberg Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" , Daniel Kahn Gillmor Subject: Re: [Trans] evaluating an SCT in the absence of the cert's issuer key X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 10:25:22 -0000 On 19 May 2016 at 15:56, Linus Nordberg wrote: > Ben Laurie wrote > Wed, 18 May 2016 18:30:37 +0100: > > | On 18 May 2016 at 17:23, Linus Nordberg wrote: > | > Ben Laurie wrote > | > Fri, 13 May 2016 15:56:44 +0100: > | > > | > | Actually, it seems to me that the simplest answer is to allow lookups > | > | in logs based on SCT alone. Then the SCT can be validated using the > | > | retrieved chain. > | > > | > That seems odd. From a logs point of view, an SCT is not a persistent > | > object. > | > > | > I don't know about other implementations but catlfish would not be able > | > to efficiently find an entry in the database given only an SCT. > | > | Are you saying there's some technical barrier to doing this, or just > | that as it stands you wouldn't be able to? > > I was being inprecise. I should have said that it would require some > redesign. > > > | It seems to me that the log could easily save SCTs it issued alongside > | the cert chains it issued them for. > > All SCT's for every chain, I presume, if there's going to be any point > in offering a lookup with an SCT as input? This would complicate things > at least in our design. I'm sure it could be solved at the price of more > complexity. We were reviewing the spec for 6962-bis, and we believe it is not possible to have more than one SCT for any particular log entry. > | And that it could easily create an index based on those SCTs. > > > | Note that 6962-bis already requires you to return SCTs in some lookups... > > You meen get-entries? I don't see how that's relevant. An SCT can be > generated given the data in leaf_input. No need to store it, unless you > wanted to for caching of course (we do that on frontend nodes). There's > a big difference between doing this and indexing on SCT's though. I agree there's a difference. I am curious what architecture makes it a big difference, though! > From nobody Tue May 24 08:15:43 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C47112D84A for ; Tue, 24 May 2016 08:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.626 X-Spam-Level: X-Spam-Status: No, score=-4.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_jUSXRJTBzU for ; Tue, 24 May 2016 08:15:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02BCF12D829 for ; Tue, 24 May 2016 08:15:39 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:45840 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1b5E3T-000Gv9-IN; Tue, 24 May 2016 11:15:36 -0400 To: Bryan Ford References: <570FA14E.4010109@bbn.com> <096DC698-534F-4632-B247-353A74564111@gmail.com> From: Stephen Kent Message-ID: <57447017.7070607@bbn.com> Date: Tue, 24 May 2016 11:15:35 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <096DC698-534F-4632-B247-353A74564111@gmail.com> Content-Type: multipart/alternative; boundary="------------070503060702070602040808" Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] slight timing whoops X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 15:15:42 -0000 This is a multi-part message in MIME format. --------------070503060702070602040808 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Bryan, Thanks for the thorough review of the sections of the sections of the doc that I know are of greatest interest to you. I have made a number of edits to address your comments, as noted below. Steve ----- A malicious CA might revoke a bogus certificate to avoid having browser vendors take punitive action against the CA and/or to persuade them to not enter the bogus certificate on a vendor-maintained blacklist. However, the CA might provide a “good” OCSP response (from a server it operates) to a targeted user (browser instance) as a way to circumvent the remediation nominally offered by revocation. No component of CT is tasked with detecting this sort of misbehavior by a CA. (The misbehavior is analogous to a log offering split views to different clients. The Audit element of CT is tasked with detecting this sort of attack.) Just a nitpick: in the parenthetical about “analogous to a log offering split view", may be worth adding a forward-reference to the text below (or just the words “described below”) containing the detailed discussion of that class of attack? *Fixed.* 3.3 Malicious, Colluding CAs … I agree with David Cooper that describing this as “two CAs” is rather strange given the assumption that they have “the same Subject name and public key”. I would call that “One Malicious CA with Two Certificate Chains” or something like that. *The issue here is whether we define CAs as identical based on their names and public keys, or based on their location in a PKI, or based on their physical instantiation, … . In the example I posed, the CAs are distinct based on two of these three criteria. I’ve edited the text to add a parenthetical discussion of this issue:* ** *(The following text refers to these as two CAs, because they might be represented by entities that are organizationally distinct, perhaps realized by different physical presences. However, because they share the same name and key pair, one also might view them as the same CA that appears in two cert paths terminating at different TAs.)*** … The above next never explicitly describes what the actual relevant attack is, or why exactly “two trust anchors” make the attack back bad and can foil the remediation procedures. It almost does, but not quite. It needs to say something like, “The CA that logged the bogus certificate may get detected and the certificate revoked via that trust anchor, but the same certificate remains usable and un-revoked via the other trust anchor through which the bogus certificate was not logged or revoked.” Or something like that. *The text you cited is part of describing the attack context, prior to describing the attack per se.* I guess the text in 3.3.1 does get to discussing this “main point", but only after the reader has waded through the several paragraphs above, without having (yet) been made aware of the whole reason for existence of this whole section. It’s probably best to summarize the attack/implications (and perhaps forward-reference the extended discussion below) in one quick sentence toward the beginning of 3.3. *The first paragraph of 3.3 describes the goal of the attack and, at a top level how it is effected, which I think suffices. It says:* ** *There is also the potential that two or more CAs might collude to issue a bogus certificate in a fashion designed to foil the remediation (but not detection) safeguards envisioned by CT. Their goal would be trick a CT-aware browser into accepting a bogus certificate because it was accompanied by a valid SCT, while evading certificate revocation status indications.*** ** … A compromised (non-malicious) CA may be able to revoke the bogus certificate if it is detected by a Monitor, and the targeted Subject has been notified. It can do so only when the serial number of the bogus certificate is made known to this CA. Also, the bogus certificate cannot have been issued with an Authority Information Access (AIA) or CRL Distribution Point (CRL DP) extension that enables only the malicious twin to revoke the certificate. (The AIA extension in the bogus certificate could be used to direct relying parties to an OCSP server controlled by the malicious twin. The CRL DP extension could be used to direct relying parties to a CRL controlled by the malicious twin.) If the bogus certificate contains either extension, the compromised CA cannot effectively revoke it, but it will also be apparent that the bogus certificate It’s probably worth clarifying exactly how this is “apparent” and to whom. e.g., something like, “also be apparent to anyone who checks the certificate against the uncompromised log and finds the SCT missing”, assuming that’s what you had in mind. Inferable, but just best to be explicit. *I have revised the paragraph to clarify what I had in mind:* ** *A compromised (non-malicious) CA may be able to revoke the bogus certificate if it is detected by a Monitor, and the targeted Subject has been notified. **It can do so only when the serial number of the bogus certificate is made known to this CA and assuming that the bogus certificate was not issued with an Authority Information Access (AIA) or CRL Distribution Point (CRL DP) extension that enables only the malicious twin to revoke the certificate. (The AIA extension in the bogus certificate could be used to direct relying parties to an OCSP server controlled by the malicious twin. The CRL DP extension could be used to direct relying parties to a CRL controlled by the malicious twin.)If the bogus certificate contains either extension, the compromised CA cannot effectively revoke it. However, the presence of either of these extensions provides some evidence that an entity other than the compromised CA issued the certificate in question. (If the extensions differ from those in other certificates issued by the compromised CA, that is suspicious.)* If the serial number of the bogus certificate is the same as for a valid, not-expired certificate issued by the CA (to the target or to another Subject), then revocation poses a problem. This is because revocation of the bogus nitpick: extra space between “revocation” and “poses" *Fixed * certificate will also invalidate a legitimate certificate. This problem may cause the compromised CA to delay revocation, thus allowing the bogus certificate to remain a danger for a longer time. Wait - isn’t the basic assumption of this section that the CA’s private key has been stolen? And in that case, shouldn’t the CA’s public key itself be revoked and considered untrustworthy, together with any certificate the CA has signed in the past (or signs in the future) with that key? It seems like even if there is a “legitimate certificate” that was signed by the same key, it should get revoked too! If that’s not the case, then the “why” needs to be clarified in the above paragraph, and it needs to be stated in what situations a relying party may still deem the “legitimate certificate” trustworthy despite being signed by a compromised CA key. 3.4.2 Benign CA, Compromised Log A benign CA does not issue bogus certificates, except as a result of an accident or attack. So, in normal operation, it is not clear what behavior by a compromised log would yield an attack. If a bogus certificate is issued by a benign CA (under these circumstances) is submitted to a compromised (non-malicious) log, then both an SCT and a log entry will be created. Again, it is not clear what additional adverse actions the compromised log would perform to further an attack on CT. Although not quite as worrisome as other attacks in practice, there is a DoS/censorship attack opportunity through equivocation here that might be worth mentioning. In particular, the compromised log could provide an SCT for a legitimate cert, and include the cert in a version of the log it shows most people, but then the compromised log server (or an evil twin of it) could send targeted relying parties a different log history that doesn’t include the legitimate cert. As a result, a web browser run by a targeted user will find the cert missing from the log and inform the user that the web site may be insecure/compromised, thus making the user (falsely) think the web site is broken rather than the log server. Of course, if the targeted user’s web browser can and does gossip STHs with benign CT servers, the discrepancy between the log server’s two histories will be detectable, and it will become known that the log server is compromised. However, if the user’s web browser is unable to gossip STHs with benign CT servers (e.g., because the only trusted auditor(s) are blocked), or if the browser is unwilling to gossip STHs for privacy reasons, or just doesn’t want the state/storage costs of tracking and gossiping all log-servers’ STH histories, then the attack might go undetected and the user might persistently think the web site itself is compromised or just broken. This might actually be a behavior desired by the attacker (effectively block the website but make the user think it’s the website’s fault) in some state-censorship type scenarios. *I have added the following paragraphs just before 3.4.3, to better explain the impact of log compromise.* ** *It is worth noting that if a benign CA was attacked and thus issued one or more bogus certificates, then a colluding, malicious log might provide split views of its log to help conceal the bogus certificate from targeted users. Specifically, the log would show an accurate set of log entries (and STHs) to most clients, but would maintain a separate log view for targeted users. This sort of attack motivates the need for Audit capabilities based on “gossiping” [gossip]. However, even if such mechanisms are employed, they might be thwarted if a user is unable to exchange log information with trustworthy partners.* ** 3.4.3 Compromised CA, Compromised Log As noted in 3.4.1, an evil twin CA may issue a bogus certificate that contains the same Subject name as a legitimate certificate issued by the compromised CA. Alternatively, the bogus certificate may contain a different name but reuse a serial number from a valid, not revoked certificate issued by that CA. The evil twin CA might submit a bogus certificate to the evil twin of a compromised log. The operator of the evil I would make it explicit here that the “evil twin CA” and the “evil twin of a compromised log” are very likely to be one and the same, i.e., just the attacker himself. Perhaps just “…of a compromised log (which may be the same attacker)." *I added a new, 2^nd paragraph to 3.4.3:* ** *An attacker who compromises a log might act in one of two ways. It might use the private key of the log only to generate SCTs for a malicious CA or the evil twin of a compromised CA. If a browser checks the signature on an SCT but does not contact a log to verify that the certificate appears in the log, then this is an effective attack strategy. Alternatively, the attacker might not only generate SCTs, but also pose as the compromised log, at least with regard to requests from targeted users. In the latter case, this “evil twin” log could respond to STH requests from targeted users, making appear that the compromised log was offering a split view (thus acting as a malicious log). To detect this attack an Auditor needs to employ a gossip mechanism that is able to acquire CT data from diverse sources, a feature not yet part of the base CT system.* ** *I revised the start of the next paragraph to say:* *The evil twin CA might submit a bogus certificate to the evil twin of a compromised log. (The same adversary may be controlling both.)* twin log can use the purloined private key to generate SCTs for certificates that have not been logged by its legitimate counterpart. These SCTs will appear valid relative to the public key associated with the legitimate log. However, an STH issued by the legitimate log will not correspond to a tree containing these SCTs. Thus thorough checking of the SCTs issued by the evil twin log will identify this discrepancy. "Thorough checking" by whom, against what reference point? *I revised the text to clarify what I had in mind.* ** *However, an STH issued by the legitimate log will not correspond to a tree (maintained by the compromised log) containing these SCTs. Thus checking the SCTs issued by the evil twin log against STHs from the compromised log will identify this discrepancy. As noted above, if an attacker uses the key to generate log entries and respond to log queries, like an evil twin CA, the effect is analogous to a malicious log.)*** Here it is important to bring out the question (again) of whether the relying party or parties targeted with this attack can, or do, gossip with uncompromised CT entities in order to be able to do that cross-checking. *I believe the revised text cited above makes this clearer.* If the compromised CA and compromised server are giving those bad certs and bad SCTs to a large body of users, at least some of whom check STH inclusion proofs and gossip regularly with uncompromised CT log servers, auditors, or monitors, then they will likely be able to notice the discrepancy fairly quickly. However, if the evil twin CA+log is attacking only a few users in a much more targeted fashion, and is in sufficient control of the target users’ external connectivity to prevent them from gossiping with legitimate CT parties (or if the attacker simply happens to know that those users are running software that disable gossip for privacy reasons), then no one will ever have the opportunity to notice the discrepancy. I think this really needs to be made explicit. An Auditor checking for log consistency might conclude that the compromised log is acting maliciously, and is presenting a split view to its clients. How does this Auditor actually obtain both “views” of the compromised log? *There are two views only if the attacker uses the purloined key to generate a parallel log, not just generate SCTs. In this case an Auditor will see that the bogus SCTs don’t fit into the tree maintained by the compromised log.It might infer (incorrectly) that the log is malicious, as the text says. I made a small change to the sentence to clarify this:* ** *An Auditor checking for log consistency and with access to bogus SCTs, might conclude that the compromised log is acting maliciously, and is presenting a split view to its clients.*** If the Auditor is obtaining log records directly from the compromised log server, then presumably the log server will send it only one of the two views. *Yes, if the Auditor has access only to the evil twin log,that’s right. But, in that case, we’re back to the case of a malicious log.* (Legitimate Auditors can be deceived through equivocation just as easily as clients!) This text needs to specify under what conditions the Auditor can notice the discrepancy: e.g., if it obtains one view from the log server and learns about a different view via gossip with other Auditors, Monitors, and/or relying parties that can and choose to gossip with it. *I revised the text to make this issue more explicit:* *An Auditor checking for log consistency (relying on a gossip mechanism to acquire log views from diverse sources) might conclude that the compromised log is acting maliciously, and is presenting a split view to its clients.*** --------------070503060702070602040808 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Bryan,

Thanks for the thorough review of the sections of the sections of the doc
that I know are of greatest interest to you.  I have made a number of edits
to address your comments, as noted below.

Steve

-----

   A malicious CA might revoke a bogus certificate to avoid having browser 
   vendors take punitive action against the CA and/or to persuade them to not 
   enter the bogus certificate on a vendor-maintained blacklist. However, the CA 
   might provide a “good” OCSP response (from a server it operates) to a targeted 
   user (browser instance) as a way to circumvent the remediation nominally offered 
   by revocation. No component of CT is tasked with detecting this sort of misbehavior 
   by a CA. (The misbehavior is analogous to a log offering split views to different 
   clients. The Audit element of CT is tasked with detecting this sort of attack.)


Just a nitpick: in the parenthetical about “analogous to a log offering split view", may be worth adding a forward-reference to the text below (or just the words “described below”) containing the detailed discussion of that class of attack?

 

Fixed.

 

3.3 Malicious, Colluding CAs

 

…

 

I agree with David Cooper that describing this as “two CAs” is rather strange given the assumption that they have “the same Subject name and public key”.  I would call that “One Malicious CA with Two Certificate Chains” or something like that.

 

The issue here is whether we define CAs as identical based on their names and public keys, or based on their location in a PKI, or based on their physical instantiation, … . In the example I posed, the CAs are distinct based on two of these three criteria. I’ve edited the text to add a parenthetical discussion of this issue:

 

(The following text refers to these as two CAs, because they might be represented by entities that are organizationally distinct, perhaps realized by different physical presences. However, because they share the same name and key pair, one also might view them as the same CA that appears in two cert paths terminating at different TAs.)



…

 

The above next never explicitly describes what the actual relevant attack is, or why exactly “two trust anchors” make the attack back bad and can foil the remediation procedures.  It almost does, but not quite.  It needs to say something like, “The CA that logged the bogus certificate may get detected and the certificate revoked via that trust anchor, but the same certificate remains usable and un-revoked via the other trust anchor through which the bogus certificate was not logged or revoked.”  Or something like that.

 

The text you cited is part of describing the attack context, prior to describing the attack per se.

 

I guess the text in 3.3.1 does get to discussing this “main point", but only after the reader has waded through the several paragraphs above, without having (yet) been made aware of the whole reason for existence of this whole section.  It’s probably best to summarize the attack/implications (and perhaps forward-reference the extended discussion below) in one quick sentence toward the beginning of 3.3.


The first paragraph of 3.3 describes the goal of the attack and, at a top level how it is effected, which I think suffices. It says:

 

There is also the potential that two or more CAs might collude to issue a bogus certificate in a fashion designed to foil the remediation (but not detection) safeguards envisioned by CT. Their goal would be trick a CT-aware browser into accepting a bogus certificate because it was accompanied by a valid SCT, while evading certificate revocation status indications.

 

… 

 

A compromised (non-malicious) CA may be able to revoke the bogus certificate if it is detected by a Monitor, and the targeted Subject has been notified. It can do so only when the serial number of the bogus certificate is made known to this CA. Also, the bogus certificate  cannot have been issued with an Authority Information Access (AIA) or CRL Distribution Point (CRL DP) extension that enables only the malicious twin to revoke the certificate. (The AIA extension in the bogus certificate could be used to direct relying parties to an OCSP server controlled by the malicious twin. The CRL DP extension could be used to direct relying parties to a CRL controlled by the malicious twin.)  If the bogus certificate contains either extension, the compromised CA cannot effectively revoke it, but it will also be apparent that the bogus certificate

 

It’s probably worth clarifying exactly how this is “apparent” and to whom.  e.g., something like, “also be apparent to anyone who checks the certificate against the uncompromised log and finds the SCT missing”, assuming that’s what you had in mind.  Inferable, but just best to be explicit.

 

I have revised the paragraph to clarify what I had in mind:

 


A compromised (non-malicious) CA may be able to revoke the bogus certificate if it is detected by a Monitor, and the targeted Subject has been notified. It can do so only when the serial number of the bogus certificate is made known to this CA and assuming that the bogus certificate was not issued with an Authority Information Access (AIA) or CRL Distribution Point (CRL DP) extension that enables only the malicious twin to revoke the certificate. (The AIA extension in the bogus certificate could be used to direct relying parties to an OCSP server controlled by the malicious twin. The CRL DP extension could be used to direct relying parties to a CRL controlled by the malicious twin.)  If the bogus certificate contains either extension, the compromised CA cannot effectively revoke it. However, the presence of either of these extensions provides some evidence that an entity other than the compromised CA issued the certificate in question. (If the extensions differ from those in other certificates issued by the compromised CA, that is suspicious.)

 

 

If the serial number of the bogus certificate is the same as for a valid, not-expired certificate issued by the CA (to the target or to another Subject), then revocation  poses a problem. This is because revocation of the bogus

 

nitpick: extra space between “revocation” and “poses"

 

Fixed



certificate will also invalidate a legitimate certificate. This problem may cause the compromised CA to delay revocation, thus allowing the bogus certificate to remain a danger for a longer time. 

 

Wait - isn’t the basic assumption of this section that the CA’s private key has been stolen?  And in that case, shouldn’t the CA’s public key itself be revoked and considered untrustworthy, together with any certificate the CA has signed in the past (or signs in the future) with that key?  It seems like even if there is a “legitimate certificate” that was signed by the same key, it should get revoked too!  If that’s not the case, then the “why” needs to be clarified in the above paragraph, and it needs to be stated in what situations a relying party may still deem the “legitimate certificate” trustworthy despite being signed by a compromised CA key.



3.4.2 Benign CA, Compromised Log

 

A benign CA does not issue bogus certificates, except as a result of an accident or attack. So, in normal operation, it is not clear what behavior by a compromised log would yield an attack. If a bogus certificate is issued by a benign CA (under these circumstances) is submitted to a compromised (non-malicious) log, then both an SCT and a log entry will be created. Again, it is not clear what additional adverse actions the compromised log would perform to further an attack on CT.

 

Although not quite as worrisome as other attacks in practice, there is a DoS/censorship attack opportunity through equivocation here that might be worth mentioning.  In particular, the compromised log could provide an SCT for a legitimate cert, and include the cert in a version of the log it shows most people, but then the compromised log server (or an evil twin of it) could send targeted relying parties a different log history that doesn’t include the legitimate cert.  As a result, a web browser run by a targeted user will find the cert missing from the log and inform the user that the web site may be insecure/compromised, thus making the user (falsely) think the web site is broken rather than the log server.  

 

Of course, if the targeted user’s web browser can and does gossip STHs with benign CT servers, the discrepancy between the log server’s two histories will be detectable, and it will become known that the log server is compromised.  However, if the user’s web browser is unable to gossip STHs with benign CT servers (e.g., because the only trusted auditor(s) are blocked), or if the browser is unwilling to gossip STHs for privacy reasons, or just doesn’t want the state/storage costs of tracking and gossiping all log-servers’ STH histories, then the attack might go undetected and the user might persistently think the web site itself is compromised or just broken.  This might actually be a behavior desired by the attacker (effectively block the website but make the user think it’s the website’s fault) in some state-censorship type scenarios.


I have added the following paragraphs just before 3.4.3, to better explain the impact of log compromise.

 

It is worth noting that if a benign CA was attacked and thus issued one or more bogus certificates, then a colluding, malicious log might provide split views of its log to help conceal the bogus certificate from targeted users. Specifically, the log would show an accurate set of log entries (and STHs) to most clients, but would maintain a separate log view for targeted users. This sort of attack motivates the need for Audit capabilities based on “gossiping” [gossip]. However, even if such mechanisms are employed, they might be thwarted if a user is unable to exchange log information with trustworthy partners.

 

 

3.4.3 Compromised CA, Compromised Log

 

As noted in 3.4.1, an evil twin CA may issue a bogus certificate that contains the same Subject name as a legitimate certificate issued by the compromised CA. Alternatively, the bogus certificate may contain a different name but reuse a serial number from a valid, not revoked certificate issued by that CA. 

 

The evil twin CA might submit a bogus certificate to the evil twin of a compromised log. The operator of the evil

 

I would make it explicit here that the “evil twin CA” and the “evil twin of a compromised log” are very likely to be one and the same, i.e., just the attacker himself.  Perhaps just “…of a compromised log (which may be the same attacker)."


I added a new, 2nd paragraph to 3.4.3:

 

An attacker who compromises a log might act in one of two ways. It might use the private key of the log only to generate SCTs for a malicious CA or the evil twin of a compromised CA. If a browser checks the signature on an SCT but does not contact a log to verify that the certificate appears in the log, then this is an effective attack strategy. Alternatively, the attacker might not only generate SCTs, but also pose as the compromised log, at least with regard to requests from targeted users. In the latter case, this “evil twin” log could respond to STH requests from targeted users, making appear that the compromised log was offering a split view (thus acting as a malicious log). To detect this attack an Auditor needs to employ a gossip mechanism that is able to acquire CT data from diverse sources, a feature not yet part of the base CT system.

 

I revised the start of the next paragraph to say:

 

The evil twin CA might submit a bogus certificate to the evil twin of a compromised log. (The same adversary may be controlling both.)

 

twin log can use the purloined private key to generate SCTs for certificates that have not been logged by its legitimate counterpart. These SCTs will appear valid relative to the public key associated with the legitimate log. However, an STH issued by the legitimate log will not correspond to a tree containing these SCTs. Thus thorough checking of the SCTs issued by the evil twin log will identify this discrepancy. 

 

"Thorough checking" by whom, against what reference point?

 

I revised the text to clarify what I had in mind.

 

However, an STH issued by the legitimate log will not correspond to a tree (maintained by the compromised log) containing these SCTs. Thus checking the SCTs issued by the evil twin log against STHs from the compromised log will identify this discrepancy. As noted above, if an attacker uses the key to generate log entries and respond to log queries, like an evil twin CA, the effect is analogous to a malicious log.)

 

 

 Here it is important to bring out the question (again) of whether the relying party or parties targeted with this attack can, or do, gossip with uncompromised CT entities in order to be able to do that cross-checking.  

 

I believe the revised text cited above makes this clearer.

 

If the compromised CA and compromised server are giving those bad certs and bad SCTs to a large body of users, at least some of whom check STH inclusion proofs and gossip regularly with uncompromised CT log servers, auditors, or monitors, then they will likely be able to notice the discrepancy fairly quickly.  However, if the evil twin CA+log is attacking only a few users in a much more targeted fashion, and is in sufficient control of the target users’ external connectivity to prevent them from gossiping with legitimate CT parties (or if the attacker simply happens to know that those users are running software that disable gossip for privacy reasons), then no one will ever have the opportunity to notice the discrepancy.  I think this really needs to be made explicit.

 

An Auditor checking for log consistency might conclude that the compromised log is acting maliciously, and is presenting a split view to its clients.

 

How does this Auditor actually obtain both “views” of the compromised log?  

 

There are two views only if the attacker uses the purloined key to generate a parallel log, not just generate SCTs. In this case an Auditor will see that the bogus SCTs don’t fit into the tree maintained by the compromised log.  It might infer (incorrectly) that the log is malicious, as the text says. I made a small change to the sentence to clarify this:

 

An Auditor checking for log consistency and with access to bogus SCTs, might conclude that the compromised log is acting maliciously, and is presenting a split view to its clients.

 

If the Auditor is obtaining log records directly from the compromised log server, then presumably the log server will send it only one of the two views.  

 

Yes, if the Auditor has access only to the evil twin log,  that’s right. But, in that case, we’re back to the case of a malicious log.

 

(Legitimate Auditors can be deceived through equivocation just as easily as clients!)  This text needs to specify under what conditions the Auditor can notice the discrepancy: e.g., if it obtains one view from the log server and learns about a different view via gossip with other Auditors, Monitors, and/or relying parties that can and choose to gossip with it.

 

I revised the text to make this issue more explicit:

 

An Auditor checking for log consistency (relying on a gossip mechanism to acquire log views from diverse sources) might conclude that the compromised log is acting maliciously, and is presenting a split view to its clients.


--------------070503060702070602040808-- From nobody Thu May 26 08:24:05 2016 Return-Path: X-Original-To: trans@ietf.org Delivered-To: trans@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6482812D707; Thu, 26 May 2016 08:24:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160526152404.14624.69365.idtracker@ietfa.amsl.com> Date: Thu, 26 May 2016 08:24:04 -0700 Archived-At: Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-15.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 15:24:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency of the IETF. Title : Certificate Transparency Authors : Ben Laurie Adam Langley Emilia Kasper Eran Messeri Rob Stradling Filename : draft-ietf-trans-rfc6962-bis-15.txt Pages : 54 Date : 2016-05-26 Abstract: This document describes a protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 26 14:18:25 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9B412DAB5 for ; Thu, 26 May 2016 14:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id je1YnY9BfhY4 for ; Thu, 26 May 2016 14:18:21 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B04C12D195 for ; Thu, 26 May 2016 14:17:06 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id g64so34633306pfb.2 for ; Thu, 26 May 2016 14:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=1vhso1FIJ/OGCt+q6B6ycZQPdKqXgCqWLT4nefBbg5E=; b=m1knvRuI2ehZEqAHHDrS+2/KXzgX/6A7rGcOnhagCl9Dxc5SB7vzeZzuEut9eOo8D5 17Lip6bnNtPw9FaUAEh4e74+PUi0jKuyg/0lr0xY5FvoJzZ2GK6BPMkvZ92me4Q40+s5 38KgjaWhTX6PMeB8MNsE6W7mPi10OED890aQA9bLEYT/xenbU2tDD5G/WzzeWH2Z8GoP W5V/z3rKbVoKaQQvy2AJ9ANJLOfKj5xBoG7OcP8w9/G3TPPegGpaR0hZlsGw8mZbZ5cU fpzZVRiSFNTmudrsSDFvLEskd24djOYGygfiVOuUc1nndAVYCoj9OB15JKYnOlOtE9fj 39cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=1vhso1FIJ/OGCt+q6B6ycZQPdKqXgCqWLT4nefBbg5E=; b=SWfiWUtePEJ8tBdjqpbbc2+X7gspFC1ryOHyxuWF13MFGjwrGy8yaqiqH9eTIRll3o lobvsSPOlxm5ogoL0l+t2FYfqbm6HvkYPOUnOm+/5YA9qn5SAn3CnvHbUI57hZfQks4g EYgW2cuCwEQFc+9/9ZuumTUPCSufckw8dcSLJAHbBNjb9yIAjUgirppFM03IWDm0tV9Y pJcE/zFuSF2KpM5dm+HEYd0Wa5kYhmGeDvn7ZW4rvjMnD42k62eRiLMTcktU9TxidxiQ EnQtZH3MvVKHOwzq95NjxiyXItIvMutLs3SxMopiIloJWTpc05fKWo1Ll0DGDpT+laZx 5C5A== X-Gm-Message-State: ALyK8tK+KVOsdAG+xatCoTSSclFEpH2fXfVmPsZsCUfFgAum1hGpA2mhbSlAngXZFF/zqA== X-Received: by 10.98.97.67 with SMTP id v64mr17214630pfb.149.1464297425626; Thu, 26 May 2016 14:17:05 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (209-112-210-20-radius.dynamic.acsalaska.net. [209.112.210.20]) by smtp.googlemail.com with ESMTPSA id yp9sm22682725pab.42.2016.05.26.14.17.04 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2016 14:17:04 -0700 (PDT) To: "trans@ietf.org" From: Melinda Shore Message-ID: Date: Thu, 26 May 2016 13:15:56 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Paul Wouters Subject: [Trans] Starting working group last call, draft-ietf-trans-rfc6962-bis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 21:18:25 -0000 This is to announce the beginning of working group last call for draft-ietf-trans-rfc6962-bis. The purpose of working group last call is to establish working group consensus that the document is ready for publication. Please give the draft a thorough review and post comments to this mailing list. Document review is one of the most significant contributions you can make to the work of the IETF, and we encourage newer participants who've never done a document review before to join in (if you've got questions about how to review a document, please contact Paul or me directly). The URL for the draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ Last call closes in three weeks, on June 16, at 23:59 GMT. Many thanks for all the work done so far, and for the reviews yet to come. Melinda & Paul From nobody Fri May 27 05:41:02 2016 Return-Path: X-Original-To: trans@ietf.org Delivered-To: trans@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A997212D60C; Fri, 27 May 2016 05:40:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160527124058.2995.71977.idtracker@ietfa.amsl.com> Date: Fri, 27 May 2016 05:40:58 -0700 Archived-At: Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-16.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 12:40:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency of the IETF. Title : Certificate Transparency Authors : Ben Laurie Adam Langley Emilia Kasper Eran Messeri Rob Stradling Filename : draft-ietf-trans-rfc6962-bis-16.txt Pages : 52 Date : 2016-05-27 Abstract: This document describes a protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 27 05:57:30 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D9E12DA71 for ; Fri, 27 May 2016 05:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smgjGGaZ2_ty for ; Fri, 27 May 2016 05:57:27 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7146812D739 for ; Fri, 27 May 2016 05:57:27 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id h19so105093179ywc.0 for ; Fri, 27 May 2016 05:57: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:from:date:message-id:subject:to :cc; bh=UjR5czvszsSEOkWakCgY5aOTpCbIEHUozAaBEeJj9HQ=; b=m8IE2la5BrrKFicK6JA3CnNjimOLJCCSvOJxZLq99IJBOixV+MjAkGetoSlnxkirkf b/5H393oszh7Jjemg1cBsQuauuvyItHR7z8rGSc1YCAxO4MMm83FGqLUid1XJYKXLJcE 2eJPLGiucoU03Q0T7CJFXtKQomg+X5intadrN65Oaf3m+nom49Ycdx71fMMxJuRzi3eg h8dM0l8sjARSyhNCftioqLlMo2SBjiVd9GsnCH8+T7viv0c2CAVTN/SohY2JEAe5LPiS TR2uF0b6AHUNWRTogtnyuR7w6oyZ12jmFmhennuNqASLsktQ7taJzloumgTKkjrHQh4i vrug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UjR5czvszsSEOkWakCgY5aOTpCbIEHUozAaBEeJj9HQ=; b=lfy8Bn0wnJF4is4uQtf2vBG8PdjhSU3e9BPIkKTzETLONbS1Mjsl0+9dQv5bFjnk/A XH9jQ40uz/V3Bs/eV+aHE4PnDON2pWY8iPAeXEbyu4JV2z2InV8ZkoGsKFxn3kt+Cfil g5+Xy6ByVctqjJ/P8lv03Ap1R1mrT7Ema42D204DQva8Kaa/9xdbG+tv8rSuF+OPglXj R8FPdjbs35XtLw1MsG2j8kYg45lkvrxlpePPfdOx29bhcVl9SEbhwE1Pu3kuZAE7xjoy C77QXphqLab1rXCXOJ46B7YClHqrDMjfHle66gv3FSqZp5Q/a9zsN+IGgbuYIJ55BE38 mUAQ== X-Gm-Message-State: ALyK8tLlrRHLun0Iu4PN2004DmAgrjCzkAXRS+M0Yu2s7w60UGd6f6bbZakLVWYwOa2korWnYKrd5sKri5bKUuYp X-Received: by 10.37.210.143 with SMTP id j137mr5429392ybg.105.1464353846234; Fri, 27 May 2016 05:57:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.216.84 with HTTP; Fri, 27 May 2016 05:57:25 -0700 (PDT) In-Reply-To: References: From: Eran Messeri Date: Fri, 27 May 2016 13:57:25 +0100 Message-ID: To: Melinda Shore Content-Type: multipart/alternative; boundary=94eb2c065c6ad517e10533d27290 Archived-At: Cc: Paul Wouters , "trans@ietf.org" Subject: Re: [Trans] Starting working group last call, draft-ietf-trans-rfc6962-bis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 12:57:29 -0000 --94eb2c065c6ad517e10533d27290 Content-Type: text/plain; charset=UTF-8 To assist and ease review of RFC6962-bis, a document highlighting the changes can be found at the bottom of: https://sites.google.com/site/certificatetransparency/ct-v2-rfc6962-bis On Thu, May 26, 2016 at 10:15 PM, Melinda Shore wrote: > This is to announce the beginning of working group last call > for draft-ietf-trans-rfc6962-bis. The purpose of working group > last call is to establish working group consensus that the > document is ready for publication. > > Please give the draft a thorough review and post comments to > this mailing list. Document review is one of the most significant > contributions you can make to the work of the IETF, and we > encourage newer participants who've never done a document review > before to join in (if you've got questions about how to review > a document, please contact Paul or me directly). > > The URL for the draft is: > https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ > > Last call closes in three weeks, on June 16, at 23:59 GMT. > > Many thanks for all the work done so far, and for the reviews > yet to come. > > Melinda & Paul > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --94eb2c065c6ad517e10533d27290 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To assist and ease review of RFC6962-bis, a document highl= ighting the changes can be found at the bottom of:<= div>

On Thu, May 26, 2016 at 10:15 PM, Melinda Shore <melinda.shore@gm= ail.com> wrote:
This is to = announce the beginning of working group last call
for draft-ietf-trans-rfc6962-bis.=C2=A0 The purpose of working group
last call is to establish working group consensus that the
document is ready for publication.

Please give the draft a thorough review and post comments to
this mailing list.=C2=A0 Document review is one of the most significant
contributions you can make to the work of the IETF, and we
encourage newer participants who've never done a document review
before to join in (if you've got questions about how to review
a document, please contact Paul or me directly).

The URL for the draft is:
https://datatracker.ietf.org/doc/draft= -ietf-trans-rfc6962-bis/

Last call closes in three weeks, on June 16, at 23:59 GMT.

Many thanks for all the work done so far, and for the reviews
yet to come.

Melinda & Paul

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

--94eb2c065c6ad517e10533d27290-- From nobody Tue May 31 07:17:36 2016 Return-Path: X-Original-To: trans@ietf.org Delivered-To: trans@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFAA12D7BD; Tue, 31 May 2016 07:17:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160531141734.18648.11967.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 07:17:34 -0700 Archived-At: Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-threat-analysis-06.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 14:17:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency of the IETF. Title : Attack Model and Threat for Certificate Transparency Author : Stephen Kent Filename : draft-ietf-trans-threat-analysis-06.txt Pages : 32 Date : 2016-05-31 Abstract: This document describes an attack model and discusses threats for the Web PKI context in which security mechanisms to detect mis- issuance of web site certificates are being developed. The model provides an analysis of detection and remediation mechanisms for both syntactic and semantic mis-issuance. The model introduces an outline of attacks to organize the discussion. The model also describes the roles played by the elements of the Certificate Transparency (CT) system, to establish a context for the model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-threat-analysis-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 31 07:19:56 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2908712D539 for ; Tue, 31 May 2016 07:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.627 X-Spam-Level: X-Spam-Status: No, score=-4.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t58OxU_8svxQ for ; Tue, 31 May 2016 07:19:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA6E912D6A9 for ; Tue, 31 May 2016 07:19:35 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:55523 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1b7kW6-000BHp-KS for trans@ietf.org; Tue, 31 May 2016 10:19:34 -0400 To: "trans@ietf.org" From: Stephen Kent Message-ID: <574D9D76.10507@bbn.com> Date: Tue, 31 May 2016 10:19:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] draft-ietf-trans-threat-analysis-06 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 14:19:54 -0000 has been posted. This version contains all of the changes made in response to comments from Ben and Bryan, as noted in my replies to their messages on 5/20 and 5/24. Steve