►
From YouTube: IETF114-PEARG-20220725-1730
Description
PEARG meeting session at IETF114
2022/07/25 1730
https://datatracker.ietf.org/meeting/114/proceedings/
D
D
Sure
thanks
this
is
the
note.
Well,
please
note
it
well
also,
please
note
that,
according
to
ietf
policy,
we
do
have
to
wear
masks
inside
all
meeting
rooms,
so
just
be
aware
of
that,
and
let's
move
on
to
the
next
slide
yeah.
So
this
is
the
agenda.
We
have
three
presentations
and
a
quick
update
on
draft
safe
measurement.
I
believe
that
mallory
will
be
giving
so
we
have,
I
guess
we
can.
The
chairs
can
do
jabbers,
keeping
an
eye
on
jabber
and
we
have
a
minute
taker.
E
E
Okay,
thanks
hi
everyone.
Thank
you
so
much
for
having
me
here.
My
name
is
sofia
celia
and
I
work
at
brave
software,
and
today
I
was
just
going
to
present
a
very
informal
note
or
an
informal
presentation
on
privacy
per
se
measurement
techniques
and,
as
I
said,
if
this
is
just
an
informal
comparison
next
slide,
please.
C
E
E
No
okay,
that's
no
problem,
we'll
move
the
slides
along
okay!
Thank
you,
sir
well,
thank
you
very
much,
sir.
Okay
suppress
a
little
bit
of
a
disclosure
again.
This
is
not
a
complete
overview,
but
rather
an
initial
note
around
the
different
techniques
that
one
can
use
for.
Indeed,
trying
to
try
to
attain
privacy,
preserving
measurement
techniques
and
what
it
really
wants
to.
E
I
aim
is
to
answer
the
question:
if
I
want
to
execute
measurements
with
privacy,
which
scheme
should
I
use
and
well
in
general,
that
seems
this
likely
seems
like
a
simple
answer.
In
reality.
It's
a
very
complex
one,
because
there's
a
big
array
of
different
techniques
that
one
can
use
in
different
schemes.
So
it's
difficult
as
a
user
of
the
system
administrator
or
just
a
user.
Who
is
a
system
administrator
to
actually
choose
the
correct
scheme
or
the
scheme
that
best
suits
your
need.
E
E
There's
also
some
clear
expectations
of
the
efficiency
of
monetary
costs
that
indeed
this
these
schemes
provide,
and
if
you
are
interested
for
some.
Furthermore,
some
further
notes
I
have
put
online
displaying
for
my
pdf
that
is
going
to
be
developed
into
some
of
something
more
formal
eventually
through
the
months
nexus
live
please,
okay.
So,
let's
just
start
from
the
beginning,
which
one
is
the
main
notion.
E
Because,
of
course,
as
I
said,
these
aggregate
measurements
correspond
to
a
centralized
leakage
of
private
user
data.
Currently,
the
ietf
actually
has
a
working
group
devoted
to
this.
That
is
called
ppm
that
precisely
has
been
trying
to
standardize
certain
of
the
techniques
that
I'm
going
to
talk
about
to
provide
privacy
and
security
for
aggregate
measurements.
C
E
So,
let's
start
with
the
actual
techniques
and
scheme,
and,
as
I
said,
there's
many
so
I've
tried
to
categorize
in
general
by
the
specific
technique
that
they
use.
The
first
one
is
the
techniques
of
differential
privacy,
and
the
reason
why
I'm
talking
about
this
in
the
first
place
is
because
it's
one
of
the
oldest
schemes
there
are
out
there
to
actually
preserve
privacy
for
aggregate
measurements,
and
the
idea
in
the
differential
privacy
techniques
is
that
some
local
randomness,
some
kind
of
nose
is
added
at
some
points.
E
When
you're
actually
performing
the
aggregate
functionality,
it
could
be
to
the
data
collector,
it
could
be
to
the
output
of
the
statistical
function
or
it
could
be
to
the
mechanism
itself
and
what
in
general
differentiation
privacy
wants
to
attain,
is
a
notion
that
is
called
epsilon
differential
privacy.
You
will
see
here
a
mathematical
notation,
just
don't
worry
about
it.
This
is
just
for
reference,
but
mainly
if
you
ever
read
the
papers
of
differential
privacy.
This
is
the
notion
that
they
want
to
attest
and
without
any
mathematics.
E
The
meaning
is
that
the
output
of
the
function
of
the
statistical
function
is
similar
on
both
data
state.
If
you
change
or
remove
the
one
element,
so
any
kind
of
operation
that
you
take
in
different
data
sets,
can
someone
looking
from
the
side
cannot
differentiate,
there's
two
basic
schemes
that
support
differential
privacy
that
he
have
been
actually
deployed
in
the
real
world.
The
first
one
is
rapport
from
2014
until
2019
it
was
kind
of
supported
and
basically
what
it
is.
E
It
uses
the
same
idea
of
acting
of
adding
local
random
noise
into
the
statistics
that
is
taken
from
users
and
also
using
memoization.
The
problem
with
this
scheme
is
that
it
is
very
costly
because
locally,
you
have
to
add
all
of
this
randomness
and
therefore
it
is
very
costly.
In
the
light
of
these,
this
very
costly
another
system
was
devel
developed,
which
is
called
proflow
and
it's
much
more
efficient
and
also
uses
a
different
architecture.
The
architecture
that
it
uses
is
called
encode,
shuffle
and
analyze.
E
It
is
an
esa
architecture,
and
mainly
the
idea
is
that
you
also
add
this
local
randomness,
but
this
one
in
turn
is
augmented
by
a
private
channel
that
randomly
permutes
a
set
of
user
supplied
data.
So
you
have
the
local
one
that
you
add,
and
in
the
encoding
section,
then
you
have
a
shuffle
path
that
permits
the
different
user
data
and
then
you
have
the
analyze
one
that
it
just
performs.
The
statistical
function
that
you
need
to
perform.
E
E
E
That
was
called
prio
and
nowadays
the
ppm
working
group
and
the
itf
is
also
trying
to
standardize
some
preo
based
like
schemes,
not
specifically
the
original
prio,
as
it
was
first
written
in
the
original
paper,
but
kind
of
similar
schemes.
What
does
basically
prior
1.10?
Basically,
what
we
started
on
the
first
slide
private
aggregation
and
also
they
specifically
specified
three
properties
that
they
wanted
to
have
privacy,
of
course,
robustness
and
scalability.
E
So
this
is
skin,
indeed
tries
to
be
a
little
bit
more
efficient
and
the
way
it
works
is
that
it
works
with
a
small
number
of
servers
and
a
large
amount
of
clients.
And
as
long
as
one
of
the
servers
is
honest,
the
system
leaks
nearly
nothing
about
the
user's
data,
except
for
what
the
aggregate
statistic
itself
reveals.
E
So,
as
you
see
here,
we
have
already
a
little
bit
of
a
leakage
of
the
of
the
privacy
that
the
system
provides,
because
it's
not
completely
privacy
private,
as
the
first
slide
that
I
showed
you
wanted,
but
rather
than
there
is
a
specific
amount
of
leakage.
So,
for
example,
let's
say
that
you
are
using
a
mean
function:
you
are
trying
to
compute
a
mean
functionality.
E
E
To
give
you
a
little
bit
of
a
specific
pinpoint
of
the
specific
privacy
that
priyo
provides,
it
uses
a
specific
privacy,
that's
called
privacy
in
which
an
adversary,
he
controls
any
number
of
clients
and
all,
but
one
server,
there's
nothing
about
the
honest
client's
values,
except
what
they
can
learn
from
the
aggregation
function
itself,
and
this
is
just
repeated
why
I
already
show
you
in
the
previous
slide
of
what
kind
of
privacy
it
provides.
It's
kind
of
a
bounded
privacy
in
the
sense
that
there's
some
amount
of
leakage.
E
E
Okay,
so
a
little
bit
of
a
diagram
for
what
does
and
know
exactly
how
prio
works.
This
is
just
a
really
high
level
explanation
how
prio
works,
but
in
general,
let's
say,
for
example,
that
you
are
an
user
who
is
who
is
going
to
a
park
and
indeed
is
in
the
park,
and
then
the
system
actually
wants
to
know
if
you
are
in
the
pack,
because
the
mobile
clients,
for
some
reason
want
to
know
that
what
amount
of
users
are
actually
going
to
this
park.
E
And
if
you
are
in
the
park,
then
the
mobile
phone
says
one.
And
if
you
are
not
in
the
park,
the
mobile
phone
stay
in,
steer
and
sends
this
data
to
a
collection
of
an
amount
of
service.
So
instead
of
sending
the
one
meaning
the
yes,
I
am
in
the
top
arc.
What
it
does
is
that
it
splits
this
one
into
shares
in
the
shares,
for
example,
of
15
plus
minus
12,
plus
minus
2,
which
all
sum
up
to
1
and
sends
the
individual
value
to
each
server
that
that
belongs
to
the
system.
E
And
as
you
see
here,
each
individual
server
will
not
be
able
to
pinpoint,
which
is
the
private
value
that
the
user
is
submitting,
because
it's
just
a
secret
share
that
the
user
has
been
submitting
to
the
server.
Now.
It's
important
here,
of
course,
that
the
user
is
honest
in
that
the
range
value
that
they
are
sending
should
correspond
indeed
to
that
range,
meaning
that
they
send
either
a
zero
or
a
one,
meaning
a
yes
or
a
no
sorry,
a
no
on
a
yes.
E
But,
for
example,
let's
say
that
a
client
sends
a
two
in
this
case
in
general,
if
you're
only
using
secret
shares,
then
that's
indeed
possible
that
the
user
could
be
sending
a
tool.
So
what
you
indeed
also
add
in
the
prior
system
is
that
you
add
a
serial
knowledge
proof
that
is
a
specifically
called
a
secret
shared
non-interactive
proof
in
the
prior
language.
And
basically
this
is
a
proof
attesting
that
indeed
the
user
is
sending
the
correct
value
in
whatever
range.
E
So
in
an
example
is
the
correct
value,
is
either
a
zero
or
a
one,
and
that
is
sent
once
that
is
sent
to
the
different
servers.
They
each
go
between
each
other
and
attest
to
the
validity
or
not,
and
if
indeed
is
valid,
they
indeed
aggregate.
Whatever
shares
were
shared
with
the
servers
and
eventually
they
will
be
able
to
compute
whatever
aggregate
function
they
were
trying
to
do
and
as
you
see,
this
is
preserved
in
the
face
of
a
malicious
client.
E
But
then
there's
some
efficiencies
robust
here,
mainly
server
to
sorry
server-to-server
communication
is
sufficient,
but
server-to-client
communication
is
inefficient
because
computing,
sometimes
the
serial
knowledge,
proves
well
efficient
than
the
previous
zero
knowledge
proofs.
It's
still
much
more
costly,
okay
and
also
a
thing
to
note,
is
that
pre-orbase
systems
only
work
on
numeric
values,
meaning
that
you
can
only
send
numeric
values.
But
if
you
want
to
send
something
like
a
strings,
then
the
system
does
not
completely
cover
that
in
the
face
of
this
there's
another
kind
of
problem
that
one
can
solve.
E
Indeed,
when
we're,
when
someone
is
trying
to
have
all
types
of
data
to
be
a
part
of
an
aggregate
function-
and
in
this
case
we
call
it
the
private
the
heavy
heaters
problem.
One
of
the
schemes
on
this
is
the
scheme
of
the
star
that
has
been
recently
been
announced
in
a
paper
and
also
proposed
to
the
itf.
E
If
there's
at
least
k
minus
one
or
the
clients
that
are
submitting
this
data
and
what
it
prevents
is
the
preventative
collateral
from
from
being
specific,
from
specifically
learning,
uniquely
identifying
information
or
uniquely
co-occurring
patterns
of
data
from
a
unique
line,
how
does
it
work
mainly?
What
it
happens
is
that
a
client
constructs
a
ciphertext
of
the
data
using
an
encryption
key
derived
from
some
randomness.
This
random
name
is
usually
taken
from
a
randomness
server
that
uses
an
opr
functionality.
To
actually
have
this
data,
then
the
client,
once
it
has.
E
The
ciphertext
sends
the
ciphertext
to
the
service
and
also
a
k
out
of
end
secret
share
of
randomness
and
tax.
These
these
shares
within
a
specific
task,
so
the
server
will
know
which
one
to
combine
and,
at
the
end,
the
aggregation
server
organizes
the
shares
into
subsets,
depending
on
the
tax
that
was
just
submitted
by
the
client
and
recovers
encryption
keys
from
those
subsets
of
size,
bigger
or
equal
to
k.
And
if
you
want
that
more
a
little
bit
more
of
a
beautiful
diagram,
it
is
here,
as
you
see
here,
you
have
three
entities.
E
The
first
one
is
only
to
actually
gather
the
randomness
in
order
to
be
able
to
derive
the
key
that
is
going
to
be
used
to
group
the
ciphertext,
and
then
the
other
ones
is
actually
the
client
sending
the
ciphertext
to
the
aggregation
server.
Who
will
take
the
auxiliary
tags
that
the
client
actually
define
will
be
able
to
reconstruct
the
specific
for
the
ciphertext
and
we'll
be
able
also
to
decrypt
it?
E
One
of
the
things
that
is
important
to
note
here
in
a
specifically
of
the
system
is
that
is
the
first
system
that
takes
into
account
not
only
about
efficiency,
but
also
the
monetary
costs
that
are
associated
with
running
all
of
these
kind
of
ppn
techniques,
mainly
the
system.
For
example,
one
of
the
aims
was
actually
to
have
low
monetary
costs.
E
Another
system
that
is
seem
very
similar
to
peop
to
prio
is
the
popular
system,
which
also
allows
for
finding
the
most
popular
string
among
a
collection
of
clients,
as
well
as
client,
as
counting
the
number
of
clients
that
hold
up
giving
a
stream.
The
only
difference
with
prior
is
that
in
prior,
you
will
require
only
one
on
a
server.
In
this
case
you
have
a
two:
no,
you
have
to
have
two
non-colluding
data
collection
service,
and
it
indeed
also
presents
the
same
amount
of
privacy
as
free
okay.
E
So
that's
a
little
bit
of
a
really
brief
overview
of
the
different
schemes,
but
if
you
are
a
little
bit
more
interested
in
how
actually
you
compare
to
each
other,
which
was
the
core
of
the
question
when
actually
having
this
note,
I
kind
of
created
two
tables
for
this.
On
the
first
time,
for
example,
it's
good
to
consider
the
type
of
data
that
you
need,
one
to
use
when
you're,
actually
thinking
about
choosing
some
schemes.
E
So,
as
I
already
said,
the
prior-based
functionality,
somehow
some
numeric
and
then
the
star
wars
has
some
a
string,
other
kinds
of
types
of
data
that
can
indeed
be
accepting.
There's
also
some
types
of
robustness.
Notion,
for
example,
when
I
say
that
in
some
systems,
for
example,
the
trust
assumptions
are
different
in
the
sense
that
at
least
one
server
has
to
be
trusted
and
on
others
they
don't
actually
require
any
kind
of
trusting
entity.
E
Also,
as
I
said,
while
all
of
them
provide
certain
kind
of
privacy
notion,
none
of
them
actually
attain
the
in
original
privacy.
Notion
that
I
just
put
you
in
the
second
slide,
but
rather
all
of
them.
Some
have
some
kind
of
leakage
in
the
case
of
pre-assistance,
for
example,
I
already
mentioned
that
the
leakage
that
they
have
is
whatever
that
the
aggregate
function
leaks
itself.
E
That's
leaked
in
the
case
of
a
star,
for
example,
the
server
learns
which
clients
share
the
same
measurements
in
the
same
popular
there's,
a
leakage
of
all
heavy
heating,
prefix
prefix.
Sorry
all
of
them
also
have
different
efficiencies.
So
we
already
saw
that
in
the
previous
prior
base
systems,
you
have
an
inefficient
client
to
serve
a
communication
that
is
improved
in
the
iterations
of
the
original
video
paper.
E
So
you
have
a
better
efficiency
in
pre-ordering
and
I
only
added
the
monetary
cost
of
the
two
last
schemes
of
star
and
poplar,
because
those
are
the
only
ones
that
I
have
seen
analyzed
for
the
monetary
cause.
Perhaps
what
is
missing
in
this
table
is
properly
inputting
for
the
other
schemes,
but
I
didn't
have
a
lot
of
time
to
actually
analyzing
them
from
the
monetary
cost.
E
At
the
same
time,
sometimes
users
will
not
be
wanting
to
participate
in
different
aggregate
functions,
service
or
in
different
kind
of
service
in
general,
and
the
reason
why
they
will
not
be
wanting
to
actually
be
part
of
the
systems
is
because,
while
maybe
this
system,
if
they
provide
some
privacy
and
not
going
against
individual
privacy,
they
might
go
against
the
whole
group
privacy.
For
example.
Let's
say
that
you
have
a
survey
about
women
and
about
the
number
of
abortions
that
women
have.
I
will
not
would
like
to
participate
in
that
kind
of
functionality.
E
Even
though,
even
if
the
system
says
to
me
that
it's
private,
because
the
output
of
that
functionality
of
the
function
might
be
used
to
harm
me
as
a
woman
that
belongs
to
the
woman
group
or
as
an
individual,
that
belongs
to
the
woman
group,
so
the
point
here
is
that,
while
it's
important
to
provide
privacy,
it
is
not
enough,
it
also
has
to
take
into
account
user
consent
and
also,
yes,
I
also
have
to
take
into
account
user
consent.
We
should
be
really
noted
and
really
important
into
the
different
design
system,
and
with
that.
B
B
C
B
G
All
of
the
questions
that
we
care
about,
but
one
of
the
core
sort
of
design
principles
that
may
be
underlying
them.
And
so
that's
what
this
talks
about.
What
we're
calling
the
decoupling
principle
so
at
a
high
level.
Basically,
the
decoupling
principle
is
for
internet
privacy.
You
want
to
decouple
who
you
are
from
what
you
do.
That's
that's
the
nutshell
of
this
talk.
This
is
an
old
idea.
Is
nothing
new
that
we've
come
up
with
here.
G
G
So
the
mechanism
might
be
a
mechanism
for
authentication
or
mechanism
for
connectivity
or
for
whatever
else
that
you're
trying
to
achieve
the
decoupling
is
always
going
to
be
protocol
and
context
specific.
So
you
have
to
look
at
the
specific
service
that
you're
trying
to
provide,
of
course.
So
we
can
go
through
that
for
a
few
examples
and
very
sort
of
at
a
high
level
trying
to
understand
what
kind
of
decoupling
is
being
achieved.
G
So
the
context
here
before
we
go
into
that
is
ordinary
data.
Confidentiality
is
nearly
solved.
This
is
sort
of
a
broad
statement
I'm
making
here,
but
we're
at
a
point
where
tls
is
everywhere.
Data
is
encrypted
at
rest,
and
if
it's
not,
we
know
that
we
need
to
do
those
things.
There
are
some
hurdles
in
some
contexts
where
you
can't
use
tls
or
you
can't
encrypt
data
at
raster.
You
can't
do
some
of
the
very
well-known
steps
for
data
confidentiality,
but
we
know
we
need
to
do
those
things.
G
G
So
a
little
bit
of
terminology
trying
not
to
make
it
super
terminological,
but
you
know
just
to
be
a
little
bit
more
clear
about
what
we're
talking
about.
So
we're
going
to
have
a
very
crude
binary
distinction
between
sensitive
and
non-sensitive
information.
That's
the
level
we're
going
to
stay
at
a
very
high
level.
G
This
filled
triangle
is
going
to
be
sensitive
user
identity.
So
this
is
you
know
my
my
name
or
maybe
in
some
context,
my
home
router
ip
address
and
the
the
hollow
triangle
is
a
non-sensitive
user
identity,
some
sort
of
temporary
identifier,
a
random
identifier
and
then
sensitive
user
data
again
is
going
to
be
context
specific.
G
So
then
we
can
describe
using.
We
just
have
sort
of
a
tuple
which
will
say
there
is
some
party
in
some
context
that
has
some
knowledge
about
the
user
and
we're
going
to
talk
from
a
single
user
standpoint
from
the
moment.
So
if
I
write
it
like
this
sort
of
a
filled
triangle
and
a
hollow
circle,
then
we're
talking
about
somebody
knows
sensitive
user
identity
and
non-sensitive
user
data.
G
So
how
do
we
apply
this?
So
we'll
go
through
a
couple
of
examples
using
just
existing
systems
and
think
about
what
the
decoupling
going
on
is.
But
first
there
are
some
caveats.
Obviously,
identity
and
data
are
always
shades
of
gray.
The
idea
that
we
can
say
this
is
sensitive
user
identity,
and
this
is
not
it's
really
difficult
to
cleanly
categorize
that,
but
you
know
that's
we're
going
to
sort
of
use.
G
These
generally
understood
categories
for
the
analysis,
and
then
we
can
complicate
it
through
thinking
about
side
channels,
and
you
know
all
the
shades
of
gray
that
also
come
about
for
our
user
identity.
The
same
thing,
of
course,
is
true:
with
data
the
data
itself,
there's
shades
of
gray
of
what
counts
as
sensitive
and
non-sensitive,
and
maybe
even
contextual.
G
Some
data
might
be
sensitive
in
one
context
and
not
sensitive
in
another.
The
user
is
ultimately
gonna,
be
the
judge
of
that
and
then
of
course,
further
still.
Identity
and
data
are
sometimes
mixed
and
conflated,
and
so
there
too,
this
is
going
to
be
complicated.
So
I'm
going
to
just
sort
of
put
those
caveats
out
there,
but
also
we're
going
to
ignore
them
for
the
moment
and
think
about
the
the
simple
case.
First.
G
G
So
in
this
context,
the
sender,
of
course,
has
all
the
sensitive
information,
I'm
the
sender,
I'm
the
user,
and
I
know,
of
course,
my
identity.
So
the
triangle
and
the
data
that
I'm
requesting.
So
that's
the
filled
circle
now.
The
first
mix
here
knows
my
identity
in
some
form,
in
the
sense
that
I
have
to
talk
to
them.
So
they
know
my
ip
address
or
they
know
some
sort
of
network
identity
of
me
for
me
and
then
the
subsequent
hops
know
less
and
less
so
they
don't
even
know
who
I
am.
G
They
just
know
that
they
got
a
message
from
somebody
and
there's
the
the
request
itself,
which
they
don't
know
now,
there's
also
the
context
in
which
it's
I
could
pretend
to
be
mix
number
one,
so
mix
number
one
actually
thinks
that
I'm
sending
on
somebody
else's
request
right,
there's
that
design
and
in
some
systems
so
mix
one
may
not
know
even
my
identity.
So
let's,
but
let's
leave
that
out
for
a
second
for
a
second
and
then.
Finally,
the
receiver
is
gonna,
get
a
message
from
somebody.
G
And
so
the
basic
idea,
the
decoupling
principle
is
really
simple.
Third
parties
should
know
at
most
one
of
sensitive
user
identity
and
sensitive
user
data,
and
so
some
of
them
might
know
the
identity
piece,
but
not
the
data
piece.
Some
of
them
might
know
the
data
piece,
but
not
the
identity
piece
and
it's
not
always
simply,
there's
one
type
of
identity
and
one
type
of
data.
G
G
In
that
context,
you
have
a
client,
an
issuer
and
an
origin,
the
issue
or
an
origin.
Neither
of
them
know
both
the
identity
and
the
data
in
the
context
of
oblivious
dns
and
odo,
the
resolver
and
the
oblivious
resolver.
Also,
they
know
either
the
identity
or
the
data,
but
not
both
same
with
the
origin
in
the
context
of
pretty
good
phone
privacy,
which
is
one
of
our
systems.
G
G
The
second
relay
knows
the
origin
that's
being
requested,
but
neither
knows
both
and
then
private
aggregate
statistics.
You
have
an
aggregator
and
a
collector,
but
neither
knows
both
the
private
identity
and
the
private
data.
So
there's
a
lot
of
these,
and
these
are
just
this
is
a
very
incomplete
list
of
examples
of
systems
that
have
used
this
principle,
and
so
really.
The
idea
in
this
talk
is
to
sort
of
point
out
this,
the
similarity
across
of
these,
and
so
why
does
this
seem
to
work?
Why
do
people
keep
using
it?
G
Why
does
it
seem
to
work,
and
it
seems
like
this
is
an
incomplete
reason
for
why
this
works
users
often
care
about
hiding
their
true
identity
from
semi-trusted
services
and
hiding
the
data
or
metadata
of
the
requests
from
untrusted
parties,
but
they
don't
care
about
that
often,
but
sometimes
they
do
whether
they
reveal
that
they
are
a
user,
some
user
of
a
public
or
popular
service.
So
I
don't
mind
revealing
that
I'm
using
such
and
such
service.
G
I
just
don't
want
that
service
to
know
too
much
about
me,
and
I
don't
want
others
to
know
too
much
about
me
and
users
often
don't
care
about
whether
they
can
hide
a
request
from
the
service
who
is
actually
providing
it.
If
I'm
requesting
something
from
a
website-
and
I
have
to
reveal
a
little
bit
to
get
that
information-
then
I'm
willing
to
do
that
because
they
are
providing
me
a
useful
service.
G
G
That
gateway
is
doing.
You
often
was,
and
still
sometimes
is
doing,
all
processing
for
that
user,
and
so
that
means
it's
seeing
decrypted
traffic,
it's
seeing
requests
that
are
going
out,
it's
seeing
user
identity,
and
so
you
have
to
put
all
your
trust
in
that,
and
we
kind
of
we've
always
known
that,
but
this
is
just
sort
of
a
way
of
analyzing
it
to
immediately
flag
the
problem
and
then
again
the
receiver
doesn't
have
all
that
information.
G
So
the
value
that
we
get
here
is
that
we
can
quickly
identify
problems
that
might
arise
by
doing
this
quick
analysis.
This
sort
of
decoupling
analysis
this
isn't
to
say
that
if
we
show
that
we've
decoupled
we've
solved
all
problems,
obviously
we
need
to
be
able
to
have
consider
lots
of
other
things
non-collusion
between
different
parties
that
are
providing
a
service.
Sometimes
you
get
benefits
by
using
hardware
enclaves
or
trusted
execution
environments,
so
you
can
shift
trust
and
therefore
shift.
Who
knows
what
and
then
of
course,
their
side
channels.
G
B
B
C
C
Okay,
so
my
name
is
mike
rosalek,
I'm
a
faculty
member
at
oregon
state
university.
I
also
happen
to
be
on
sabbatical
at
cloudflare
research
these
days
and
I'm
going
to
be
talking
about
this
paper.
That's
going
to
appear
next
next
month
that
usenix-
and
I
just
want
to
thank
the
chairs
for
the
opportunity
to
present
here.
Let's
see
if
I
can
figure
out
how
to
drive
the
slides.
C
So
this
is
a
talk
about
ssh
authentication
and
specifically
authentication
using
public
keys.
So
I
want
to
review
how
things
currently
work
in
ssh.
So
when
I
connect
to
an
ssh
server,
my
client
offers
a
public
key
and
says:
hey.
Do
you
want
me
to
authenticate
under
this
public
key
and
the
server
might
say
no?
C
With
this
approach,
I
think
one
of
the
most
well-known
problems
with
this
is
that
the
server
can
fingerprint
the
client,
and
what
I
mean
is
that
the
server
can
just
say
no
to
all
of
the
clients,
advertisements
and
actually
by
default.
The
ssh
client
will
send
all
of
the
public
keys
that
it
knows
about
that
are
currently
loaded
into
the
ssh
agent.
C
So
the
server
can
see
your
public
keys.
Even
your
keys,
that
are,
you
know,
presumably
not
not
generated
for
this
particular
server.
So
I
want
to
point
out
a
cool
application
of
this,
or
maybe
it's
creepy.
I
don't
know
if
it's
cool,
but
maybe
creepy-
and
this
is
what
first
got
me
aware
of
this
problem.
C
C
So
that's
kind
of
creepy
and
the
reason
this
works
is
that
my
github
public,
my
my
public
key
for
github
ssh,
is
loaded
into
my
ssh
agent,
all
the
time
because
I'm
always
using
github
and
so
my
ssj.
My
ssh
client
offers
it
to
this
the
philippo's
ssh
server
and
he
has
a
database
of
public
keys.
He
knows
that
this
public
key
belongs
to
this
user
on
github,
so
this
problem
can
be
resolved.
C
You
can
configure
your
client
to
only
send
keys
to
the
servers
that
you
expect,
so
this
can
be
resolved
with
some
configuration
changes,
and
so
if
this
was
the
only
problem
with
ssh,
then
I
would
wouldn't
really
have
much
to
say
so.
I'm
going
to
mention
a
few
other
issues
with
this
ssh
authentication.
C
C
Now
the
ssh
protocol
does
support
a
preemptive
signature,
so
the
client
can
provide
a
signature
along
with
the
public
key
in
the
offering.
You
know
in
the
hopes
that
this
might
save
a
round,
but
as
far
as
I
know,
there's
no
ssh
server
that
that
has
any
has
a
configuration
option
that
enforces
these
preemptive
signatures
to
be
given.
C
So
that's
a
bit
of
a
problem.
Another
issue
is
that
the
server
obviously
sees
which
of
the
keys
was
used.
So
if,
if
several
keys
are
authorized
to
perform
an
operation
on
the
ssh
server,
then
the
server
observes
which
of
the
keys
was
actually
used.
This
is
kind
of
fundamental
to
the
protocol
and
it's
even
a
little
bit
worse,
because
the
ssh
server
can
prove
to
anybody
that
you
know
somebody
authenticated
under
this
specific
key,
so
authentication
is
not
deniable
and
last.
This
is
a
little
bit
esoteric.
C
C
C
Those
are
the
inputs
to
the
protocol
and
you
can
see
in
this
case.
Sk1
is
supposed
to
go
with
pk1
and
sk4
is
supposed
to
go
with
pk4.
For
example,
these
keys
can
be
a
mixture
of
rsa,
ecdsa
and
so
on.
So,
for
example,
sk
the
first
public
key
could
be
rsa.
The
second
public
key
could
be
dsa.
For
example,
all
of
these
can
be
used
together
in
one
attempt.
C
What
does
the
server
learn
from
the
interaction?
The
server
learns
that
the
number
of
keys
the
client
has
and
the
server
learns
that
at
least
one
of
this
client's
keys
is
authorized,
so
it
doesn't
in
particular
it
doesn't
learn.
In
this
case.
We
can
see
that
key
number
one
and
key
number
four
are
authorized,
but
the
server
doesn't
learn
that
information.
C
It
just
knows
that
at
least
one
of
the
authorized
keys
was
being
used,
but
it
doesn't
learn
which
one
and
the
client
learns
the
number
of
keys
that
the
server
has
and
it
learns
which
of
its
keys
were
authorized.
So
it
learns
that
pk1
and
pk4
were
authorized
keys,
but
in
particular
the
client
cannot
learn
whether
public
key
pk2
is
authorized
by
the
server,
because
the
client
doesn't
know
the
corresponding
secret
key.
So
the
client
can't
offer
somebody
else's
public
key
and
learn
whether
the
server
recognizes
it.
C
C
So
basically,
you
can
think
that
the
server
generates
a
ciphertext
and
it's
addressed
to
a
set
of
public
keys
and
the
ciphertext
is
c
and
while
generating
that
ciphertext,
the
server
knows
that
okay,
somebody
who
has
secret
key
j,
will
decrypt
this
message
to
message
mj.
So
the
server
learns
all
these
mj
messages
and
we
need
the
property
that
the
ciphertext
c
hides
the
identity
of
these
public
key
recipients.
C
C
So
the
server
sends
that
cipher
text
over
to
the
client,
the
client
can
decrypt
with
all
of
its
secret
keys,
and
so
now
some
of
these
decryptions
are
equal
to
the
values
that
the
server
already
knows
and
so
to
tell
whether
they
have
any
in
common.
They
use
a
private
set
intersection
protocol,
so
in
private
set
intersection.
Each
party
has
a
set
of
items
and
we
use
a
variant
where
the
client
learns
the
intersection
of
the
items
and
the
server
only
learns
whether
the
intersection
was
empty.
C
So
this
is
a
composable
security
kind
of
the
best,
the
best
kind
of
security
that
we
know
how
to
prove
for
an
interactive
protocol
like
this
okay.
So,
finally,
I
want
to
just
mention
the
performance
of
this
protocol.
We
implemented
this
as
a
extension
of
open
ssh,
and
it's
quite
practical.
So
I
mentioned
that
the
protocol
supports
rsi
keys
and
elliptic
curve
keys
simultaneously,
but
the
rsa
keys
are
much
more
expensive.
C
So
for
the
worst
case,
let's
look
at
if
all
the
keys
are
only
rsa
keys,
that'll
be
the
the
worst
case
in
terms
of
performance,
and
the
best
case
in
terms
of
performance
is
if
all
of
the
keys
are
just
these
elliptic
curve
keys
and
there's
really,
we
didn't
find
any
difference
between
ec
dsa
and
dsa.
There's
very
little
difference
there.
So
I
just
lump
them
into
one
category
as
elliptic
curve
keys.
C
So
in
a
realistic
setting
where
the
client
has
five
keys
and
the
server
has
ten
keys,
I
think
that's
a
realistic
setting
for
a
kind
of
a
small
github
repository,
let's
say
even
with
rsa
keys,
60
milliseconds
and
with
elliptic
curve
keys.
It's
like
instantaneous,
nine
milliseconds,
I
mean
nine
milliseconds
is
not
instantaneous,
but
for
authenticating
a
connection.
That's
that's
pretty
good.
C
C
Even
that
is,
is
still,
I
believe,
within
the
realm
of
reasonableness
for
authenticating
a
connection
even
with
rsa
keys.
We
try
to
take
this
to
the
extreme
and
imagine
a
server
with
1000
keys.
So
that's
a
server
that
authorizes
1
000
different
public
keys
to
be
able
to
connect
so
with
rsa
keys,
that's
a
little
slow
it's
over
a
second,
but
even
with
elliptic
curve
keys
less
than
a
quarter
of
a
second.
So
again
I
think
it's
pretty
reasonable.
C
C
C
A
C
Question
in
the
chat
from
from
chris
p
concrete
performance:
this
was
like
total
round
trip
time.
So
from
the
from
the
client's
perspective.
From
the
time
you
say,
I
want
to
connect
to
the
server.
It
includes
the
tcp
setup
as
well.
I
think,
but
these
were
two
two
servers
on
the
same
lan.
So
the
time
from
saying
connect
to
the
time
that
we
can
send
the
first
application
command
to
the
ssh
server.
C
F
C
C
So
it's
true
that
at
the
time
that
you
run
the
protocol,
let's
see
if
I
can
illustrate
with
the
picture
it's
easier
for
me
at
the
time
you
run
the
authentication
protocol.
The
server
has
to
know
which
keys
are
authorized
and
if
the
server
only
knows
that
some
github
user
is
connecting
to
some
repository,
that's
not
quite
enough
information,
so
it
turns
out
in
the
in
the
ssh
flow.
The
client
says
I
want
to
authenticate
to
this
user.
C
C
C
A
A
A
So
next
slide
please.
There
are
quite
a
few
open
issues,
mostly
because
the
original
author
ian
leermath,
who
has
done
the
vast
majority
of
the
work,
already
put
those
issues
in
there.
They
have
not
all
been
solved,
but
mostly
they're,
quite
low-hanging
fruit
in
terms
of
he's
identified,
some
really
good
citations
that
are
within
scope
of
the
document.
They
just
need
to
be
elaborated
within
the
structure
and
here's
a
sort
of
short
list
of
those
six
open
issues.
You
can
see
right
there,
there
they're
pretty
obvious.
A
Then
I
think
so,
yeah
there's
a
really
basic
update
to
this,
which
I
think
makes
the
structure
a
little
bit
more
straightforward.
I'm
going
to
also
plan
to
send
a
message
to
the
perigee
list
for
those
that
aren't
here
or
participating
online
in
this
meeting
to
get
more
feedback
on
folks
who
might
be
interested
in
suggesting
text
for
the
open
issues
or
reviewing
the
current
version
to
make
sure.
I
think
I
have
two
questions
about
review
at
this
stage.
A
One
is
the
table
of
contents
complete
so
far
and
then
two
if
there
are
definitely
missing
sections
that
we
already
know
about,
but
the
one
the
last
thing
I'll
say
before.
Maybe
people
have
comments
or
want
to
volunteer
to
help.
It's
just
that
you
might
have
seen
the
iab
announce
a
workshop
coming
up
like
q4.
A
It's
the
workshop,
I
think,
turns
the
concept
on
its
head
a
little
bit,
because
what
it's
trying
to
do
is
you
know,
make
network
measurement
a
little
bit
easier
or
try
to
solve
some
of
the
sticky
issues
with
network
management
and
encrypted
environments,
and
this
draft
is
sort
of
coming
at
it
from
like
from
a
safety
and
privacy
perspective.
You
want
to
make
that
measurement
safe.
A
B
It
doesn't
look
like
there's
any
questions,
but
one
recommendation
now
that
the
ietf
is
working
on
privacy,
preserving
measurement.
That's
certainly
a
group
that
will
probably
need
some
guidance
in
terms
of
how
to
use
the
systems
they're
developing
adap.
Specifically,
so
I
wonder
to
what
extent
you
know
either.
This
document
would
benefit
from
the
work
that
that
group's
doing-
or
that
would
benefit
from
the
work
that's
being
developed
here,
but
it
seems
like
there's
some
cross-pollination
that
should
be
happening
as
we
move
forward.
A
I
really
love
to
know
that
now
or
we
can
talk
in
the
hallway
or
at
some
point
in
the
future,
but
because
I
think
the
idea
is
that
this
would
maybe
be
this.
This
draft,
because
it's
in
the
irtf
especially
would
kind
of
be
making
a
broader
sort
of
approach
to
the
issue
and
then
ppm
would
maybe
then
yeah,
as
you
say,
sort
of
take
advice
from
it.