Minutes IETF102: trans
Public Notary Transparency
||Minutes IETF102: trans
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)
6962-bis has six open items to resolve to be able to close
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
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.
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
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
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
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.
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
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.