Subject: [Trans] Next steps for 6962-bis

From: Paul Wouters <[email-masked]>
Date: Wed, 20 Jun 2018 13:13:42 -0400 (EDT)

We just wanted to clarify where we are with 6962bis. We have scheduled a
meeting at IETF102, and I think it would be a good goal to discuss the
remaining items on the list now and see if we can wrap this up in
Montreal. We have a short timeslot, so let's try and wrap up the
main discussions before Montreal. Rob Stradling gave us a nice summary
list of open items to talk about. Thanks Rob!

1) Document status

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.

Proposed textual change:

 	https://github.com/google/certificate-transparency-rfcs/pull/297

One suggestion by Rob was to perhaps clarify why we are going from
Experimental to Experimental. If you think this is needed, please let
us know (or better, provide text)

2. AD review: Remove the 'no security implications' claim

 	https://github.com/google/certificate-transparency-rfcs/pull/296

No one objected on the list, but Rob would like to hear at least one
more voice agreeing with this change. If we don't hear any objections,
we will proceed with this change.

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.

4. Fotis Loukos proposed clarifying what we mean by "current NTP Time".

Does this need clarification? Or can it punt this to other documents?
If this is needed, we need someone to write up the text required.
If we don't hear from others, we will not make any change.

5.  Corey Bonnell proposed switching error reporting to use the JSON Problem Details format (RFC7807).

If this is needed, we need someone to write up the text required.
Please discuss. If we don't hear from others, we will not make any change.

6. Option for CT logs to signal when rejections were due to rate-limiting

If this is needed, we need someone to write up the text required.
Please discuss. If we don't hear from others, we will not make any change.

Paul & Melinda

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 20 Jun 2018 17:30:47 +0000

I will start by saying that I am very disappointed in the lack of openness. The fate of a WG document should be discussed in the official WG channels.

>    1) Document status
  
The proposal would now swap one experiment for another. The first is being deployed yet the second is newer.  I do not think we are doing the Internet any great service to posit two experiments at the same time, in the same area, with differences that are apparently not compelling enough to entice the nascent ecosystem to migrate.

We should withdraw this document from any publication stream.  What is the point of publishing it?

---

From: Paul Wouters <[email-masked]>
Date: Wed, 20 Jun 2018 13:46:06 -0400 (EDT)

> I will start by saying that I am very disappointed in the lack of openness. The fate of a WG document should be discussed in the official WG channels.

That is what we are doing now?

> The proposal would now swap one experiment for another. The first is being deployed yet the second is newer.  I do not think we are doing the Internet any great service to posit two experiments at…

The idea would be that the 6962 experiment is phased out for the 6962bis
experiment. The motivation for not making it a proposed standard, is
that we currently have no implementations and that the changes between
the two documents are not minor. If we don't do this, we could end up
with a Proposed Standard document that is not usable.

> We should withdraw this document from any publication stream.  What is the point of publishing it?

The idea is to see implementations, confirm proper functioning and
then (maybe with some minor changes that we learned from running the
experiment) publish this as Proposed Standard.

Note that the IETF currently is also discussing the meaning of these
statuses and how people inside and outside the IETF community see these.
The 6962 document is a good example of how the status of Experimental
does not really reflect deployment (mainline browsers making this
experimental feature mandatory for millions of users)

I don't see anything changing in practise based on changing the status
of this document. Regardless of the status, we will see the existing
experiment continue until a few CT logs with the 6962bis code pop up,
and then when successfull, a gradual move from 6962 log servers to
6962bis log servers.

However, withdrawing the publication would leave 6962 as the only
kind of CT log server, and we would miss all the improvements that
we worked on for years with 6962bis ?

Paul

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 20 Jun 2018 18:12:01 +0000

>    That is what we are doing now?
  
Better late than never.  The PR is five days old.  When did the discussions happen?  Why did they not happen on the WG mailing list? You can consider those rhetorical questions.

>    The idea would be that the 6962 experiment is phased out for the 6962bis
    experiment. 

Yes, I know.

  
Do you have any indication that anyone else is looking at deploying this?  I mean "experiment" is a pretty weak enticement, especially compared to a proposed Internet standard.  I believe there will be no experiments deployed.  From everything I've seen, the community is focused only on 6962.

Yes, it is frustrating to see so much effort wasted.  But I truly believe it's the honest thing to conclude.  Has anyone from any log made any pubic commitment to deploy the next experiment?

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 20 Jun 2018 15:30:08 -0400

On Wed, Jun 20, 2018 at 2:12 PM, Salz, Rich <
rsalz=[email-masked]> wrote:
> Do you have any indication that anyone else is looking at deploying this?
> I mean "experiment" is a pretty weak enticement, especially compared to a
> proposed Internet standard.  I believe there will be no experiments
> deployed.  From everything I've seen, the community is focused only on 6962.
>

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

I think your belief that there will not be experiments is not well-founded.
Google is strongly interested in 6962-bis.

While 6962 is being required for new certificates, it is merely a stepping
stone towards the overall goal of CT as a holistic ecosystem. 6962-bis
provides a number of compelling advantages over 6962, both in terms of
protocol and in terms of the policy options it affords. For example,
certain policy options are simply not available under 6962 while obtaining
the necessary privacy and performance goals of all participants in the
ecosystem.

Google is interested in supporting 6962-bis in its open-source log software.
Chrome is interested in supporting 6962-bis in its client software.

I can't speak for the log software timeline, but Chrome sees this as
something to be looking at for 2019, rather than 2018, due to significant
changes already underway in the Web PKI - such as the rollout of 6962 and
the deprecation of trust in large CAs.

I can't speak for other user agents, but in our discussions with them, it
appears there's consensus that 6962-bis allows deeper explorations of
policy challenges that remain unaddressed by 6962 (at least, not without
sacrificing some essential property that is non-negotiable).

To successfully experiment, it will need log operators and CAs willing and
able to do experiments, side-by-side with 6962. That is, dedicated -bis
logs, and CAs logging to both 6962 and 6962-bis logs and presenting SCTs
from both. 6962 and 6962-bis will need to exist side-by-side for some time.
It is not expected that CAs will be required to adopt 6962-bis until such
experiments have been done, and so the notion of a flag day transition is
simply non-viable.

It's helpful to think of this as something akin to the -draft experiments
done by TLS1.3, working from an idealized protocol on paper into one that
can be successfully and interoperably be deployed at Web scale. Just as
with TLS1.3 discussions, there will no doubt be practical tradeoffs that
need to be made that sully the platonic ideal of the protocol, but ensure
the ability to successfully deploy. Unlike TLS1.3, however, the ecosystem
interoperability tests require much greater timeframes, and so the notion
of 1-2 year long inter-draft stages is also not viable.

Chrome's focus on communicating this view and understanding has been with
other log operators and user agents, as those most affected by both the
policy implications and the technical roadmaps. I can understand we've been
relatively quiet within this WG, both in part because the IETF process
model does not lend itself well to how browsers are developed and iterate,
and due to other significant changes in the Web PKI going on during the
same period. In this regard, the experimental status is both an accurate
and near-ideal representation of where 6962-bis is and the value it can
bring, while also highlighting that the validation of the ideas and
improvements in 6962-bis will take time. As the recent issues with the
Threat Model document highlight, or the recent issues discussing
Cloudflare's reading of 6962 vs the intent of Chrome, even the present
document can benefit from improvements and clarifications that only reveal
themselves once there are real world implementations being worked on.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 20 Jun 2018 15:31:53 -0400 (EDT)

> Do you have any indication that anyone else is looking at deploying this?  I mean "experiment" is a pretty weak enticement, especially compared to a proposed Internet standard.  I believe there wil…

We were told by one vendor that expects to begin work their 6962bis implmentation in half a year.

> Yes, it is frustrating to see so much effort wasted.  But I truly believe it's the honest thing to conclude.

I do not think that is the thing to conclude.

> Has anyone from any log made any pubic commitment to deploy the next experiment?

I don't know. Perhaps the vendors on this list can answer this question?

Paul

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 20 Jun 2018 20:01:11 +0000

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

Most organizations have limited resources and cannot implement everything, and focus on things like standards-track.  Perhaps I used the wrong word.

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

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 20 Jun 2018 17:21:19 -0400

On Wed, Jun 20, 2018 at 4:01 PM, Salz, Rich <
rsalz=[email-masked]> wrote:

>
>    - I'm not sure what you mean by "enticement". The document status is
>    by no means an enticement to implementation.
>
>
>
> Most organizations have limited resources and cannot implement everything,
> and focus on things like standards-track.  Perhaps I used the wrong word.
>
>
>
> At any rate, I am glad that Google is strongly interested in 6962-bis. I
> don’t understand how a mailing list discussion in an IETF WG doesn’t work
> well for browser development – doesn’t Google do much work through mailing
> lists? – but I am glad you spoke up now.
>

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

As far as list participation 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 that we think this is a solid and welcome forward path,
and one that hopefully produces lower risk to the ecosystem than pursuing
it as Standards Track without any real world implementation experience or
running code.

---

From: Andrew Ayer <[email-masked]>
Date: Thu, 21 Jun 2018 10:19:58 -0700

On Wed, 20 Jun 2018 13:13:42 -0400 (EDT)

> 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: Eric Rescorla <[email-masked]>
Date: Thu, 21 Jun 2018 17:46:18 -0700

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 <[email-masked]> wrote:

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Andrew Ayer <[email-masked]>
Date: Thu, 21 Jun 2018 18:07:12 -0700

On Thu, 21 Jun 2018 17:46:18 -0700
Eric Rescorla <[email-masked]> 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: "Salz, Rich" <[email-masked]>
Date: Fri, 22 Jun 2018 01:17:10 +0000

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.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Jun 2018 19:39:57 -0700

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 22 Jun 2018 08:26:32 -0700

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:
<https://tools.ietf.org/rfcmarkup?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 <rsalz=[email-masked]
.org> wrote:

> 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
>

---

From: Ben Laurie <[email-masked]>
Date: Fri, 22 Jun 2018 10:54:55 -0700

> once and storing the signature, instead of signing on demand.

That can't be a hard requirement without impacting availability, FWIW.

---

From: Andrew Ayer <[email-masked]>
Date: Fri, 22 Jun 2018 11:28:24 -0700

On Fri, 22 Jun 2018 10:54:55 -0700
Ben Laurie <benl=[email-masked]> 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.
> >

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

Regards,
Andrew

---

From: Ben Laurie <[email-masked]>
Date: Fri, 22 Jun 2018 11:45:45 -0700

> 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.