On Wed, Jun 20, 2018 at 4:01 PM, Salz, Rich <rsalz= =3D40akamai.com@dmarc.ietf.org> wrote:

I'm not sure what you mean by "enticement". The docu= ment status is by no means an enticement to implementation.

=C2=A0

Most organizations have limited resources and cannot= implement everything, and focus on things like standards-track.=C2=A0 Perh= aps I used the wrong word.

=C2=A0

At any rate, I am glad that Google is strongly inter= ested in 6962-bis. I don=E2=80=99t understand how a mailing list discussion= in an IETF WG doesn=E2=80=99t work well for browser development =E2=80=93 = doesn=E2=80=99t Google do much work through mailing lists? =E2=80=93 but I am glad you spoke up now.

I'm afraid there's some rather significant misunderstanding a= bout that remark - it was about the notion of 'freezing' the specs,= especially without a great deal of maturation. The W3C, for example, is si= milarly recognizing this in terms of=C2=A0https://www.w3.org/wiki/Evergreen_Standards and = better captures the tradeoffs.

As far as list part= icipation goes, communicating product plans and roadmaps to the IETF is not= generally a workmode that the Chrome team does. However, as it matters to = the understanding that we are committed to exploring 6962-bis, and believe = it provides distinctive value over 6962, I'm more than happy to share t= hat we think this is a solid and welcome forward path, and one that hopeful= ly produces lower risk to the ecosystem than pursuing it as Standards Track= without any real world implementation experience or running code.

--00000000000047c6dd056f19612a-- From nobody Thu Jun 21 10:22:00 2018 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 5D317130E9F for ; Thu, 21 Jun 2018 10:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name 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 7vu4bZfucQFM for ; Thu, 21 Jun 2018 10:21:57 -0700 (PDT) Received: from thompson.beanwood.com (thompson.beanwood.com [IPv6:2600:1f14:a46:c400:6107:163e:4681:134e]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E1B2130E8A for ; Thu, 21 Jun 2018 10:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1529601716; bh=j1QV1nfzwN+V9/MaaLZphfL1mclHJ2mB1wN5GwC9a1w=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=dWSbTw2LAJrqTfJqaUMv453yOf0G7mdU2yWyC7stcOUOX2vbvYtqEWiNskznxnCT+ oxGajtdklcjqwSK7bZ/KpFVTDLv2ssQ9uk/wktDMrJ//y16FzX7w3zmlY7mUAqZvhX dciQFj5DpSJ1ZY8gNtIaYnfxQ+ZkOy9D/7vJoH41R71XyXSa0vs7t/ztsID4W5Xc5d LWL2OXN8pHgPuh1I8eMf7IpiCr8jslCKEfmQt259SbC0Fnpu2nQxFd982ztsGQPSZl tFAtguk0MhN+supayOFprL0gQKftlplE531y9mq1GsIxBWqQqGEIbO+SVcSqzQs0sQ szuVqL/Iu1UAQ== Date: Thu, 21 Jun 2018 10:19:58 -0700 From: Andrew Ayer To: Paul Wouters Cc: Trans Message-Id: <20180621101958.8ea6f31b764a346e4d02e1c8@andrewayer.name> In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Next steps for 6962-bis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.26 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, 21 Jun 2018 17:21:59 -0000 On Wed, 20 Jun 2018 13:13:42 -0400 (EDT) Paul Wouters wrote: > 3. AD revieW: Remove the Preventing Tracking Clients claim > > https://github.com/google/certificate-transparency-rfcs/pull/295 > > We had some discussion on the list. Eric has pointed out this > complicated RSA-PSS. Previous discussion talked about removing > this as it was mostly to faciliate the (still incomplete) gossip > protocol. We can either leave it in, remove it, or rewrite it to > more advisory/BCP and less restrictive ? Please dicsuss, otherwise > it seems to consensus is to remove this claim. Why do you think the consensus is to remove? During the mailing list discussion, Linus Nordberg, Tom Ritter, and I all spoke up in favor of keeping it. No one spoke in favor of removal. Regards, Andrew From nobody Thu Jun 21 17:47:07 2018 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 E265912F1AB for ; Thu, 21 Jun 2018 17:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 JBzqyI9WjXiZ for ; Thu, 21 Jun 2018 17:47:00 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::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 A4E6712F1A6 for ; Thu, 21 Jun 2018 17:47:00 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id z12-v6so1221460ybj.4 for ; Thu, 21 Jun 2018 17:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jn3xR1YaX0hWoXsa/5X91DyHCGbZPl0rG7180qzIR9g=; b=sOEWB6qMH6THw9HkJ2mfJmydM9q675D3Ft2VjwOOxadvim4dBg8WvNIBustu8/+ii6 Gb3NuPtopwCV6cPjwDjzDK3zWLAWqs+jO3NSj+MoKTY8697vi7jVqRG3CJLqtzvZusCE xtJeLZ0rDcyV2rc9zq3C6BtMkmXqgc5R/BlpBW4L0WbQSozgZ1uuIVbpj4YAGSzwRWZB rl0Wpq/tvl3O6xXm1HvKF2LKQK5Th5+ONobRtl1/TfkrqhBBFPN+UAJiwMpDmtpZUg8i I97YDXB6TdbDw9cFBWLpeKKEUwFjXDyxYTMpEKkLDjg5IU0WQepe1cJQbVJkZ/llnXey OE+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jn3xR1YaX0hWoXsa/5X91DyHCGbZPl0rG7180qzIR9g=; b=H6cCHgvDh2ARjXnP6y758QGewZVBhOR+6pT0kbTSm2ciScomKFdHxomUEFE+Bu3cEz XavFTNU/SILH4Zatv5K58TgTVe6lMKBiI1WiAlZaWJPoFbVjloKhWFlMvA3BknuZ3Wcm w1rQm5dIlXhX5ob+r4Z0FJQMCoFSOTgDONV0pK6hLAqYE2zpamTyxYNuuazLm5WYFSzl 7SjjEi9ZRgB1nvLEue7HWDdWASldv6eC45cZL58PUIa5z7XzQY7kz3b2BSeru2Z4WZu7 FgR+WXoc6nrvoKp3hut61fBYwWZYwLSFjbYJKgBKJ1kKZcU0YRkXlZm1dWUYOuP8dFCj bDoQ== X-Gm-Message-State: APt69E3V6DdYFBK075Cxn06I1WfBrouW723KQ2K1r7PHNUAGGM3VRAZ8 TYd6l6adVXCJ9gl58ypksdgeiS34pbCSpMFej8u75Wp9 X-Google-Smtp-Source: ADUXVKLpbvHkSRNldOfpKA/UwjFfm3KD5wodiKHAwMBh+n+CVP9BnA7TGRJ5BW1FAcwQKL3trXqNw9+NyUuNCcC2CTY= X-Received: by 2002:a25:6542:: with SMTP id z63-v6mr14575848ybb.73.1529628419717; Thu, 21 Jun 2018 17:46:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:613:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 17:46:18 -0700 (PDT) In-Reply-To: <20180621101958.8ea6f31b764a346e4d02e1c8@andrewayer.name> References: <20180621101958.8ea6f31b764a346e4d02e1c8@andrewayer.name> From: Eric Rescorla Date: Thu, 21 Jun 2018 17:46:18 -0700 Message-ID: To: Andrew Ayer Cc: Paul Wouters , Trans Content-Type: multipart/alternative; boundary="0000000000009893ac056f305e9c" Archived-At: Subject: Re: [Trans] Next steps for 6962-bis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 00:47:05 -0000 --0000000000009893ac056f305e9c Content-Type: text/plain; charset="UTF-8" I am not arguing for removal, but I don't think it's appropriate to have a recommendation which precludes the use of the mode of RSA that we are otherwise telling people to use. -Ekr On Thu, Jun 21, 2018 at 10:19 AM, Andrew Ayer wrote: > On Wed, 20 Jun 2018 13:13:42 -0400 (EDT) > Paul Wouters wrote: > > > 3. AD revieW: Remove the Preventing Tracking Clients claim > > > > https://github.com/google/certificate-transparency-rfcs/pull/295 > > > > We had some discussion on the list. Eric has pointed out this > > complicated RSA-PSS. Previous discussion talked about removing > > this as it was mostly to faciliate the (still incomplete) gossip > > protocol. We can either leave it in, remove it, or rewrite it to > > more advisory/BCP and less restrictive ? Please dicsuss, otherwise > > it seems to consensus is to remove this claim. > > Why do you think the consensus is to remove? During the mailing list > discussion, Linus Nordberg, Tom Ritter, and I all spoke up in favor of > keeping it. No one spoke in favor of removal. > > Regards, > Andrew > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --0000000000009893ac056f305e9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I am not arguing for removal, but I don't think i= t's appropriate to have a recommendation which precludes the use of the= mode of RSA that we are otherwise telling people to use.

-Ekr

On Thu, Jun 21, 2018 at 10:19 AM, Andrew Ayer <ag= wa@andrewayer.name> wrote:

= On Wed, 20 Jun 2018 13:13:42 -0400 (EDT)
Paul Wouters <paul@nohats.ca> w= rote:

> 3. AD revieW: Remove the Preventing Tracking Clients claim
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://github.com/google/certificate-transparency-rfcs/pull/295 >
> We had some discussion on the list. Eric has pointed out this
> complicated RSA-PSS. Previous discussion talked about removing
> this as it was mostly to faciliate the (still incomplete) gossip
> protocol. We can either leave it in, remove it, or rewrite it to
> more advisory/BCP and less restrictive ? Please dicsuss, otherwise
> it seems to consensus is to remove this claim.

Why do you think the consensus is to remove?=C2=A0 During the mailin= g list
discussion, Linus Nordberg, Tom Ritter, and I all spoke up in favor of
keeping it.=C2=A0 No one spoke in favor of removal.

Regards,
Andrew

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

--0000000000009893ac056f305e9c-- From nobody Thu Jun 21 18:07:17 2018 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 E02C7130934 for ; Thu, 21 Jun 2018 18:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name 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 4KNKpxfGTgcn for ; Thu, 21 Jun 2018 18:07:14 -0700 (PDT) Received: from thompson.beanwood.com (thompson.beanwood.com [34.214.229.188]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F9512F1A5 for ; Thu, 21 Jun 2018 18:07:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1529629633; bh=+Pamg8QlfKjclhKXy07dzgVSwXAlu7V94LXQtY0Cw2I=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=BF08JaDGeIUP8B/EGVrtK7fM0n0kTPbT/g95WJyWZ1AKCQw6guSpOY6suL4uD1i5w D8547snOdZlXb8Weefjr2Es9e7ppq96RgWM8hsWm4eSvHZD3Qa/k1IZDZ5pX/2Ch6U Q8gIe9E9X5sHP7q2cp7QxjTKDoQRICO4tWX7pK7mGj0ryc8dUJmgiAHq/Jif2bDvMY 8Rfvg3GATSmGMKvawmjgg4fxFcSe4IJy9tX+EJRznFzIep2QL+7MqIfoTMLfErMwRW Mg3IjMSntnCtSHi+5ACeuEgiUaf+R0VStcxbYlV8z1nFaCuK1ltN15TqGX8pApg1dt QjBCeOCMH3mAw== Date: Thu, 21 Jun 2018 18:07:12 -0700 From: Andrew Ayer To: Eric Rescorla Cc: Paul Wouters , Trans Message-Id: <20180621180712.a3beba04afbc56ff1a7d6518@andrewayer.name> In-Reply-To: References: <20180621101958.8ea6f31b764a346e4d02e1c8@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Next steps for 6962-bis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 01:07:16 -0000 On Thu, 21 Jun 2018 17:46:18 -0700 Eric Rescorla wrote: > I am not arguing for removal, but I don't think it's appropriate to > have a recommendation which precludes the use of the mode of RSA that > we are otherwise telling people to use. Thanks for clarifying what your concern is. The recommendation doesn't preclude the use of RSA-PSS, or any other nondeterministic signature scheme. As reflected in the text, logs can satisfy the recommendation by signing a particular STH/SCT only once and storing the signature, instead of signing on demand. Regards, Andrew From nobody Thu Jun 21 18:17:24 2018 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 0F158130DBE for ; Thu, 21 Jun 2018 18:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 pFrESjdTnxR7 for ; Thu, 21 Jun 2018 18:17:20 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 4D7A512F295 for ; Thu, 21 Jun 2018 18:17:20 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5M1C899015326; Fri, 22 Jun 2018 02:17:19 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=dyIbTiS16JMWVoC/fVOIZbyw9wixiFVBJUYJaDhzi1M=; b=liDPF28qN0Vpx5AHY6PYrDNOknGMxUhMHAtov7Bn0/4lTVDKyAalSU7GmgGsauq8HpFQ GX4bEDUB8HVrYyN9pb+m+hN30foK+S8DKTt3NnwSqMB5yr7oAO1ZZ4cCrGwdi/uZW/WO jzVZGGKeC730C/s1DCzUBjmtRSaLkMCvZOopH3a2no8jeArID1zVFmqWK47wjQY5kekl WOQSYsUnE88exInzZval10SMpehLO/2yKvKCuEkvR8BF9ycWyigrvte4cw084u+jo8gN 08FYe3XuEt6S1ytt7CdvkO9g/hER7A+LK3LnKPONw50UL2wQWv+iZeqn1M2/AL4Had6A Uw== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2jrp7p047j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Jun 2018 02:17:19 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5M1B6jY016044; Thu, 21 Jun 2018 21:17:18 -0400 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint4.akamai.com with ESMTP id 2jrp70r5vy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 21 Jun 2018 21:17:17 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 21 Jun 2018 20:17:10 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Thu, 21 Jun 2018 20:17:10 -0500 From: "Salz, Rich" To: Paul Wouters , Trans Thread-Topic: [Trans] Next steps for 6962-bis Thread-Index: AQHUCLpo1oS15NyUwUCGgYpO6essNaRrjLaA Date: Fri, 22 Jun 2018 01:17:10 +0000 Message-ID: <4260F3FB-2919-4137-AB5A-506666E3D16D@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.45.4] Content-Type: text/plain; charset="utf-8" Content-ID: <1FCCBE5A3DB53E4FA3A11E45A5B4C2A7@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-21_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806220009 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-21_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806220009 Archived-At: Subject: Re: [Trans] Next steps for 6962-bis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 01:17:22 -0000 ICAgIFRoZXJlIGhhcyBiZWVuIGEgZGlzY3Vzc2lvbiBhYm91dCB0aGUgZG9jdW1lbnQgc3RhdHVz LCB3aGljaCB3YXMgc2V0IHRvDQogICAgUHJvcG9zZWQgU3RhbmRhcmQuIFJGQyA2OTYyIGl0c2Vs ZiBpcyBFeHBlcmltZW50YWwuIEFmdGVyIHNvbWUgZGlzY3Vzc2lvbg0KICAgIGJldHdlZW4gYXV0 aG9ycywgQUQgYW5kIGNoYWlycywgd2UgYWdyZWVkIHRoYXQgc2luY2UgdGhlIGNoYW5nZXMgYmV0 d2Vlbg0KICAgIDY5NjIgYW5kIDY5NjJiaXMgYXJlIG5vdCB0cml2aWFsLCBhbmQgdGhhdCB3ZSBo YXZlIG5vIGltcGxlbWVudGF0aW9ucw0KICAgIHlldCB0aGF0IHZhbGlkYXRlIHRoYXQgdGhlcmUg YXJlIG5vIGltcGxlbWVudGF0aW9uIGlzc3VlcywgdGhhdCB3ZSBzaG91bGQNCiAgICBjaGFuZ2Ug dGhlIGRvY3VtZW50IHN0YXR1cyB0byBFeHBlcmltZW50YWwuIFBsZWFzZSBzcGVhayB1cCBpZiB5 b3UNCiAgICBkaXNhZ3JlZSB3aXRoIHRoaXMgZGVjaXNpb24uDQoNClRoaXMgbmVlZHMgdG8gaGF2 ZSBjb25zZW5zdXMgZnJvbSB0aGUgV0cuICBJdCBzaG91bGQgbm90IGJlIGEgcHJpdmF0ZSBkZWNp c2lvbiBhbW9uZyB0aGUgQUQgYW5kIGNoYWlycy4gIFRoZSBhdXRob3IgaXMgbm90IHRoZSBvd25l ciBvZiB0aGUgZG9jdW1lbnQsIGl0IGlzIG5vdCBoaXMgdG8gY2hhbmdlLiAgQXJlIHlvdSBkb2lu ZyBhIGZvcm1hbCBjb25zZW5zdXMgY2FsbD8gIFNvIGZhciBvbmx5IEdvb2dsZSBoYXMgc2FpZCB0 aGV5IHdpbGwgc3Ryb25nbHkgc3VwcG9ydCA2MjkyLWJpcyBleHBlcmltZW50cy4gSSB3b3VsZCBs aWtlIHRvIGhlYXIgZnJvbSBvdGhlcnMsIGVzcGVjaWFsbHkgdGhvc2Ugd2hvIGFyZSBwYXJ0aWNp cGF0aW5nIGluIHRoZSBjdXJyZW50ICc2MjkyIGV4cGVyaW1lbnQnIGNvbW11bml0eSAtLSBsb2cg b3BlcmF0b3JzLCBmb3IgZXhhbXBsZS4NCg0KSW4gbXkgbGltaXRlZCBleHBlcmllbmNlLCAic3Bl YWsgdXAgaWYgeW91IGRpc2FncmVlIiBpcyB1c2VkIGFmdGVyIHRoZXJlJ3MgYmVlbiBkaXNjdXNz aW9uIGFuZCBpdCBzZWVtcyB0aGF0IGEgV0cgY29uc2Vuc3VzIGlzIGVtZXJnaW5nLiBEaXNjdXNz aW5nIGEgY2hhbmdlDQoNCkkgd2FudCB0aGlzIGRpc2N1c3NlZCBpbiBNb250cmVhbCBhbmQgdGhl biBoYXZlIGNvbnNlbnN1cyBjb25maXJtZWQgb24gdGhlIGxpc3QuDQogDQoNCg== From nobody Thu Jun 21 19:40:42 2018 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 3F2BC130DD2 for ; Thu, 21 Jun 2018 19:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 JC1lp6-CosMf for ; Thu, 21 Jun 2018 19:40:39 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::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 E4525130DC6 for ; Thu, 21 Jun 2018 19:40:38 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id q62-v6so2004022ybg.5 for ; Thu, 21 Jun 2018 19:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=enKDzDBiBjffW5lax4TWVr3zCLMYLrKaWjAVCS4IvfU=; b=wqwa0PKmS0EKGrQgR8vUgmtWiF9exX3yAaIr4L3q4WQuy0j2fm1CJt5UjeOWRI6pfz MGvv8/+ztAK+cRYLaAuV4BeshR0HzpHID6EPueOtDSUUOC3+WE9xTGHkUzY5HsjiQdPU f6dExqYZak7wu/+7d3gb/EwAK6demB4989w+yAQ1v9NnXH359TCHsthLXXlMYhVfyU8Y WeGFp82+ZvPKPhuWg1pMTxN6OcheK2RsMNAl/1k4tN/Iz9JXej/dWbh8oTz/DOaJaG+T PuKaO4rx9HheSkyXfVjP7voFZUvP2AdIdw317fWxg0Z7lhhKEH0nUQdjPxzmHAzkAapo xaEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=enKDzDBiBjffW5lax4TWVr3zCLMYLrKaWjAVCS4IvfU=; b=EhVgz3pujWEYQvTKAJsDjWOuyA9Kw9q3DiwBxBZya61+IJpCJa2urQqmZX41DRXItG TxjN9RRB2onxrxz1r1/D9YuYmf8sp67S1W17JidiDy7HQaBlz8dWp7t3MIyR4avhiHdp cd5NPKc4Y9ap8wljM8Puvm+JOtLjL1KDQYsKFwbl6wYpgjjvm9mp6713zRoavg6iV01H PDACDG8BcvHyk/lihBTBtgLx32kK/2LmjpvlcM0Ul6HpKgzvNz1Gts0OCD11wLbOeuff lawwPPk/WtfIiI+9yfzCDGVFxTS0BkGKRNXU0nc46Q9aAlUfwL2pyzxTiHgIDqvXl4MP Vhhw== X-Gm-Message-State: APt69E2rSAfpOo9k1e1tVVmSxtXsArzQopzbw9X/81hPd4cdlHub1GqW /7uBKc36I3rMHzGcx6daxEtG28PgrsQougGfdAU7Evh/ X-Google-Smtp-Source: ADUXVKKfPmxlBk0MJ3anny0qbqNz0uOfvTVKo+Hk3jpY/tVHf/VTXgZPIdoOfP86fI6SvWDqLiUy/kSFRmsEz7iHMoQ= X-Received: by 2002:a25:c9c3:: with SMTP id z186-v6mr14807751ybf.407.1529635238007; Thu, 21 Jun 2018 19:40:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:613:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 19:39:57 -0700 (PDT) In-Reply-To: <20180621180712.a3beba04afbc56ff1a7d6518@andrewayer.name> References: <20180621101958.8ea6f31b764a346e4d02e1c8@andrewayer.name> <20180621180712.a3beba04afbc56ff1a7d6518@andrewayer.name> From: Eric Rescorla Date: Thu, 21 Jun 2018 19:39:57 -0700 Message-ID: To: Andrew Ayer Cc: Paul Wouters , Trans Content-Type: multipart/alternative; boundary="000000000000ff6907056f31f4fa" Archived-At: Subject: Re: [Trans] Next steps for 6962-bis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 02:40:40 -0000 --000000000000ff6907056f31f4fa Content-Type: text/plain; charset="UTF-8" On Thu, Jun 21, 2018 at 6:07 PM, Andrew Ayer wrote: > On Thu, 21 Jun 2018 17:46:18 -0700 > Eric Rescorla wrote: > > > I am not arguing for removal, but I don't think it's appropriate to > > have a recommendation which precludes the use of the mode of RSA that > > we are otherwise telling people to use. > > Thanks for clarifying what your concern is. > > The recommendation doesn't preclude the use of RSA-PSS, or any other > nondeterministic signature scheme. As reflected in the text, logs > can satisfy the recommendation by signing a particular STH/SCT only > once and storing the signature, instead of signing on demand. > This doesn't sound very convenient, and given the rather unbaked nature of gossip, it seems like the wrong tradeoff. That said, it's a WG decision, so I trust the chairs to determine consensus. -Ekr --000000000000ff6907056f31f4fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Jun 21, 2018 at 6:07 PM, Andrew Ayer <agwa@andrewayer.name<= /a>> wrote:

On= Thu, 21 Jun 2018 17:46:18 -0700
Eric Rescorla <ekr@rtfm.com> wrot= e:

> I am not arguing for removal, but I don't think it's appropria= te to
> have a recommendation which precludes the use of the mode of RSA that<= br> > we are otherwise telling people to use.

Thanks for clarifying what your concern is.

The recommendation doesn't preclude the use of RSA-PSS, or any other nondeterministic signature scheme.=C2=A0 As reflected in the text, logs
can satisfy the recommendation by signing a particular STH/SCT only
once and storing the signature, instead of signing on demand.

This doesn't sound very convenient, and given th= e rather unbaked nature
of gossip, it seems like the wrong tradeo= ff. That said, it's a WG decision, so
I trust the chairs to d= etermine consensus.

-Ekr

<= /div>

--000000000000ff6907056f31f4fa-- From nobody Fri Jun 22 08:07:23 2018 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 672DA130E90 for ; Fri, 22 Jun 2018 08:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 V7n6E20JXxI4 for ; Fri, 22 Jun 2018 08:07:13 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 0A65E130E93 for ; Fri, 22 Jun 2018 08:07:13 -0700 (PDT) Received: from cmgw13.unifiedlayer.com (unknown [10.9.0.13]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 82F501E0BC7 for ; Fri, 22 Jun 2018 09:07:12 -0600 (MDT) Received: from box514.bluehost.com ([74.220.219.114]) by cmsmtp with ESMTP id WNe5fWQGAlpkrWNe6fCZDO; Fri, 22 Jun 2018 09:06:42 -0600 X-Authority-Reason: nr=8 Received: from [173.224.162.69] (port=2381 helo=[10.225.80.111]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1fWNeX-002H28-6f for trans@ietf.org; Fri, 22 Jun 2018 09:07:09 -0600 From: =JeffH To: trans@ietf.org Message-ID: <17e72fce-ba3a-5832-5568-fff3b4330dc2@KingsMountain.com> Date: Fri, 22 Jun 2018 08:09:16 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 173.224.162.69 X-Source-L: No X-Exim-ID: 1fWNeX-002H28-6f X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.225.80.111]) [173.224.162.69]:2381 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 1 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [Trans] fyi: Bandwidth-efficient Transparency Logs via Append-only Authenticated Dictionaries (AAD) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 15:07:19 -0000 of possible topical interest. I could not find the paper, perhaps it is not published as yet... From: security-seminar Date: Thursday, June 21, 2018 at 9:16 PM To: Subject: Tuesday, June 26 -- Aline Tomescu: Bandwidth-efficient Transparency Logs via Append-only Authenticated Dictionaries Bandwidth-efficient Transparency Logs via Append-only Authenticated Dictionaries Alin Tomescu Tuesday, June 26, 2018 Talk at 4:15pm Gates 463A, Stanford, CA Abstract: Transparency logs enable anyone to audit a potentially malicious service, paving the way towards a more ac- countable Internet. For example, Certificate Transparency (CT) enables domain owners to audit Certificate Authorities (CAs) and detect impersonation. Yet to achieve their full potential, transparency logs must be easily auditable by everyone. Specifically, everyone should be able to verify both (non)membership of log entries and that the log remains append-only. Unfortunately, current transparency logs either provide small-sized (non)membership proofs or small-sized append-only proofs, but never both. In this paper, we formalize and instantiate a new primitive called an append-only authenticated dictionary (AAD) that addresses this gap. Our construction provides succinct proofs for both (non)membership and append-only checks, solving an open problem in the authenticated data structures literature. We believe AADs can help scale transparency logs and add more accountability to today?s Internet. Bio: Alin is a PhD candidate at MIT focusing on public-key distribution for HTTPS and secure messaging. His interests lie at the intersection of theory and practice: he enjoys applied cryptography and building systems.Recently, Alin worked on Catena, a system that leverages the Bitcoin blockchain to prevent equivocation attacks on public-key directories. In the past, Alin has worked on privacy-preserving file systems, private social networking and secure email. Alin's other interests include cryptocurrencies, anonymous networks and distributed systems in general. From nobody Fri Jun 22 08:27:18 2018 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 4FA57130E96 for ; Fri, 22 Jun 2018 08:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 8ssf-fC7bNhH for ; Fri, 22 Jun 2018 08:27:14 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::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 7F87F130E98 for ; Fri, 22 Jun 2018 08:27:14 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id p129-v6so2519490ywg.7 for ; Fri, 22 Jun 2018 08:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mnraZXmy9UME1sCNEN0MOp3aWDeH4CUuhfv0k0Ly7e4=; b=i//89faacpPCEbWQftnaExL/zIubji2E5759L4ExCYqnieERq8i6ZnSs15wM2BTt2x q6E4XHCqQk6HhgQOEj3Sb5vGFTqxdLIKUTco/P+LgGccwK8knqLs6OcbaMCGGUfIjxGI AJX07XklG1+pu81ZQSHjV5AJLZ6zFphfCQ46hTg9FoJfd8hZu1cuP/nDtGETC5wF9Q3p lzshgnNaMkGKLaxnG46MQTpcS/IU+WgPdy7nDk3eB0h2YTUwvQMwxukXW68DRH91Dh+m Jju+iI92gOjK0/pxHceixQrNCglZsFUPeWgiOU95acQPuu6co6hLTEYJoNMEHOBn/zfO 3v/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mnraZXmy9UME1sCNEN0MOp3aWDeH4CUuhfv0k0Ly7e4=; b=XlUSxgK8vA3ohixrehQdiUOLNn/VPIjC5HyzXsqxla6vZk/NlD5H+6ug2ThkQN6bwC vWSVxysbZEYNkYQv055UHshLlTXya2GFCXXxGhfUw2z6rEsy9nIqQVeS/xoXEd5uvb67 BZ9oN9k15NTw899HowllpVBE19ZlISAvW3aCBGCkbo4UifIoO+QnvZU5RRVAan1U/ZWK r0byihdLq2Co1cMNlkvqO9a5Pa5KbDQUKZQqMil4oC/H8Jj/fnyqHsbnJXuwqplpvkCF fC+z2vWECcVY0pM+a1yRpnfZuTMgYiW9W7Zn15/5ksNeiTTbUWHTJRyc2I6snXceP6+w LetQ== X-Gm-Message-State: APt69E0VUtvUIjyex55d2ci7A44VfVbyaI8P8nF++33D1BPAvAnyvQ/S DmTu770Z1KtXD8/u0CThQPpLxVl011OB/Q/eQkOrHHHA X-Google-Smtp-Source: ADUXVKKsZyuTHggGkBAe9GYQ0iEBGnUc6CvRBPn3dFeith31kiWbAR+wlVKEqP+iXfxF/NQiIv/Ey5VD/gyLd94fwV8= X-Received: by 2002:a81:9152:: with SMTP id i79-v6mr1034160ywg.175.1529681233574; Fri, 22 Jun 2018 08:27:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:613:0:0:0:0:0 with HTTP; Fri, 22 Jun 2018 08:26:32 -0700 (PDT) In-Reply-To: <4260F3FB-2919-4137-AB5A-506666E3D16D@akamai.com> References: <4260F3FB-2919-4137-AB5A-506666E3D16D@akamai.com> From: Eric Rescorla Date: Fri, 22 Jun 2018 08:26:32 -0700 Message-ID: To: "Salz, Rich" Cc: Paul Wouters , Trans Content-Type: multipart/alternative; boundary="0000000000008c1442056f3caa03" Archived-At: Subject: Re: [Trans] Next steps for 6962-bis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 15:27:16 -0000 --0000000000008c1442056f3caa03 Content-Type: text/plain; charset="UTF-8" I think it would be good to see this discussed in YUL, and generally the WG does decide the level of the document but formally, the determination of the standards level is an IESG decision, as stated in https://tools.ietf.org/rfcmark up?doc=2026#section-6.1.2: The IESG is not bound by the action recommended when the specification was submitted. For example, the IESG may decide to consider the specification for publication in a different category than that requested. If the IESG determines this before the Last- Call is issued then the Last-Call should reflect the IESG's view. The IESG could also decide to change the publication category based on the response to a Last-Call. If this decision would result in a specification being published at a "higher" level than the original Last-Call was for, a new Last-Call should be issued indicating the IESG recommendation. -Ekr On Thu, Jun 21, 2018 at 6:17 PM, Salz, Rich wrote: > There has been a discussion about the document status, which was set to > Proposed Standard. RFC 6962 itself is Experimental. After some > discussion > between authors, AD and chairs, we agreed that since the changes > between > 6962 and 6962bis are not trivial, and that we have no implementations > yet that validate that there are no implementation issues, that we > should > change the document status to Experimental. Please speak up if you > disagree with this decision. > > This needs to have consensus from the WG. It should not be a private > decision among the AD and chairs. The author is not the owner of the > document, it is not his to change. Are you doing a formal consensus call? > So far only Google has said they will strongly support 6292-bis > experiments. I would like to hear from others, especially those who are > participating in the current '6292 experiment' community -- log operators, > for example. > > In my limited experience, "speak up if you disagree" is used after there's > been discussion and it seems that a WG consensus is emerging. Discussing a > change > > I want this discussed in Montreal and then have consensus confirmed on the > list. > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --0000000000008c1442056f3caa03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I think it would be good to see this discussed in YUL= , and generally the WG does

decide the level of the document but = formally, the determination of the standards level is

an IESG dec= ision, as stated in https://tools.ietf.org/rfcmarkup?doc= =3D2026#section-6.1.2:

   The IESG is not bound =
by the action recommended when the
   specification was submitted.  For example, the IESG may decide to
   consider the specification for publication in a different category
   than that requested.  If the IESG determines this before the Last-
   Call is issued then the Last-Call should reflect the IESG's view.
   The IESG could also decide to change the publication category based
   on the response to a Last-Call. If this decision would result in a
   specification being published at a "higher" level than the ori=
ginal
   Last-Call was for, a new Last-Call should be issued indicating the
   IESG recommendation.

-Ekr

On Thu, Jun 21, 2018 at 6:= 17 PM, Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.= org> wrote:

=C2= =A0 =C2=A0 There has been a discussion about the document status, which was= set to
=C2=A0 =C2=A0 Proposed Standard. RFC 6962 itself is Experimental. After som= e discussion
=C2=A0 =C2=A0 between authors, AD and chairs, we agreed that since the chan= ges between
=C2=A0 =C2=A0 6962 and 6962bis are not trivial, and that we have no impleme= ntations
=C2=A0 =C2=A0 yet that validate that there are no implementation issues, th= at we should
=C2=A0 =C2=A0 change the document status to Experimental. Please speak up i= f you
=C2=A0 =C2=A0 disagree with this decision.

This needs to have consensus from the WG.=C2=A0 It should not be a p= rivate decision among the AD and chairs.=C2=A0 The author is not the owner = of the document, it is not his to change.=C2=A0 Are you doing a formal cons= ensus call?=C2=A0 So far only Google has said they will strongly support 62= 92-bis experiments. I would like to hear from others, especially those who = are participating in the current '6292 experiment' community -- log= operators, for example.

In my limited experience, "speak up if you disagree" is used afte= r there's been discussion and it seems that a WG consensus is emerging.= Discussing a change

I want this discussed in Montreal and then have consensus confirmed on the = list.

=C2=A0

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

--0000000000008c1442056f3caa03-- From nobody Fri Jun 22 10:55:13 2018 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 6E031130EB9 for ; Fri, 22 Jun 2018 10:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 7Ib1V-oUVEBo for ; Fri, 22 Jun 2018 10:55:08 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 27FF7130E10 for ; Fri, 22 Jun 2018 10:55:08 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id q4-v6so6867367iob.2 for ; Fri, 22 Jun 2018 10:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pMUoQOX6dOZWrLuFB4xqSD1q1kyQYpqB57ahcDOlPIo=; b=Yoq8Rx+DMAu9izAXdgoPlvTDGVsp8WPV2SzZkUe4wQ3UsPgkjjSjvKl6WX5TB7ohGP ljGjWTf6Kb9KjJOOAsDzBMkvIhbSGI92Bp/qkgsNEqmUeebAG40D94xvf3WO1intGRxb zx4RB4X1pNCHszwd6Xdp0tVVzzqOhYw/NXAb2Xe+9yYxR2acNMs9qt9iI1Yny6IkChJP Bm0cpXiQfUHZYYV3OJKBwEadfi6dltl6u4wEJMrFjNuxi/Jnn1Aa1p8Qd6xrz04nGSVu WcNoKsatmKfb7MnJTCR7YGR/eZ0wwzXmrHA7yH4TwySdwXqyjS6LBiyRgqKHkay+eC8Y eaKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pMUoQOX6dOZWrLuFB4xqSD1q1kyQYpqB57ahcDOlPIo=; b=pat1WN1ROWUfw+W8JoFRbctJ8O/TI0c6XFiLIIf/gui69LNh/xo7dZ9App4Q/JHA8p pqoqvRtEX+uz27vImzQuTf/4W9ucjT5dAWtGCfwIlyIZ462tDrINj/Tpo/D50uinaEze wCBKXnNSS9vlNp8l6n9Eq364252DGFj/EjQFIsbYrdcNK5PVclEh/PCxbuiVtHPB1A8P Riht+oEncofJFljNeDfvVHGeREKChCjfvdHd+MgIB6qNWSG8F0Em1FvxXzug6uokSVpf 8x+oHC5sjEiPufkauLfkQ9ShlCkVfYqjhu1YR9rBapikvV+FHbD3gBgYNsVKAIjiByH6 JVPw== X-Gm-Message-State: APt69E3mv6tF96a39uWjivY/SsUje2yf86gkbFO7MeJo5771ZweSnAP8 aI4zLpNaWnz45m54yX3oDxdeMErGMtEh62LQlwuYrA== X-Google-Smtp-Source: AAOMgpekIl0QA9KhaMJjIbWGTxiiqeBa96m/seCDCqR1xBjqZl97C3x5nlLb3pQODHrgekcy/ANC7fymcQ3c16eewx8= X-Received: by 2002:a6b:fa09:: with SMTP id p9-v6mr2176654ioh.101.1529690107087; Fri, 22 Jun 2018 10:55:07 -0700 (PDT) MIME-Version: 1.0 References: <20180621101958.8ea6f31b764a346e4d02e1c8@andrewayer.name> <20180621180712.a3beba04afbc56ff1a7d6518@andrewayer.name> In-Reply-To: <20180621180712.a3beba04afbc56ff1a7d6518@andrewayer.name> From: Ben Laurie Date: Fri, 22 Jun 2018 10:54:55 -0700 Message-ID: To: Andrew Ayer Cc: Eric Rescorla , Paul Wouters , trans@ietf.org Content-Type: multipart/alternative; boundary="00000000000073e0cd056f3ebb11" Archived-At: Subject: Re: [Trans] Next steps for 6962-bis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 17:55:11 -0000 --00000000000073e0cd056f3ebb11 Content-Type: text/plain; charset="UTF-8" On Thu, 21 Jun 2018 at 18:07, Andrew Ayer wrote: > On Thu, 21 Jun 2018 17:46:18 -0700 > Eric Rescorla wrote: > > > I am not arguing for removal, but I don't think it's appropriate to > > have a recommendation which precludes the use of the mode of RSA that > > we are otherwise telling people to use. > > Thanks for clarifying what your concern is. > > The recommendation doesn't preclude the use of RSA-PSS, or any other > nondeterministic signature scheme. As reflected in the text, logs > can satisfy the recommendation by signing a particular STH/SCT only > once and storing the signature, instead of signing on demand. > That can't be a hard requirement without impacting availability, FWIW. > > Regards, > Andrew > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --00000000000073e0cd056f3ebb11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu= , 21 Jun 2018 at 18:07, Andrew Ayer <agwa@andrewayer.name> wrote:

On Thu, 21 Jun 2018 17:46:18 -0700
Eric Rescorla <ekr@rtf= m.com> wrote:

> I am not arguing for removal, but I don't think it's appropria= te to
> have a recommendation which precludes the use of the mode of RSA that<= br> > we are otherwise telling people to use.

Thanks for clarifying what your concern is.

The recommendation doesn't preclude the use of RSA-PSS, or any other nondeterministic signature scheme.=C2=A0 As reflected in the text, logs
can satisfy the recommendation by signing a particular STH/SCT only
once and storing the signature, instead of signing on demand.

That can't be a hard requirement without impacti= ng availability, FWIW.
=C2=A0

Regards,
Andrew

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

--00000000000073e0cd056f3ebb11-- From nobody Fri Jun 22 11:28:37 2018 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 49786130EC6 for ; Fri, 22 Jun 2018 11:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name 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 YqCxG1NNi135 for ; Fri, 22 Jun 2018 11:28:26 -0700 (PDT) Received: from thompson.beanwood.com (thompson.beanwood.com [IPv6:2600:1f14:a46:c400:6107:163e:4681:134e]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96179130EE5 for ; Fri, 22 Jun 2018 11:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1529692105; bh=L0nE3bXKNRHZ2qdKEbW3WrpHykaMUiszeFeXghjvANY=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=DQrBIUI/eCZ6DYVUN+uQH6y4ZCldcpf6/WAXwVA2FsewSrv5RcpYpcRkop1ci/GbG QsnKbXQFVYiU4iQuWBb8505A9Y71nJm2G/Zp9h5eldR+hDKsutfZiNPVz2zvvJUp0s 870ivd23DMeEh2wjULUOf0yz7ya9uO/5SjH0ReYL0FEcc3WVIWQAhPjtiU5hZCNNPi eT+EYmOG6oGDqhkWIlrpR+5AQugeHFhCDzh0KjW2Xr8L+0cOnyPLXx+uC1Ma1Q71UK YG0jUZR2qSfJvpiZdBbzemDk6p1bCr0oAj0g84hYocMU5OJmrPPA1mDhdAuVMOW6vY Cu6Lxe070+FPw== Date: Fri, 22 Jun 2018 11:28:24 -0700 From: Andrew Ayer To: Ben Laurie Cc: Eric Rescorla , Paul Wouters , trans@ietf.org Message-Id: <20180622112824.69fef8f215addfa786b4096b@andrewayer.name> In-Reply-To: References: <20180621101958.8ea6f31b764a346e4d02e1c8@andrewayer.name> <20180621180712.a3beba04afbc56ff1a7d6518@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Next steps for 6962-bis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 18:28:35 -0000 On Fri, 22 Jun 2018 10:54:55 -0700 Ben Laurie wrote: > On Thu, 21 Jun 2018 at 18:07, Andrew Ayer > wrote: > > > On Thu, 21 Jun 2018 17:46:18 -0700 > > Eric Rescorla wrote: > > > > > I am not arguing for removal, but I don't think it's appropriate > > > to have a recommendation which precludes the use of the mode of > > > RSA that we are otherwise telling people to use. > > > > Thanks for clarifying what your concern is. > > > > The recommendation doesn't preclude the use of RSA-PSS, or any other > > nondeterministic signature scheme. As reflected in the text, logs > > can satisfy the recommendation by signing a particular STH/SCT only > > once and storing the signature, instead of signing on demand. > > > > That can't be a hard requirement without impacting availability, FWIW. Is that true of both STHs and SCTs, or just SCTs? Regards, Andrew From nobody Fri Jun 22 11:46:03 2018 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 D7954130EAF for ; Fri, 22 Jun 2018 11:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 VFYDzSDLpCFq for ; Fri, 22 Jun 2018 11:45:59 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 F3FB1130EC5 for ; Fri, 22 Jun 2018 11:45:58 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id s26-v6so6989632ioj.4 for ; Fri, 22 Jun 2018 11:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T5/rWJFCVoAm1wlYAbG4h4psESL1gWEiKYhbyIrcUPU=; b=ql4hPSAixrI6ewW8GAEAxtPFm7LN7Qz/jLpq65Q+LevvpVbUdknggaxv5poFmvwv3A H+SjkObjMnsRHyG3GpsDRHz9hts1leaAIrln7LOGr4CpO1B/ZmGww0s1dbACFA0OExaT 3u39oKRCU+nobZF9wBBK4UO3Ww//rotrAgevhFX1ifsYGwueo+o6RQ/1affPbpSANcUk j/mAFu97aG2bGs9iAWmmX1kmh6oEADJ7VbVhpNX0qfvhST0cZVARNVOxQjAs+KPGwDa9 tMxdXE7XumeRCeDjRC0Y4zzvPO/pMnh7BZaLpyzDjEg2MNNiawgox6JaeAXRu6wCx3sN UJFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T5/rWJFCVoAm1wlYAbG4h4psESL1gWEiKYhbyIrcUPU=; b=OJF5FDe/tB/hZZWHCoa5RKn9Z4ELHZycfi8jMyF4+xT6oDMgZvXJrtMuYEzkJ1wT2c wjWoh5/DZK+Trvv2dtWj3h1EuNn4mi97E4RvGi9G3UN3qXmBll4sCUd09htKuAVW5YXr 7qWowfTaaShRTvkgD58zh1B5A6NvBsGKLEWH0b7N0QGYejnWJ0uqsT8g8fy8WG2RoJGy KQtaKS8hyusmDNeCvop0JCgh+UWLgT9GyYNK09Z4cJjsWpDHtV11cQ2mswM0m+iim9o4 MgTn6xHyfViS9Jj7PQZulUPcLKCtYsWgAFF5CpsHWOJtsHuaUp+SE7PxVEj3xRsCqfFd mVlA== X-Gm-Message-State: APt69E0nm/LMqMNaSydGpdtABPGsaRQR2J33Q6jnhsKh4osKlgxBeqb2 yHh/d45s6w+Zfh+FrTKBt23Cz9uKdWlwZFDeKXqBxg== X-Google-Smtp-Source: AAOMgpeKjidjqr06AfY4mUvJCYzbP+9ETummcm4wHkRU17aF81t8vlxVOcB4snPqSgM/B1kkSGfWdufvyfLoCCxXdKs= X-Received: by 2002:a6b:4a15:: with SMTP id w21-v6mr2136039iob.277.1529693158037; Fri, 22 Jun 2018 11:45:58 -0700 (PDT) MIME-Version: 1.0 References: <20180621101958.8ea6f31b764a346e4d02e1c8@andrewayer.name> <20180621180712.a3beba04afbc56ff1a7d6518@andrewayer.name> <20180622112824.69fef8f215addfa786b4096b@andrewayer.name> In-Reply-To: <20180622112824.69fef8f215addfa786b4096b@andrewayer.name> From: Ben Laurie Date: Fri, 22 Jun 2018 11:45:45 -0700 Message-ID: To: Andrew Ayer Cc: Eric Rescorla , Paul Wouters , trans@ietf.org Content-Type: multipart/alternative; boundary="0000000000004da251056f3f712b" Archived-At: Subject: Re: [Trans] Next steps for 6962-bis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 18:46:01 -0000 --0000000000004da251056f3f712b Content-Type: text/plain; charset="UTF-8" On Fri, 22 Jun 2018 at 11:28, Andrew Ayer wrote: > On Fri, 22 Jun 2018 10:54:55 -0700 > Ben Laurie wrote: > > > On Thu, 21 Jun 2018 at 18:07, Andrew Ayer > > wrote: > > > > > On Thu, 21 Jun 2018 17:46:18 -0700 > > > Eric Rescorla wrote: > > > > > > > I am not arguing for removal, but I don't think it's appropriate > > > > to have a recommendation which precludes the use of the mode of > > > > RSA that we are otherwise telling people to use. > > > > > > Thanks for clarifying what your concern is. > > > > > > The recommendation doesn't preclude the use of RSA-PSS, or any other > > > nondeterministic signature scheme. As reflected in the text, logs > > > can satisfy the recommendation by signing a particular STH/SCT only > > > once and storing the signature, instead of signing on demand. > > > > > > > That can't be a hard requirement without impacting availability, FWIW. > > Is that true of both STHs and SCTs, or just SCTs? > STHs already require a master, so just SCTs. Well, modulo some ingenious architecture I can't currently imagine. > > Regards, > Andrew > --0000000000004da251056f3f712b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri= , 22 Jun 2018 at 11:28, Andrew Ayer <agwa@andrewayer.name> wrote:

On Fri, 22 Jun 2018 10:54:55 -0700
Ben Laurie <benl=3D40google.com@dmarc.ietf.org> wrote:

> On Thu, 21 Jun 2018 at 18:07, Andrew Ayer <agwa@andrewayer.name>
> wrote:
>
> > On Thu, 21 Jun 2018 17:46:18 -0700
> > Eric Rescorla <ekr@rtfm.com> wrote:
> >
> > > I am not arguing for removal, but I don't think it's= appropriate
> > > to have a recommendation which precludes the use of the mode= of
> > > RSA that we are otherwise telling people to use.
> >
> > Thanks for clarifying what your concern is.
> >
> > The recommendation doesn't preclude the use of RSA-PSS, or an= y other
> > nondeterministic signature scheme.=C2=A0 As reflected in the text= , logs
> > can satisfy the recommendation by signing a particular STH/SCT on= ly
> > once and storing the signature, instead of signing on demand.
> >
>
> That can't be a hard requirement without impacting availability, F= WIW.

Is that true of both STHs and SCTs, or just SCTs?

STHs already require a master, so just SCTs. Well, modulo some i= ngenious architecture I can't currently imagine.

=C2=A0

Regards,
Andrew

--0000000000004da251056f3f712b--