►
From YouTube: IETF92-TRANS-20150323-1300
Description
TRANS meeting session at IETF92
2015/03/23 1300
A
A
B
Hello,
I'm
Daniel,
con
Gilmore,
so
Linus,
Nordberg
and
I
have
worked
on
the
draft
about
how
to
how
we
use
gossip
in
this
certificate
transparency
model
to
try
to
provide
additional
additional
checks
on
some
of
the
players
in
the
in
the
CTE
ecosystem.
I.
Think
Steve's,
description
of
this
as
a
complex
system
with
lots
of
moving
parts
is
definitely
something
to
be
concerned
about,
and
so
the
gossip
draft
rise
to
address
that,
specifically
with
the
goal
of
trying
to
make
sure
that
the
logs
are
not
misbehaving.
So
just
wanted
to
clarify
this
right.
B
The
goal
of
the
gossip
is
to
make
sure
that
the
logs
are
are
doing
what
they
claim
that
they
would
do
so
logs
need
to
prove
that
they
are
honoring
the
MMD,
the
minimum
merge
delay.
I
think
I
got
that
acronym
right
and
then
they
need
to
make
sure
that
they
also
they
shouldn't
be
presenting
split
views
of
the
history
that
they
provide
to
like
two
different
clients:
query
them.
They
shouldn't
be
able
to
provide
one
view
to
one
client
and
another
v
to
another
and
the
folks
who
are
doing
this.
We've
called
them
auditors.
B
Traditionally,
I've
noticed
some
discussion
in
the
landless
that
we're
dropping
the
term
auditor
or
something-
and
I'm
actually
a
little
surprised
by
that.
Maybe
I
missed
that
part
of
the
discussion,
so
we
have
traditionally
called
the
folks
who
are
checking
up
on
the
logs
auditors
so
I'm
using
that
term
still
here,
if
we're
not
supposed
to
be
using
that,
then
I'd
like
to
know
what
we
should
call
it,
because
it's
a
different
job
than
the
monitoring
job
yeah.
B
So
looking
at
the
we
spent
quite
a
while
looking
at
the
different
players
in
the
CT
ecosystem,
and
it
seems
obvious
that
if
you
do
that,
the
work
of
a
monitor
is
probably
involves
quite
a
lot
of
data
and
doing
quite
a
lot
of
work
with
the
log.
It
seems
likely
that
pretty
much
every
monitor
is
also
going
to
be
an
auditor
effectively,
but
there
may
be
parties
that
can
act
as
auditors
that
don't
need
to
act
as
monitors.
B
The
monitor
is
effectively
getting
all
of
the
data
from
the
log
and
reviewing
it
to
see
whether
things
have
been
included,
that
shouldn't
have
been
included,
and
the
auditor
is
doing
slightly
less
work,
they're,
doing
sort
of
consistency,
proofs
and
inclusion
proofs
and
making
sure
that
those
things
show
up
properly.
So
not
all
on
those
are
monitors,
but
we
expect
probably
all
monitors
would
be
able
to
act
as
auditors.
B
So
the
biggest
problem
that
we
ran
into
in
trying
to
spec
this
out
is
a
privacy
issue
with
gossip.
So
it
turns
out
that
when
you're
collecting
these
s,
cts
from
peers
that
you
communicate
with
that
information
is
analogous
to
your
browser
history
or
something
comparable
at
least
to
the
web
space.
And
so
there
are
some
there's.
Definitely
some
sensitive
associations
that
we
don't
just
want
to
broadcast
everywhere
and
we're
talking
about
gossip
as
a
way
to
like
keep
track,
make
sure
everyone's.
Seeing
the
same
thing.
B
I
may
not
just
want
to
say
hey
by
the
way
you
know
I'm
a
regular
like
I've
visited
cat
fanciers
calm
yesterday,
because
you
know
I
might
be
with
the
good
people
who
prefer
dogs,
two
cats.
So
so
the
relationship
between
the
clients
and
the
servers
are
things
that
we
want
to
protect
in
terms
of
privacy,
the
relationship
between
the
other
players
in
the
ecosystem.
We
don't
care
so
much
about
privacy.
B
If
people
disagree
with
that,
I'd
like
to
hear
it,
but
from
looking
at
it,
it
looks
like
everybody
else
is
sort
of
acting
in
a
public
way,
but
the
relationship
between
clients
and
servers
is
a
thing
that
we
want
to
protect
so
that
that
drove
our
decisions
about
how
gossip
is
supposed
to
work.
Next
is
so
the
things
that
need
to
be
gossiped
in
order
make
sure
that
everyone
sort
of
seeing
the
same
view
of
the
world
well
in
individual
auditors.
Can
gossip
sign
tree
heads
to
each
other,
so
for
it?
B
The
other
thing
is
that
server
operators
and
auditors
can
share
any
s
cts
that
they've
seen,
so
that
is,
if
I
run
cat,
fanciers,
calm
and
I
want
to
and
I
want
it
to
be.
I
want
to
make
sure
that
the
logs
that
I'm
working
with
have
honored
the
various
promises
they've
made,
the
MMD
and
so
forth
I
can
send
them
all
of
the
s
cts
I've
ever
seen
for
myself.
B
Now,
normally
you
say
well,
what
are
you
gonna
see
for
yourself
and
most
servers
aren't
going
to
automatically
know
that
they're
not
going
to
have
extra
s
cts
for
themselves.
So
the
third
piece
of
the
puzzle
is
that
the
client,
a
client
talking
to
a
server,
can
say:
hey
I've
seen
some
other
s
cts
for
you,
and
here
they
are,
and
here
are
the
certificates
that
went
with
them
and
then
so
that
keeps
that
particular
relationship
confidential,
because
it's
the
server.
B
Now
we
talked
to
the
auditor
and
says
hey:
this
is
what
I'm
seeing
about
myself.
Clients
can
also
talk
to
auditors
directly
if
they
have
a
trust
relationship
with
them,
but
that's
not
required
and
should
not
be
required
for
clients
or
to
be
able
to
make
this
work.
So
next
slide,
please
it's
just
a
graphical
visualization
of
what
I
was
just
talking
about.
So
these
are
all
the
players
in
the
current
yuko
system
without
and
gossip
right.
So
the
monitor
here
is
just
saying:
hey
give
me
everything
from
the
log.
B
The
website
is
asking
for
us
SCT
from
the
log
that
might
happen
mediated
by
CA
or
it
might
happen,
live
the
browser
is
communicating
with
the
website.
This
is
in
the
https
context.
Our
gossip
only
actually
works
specifically
for
https.
It
doesn't
work
for
other
TLS
mechanisms
at
the
moment.
So
be
aware
of
that,
and
then
the
auditor
is
doing
these
different
things.
It's
asking
given
a
time
step.
B
I
want
to
sign
tree
head
given
to
sign
tree
heads
I,
want
to
consistency,
proof
and
given
us
sign
tree
head
and
SCT
I
want
an
inclusion
proof,
so
this
is
without
gossip.
It's
already
a
complicated
system.
Next
slide,
please
good
gossip.
So
the
auditors
talk
to
each
other
and
share
their
span
tree
heads
signed
tree
heads.
The
browser
will
say
to
the
website:
hey
here's,
some
other
s,
cts
inserts
that
I've
seen
for
you.
So
the
website
maybe
can
build
the
cache
of
those.
B
The
website
then
talks
to
the
auditor
either
the
auditor
pulls
the
website
or
their
website.
Ghost
daughter
and
says:
hey
here
are
some
things
that
I've
found.
So
the
auditor
is
collecting
all
these
sign
tree
heads
and
s
cts,
and
then
that
dashed
red
arrow.
That's
a
trusted
relationship
there,
where
the
browser
acknowledges
that
the
auditor
is
likely
is
likely
able
to
do
things
like
D,
anonymize
them
or
learn
their
traffic
habits
or
whatever.
If
they,
if
the
browser
does
have
a
trusted
relationship
with
an
auditor,
they
can
send
the
s
cts
inserts.
B
B
Okay,
next
slide,
so
open
questions.
As
I
said,
it's
https
only
our
proposal,
if
you
read
the
draft
users,
well
known
urls
between
the
different
parties
and
there's
a
specification
for
what
to
send
to
the
different
urls
so
that
gossip
can
work.
We
mentioned
that
auditors,
if
they're
receiving
information
as
a
trusted
party
from
clients
that
they
should
not
immediately
then
send
that
trusted
that
information
on
to
the
log,
because
there's
a
traffic
analysis
attack
where,
if
I
wanna,
if
I,
let's
say
I,
want
to
know
what
what
a
given
clients
activity
tends
to
be.
B
I
know
that
they
have
a
trust
relationship
with
a
with
an
auditor.
I
can
sit
at
the
network
on
that
auditor
watch.
The
requests
come
in
from
the
client
that
I
care
about
you
need
it.
If
that's
encrypted,
I
can
then
see
what
requests
come
out
from
the
auditor
in
that
form
and
then
I
can
infer
something
about
what
the
client
was
asking
and
learn
something
about
the
client.
So
we
recommend
that
auditors
actually
mix
information
in
all
of
this
detection
is
going
to
be
done
after
the
fact
anyway,
like
once.
B
None
of
this
is
going
to
prove
a
connection
from
occurring
right.
This
is
all
happening
offline.
So
a
little
bit
of
extra
latency
for
the
mix
will
provide
a
level
of
privacy
for
the
clients
who
have
a
trusted
relationship
with
auditor.
But
we
don't
have
an
explicit
mix
policy
to
find
and
then
there's
an
open
question
about
how
the
auditor
talks
to
the
server,
whether
it's
pole
or
how
often
would
note,
should
it
be
pull
vs
send
there
may
be
a
business
relationship,
that's
defined
there
between
servers
at
all.
B
D
The
sneak
can't
be
the
end.
First
I
want
to
thank
you
that
I
thought
those
were
beautiful
diagrams
and
that
the
first
one,
which
is
the
before
adding
in
the
audit
parts,
belongs
in
69-62,
bisque
or
in
an
architecture
document,
because
it
does
the
clearest
job
of
explaining
the
presumed
relationships
among
the
components
here.
So
I
think
that's
an
outstanding
thing
to
do.
I.
D
You
have
to
turn
into
ascii
art,
okay.
Now,
second,
though,
at
various
points
you
talk
about
clients
and
I
think
there's
some
inconsistent
use
between
the
way
you're
using
the
term
and
the
way
696
to
this
does
at
the
moment,
because
696
to
this
talks
about
all
the
other
elements
being
clients
of
logs
I,
see
and
you're
talking
about
clients
as
TLS
clients,
which
I
believe
correct,
yeah,.
B
D
B
We
haven't
specified
the
specific
timing
and
it
does
assume,
therefore,
that
the
to
make
this
for
this
to
effectively
detect
in
this
issue
aids.
It
means
that
someone
who
has
seen
an
invalid
SCT
means
at
some
point
reconnect
to
the
legitimate
server
or
have
one
of
these
trusted
relationships
to
an
auditor.
We
will
not
be
able
to
detect
it
in
that
case
the
frequency
of
sending
the
SE
of
the
seeing
the
other
ones.
We
haven't
sorted
that
out.
If
you
have
recommendations
at
the
equity
here.
B
E
B
E
B
E
B
G
G
Am
proud
to
tackling
from
Java
and
C
Peters
said
start
TLS
an
SMTP.
Why
not
include
it
and
I
have
an
answer
from
Garber
learner's
says
it
says:
HTTPS
l
through
then
says
in
the
short
in
the
long
run.
Yes,
maybe
include,
have
family
started.
There
was
very
few
smtp
sorts
or
CIA
issued
and
then
separately
then
said
he
imagined
browser
sending
schs
to
websites
and
vice
versa.
Look
at
those
answering
a
different
point.
So
I
guess
the
question
initially
was
smtp
and
start
to
us.
So.
B
For
smtp
insert
see
less
the
reason
that
we
didn't
define
it
for
them
is
because
our
our
feedback
mechanism
from
browsers
to
websites
or
browsers
to
servers,
I,
can't
say
clients,
servers
anymore.
Now
that
see
point
of
that
is
HTTPS.
So
if
we
say
that
we're
doing
smtp
s,
we
don't
have
a
guaranteed
mechanism
for
delivery.
So
someone
wants
to
spec
out
what
that
would
look
like
how
to
gossip
back
to
a
server
that
supports
smtp
s,
then
that
would
be
great,
but
we
SPECT
it
out
for
https.
A
F
G
So
vanished
in
the
Java,
rumors
I
think
he's
changed.
We
wanted
to
say
so.
I'll
give
his
original
comment.
So,
as
I
said,
I
thought
st
agents
should
go
from
browsers
or
strictly
auditors
actually
to
websites
and
vice
versa,
and
then
later
he
said
so
revise
my
comment
as
auditors
to
websites,
in
vice
versa.
So.
B
B
Okay,
I
so
so
so
been
on,
I'm
happy
to
talk.
It
would
give
it
to
another
auditors.
I
would
give
it
to
another
auditor.
So
we've
got
this
auditor
to
auditor
feedback
loop
going
on
here
and
so
you're
saying
so.
Ben
suggestion
is,
then
that
websites
could
have
relationships
with
multiple
auditors
and
the
s
th
s
could
be
passed.
Auditor
to
auditor
via
the
website,
as
an
interim
measure,
I
would
hope
that
auditors
would
be
interested
in
communicating
with
each
other.
B
So
he's
saying
that
browsers
will
be.
Auditors
I
think
that
reintroduces
all
of
the
privacy
concerns
the
main
advantage
of
the
auditors.
Being
independent
from
the
browser
is
that
it
is
that
these
queries
here,
sorry
I'm,
pointing
maybe
I'll,
be
able
to
see
it.
The
queries
between
the
auditor
and
the
log
are
things
that
provide
privacy,
sensitive
information,
and
so,
if
the
browser,
if
the,
if
the
browser
actually
contains
the
auditor,
then
the
browser
is
basically
reporting
back
to
the
log.
B
All
of
the
things
that
they've
seen
and
so
so
our
assumption
here
was
that
auditors
were
independent
from
browsers
and
that
the
that
the
auditors
are
providing
a
layer
of
mixing
to
avoid
that
particular
privacy
implication.
So
if
we
think
that
all
browsers,
our
auditors
then
actually
now
have
concerns
about
this
draft,
so.
B
A
A
A
H
The
downside
is
that
the
signature
itself
we
see
will
be
included
in
the
wouldn't
be
covered
by
the
SCT
and,
as
things
stand
now,
basically
it
would
be
impossible
sort
of
to
polish
the
final
signature,
because
the
log
went
quickly
when
asked
for
the
entry
will
provide
the
entry
itself,
which
one
includes
a
TV,
significant
and
the
chain,
the
clear
it
which
will
exclude
them
sort
and
entity
certificate.
So
that's
so
this
is
of
this.
What
you
have
to
once
next
slide,
please.
H
So
in
case
yes,
like
a
CA
would
want
to
log
a
redacted
pretty
certificate
after
it
is
already
being
issued
and
would
like
to
serve
additional
s
cities
over
Taylor's
extension,
then
the
only
way
to
do
it
would
be
to
provide
this
pre
certificate
is
like
this
for
Pacifica.
So
did
the
motivation
for
this
ticket
and
I
think
the
one
of
the
suggestions
was
to
define
a
backwards,
compatible
structure
that
will
contain
US
cities
and
will
still
be
used
in
the
same
tale.
H
As
extension
than
stapled
ocsp
responds,
so
the
one
question
is
whether
we
should
use
the
same
Tillis
extension
and
if
so,
how
should
you
define
this?
The
structure
of
this
the
backwards
compatible
structure
for
containing
like
a
new
style
cities
which
will
have
the
type
embedded
in
them
and
all
style
cities?
Next,
like
this.
H
H
H
So
this
ticket
for
security
considerations
was
suggested
as
a
middle
ground
between
have
mandated
Klan
behavior
and
not
specifically
install-
and
it's
probably
your
done
that,
given
the
wrist
like
a
whole
discussion
about
climbing
ever,
which
is
grown
since
this
ticket
was
found
next
to
get
next
slide.
Please
ok!
So
this
ticket
is
about
limiting
the
number
of
off
sign
three
heads,
the
tell
Alicia's
per
time
unit
and
the
goal
is
to
avoid
contouring,
a
printing
or
basically
the
log,
sending
a
different
sign
three
head
for
each
channel
which
get
the
theater
quest.
C
H
So,
okay,
so
what
this
I
think
this
suggestion
is
overall
sensible
except
we
don't
have
a
good
way
to
enforce
it
in
the
moment,
because
it
so
if
along
we'll
do
that
lacking
gossip,
we
will
not
be
able
to
figure
out
that
so
the
log
is
doing
or
is
it
couldn't
do
it
for
some
plans
and
at
the
moment
there
is
no
good
way
to
detect
it
so
suggesting
some
data.
Welcome
and.
A
H
C
D
H
D
Yes,
I
agree,
but
that
seems
like
something.
So
if,
if
you
added
to
the
log
metadata,
not
only
a
maximum
time
between
issuing
sths,
but
also
a
maximum
number
per
some
unit
of
time
that
you
agree
upon,
couldn't
an
audit
function
detect
by
looking
at
the
sths
that
had
been
acquired.
If
the
log
were
to
exceed
that
limit,
that
it
had
publicly
advertised
through
the
metadata.
D
H
H
The
next
slide
yeah,
if
there
are
more
questions
about
this
one
so
as
I
said
about
client
here,
dark,
20,
tickets
and
I
didn't
want
to
list
them
all,
partly
because
the
issue
tracker
started
this
inning
out
500
errors
when
I
was
looking
at
them,
so
I
think
we'll
just
talk
about
it
later.
Next
slide.
H
H
So
when
the
client
asks
the
lock
for
an
occlusion
proof
of
a
specific
entry,
it
discloses
to
the
log
which
Selena
Kate
it's
holding,
simply
which
site
is
visited
and
one
suggestion
is
to
send
or
to
request
a
bunch
of
proofs
around
a
given
time,
stamp
or
or
some
bits
of
the
hash,
and
so
the
log
doesn't
know
exactly
which
which
certificate
defines
is
interested
in
it
only
it
knows
about
range
or
collection
of
them,
and
this
is
so.
This
is
a
sort
of
significant
change
or
a
significant
effort
for
logs
to
implement.
H
We
have
to
sort
of
specified
carefully
and
we'll
not
entirely
sure
it
preserves
privacy.
Well
enough.
There
are
suggestions
for
four
in
an
iterative
version
of
of
this
approach,
where
a
client
keeps
asking
the
log
for
what's
the
window
size
like
how
many
certificates
do
have
in
this
time
range
or
for
this
for
this
number
of
Auschwitz
until
the
client
gets
an
answer,
it's
happy
with
and
then
fetches
the
inclusion
proof
batch
for
this
range.
So
we've
to
the
point
where
it
stands
now
is
the
postponing
this
this
ticket.
H
C
A
A
A
A
F
C
H
So,
yes,
I
think
it's
a
it's
a
shame
that
he
can't
presented
himself,
because
a
lot
of
that
is
is
obviously
his
work
and
as
tall
as
this
sort
of
statuses,
all
of
the
like
historical
tickets
and
like
small
from
this
one,
solid
small
changes.
Some
of
the
bigger
changes
are
are
now
resolved
and
I've
mailed,
the
least
while
ago,
with
the
list
of
results
tickets.
So
we
will
not
go
over
them
here.
Next,
like
this.
H
We
will
just
recover
some
of
the
big
changes.
The
first
of
them
was
service
school,
the
basically
the
option
of
a
client
asking
for
sth
and
getting
getting
it
from
front
end,
a
of
the
lock
server
and
then
requesting,
like
a
recent
inclusion
proof
against
this
stage,
but
that
request
ends
up
its
ever
be
they'd
like
it
fronting
bit
different
from
the
furnace,
a
log
which
only
has
the
has
an
alder
st
h,
and
when
the
client
tries
to
then
get
a
new
stage,
it
gets
it
from
front
a
day.
H
So
the
client
can
never
really
get
the
the
right
inclusion
proof
for
the
sth
it
holds.
So
all
other
aps
were
updated
to
with
basically
to
allow
this
front
end
to
specify
everything
it
has,
including
an
old
st
age
or
new
or
sth.
If
it
has
one,
so
the
clients
no
longer
has
to
go
and
request
each
of
them
individually,
or
at
least,
if
it
does,
it
can
get
in
your
answer.
H
H
Echoes
yes,
so
when,
as
I
did,
a
bunch
of
machine,
readable
error
codes
to
all
the
responses,
this
is
mostly
useful
when,
obviously
when
the
client
has
to
either
retry
or
the
request
is
malformed.
So
now
it
should.
Click
should
be
clear,
for
example,
when
a
chain
is
submitted,
whether
it
was
not
accepted
because
dedicate
itself
was
invalid
or
because
they
routed
changed
to
is
not
included
in
the
set
of
fruits.
The
log-log
accepts
next
slide.
Please.
H
Ok,
so
the
API
efficiency
issue
that
was
resolve
this
is
related
to
the
prison
when
I
presented.
Where
now
the
client
doesn't
have
to
perform,
three
calls
to
get
included
proof.
You
know,
for
example,
will
be
like
any
fresher
stage,
because
this
is
approved
between
the
two
stages,
so
it
resonate
vehicle
to
the
all
three
screen.
One
go
next
slide.
This.
H
H
The
dude
I
think
the
suggested
resolution
for
this
ticket
is
that,
if,
if
allah
wants
to
change
algorithms
harsher
with
no
signature
algorithm,
this
simplest
way
in
terms
of
protocol
simplifying
the
protocol
and
making
clients
lives.
Easy
is
just
freeze
the
existing
log
and
start
a
new
one.
So,
and
if
it
is,
it
is
possible
just
to
feed
the
old
data,
the
data
from
the
old
log
into
the
new
log
to
have
it
to
heaven.
H
You
dog
include
a
copy
of
all
the
relevant
data
so
rather
than
trying
to
build
in
agility
into
the
protocol,
which
will
make
it
significantly
more
complex
because
then
each
entry,
the
logos
to
indicate
which
algorithm
was
used
to
sign
each
entry,
will
and
will
make
obviously
life
of
clients
much
more
difficult.
This
is
there
so
there's
a
proposed
solution.
H
D
Steve
can't
be
the
end
first
I
want
to
thank
you
for
having
I
had
done
two
of
the
things
that
are
cited
in
the
slides
one,
adding
machine,
readable
error
codes
to
the
responses
I
think,
is
very
good
and
to
putting
together
in
the
current
version
of
the
document.
All
the
log
metadata
in
one
place
and
describing
format
is
very
valuable.
D
However,
I
did
file
a
ticket
on
the
algorithm
agility
part,
because
this
describes
a
mechanism
by
which
to
do
it,
but
it
does
not
provide
a
comprehensive
description
of
algorithm
agility
in
the
way
other
systems
have
done
and
I
provided
a
reference
there.
So
I
think
this
is
a
step
in
the
right
direction.
In
terms
of
saying,
this
is
how
we
plan
to
deal
with
it,
but
I
would
disagree
that
this
solves
the
problem,
also
just
for
the
heck
of
it.
H
So
about
the
holiday,
the
confidentiality
notice,
it's
Ben's
fault,
but
about
the
algorithmic
duty.
So
just
I
understand
the
concern,
and
this
is
about
not
having
like
a
well-described
or
well
specified
list
of
steps
of
how
to
migrate
a
log
or
how
to
migrate.
A
client
from
the
old
log
which,
with
sort
of
one
other,
is
into
a
new
log
with
a
different
algorithm.
Is
it
right,
I.
D
D
They'll
need
to
do,
how
they
are
expected
to
detect
this
and
how
they're
expected
to
deal
with
it,
including,
for
instance,
in
the
context
of
audits.
If
auditing
functions
are
supposed
to
deal
with
the
possibility
of
funny
stuff
happening
across
what
appears
to
be
an
algorithm
change
boundary,
then
how
do
we
know
that
one
wasn't
just
freezing
a
log
and
starting
a
new
one
to
hide
inconsistencies,
for
example,
so
that
has
to
be
addressed
at
some
level.
H
So
I
agree
I,
agree
with
that.
It's
I
think
it's
like
it's
it's
a
very
good
point
right.
We
should
be
clear
how
sort
of
a
client's
of
my
grades
from
logs
I
think
it's
like.
It
is
device
it
it's
related
to
a
incremental
deployment,
which
is
an
issue
if
the
developer
correctly,
you've
also
raised
in
the
past
and
somewhat
to
climb
behavior
right.
So
what
how
should
watch
a
decline
do?