Minutes IETF98: trans
minutes-98-trans-00

Minutes, trans working group, IETF 98
Tuesday, March 28 2017


Summary:
--------

    .  6962-bis still has some open issues to resolve, most
       have been addressed.  Rest will be brought to mailing
       list.
    .  <somebody> will produce a draft describing how to
       provide stronger guarantees to clients
    .  there are three existing proposals for how to do
       redaction; Symantec has implemented and deployed one
       of them.  There is a question about whether or not
       redaction is compatible with transparency goals,
       particularly given the additional complexity it
       introduces
    .  there is interest in logging binaries but the current
       draft is not seen as a good basis for further work
       


Introduction
------------

Agenda-bashing

Thank you to Stephen Farrell.

Status update
-------------
No changes to the charter, still behind schedule.  42 open
tickets, many of them new.  6962-bis did not complete
working group last call successfully.  Several competing
proposals for name redaction.

Threat analysis document is stuck and we need to get this
done.  (Deb Cooley has since volunteered to wrap it up and
get it out).

CT Gossip has completed working group last call and has been
sent to the IESG (many thanks to the authors, and to those
who reviewed and commented).

No update on CT-DNSSEC.  There was some interest in the room
in seeing it progress, but we need drafts.

New interest in picking up work on CT-binaries, will be
discussed later.

6962-bis update (Eran Messeri)
------------------------------

During wglc, received significant feedback from Mozilla, in
roughly 4 categories: 1) architecture, 2) data structures,
3) editorial, and 4) http api.  Goal was to provide stronger
guarantees to clients.  All issues have tickets in the issue
tracker and almost all have been triaged.  There's agreement
on almost all recommended changes, and they will be brought
to the working group for consensus.  All of the editorial
suggestions seem sensible.  Please review open tickets and
provide feedback.

One issue that needs to go out to the mailing list is the
question of whether or not the timestamp should be removed
from the STH, as it doesn't help with proof of liveliness.

The question of BCP 190 compliance received extensive
discussion and needs to go to the mailing list as well.  The
goal of BCP 190 is to avoid overly constraining web
application deployment by preallocating portions of the
namespace.  On the other hand log operators do not feel
overly constrained, and this may be a case of adding
complexity for no actual purpose.

Richard Barnes and Eran will work together to resolve
several issues around the set of artifacts a log is expected
to produce, and bring it to the mailing list.

No agreement on: 1) whether log IDs should be OIDs or
INT32s, and 2) whether OIDs should come from an IANA-managed
registry.

Way forward:

  .  Write up clarifications/suggestions in filed tickets,
  .  Pull requests for issues where there's agreement,
  .  Post each change to mailing list,
  .  Hash out few remaining disagreements, and
  .  New document to describe a variant of CT with stronger
     guarantees for clients

Privacy and redaction
---------------------

Saba Eskandarian presented a redaction proposal and
privacy-preserving proofs - the problems he addresses in his
work are
   .  Private subdomains,
   .  Privacy-preserving proof of SCT exclusion, 
   .  Actionable proofs of exclusion,
   .  Privacy compromises, and
   .  CT and short-lived certificates

but he focused on the first two during the meeting.  Work is
based on a commitment scheme.  Most of the concerns raised
about this particular scheme apply to redaction more
generally.

Clint Wilson presented an overview of the state of redaction
in CT, to provide background and set a baseline for further
discussion.  He drew a distinction between withdrawing
information from a log (for example, a legal requirement to
remove PII), which he said is not worth pursuing right now
in the working group, and not logging sensitive information
in a certificate in the first place.  There are three active
proposals today:
   .  Rob Stradling's proposal, from 6962bis-17
   .  Saba's proposal (from earlier in the session)
   .  Symantec's precertificate transformation extension

DKG reinforced the difference between dealing with toxic
data that need to be removed, on the one hand, and data in
logged certificates that needs to be concealed.  Wes
Hardaker pointed out the inherent tension between committing
to logging certificates and then complicating things
considerably by choosing not to log some data.  Because we
were short on time, the discussion was moved to the mailing
list.

Logging binaries (Frank Xia)
----------------------------

Goal is to reuse CT technology to log binary (software), or
its digest, to provide public auditability of software
distributions.  Issues raised include:

   .  How to avoid log spam (certificates have signatures
      that can be verified, but how would you avoid logging
      random hashes?
   .  Richard Barnes pointed to some work at Mozilla in
      which a digest of the binary is encoded into a domain
      name, put into a certificate, and the certificate is
      logged via CT
   .  DKG pointed to some work going on outside the IETF
      with free software distributors.  It is important to
      log identity and version of the software, and it's not
      clear that that's in the current draft.
   .  Martin Thomson asked if the machinery associated with
      an SCT is really necessary
   .  Adam Langley said that it needs to be tied into
      verifiable builds and other mechanisms associated with
      provable provenance
   .  EKR said that what Mozilla is trying to accomplish is
      to establish confidence that when you download a
      version of a piece of software, you're getting the
      same version as everybody else.  Verifiable builds are
      a worthy goal but a simpler mechanism is still useful
   .  He also said that the reason Mozilla went with putting
      digests in certs is that there's an existing
      infrastructure they were able to leverage, and there
      are logs operating today.
   .  Rich Salz pointed to attribute certificates as an
      example of certificates that do not have associated
      keys as a way to address both the spam issue and the
      identity issue.
   .  Phill Hallam-Baker pointed to Comodo's code-signing
      infrastructure, and mentioned problems around
      differences in code signing practice among CAs.

Hums taken:  Is there interest in seeing this work go
forward in the IETF, even if not in the trans working group?
Some interest.  Is this draft appropriate as a basis for
this work?  No.