Minutes IETF102: trans
minutes-102-trans-00

Public Notary Transparency (trans)
IETF 102: 11:00 - 12:00 19 July 2018
Chairs: Paul Wouters, Melinda Shore
Minutes by Melinda Shore
(video at https://www.youtube.com/watch?v=ioxoCb9nLfM)


Status update
-------------

6962-bis has six open items to resolve to be able to close
the document:

1) change status from "Proposed Standard" to "Experimental
   Standard": There was some confusion about what was meant
   by "experimental."  There was agreement that the revision
   from 6962 to 6962-bis is extremely valuable and everybody
   plans to implement -bis, but it's going to take some
   time.  There didn't seem to be any objection

2) In EKR's AD review, he asked that we remove the "preventing
   tracking clients" claim.  Andrew Ayer disagrees, as we
   don't know yet how gossip is going to work, and it might
   not be possible to deploy gossip if there's concern that
   it's going to lead to tracking.  We'll take it to the
   mailing list

3) Also in EKR's AD review, he asked that we remove the "no
   security implications" claim.  EKR was not in the room,
   so we'll delay discussion until he's available

4) Fotis Loukos requested that we clarify what we mean by
   "current NTP time."  There is no proposed text.  Given
   how late this is in the process, if someone doesn't give
   us text there's nothing to talk about, so if someone
   feels strongly about this they should contribute text.
   Nobody expressed concern.  Fotis should produce text, or
   we'll drop it.

5) Using JSON format for error reporting: concern was that
   in some cases intermediates were being rate-limited but
   didn't know what the actual problem was.  Corey Bonnell is
   going to produce text.  Tim Hollebeek was concerned about
   making it mandatory and asked if it was going to be a
   SHOULD.  We'll have it be a SHOULD for now, and if it
   works well we'll turn it into a MUST when the document is
   published as a proposed standard.

6) Option for CT logs to signal when rejections were due to
   rate limiting:  this is covered by the proposal to use
   the JSON error reporting format


Trans threat analysis
---------------------

There hasn't been much progress and we don't want to keep
the working group open for just this document.  There
doesn't seem to be much interest among working group
participants.  Rich Salz thinks we should flip a coin to
settle the difference - he thinks the document has value.
Paul and Melinda will discuss it after the meeting and take
it back out to the mailing list.


Other documents
---------------

Gossip, binaries logging, and client behavior:  if there's
progress on those documents we can take it to a new working
group.  We don't need to remain open for those.  NTIA is
holding a workshop on software module transparency, and a
specification may come out of that (wrt binary
transparency), and Paul has a proposal for DNS transparency
that doesn't reuse the CT format, so is probably a fit for
another group.


Redaction
---------

Ben Schwartz asked about redaction and IP address
certificates.  Paul said that the people who are interested
in working on that should write it up and organize a BOF.
Tim Hollebeek said that the lack of activity on this is due
entirely to the browser community, and that there are CAs
who continue to be interested in doing something about
redaction.  None of the current methods work particularly
well.  Tim encouraged people who are interested in this to
have discussions with browser root programs and to see if
they can get some interest there, but this working group
doesn't need to hang around for that.

Ben pointed out that IP address certificates have very
different security properties, and he's concerned about
creating a situation in which there's an enumeration of
every address that's ever requested an IP certificate.

Tim said that IP certificates are rare and they have a
number of issues, so they're being discussed actively in the
CA/B Forum.

Devin from Google Chrome asked why logging IP certificates
is particularly concerning.  Ben's use cases are services
operated by clients that they want to be able to use
securely from a browser but that they don't want publicly
known.  IPv4 addresses can be trivially enumerated but IPv6
addresses cannot, and he'd prefer if they weren't logged in
CT logs.

Tim pointed out that this conflicts with the "transparency"
aspect of CT and he doesn't know how to weigh the
tradeoffs.  In existing redaction cases it turns out that
people thought they were doing a better job of hiding things
than they were.  For example, most of the certificates not
logged by Symantec ended up being logged by Google, anyway.


EKR's review concerns
---------------------

He's happy to go along with the working group decision on the
"preventing tracking clients" text.  His concern is that the
text says "don't use deterministic signatures" and in the
meantime the IETF is pushing people using RSA towards PSS,
so those seem to be in conflict.  He's not pressing towards
any particular resolution.

With respect to the "no security implications" text, it's
fine with him.  Andrew Ayer said that he thinks there was
some confusion about this was in there in the first place.
The original intent was anti-spam, but Andrew pointed out
that it's not just anti-spam, but to link every certificate
back to a certificate authority so that browsers can take
action if there's a problem.  So, there is a security
implication and it's not just anti-spam.  EKR suggested it
would be useful if someone would add some text to that
effect.  The PR does include explanatory text.  EKR: "looks
good to me."  He expects a new draft relatively soon.


Shutting down
-------------

Paul asked what happens to unfinished working items when a
working group closes down.  Alissa says that it's up to us,
and the options are that the documents can be AD-sponsored,
or they can just expire.  For example, the gossip draft
could potentially be AD-sponsored.  Alissa said that we
should keep the wg open until the -bis document is finished,
and we might as well progress the other documents while
we're open.

Devin from Chrome asked what should be done if his group
comes up with new proposals - where should those those be
taken?  We could potentially spin up a new working group.
Chrome is hoping to have initial feedback around the time of
IETF 104.  EKR said that if what's found would just involve
small changes, we could essentially rebadge 6962-bis as a
proposed standard.  If the changes are not small, we could
spin up a new working group.

Tim will probably have proposed improvements before 104, and
he thinks they'll mostly take the form of new features
rather than changes to the existing protocol.  Those are
better handled as new drafts rather than as -bis-bis.

Alissa: close the group but keep the mailing list.