►
From YouTube: IETF95-TRANS-20160404-1550
Description
TRANS meeting session at IETF95
2016/04/04 1550
A
B
D
E
D
A
D
D
D
D
So
just
a
quick
update
on
it,
so
we
have
no
not
on
no
change
on
the
Charter.
The
tracker
has
17
open
issues
compared
to
last
time
we
had
22,
but
last
time
we
had
issues
open
on
the
base
document
and
currently
to
this
document
has
no
open
issues.
So
we're
really
hoping
to
start
working
group
last
call
on
it
and
for
that
we
have
Aaron
giving
a
remote
presentation.
D
F
F
G
A
F
So
I
see
a
frozen
video
feed,
so
I
guess
I'll
just
go
and
make
sure
that
each
slide
title
is
the
one
that
I
intend
the
1
I'm
reading
with.
Ok,
ok,
but
so
I
may
run
a
safe
from
google
one
of
the
authors
of
6
and
6
2
b's
and
other
than
doing
my
usual
blunt
released
of
serogroup,
but
a
grocery
list
of
open
issues.
I
decided
to
give
an
overview
from
six
and
six
to
between
2-6
2
and
six
and
six
to
this.
F
F
So
it's
unchanged,
the
soda
miracle
tree
structure
itself
and
the
way
it
is
used
have
remained
the
same,
particularly
so
nodes
and
leave
our
hash
the
same
way
so
nodes
and
leaves
have
a
different
value
pendant
to
them
when
they
are
hashed
that
that
remain
the
same.
The
way
that
inclusion
and
consistency
proofs
are
used
is
are
created
and
used
is
again
the
conceptually
the
same
in
a
696.
F
The
concept
of
free
silicates
has
remained,
but
the
implementation
has
changed
that
that's
in
the
next
slide
and
the
density
distribution
mechanisms
have
also
like
I've
also
remained
the
same.
These
are
embedding
in
certificates
till
eccentric
and
stapled
ocsp
responses
next
slide,
please,
the
one
titled
removed
so
what's
been
removed
is
the
place
certificate
concept
and
birth
certificate.
Signing
certificate,
so
in
RFC,
696
to
like
issuers,
could
use
an
intermediate
certificate
to
sign
the
birth
certificate
different
than
the
one
used
for
issuing
the
final
certificate.
F
With
the
city's
embedded
in
it,
but
because
be
so
difficult
are
no
longer
x.509
certificates,
then
there
is
no
need
to
have
the
certificate
signing
certificate,
so
that's
gone
for
the
same
reason:
the
poison
extension,
a
critical,
critical
extension
with
a
null
value
is
also
no
longer
needed,
because
the
Pacific
is
are
no
longer
x.509
certificates.
We've
also
removed
one
layer
of
abstraction.
From
the
miracle
tree
data
structure,
there
was
just
an
extra
layer
that
there
was
not
really
necessary
so
removed
it
and
s.
It
is
4x.
F
Avanade
certificates,
as
opposed
to
be
certificates,
are
no
longer
over
the
entire
certificate,
as
is
so
we've
simplified
and
unified.
The
data
structure
used
for
assigning
for
basically
over
which
the
signatures
in
the
cities
are
valid
for,
and
it's
the
same
for
exogenous
certification,
page
certificates.
Now
that
means
that
the
SCT
4x
far
more
significant
cover
the
entire
certificate
aziz
question
so
far,.
F
Okay,
so
is
that
I
think
the
biggest
change
will
run
of
the
big
changes
is
Pacific
eights
the
Pacific
is,
are
now
CMS
objects
that
contain
the
TBS
certificate
designated
for
the
fan
certificate.
Crucially,
the
serial
number
of
the
final
certificate
file
expensive
ink.
It
is
still
included
and
is
still
needed,
but
in
some
of
you
may
recall
the
main
reason.
F
The
main
objection
to
the
previous
for
multiplicity
Kate's
was
is
that
these
were
actually
x.509
certificates
and
issuers
would
sign
this
basically
different
certificates
twice,
but
with
the
same
serial
number
twice,
then
there
was
drug
pushback
from
that.
So
now
the
Pacific
is
embedded
a
consumer
subjects
and
that
you'd
still
have
to
use
the
same
issue.
F
F
Redacting
labels
from
the
front
of
my
name
is
a
Pacific,
eight
or
login
get
completely
avoiding
logging,
and
that
is
a
certificate
by
looking
at
name
constraint,
intermediate
CA
certificate
with
again
special
the
extension
indicating
these
are
load
instead
of
them
the
entity
in
the
leaf
certificate,
and
they
are
also
technically
constrained
or
fit
the
thing.
They
see
a
cup
forum
definition
of
technically
constraint
certificates,
so
they
will
fulfill
for
both
requirements.
F
Please
titled
log
entries
in
RC,
6
and
6
to
base.
So
we've
introduced
a
new
data
structure-
trans
item
that
is
basically
used
everywhere
and
that
encapsulates
all
of
the
all
the
pieces
of
data
that
we
would
like
to
return.
So,
if
you
look
at
the
first
to
the
x.509
entry,
vitor
preset,
entropy
to
these
are
just
entries
for
birth
certificates.
It
also
can
it
also
contains
se
keys,
Prince
illicit
ease.
Tree
has
Sankri
heads
constancy,
proofs,
inclusion,
proofs
and
a
combination
of
the
above
and.
F
Basically,
whatever
will
it
turn
like
a
binary
data
secure,
it
will
be
a
trance
item.
That
is,
the
party
party
simplifies
plenty
of
limitation,
because
that's
the
exact
thing
thing
that
will
be
passed
around
and
that
also
future
proofs.
The
protocol
to
an
extent,
because
me
you
knew
the
lady
tops-
could
be
added
to
translate
them
and
persuaded
over
RFC
six
and
six
to
be
compliant
channels.
F
Next
next
slide,
please
title
the
log
entries
continued.
So
what
do
we
have
in
the
in
the
log?
As
I
mentioned,
the
concepts
bring
me
the
same,
but
the
data
structure
in
logs
now
is
a
trance
item
structure
only
of
type
x,
59
entropy
to
or
reset
entropy
to
only
one
of
those
and
nothing
else
you
can't
put
into
log
leaves
anything
else
and
both
of
these
suckers
encapsulate
the
data
structure
called
time
steps
of
the
vaquita
entry
data,
which
is
it
held
in
them
in
the
next
slide.
F
So
next
slide,
please
titled
log
entries
give
data,
so
both
43
certificates
end
x.509
certificates.
We
take
the
pre
certificate
and,
together
with
the
time
step,
you
should
buy
the
log
and
the
issuer
key
hash
and
extensions
is
the
block
of
data
is
a
blob
of
data
that
we
will
use
that
will
be
signed
in
the
sign
certificate.
I'm
stem
so,
as
I
mentioned
earlier,
because
the
SCT
the
synchronicity
4x4
no
certificates
is
not
over
the
entire
certificate.
We
always
attach
the
issuer
key
too,
but
basically
providing
the
issuer
to
the
to
the
TBS
certificate.
F
Another
point
is
that
the
extensions
the
city
extensions
field
is
now
typed,
so
no
se
te
extensions
you
currently
specified,
but
it
would
be
easy
to
specify
one.
Where
is
in
the
RFC,
696
and
62.
This
was
basically
an
epic
string
without
any
semantic
meaning
define
so
should
we
ever
have
to
defect.
Sessions
should
be
placed
at
fault
next
slide.
Please
take
a
blog
entries
original
submission.
F
So
that's
this
statue
that
is
returned
by
the
log
together
with
the
leaf
data
when,
when
a
client
calls
the
gate
entries-
and
that
is
the
original
submission
in
case
of
a
preset,
we
have
the
CMS
blizzard
and
it
was
submitted
together
with
a
chain
that
was
used
to
validate
it
and
in
case
of
an
x.509
entry.
We
have
the
belief,
certificate
and
the
change
it
was
used
to
validate
it
and.
F
F
F
F
Alright,
so
in
that
case,
is
for
the
I'll
go
into
the
class
I'd
climb
facing
API
changes.
I'll
know
that
all
the
HTTP
methods
from
696
to
have
changed
and
they
all
now
live
under
a
city
/
to
the
old
one,
should
live
under
city
v,
one
da
the
changes
affected,
all
all
the
api's
and
some
that
are
specific
to
the
few
API
calls.
The
main
thing
is
that,
rather
than
return
JSON,
we
now
return
trance
atoms,
encoded
and
Tillis
encoding
other
than
Jason,
so
previously,
like
it.
F
Six
and
six
to
a
client
calling
gum
at
the
chain
or
get
a
stage
would
get
would
get
Jason
and
they
would
then
have
to
assemble
the
T
less
encoded
data
structure
to
check
the
signature
over
now.
The
Jason
which
returned
will
return,
base64,
encoded,
transact
them,
and
the
trans
item
is
encoding
until
s
encoding,
which
means
counting
limitation,
particularly
for
issuers.
It's
much
simpler,
basically,
client
can
take
the
result
from
an
ED
chain.
Call
from
several
agent
calls
to
seven
different
locks,
put
them
in
one
structure
and
embed.
F
That
is
that
in
a
certificate
or
serve
that
luck
until
eccentric.
There
we've
introduced
error
codes,
both
fixed
drinks
and
human,
readable
ones,
and
these
are
defined
for
all
methods,
so
each
method
specified
is
its
own
error
codes
and,
additionally,
we
have
exclusively
designated
a
GP
error
codes,
500
503
s,
transient
errors.
So
when
the
log
sends
that
vector
client,
the
client
is
expected
to
wait.
Try.
F
Another
issue
is
dealing
with
the
school
distributed
log
implementations.
So
basically
the
problem
there
was
that
the
loge
can
have
several
front
ends.
Some
of
them
know
about
the
newer
sth
than
others,
and
simply
because
it
takes
time
to
this
route,
the
same
agenda
that
world
front
ends
and
to
switch
them
all
to
serve
new
data.
So
it
could
be
that
a
client
would
call
get
a
stage
learn
about
a
new
sth.
F
Then
we'll
call
get
entries
or
request
an
inclusion
proof
after
the
test
eh
and
that
the
second
request
will
will
reach
a
front
end
that
doesn't
know
usta.
In
that
case,
a
front-end
can't
basically
can't
answered
concerns
to
the
client,
and
there
is
no
guarantee
that
the
client,
when
it
tries
calling
at
the
stage
again,
for
example,
will
will
reach
that
front.
End
and
not
the
newer
one,
so
I
had
the
way
we've
addressed.
F
It
is
by
allowing
a
particular
lock
front
end
receiving
a
request
for
an
inclusion,
because
this
is
a
proof
that
it,
but
is
up
to
a
Trinity
is
not
aware
of.
It
can
now
reply
with
the
proof
chaining
to
the
sth.
It
is
aware
of
and
include
the
stage
itself
in
the
reply,
so
that
somehow
decreases
the
Delta
between
three
sizes.
The
client
has
to
know
about
or
validate
so
when
a
client
receives
an
answer
from
such
a
fronting.
That
includes
an
older
stage.
F
It
can
hold
due
to
the
slightly
older
stage
and
then
just
retry
check
getting
a
facility
proof
between
the
secondary
stage
in
the
newest
stage.
It
knows
of
next
slide.
Please
title
the
method,
specific
client,
a
pair
changes,
so
they
were
tuned
value,
changes
for
all
this
method.
A
channel
pitch
n
get
a
stage
and
SB
a
decision
causes
a
group
and
get
worth
my
hash
have
all
changed.
As
I
mentioned,
to
turn
binary.
F
The
cities
in
the
stages
are
telling
the
binary
representation
base64
encoded
by
than
jason,
and
the
same
goes
for
the
inclusion,
consistency
proofs.
So
if
you,
if
you
remember
in
that
trans
item,
we've
defined
basically
data
structures
for
providing
inclusion,
consider
proofs.
This
will
also
be
a
binary
coded
next
slide.
Please
one
titled
client
api
changes
continued
so
for
every
chain
with
there
is
a
different
episode,
difficult
in
coding
using
CMS
that
I've
mentioned
get
increase,
we've
renamed
the
so
there
were
22
of
values
returned
from
gate
entries
and
second
one
was
called.
F
One
was
the
one
of
the
leaf
data
in
the
second
one
is
what
was
called
the
extra
later,
which
was
actually
the
original
submission,
so
that
was
now
renamed
to
log
entry,
and
we
also
returned
the
SCT
fought
for
that
particular
entry,
which
means
a
mewling
logs,
is
now
trivial
because
mewing
software
just
called
get
entry,
so
no
one
trees
and
have
exactly
the
same
data
as
the
original
log
get
a
stage.
Consistency
now
optionally
returns,
and
this
is
forgetting
acosta,
see,
probably
20
stages
and
optional
returns
on
sth.
F
If
the
second
precise,
the
newer
one
specified
backlight,
is
unknown
by
the
particular
lock
front
and
receiving
this
request
get
proof
I
hash
and
get
entries
they.
These
methods
to
can
also
return
basics
for
encoded
a
stage
if
the
client
asks
for
chris
is
that
they
don't
know
yet
so
they
can
return.
The
entries
were
proof
up
to
the
point
that
front
end
knows
about
last
sth.
For
that
up
to
that
point,
there
is
a
new
method
called
get
all
by
hash,
which
gives
the
parameter
the
hush
of
the
leaf.
F
The
cloud
can
also
specify
the
tree
size
knows
about.
The
client
will
then
get
a
fresh
red
stage,
a
consensus
approved
between
the
sth
it
knows
about,
and
the
freshest
age
provided
and
an
inclusion
proof
up
to
that
tree
size.
After
that
I
say
the
tree
says
the
one
who
turned
by
this
method
next
slide.
Please
titled
can
t
pay
changes
continued,
so
we've
renamed
one
method:
grapefruits
was
renamed
to
get
anchors
and
get
adrian
proof
was
removed.
F
No
okay!
So
next
like
this,
which
is
also
my
final
slide
about
backwards
compatibility,
it's
very
simple:
there
is
very
little
backwards
compatibility.
These
are
separate
protocol,
so
logs
from
the
perspective
of
logs,
they
can
either
conform
to
696,
2
or
6
and
6
to
base.
They
can't
confirm
to
both
because
the
data
structures
are
different.
The
way
so,
basically
different
things
are
hushed
and
the
Leafs
are
different.
So
it
is
not
possible
to
create
and
run
the
log
that
will
produce
a
cities
that
are
compliant
with
v1
and
v2.
F
However,
v1
electricity
is
basically
on
with
two
sats
are
independent
creatures.
They
are
delivered,
delivered
using
different
extensions,
so
it
SAT.
There
is
a
new
x5,
an
extension
for
velocities,
a
new
TLS
extension
for
again
for
p2
v2
clients
and
a
separate
extension
and
the
process
fixed
an
extension.
So
that
means
that
v1
and
v2
as
it
is,
can
coexist
and
TLS
clients
can
support
both
simultaneously.
D
F
D
F
The
TV
certificate,
and
only
then
validate
their
cities,
so
the
way
an
issuer
can
create
and
SN
x509certificate
with
embedded
s.
It
is
both
V,
1
and
V.
Class
cities
is
by
first
sending
the
Pacific
eight
2v
two
logs
collecting
all
of
the
all
the
v2s
cities
and
bending
those
in
the
TBA
certificate
sent
that
keep
producing
the
v1
pretty
certificate
like
a
six
and
six
to
put
certificate
from
that.
Tv
certificated
contains
the
victory.
Cities
send
that
to
city
logs
get
three
1s.
F
It
is
embed
them
and
then
sign
this
tibia
certificate
to
produce
the
final
x.509
certificate
so
that
when
v1
clients
check
via
wanna
cities,
they
check
it
over
the
locket
arteaga
certificate,
including
the
v2s.
It
is
it's
just
as
opaque
extensions
and
when
v2
clients
check
the
signature
of
a
certificate,
they
remove
both
velocities
NV
wanna
cities
and
they
are
left
with
the
same
tip,
a
certificate
that
was
sent
to
the
v2
logs.
That
issue
these
these
specific
eights.
F
So
to
conclude,
it's
possible
to
basically
p1m
velocities
can
co-exist
and
it's
also
possible
to
create
exponent
certificates
that
have
both
v1
and
v2
as
a
cities.
In
them,
and
will
be
valid
both
with
v1
and
v2
clients,
that's
that's.
It
does
overview
the
changes
and
said
I
intend
to
post
to
the
list
a
document
saying
basically
the
same
thing
of
San
I've
said
here
with
the
sake
more
explanation,.
D
D
G
Okay,
so
this
is
the
gossip
draft
is
something
that
Lena's
Nordberg
and
Tom
Ritter
and
I
have
been
working
on
so
next
I,
please
so
just
to
recap
here
is
that
I'm
going
to
talk
about
what's
changed,
but
just
to
just
to
be
clear.
The
point
of
gossip
is
to
be
able
to
detect
log
misbehavior,
and
so
we
want
to
make
sure
that
the
logs
aren't
doing
things
like
presenting
splitview
attacks,
slip,
split
views
to
different
parts
of
the
network
or
rolling
things
back
in
time.
G
G
The
one
of
the
hardest
part
of
dealing
with
with
gossip
in
CT
scenario
is
that
you're
effectively,
you
potentially
have
a
lot
of
privacy
concerns,
because,
if
you're
gossiping
about
information
about
what
things
you've
seen
you're
effectively
potentially
gossiping
about,
like
your
browsing
history,
for
example,
so
so
this
book
it's
become
fairly
complicated
and
the
rationale
for
the
complication
is
to
try
to
minimize
the
amount
of
privacy
leakages
there.
So
the
things
that
have
changed
so
so
just
a
quick
recap
on
gossip.
G
If
folks,
don't
remember
how
that
works,
we
have
there's
three
different
methods
by
which
information
can
be
gossiped.
One
of
them
is
called
SCT
feedback,
where
the
https
client
sends
the
s
cts
that
it's
seen
for
a
given
host
back
to
the
host
on
subsequent
connections,
and
it
does
that
it's
basically
we're
not
leaking
any
information
to
any
outside
party.
The
host
revisiting
might
know
that
you've
been
there
before,
but
you're
not
going
to
actually
be
not
telling
arbitrary
other
people
that
you've
been
to
this
one
host.
G
Th,
those
s
th
s
will
be
pollinated
from
browser
to
client,
to
browser
sorry
browser
to
server
to
browser,
to
server,
to
browser
to
server
all
around
and
then
the
third
one
is
a
trusted
auditor,
which
is
that
you
have
a
pre-established
relationship
with
an
auditor,
and
you
can
show
them
that
the
artifacts
that
CT
artifacts
that
you've
seen
and
they
can
use
them
to
keep
tabs
on
the
logs.
So
things
that
have
changed
in
the
new
draft
we've
been
clearer
for
SCT
feedback
about
who
you
should
send
it
back
to.
G
We
had
some
fuzzy
language
in
there
before
and
we're
now
much
clearer
that
it's
actually
the
exact
same
hostname.
So
if
I
get
a
cert
for
example.com,
I
shouldn't
send
it
back
to
dub
dub
dub
example.com
I
should
just
send
it
back
if
I
visit
example.com
a
second
time
and
vice
versa.
If
I
get
a
search
for
dub,
dub,
dub
I
shouldn't
get
it
to
example.
G
So
there
was
some
open
questions
about
locally
added
logs
and
chains.
Locally.
Added
in
this
case
is,
I
think,
a
euphemism
for
you're,
the
man
in
the
middle
configured
by
your
anti
malware
or
your
business,
Surveillance
Unit,
and
so
one
of
the
concerns
is
that
many
of
these
men
in
the
middle
boxes
that
are
set
up
with
a
phony
CA,
will
also
have
a
phony
may
have
a
phony
log.
G
But
if
they
have
a
phony
CA,
the
ca
might
be
customized
to
you
and
if
you
are
doing
SCT
feedback
with
certs
that
you
got
from
this
phony
CA,
you
might
be
identifying
yourself
because
of
the
certificate
chain
in
SCT
feedback.
You
give
back
the
entire
chain
and
there's
a
concern
that
if
I
have
a
man-in-the-middle
box,
that's
that
I'm
connecting
through
and
the
certs
in
that
chain
are
specific
to
my
man
in
the
middle
box.
G
They
might
identify
me,
and
so,
if
I'm
submitting
those
back
to
the
server
that
that
I,
that
I'm
connecting
to
say
I
move
off
of
the
men
middle
networking
on
to
another
one.
Then
maybe
I'm
identifying
myself
to
the
server
in
ways
that
I
shouldn't
be.
But
what
we
decided
is
because
you're
only
submitting
sut
feedback
for
cert
chains
that
actually
have
an
SCT.
G
That
is
where
your
sorts
have
actually,
then,
where
those
sorts
have
already
been
logged,
that
that
information
is
already
logged
and
you
should
go
ahead
and
publish
it,
so
you
should
send
it
back
to
the
server
that
there
isn't
a
privacy
concern.
We
wanted
to
also
minimize
the
number
of
code
paths
available
when
you're
thinking
about
what
do
you
send
back,
so
we're
gonna
be
sending
back
the
entire
chain,
whether
you
have
a
locally
added
CA,
whether
these
two
locally
added
CA
or
not.
G
We've
described
this
auditor
of
last
resort
role,
which
is
something
that
would
be
built
into
the
browser
into
the
HTTPS
client
itself.
An
auditor
of
last
resort
is
basically
so
the
two
things
you
could
be
gossiping
about
our
sgts
and
sign
tree.
Heads
of
the
2's
CTS
are
significantly
more
privacy
sensitive
right
because
they
tell
you
they
tell
something
about
which
hosts
you
have
talked
to,
as
THS
are
just
the
latest
sths
for
a
given
log
that
you
use.
G
G
It's
not
super
complicated,
but
we'd
be
great.
Somebody
want
to
take
a
look
at
it
and
say
whether
they
think
it's
implementable
or
not.
Next
slide
people
have
questions
they
should
ask
them
to
so
because
the
privacy
is
a
big
part
of
this.
A
big
chunk
of
the
new
text
is
trying
to
describe
the
different
privacy
concerns
that
we've
been
wrestling
with
turns
out.
It's
really
hard
to
gossip
stuff
without
leaking
information
about
what
you
doing,
and
so
the
fact
that
we
have
these
three
methods.
G
G
So
the
other
thing
is
when
you're
deciding
when
you're
doing
this
sth,
when
you're
doing
SCT
feedback
or
sth
pollination,
you
have
to
decide
which,
if
you
have
a
pool
of
things
to
send
back,
you
have
to
decide
which
ones
to
send
back
and
when,
and
so
we've
documented
some
concrete
algorithms
that
we
want
to
encourage
clients
to
use
when
they're
doing
these
particular
things.
Otherwise,
there's
it
turns
out
there's
a
whole
bunch
of
different
sort
of
fiddly
knobs.
You
could
said
about.
Do
you
want
to
send
them
all
back
all
the
time?
G
Well,
no,
you
don't!
So
when
do
you
and
if
you
have
multiple
ones,
how
you
choose,
which
one
and
how
many
times
you
need
to
send
it
back
before
you're
convinced
that
it's
gotten
upstream,
can
you
can
you
let
go
of
stuff,
so
we
have
concrete
algorithms
proposed
for
that
and
removed
everything
about
monitors.
It's
just
we're
dealing
with
with
auditors
and
HTTPS
clients
and
and
the
web
servers
only
the
rash.
So
it's
nice
that
we
don't
the
deal
with
the
monitors
here.
G
The
goal
the
entire
goal
here
is
how
the
how
the
gossip
framework
works
to
get
information
out
and
the
monitors
job
is
to
actually
just
go
through
the
a
given
log
that
has
been
properly
audited
and
make
sure
that
that
a
given
host
isn't
being
represented
multiple
times
there.
So
monitors
are
not
relevant
for
gossip,
so
we
managed
to
remove
all
that
so
a
little
bit.
Simplification
at
least
so
next
slide.
G
Please
so
a
couple
of
open
questions,
one
question
so
for
SCT
feedback
and
for
sth
pollination
when
I
connect
when
the
HTTPS
client
connects
to
the
web
server,
and
in
that
connection
it
sends
back
the
feedback
or
the
pollination.
So
one
question
is:
if
I
send
that
via
HTTPS,
is
it
acceptable
for
that
server
to
say
actually
HTTP
302
response
send
a
send
the
feedbacks
and
the
pollination
to
somewhere
else,
and
there
are
there
trade-offs.
If
you
don't
allow
redirection,
then
it
will
be
harder
for
some
people
to
deploy
it.
G
Some
people
simply
some
servers,
won't
deploy
it.
They
won't
run
a
service
locally
that
handles
it.
If
you
do
allow
redirection,
then
it
provides
then
we're
basically
enabling
another
major
surveillance
centralization
endpoint
right,
which
is,
if
everybody
decides
oh
yeah,
we're
not
handling
our
sut
feedback
or
sth
pollination.
You
can
just
send
it
over
here
to
example,
org.
Well,
then,
whoever
operates
exist.
If
there's
one
canonical
place
that
everybody
does
and
oh
all
you
have
to
do
is
set
up
this.
G
You
know
three
line,
Apache
redirection
set,
then
pretty
much
everybody
is
going
to
have
their
browsers
reporting
all
their
activity.
Back
to
example,
org.
So
there's
trade-offs,
hear
about
deployability
versus
sort
of
centralized
surveillance.
I
would
much
rather
say
that
fine,
if
you
want
to
deal
with
centralized
surveillance,
don't
do
an
HTTP
302
redirect,
but
instead
except
the
stuff
and
send
it
there
yourself
that
actually
removes
the
privacy
implications
for
the
for
the
clients.
G
So
so,
but
there
is
an
open
question:
do
we
want
to
support
delegation
or
not
we're
leaning
towards
not
we're
leaning
towards
staying
at
https
client
that
receives
an
HTTP
t
302
redirect
should
not
redirect
on
on
the
submission
of
SCT
feedback
or
sth
pollination.
So
there's
a
note:
yeah
Stephen
Stephen.
H
H
H
G
Can
give
you
a
3
so
if
I
go
to
your
posting
right,
you're
posting
data
that
says
here
are
some
certificates
that
I've
seen
of
you
yeah.
If
the
website
says
to
you
when
you're
just
visiting
the
website,
don't
go
to
me,
go
over
to
him.
Well,
that's
fine!
You're,
not
necessarily
going
to
post
the
information
you're
not
going
to
you're
not
going
to
turn
around
and
give
that
the
centralized
Authority.
The
information
that
you
were
visiting
that
website
you
might
if
your
refer
party
is
loose
I'm.
G
H
H
G
F
G
One
canonical
centralized
provider
that
everyone's
just
going
to
do
htp
delegation
to
right.
In
that
scenario,
if
I
have
any
sort
of
established
state
with
that
centralized
provider,
then
they
can
learn
my
entire
browsing
history
and
habits.
Okay.
So
if
my
connection
is
between
a
B
and
C
individually,
then
yes,
a
B
and
C
individually
can
say:
hey
I
got
the
cert
and
it
came
from
somebody.
G
G
G
H
It
but
all
of
the
example
of
common
example
that
net
could
they
have
all
this
information
that
they
could
all
just
give
to
the
collector
anyway
pretty
much,
but
they
wouldn't
they
don't
actually
have
the
correlations.
They
don't
know
that
you're
the
same
person
in
each
of
the
three,
whereas
when
you're
submitted
and
they
old,
if
they
all
tell
the
bat
that
the
centralized
bad
guy,
then
he
gets
to
know
the
same
stuff
eventual
eyes.
Bad
guy
doesn't.
H
G
Very
similar,
but
but
it
is
not
the
same
because
if
you
have
a
relationship
with
example,
calm
and
you
send
it
I've
been
to
a
B
and
C
a
B
and
C
turn
around
and
say:
hey
somebody's
been
to
us.
Then
the
collector
can't
tell
that
those
are
three
distinct,
whether
those
are
three
distinct
individuals
or
one,
and
the
link
ability
between
sessions.
Right
you
if
I,
say:
okay,
who
here
is
browse
google.
The
answer
will
be
everyone.
G
G
We've
said
in
the
in
the
draft
that
you
should
only
be
gossiping
recent
sths
and
that's
to
prevent
a
fingerprinting
attack
where
I
pull
an
old,
sta
and
I,
give
you
an
old
sth
in
the
during
the
sth
pollination
and
then,
as
you
browse
around
the
web,
you
hand
that
ol
sth
back
to
the
browser.
The
web
servers
that
you
visit
and
someone
can
look
for
that
old
sth
as
something
that
hops
around
between
servers
and
see
where
it
came
from.
So
it's
a
way
to
try
to
find
a
user.
G
G
This
is
to
detect
miss
to
detect
misbehaving
logs,
and
so
one
of
the
rules
of
the
misbehaving
log
is
like
certificates.
Much
must
be
issued
within
the
MMD.
They
must
only
issue
s
th
s,
@a,
sir.
You
know
no
more
frequently
than
a
certain
frequency,
so
they
have
a
set
of
rules
that
they
have
to
follow.
If
the
s
th
s
are
all
published
and
visible,
then
you
can
detect
that
a
log
has
failed
to
meet
one
of
the
requirements
that
are
committed
to
doing
initially
and.
G
Should
you
provide
the
S,
the
the
redacted
cert,
even
though
so
you
might
you're
visiting
what
you
think
is
the
same
host
a
second
time.
Should
you
provide
the
redacted
cert
back
to
that
host
if
it's
red,
if
it
may
have
changed,
and
I
believe
we
settled
on
the
side
of
yes,
you
should
go
ahead
and
provide
that
back
unless
you,
unless
the
client
has
some
specific
reason
to
think
otherwise,
but
I
think
the
current
conclusions
that
we're
going
to
go
ahead
and
encourage
that
to
be
sent
back.
G
G
Who
here
has
read
the
draft
all
right?
Okay,
so
no
one's
no
one's
in
the
middle,
it's
just
it's!
It's
nothing
or
actually
read
it.
So
that
way,
this
is
where
we
stand.
Do
folks
have
folks
have
more
questions,
I'm
happy
to
answer
them.
I
really
do
encourage
people
to
read
the
draft
there.
The
privacy
considerations
are
daunting,
but
we
need
to
think
about
them
and
if
we
don't
monitor
the
logs,
then
we
just
created
another
layer
of
potential
abuse.
So
all
right.
D
Thanks,
so
no
more
questions
on
this,
nothing,
you
remote
eater,
so
I've
got
a
document.
We're
working
on
is
the
threat
analysis.
There
was
some
discussion
about
the
dual
see
a
compromise
attack,
so
Steve
committed
to
to
updating
those
two
sections,
section
33
and
34
of
the
threat
document
in
the
next
week
or
so
so
once
you
receive
that
and
see
what
the
discussion
says
will
probably
also
bring
that
documented
to
work
into
a
pass
call.
D
G
So
I
believe
the
current
status
is
that
there's
a
sort
of
an
experimental
attempts
to
log
the
root
zone
and
the
pieces
are
being
put
in
place.
There
is
a
log
that
accepts
I
think
some
of
this
data,
but
we
want
it,
there's
a
bunch
of
work
still
being
done
to
like
try
to
avoid
it
being
spammable
and-
and
so
it's
not
like-
there's
nothing
useful
yet
to
report
back.
But
if
people
are
interested
there
is
a
DNS,
DNS,
SEC
transparency
mailing
list
that
people
can
join.
If
they're
interested
to
talk
about.