►
From YouTube: IETF-TIGRESS-20230223-1800
Description
TIGRESS meeting session at IETF
2023/02/23 1800
https://datatracker.ietf.org/meeting//proceedings/
A
A
We
should
get
started
all
right,
welcome
everyone
to
Tigress
working
group
Intro
meeting.
My
name
is
prachi
Jin
and
leave
unfortunately
looks
like
couldn't
make
it
today,
so
we'll
go
back
and
check
with
him.
But
here's
the
note.
Well,
please
note
the
note
well
well,
as
they
say
in
ITF
land
for
remote
participants,
please
try
to
use
your
headset
if
you're,
not
speaking,
you're,
not
cheering,
keep
your
video
and
audio
off
and
then
for
the
agenda
today.
A
B
A
There
so
I'll,
let
and
if
you
are
willing
to
help
me,
take
minutes.
It's
a
10
crew
today,
I
understand.
So
if
anybody
is
willing
to
help
me
out
with
notes,
please
do
I
share
the
link
to
the
notepad
in
the
chat
with
that
Casey.
Do
you
want
to
get
started
or
is
Dimitri
or
Brad?
Okay,
all
right
so
I'll
give
it
to
you
I'll,
go
ahead
and
share
your
slides
great,
thank
you
and
I'll
pass
you
the
control
as
well.
B
Awesome,
perfect,
okay,
so
thank
you
all
so
much
for
joining.
Definitely,
as
prachi
said,
we've
been
getting
a
lot
more
discussion
over
our
email
thread,
so
we
really
wanted
to
just
do
a
quick
interim
meeting
before
the
next
iitf
to
kind
of
drill
down
on
some
of
these
pieces
have
been
discussed.
So,
let's
see.
B
Sorry,
oh
okay,
okay,
so
here
is
our
agenda,
so
we're
just
going
to
do
a
quick
review
of
what
we've
been
working
on
since
the
last
iitf
meeting.
Talk
about
the
high
level
of
updates
of
a
requirements
document
the
update,
store
threat
model
document
and
then
a
quick
review
of
some
of
these
new
documents.
We've
created
I.
B
Think
our
goal
is
to
spend
the
majority
of
the
time
really
on
those
requirements
and
threat
model
documents
that
we
had
the
most
commentary
on
in
previous
meetings
and
kind
of
nail
down
anything
that
might
be
controversial
and
hopefully
hopefully
maybe
we
can
do
a
vote
for
adoption
for
those
two
documents.
Nothing
else
all
right
with
that
I'll
just
start
diving
in
at
a
high
level
the
work
we've
done
since
itf115
was
mainly
addressing
feedback
on
requirements
and
the
threat
model
documents.
B
In
addition,
we
worked
on
some
one
pages
that
were
about
alternate,
suggested
approaches
for
how
we
could
solve
Tigress.
So
the
point
of
those
particular
documents
was
not
to
say:
we
need
to
like
choose
one
of
these
exact
directions,
but
more
of
a
thought
experiment
to
understand
you
know:
could
these
alternate
solutions
that
were
suggested
or
existing
solutions,
kind
of
match
our
requirements?
So
for
us
that
was
really
really
helpful
and
we'll
talk
about
that
more
at
the
end,.
B
Okay,
so
high
level
update
to
the
requirements.
We
got
a
lot
of
feedback,
basically
about
making
them
more
generic
and
taking
out
pieces
that,
were,
you
know,
not
considered
to
be
part
of
an
iotf
requirements
document.
So
things
like
user
interface,
related
requirements
were
all
taken
out
and
we
also
made
them
significantly
more
generic
and
added
an
example
diagram
for
some
additional
context
for
what
we
were
trying
to
solve.
B
So
that
was
the
high
level
and
now
we'll
focus
on
talking
through
like
individual
requirements.
I
think.
First,
we
talked
through
some,
hopefully
on
controversial
ones
and
I
was
I
was
hoping
to
spend
some
of
this
time
kind
of
like
showing
the
slide,
letting
you
all
read
and
then
maybe
getting
feedback
so
certainly
feel
free.
B
If
you
want
to
start
addressing
comments,
so
I'll
just
give
everyone
a
couple
of
minutes
just
to
take
a
look
at
this
slide
and
just
read
through,
and
if
anyone
has
comments
on
these
particulars
again,
we
think
these
ones
are
uncontroversial,
so
I
wasn't
anticipating
too
much
talk,
but
certainly
feel
free
to
raise
your
hand
and
I'll.
Also,
let
Dimitri
and
Brad
take
ownership
of
this
section.
They
worked
really
hard
on
the
requirements.
C
E
C
Guess,
I
guess
sorry,
go
ahead.
Sorry,
go
ahead!
Well,
I!
Guess
what
I
wonder?
Is
there
a
stronger
version
of
that
requirement?
In
particular,
you
know
we
were
some
conversation
during
both
meetings
and
offline
about
like
about
about
situations
in
which
you
require
that
the
the
device
is
indicated
TPM
in
order
to
be
able
to
participate
in
this
protocol
right
and
so
and
so
I
guess,
like
you
know
like
again,
I
guess
like
there's
one
thing
that
they
do
a
platforms.
C
F
D
D
F
B
E
B
No
no
I
I
was
I
was
having
a
little
bit
of
trouble
hearing
you
as
well
Eric,
but
I.
Think
I
understand
your
point,
I
think
their
piece
that
you
were
discussing
and
I
don't
think
we
have
a
solution
to
this
is
when
like,
if
you
were
trying
to
share
to
one
person,
if
they
continue
to
share
it
down
a
loop
I,
don't
think
from
all
the
solutions
we've
kind
of
discussed,
I,
don't
I,
don't
think.
We've
generally
talked
about
too
much
of
that
like
how.
B
C
C
C
So
so
maybe
there's
some
way
to
generalize
that,
but
you
know
I
think
you
know
again,
I
think-
and
it's
also
I
think
maybe
a
question
of
like
is
that
is
that
is
that
is.
Is
this
the
right
place
to
locate
it
as
opposed
to
in
in
the
in
in
the
sort
of
protocols
that
we
are
carrying,
but
again
I?
Don't
think
I
don't
think
it's
necessarily
a
problem
with
just
trying
to
like
I.
B
F
B
Oh
yeah,
okay,
so
I
was
just
gonna
say
that's
a
really
good
point
and
I
think
I've
been
thinking
about
it
as
a
requirement,
but
in
a
sense
it's
just
an
additional
security
item
or
like
an
additional
way,
for
you
know,
say
for
our
use
case.
We
only
have
these
like
single,
shared
share
or
person-to-person
sharing
in
a
sense
to
your
point.
B
F
Just
to
add
to
that,
we
were
trying
to
build
our
requirements
through
a
simple
use
case
where
we
send
credentials
from
one
device
to
another,
since
the
groups
are
in
wheel,
certainly
add
complexity,
and
we
just
don't
want
to
address
it
yet.
So
we
want
to
use
this
as
a
stepping
stone
for
possible
future
extensions
if
it
makes
sense.
E
D
F
I
think
the
next
two
slides
contain
the
difference
with
the
original
requirement
statement
yeah.
So
we
we
decided
to
break
it
down
to
three
portions
three
statements:
first
about
prevent
and
correlating
users,
exchanges
or
creating
social
graph,
and
then
Integrity
server,
not
being
an
Arbiter
of
identity
and
finally,
the
user
identification
will
be
collected
and
we
are
kind
of
not
certain
like
we
wanted
to
remove
that
requirements.
If
the
first
two
objectives
can
be
reached
without
the
Third,
but
is
that
correct.
D
I
think
the
key
thing
here
is
that
the
protocol
itself
can't
do
anything
about
the
cluster
practices
of
the
participants.
You
can
only
collect
what
or
it
can
only
prevent
information
being
being
transmitted.
So
that
was
the
purpose
of
that
edit
to
remove
the
non-collection
requirement
and
rely
on
the
fact
that
the
data
is
that's
being
shared
with
the
participants
by
the
protocol.
It
doesn't
allow
for
coalition.
F
Standard
trust
again
back
to
the
previous
requirements.
There
should
be
a
certain
level
of
trust
between
the
device
mortgage
and
a
team.
The
answer
and
the
integrated
server
is
the
solution,
includes
intermediate
server
and
that's
important
for
a
number
of
reasons
which
we
discussed
in
the
past
and
I
see.
Eric
wants
to
share
his
opinion.
Oh
I
know
there
was
a
discussion
through
memories.
C
B
G
F
C
You
trying
I
mean
I
mean
like
when
this
was
first
presented
right.
The
sort
of
up
the
sort
of
the
model
that
I
heard
described
was
that
I'm
going
to
SMS
some
link
to
somebody
or
iMessage
it
or
whatever,
right
and
then
they're
going
to
click
on
it,
and
this
back
and
forth
is
going
to
happen
right
and
so,
like
the
relevant
trust
relationship.
Is
that
the
user,
like
like
the
person
who
sent
them
the
message
in
the
first
place?
C
It's
none
of
this
stuff
about
the
relay
server,
which
these
are
not
really
stupid
at
all,
and
so
who
who's
being
protected
by
by
this
like
by
this
requirement
and
I.
Just
don't
think
that
is
right
and
like
in
particular,
like
you
know,
I
mean
so
I
mean
I
mean
I.
I
mean
I,
I
assume.
The
way
this
works
is
that
this
link
has
some
decoration
on
it.
That,
like
says
now,
engage
like
apple
wallet
and.
H
C
Wallet
pulls
it
up
and
does
some
like
nonsense
right
and,
like
that's
the
part,
that's
where
the
production
comes
from,
not
like
the
release
and
to
Flip
Flip
it
around
to
talk
about
the
relay
server
trust
in
the
in
the
in
the
user
instructions.
The
relay
Surfer
like
that's
what
the
encryption
is
for,
so
so
I
guess
like
this
I.
Just
like
you
know,
I'm
much
happier
there
is
over
like
a
completely
untrusted
Party
part
of
the
system
for
the
purpose
of
our
security
analysis.
F
F
D
May
I
yeah,
oh
sorry,
may
I
suggest
we
remove
this
requirement
and
articulate
any
threats
that
you
are
trying
to
mitigate
with
it
in
the
the
threat
model
and
think
through
the
possible
mitigations
for
that
and
if,
in
the
end
of
going
through
that
process,
if
they
only
mitigation
we
come
up
with
is
some
sort
of
trust
relationship.
Then
the
requirement
can
go
back
in,
but
I
think
there's
at
this
point
significant
doubt
as
to
whether
this
requirement
is
a
core
requirement.
G
The
goal
of
this
requirement
is
a
relay
server
protection,
not
user
protection.
Just
saying
that
the
relay
server
needs
to
have
some
way
to
trust
the
sending
device-
and
it's
not
really
trust,
but
just
know
that
they're
sending
device
is
allowed
to
create
mailbox.
It's
really
to
prevent
a
bad
actor
from
just.
D
G
H
D
G
C
So
this
seems
like
a
reasonable
requirement,
but
I
think
it.
Maybe
that's
the
thing
that
has
to
get
pulled
in
here,
because
I
think,
like
I,
mean
I
think
maybe
like
I
was
sort
of
typing,
that
they've
seen
vague
and
so
I
think,
like
exactly
the
point
you're
making
about
how
it
has
to
be
notification.
Mechanism
like
that
seems
like
that
seems
like
something
that
we
ought
to
be
pulled
in
here.
If
this
is
a
requirement.
C
G
I
wonder
if
we
could
say
maybe
just
explicitly
call
out
that
we
don't
want
to
do
polling
as
a
solution.
You
know
for
battery
and
Network
reasons
and
then,
if
we
like,
if
the
end
solution
needs
something
like
sockets
or
HEB
keep
alive,
then
we
wouldn't
need
notifications
and
web
hooks.
We
could
because
it
would
just
be
built
into
the
protocol.
D
D
I
B
C
B
C
C
But,
like
you
know,
let
me
give
you
a
hypothetical
suppose
that
it
was
just
a
URL
and
it
always
went
to
like
a
regular
web
server
and
the
web
server
fed
back
like
you
know
something
in
the
mind,
content
type,
and
that
was
the
indicator
that
kicked
off
the
you
know,
Apple
wallet
or
whatever.
Is
that
an
acceptable
outcome?
If
it's
not
acceptable
outcome,
then
you
know,
then
what
is
a
sensible
outcome?
C
D
I
suspect
this
also
might
be
a
candidate
for
a
consideration
session.
I
think
another
consideration
here
is
I've
heard
the
desire
or,
if
you
don't,
have
an
appropriate
device.
So
if
you
have
an
Android
phone
that
doesn't
have
the
wallet
installed
that
engaging
with
whatever
this
invitation
is,
would
display
some
instructions
about
how
to
actually
move
forward
with
it,
rather
than
just
being
a
broken
leg,
but
anyway,
there
are
a
lot
of
trade-offs
involved
in
that
so
I
I
suspect.
D
I
I
mean
just
typing
in
there,
I
think
it's
kind
of
like
device
Globe
right
in
open
ID,
but
sometimes
you
want
to
do
it
with
like
the
type
instruction
to
the
user
on
the
TV
screen,
and
sometimes
it's
a
QR
code,
and
sometimes
it's
something
else.
Sometimes
you
kick
in
click
this
URL
there
I
I,
think
but
yeah
I
think
the
intention
that
Eric
was
talking
about
is
kind
of
what
you're
going
for
right.
It's
a
simple
thing
that
the
user
can
interact
with,
but
it
doesn't
always
fulfill
inside
of
the
bus
requirement.
F
F
B
Yeah,
so
this
last
slide
was
just
talking
about
additional
considerations.
I
think
I
might
I
have
written
some
notes
about
some
considerations.
I
would
just
discussed
so
we
might
move,
but
this
is
just
one
note.
We
were
curious
what
people
thought
we
had
talked
about
the
provisioning
partner
as
an
entity
within
the
requirements,
doc
such
as
kind
of
additional
context
about
what's
happening,
but
I
think
we
were
unsure
if
people
wanted
that
context
or
if
it
should
be
completely
removed.
F
Yeah,
so
just
in
additional
consideration
session
section,
we
added
a
brief
description.
What
that
could
be,
what
different
types
of
credential
transfer
could
be
included,
a
difference
in
key
material
Etc
again,
it's
all
based
on
the
previous
questions,
where
I,
initially
it
was
out
of
school
and
we
didn't
provide
any
information,
and
we
are
certainly
open
to
remove
that
particular
pretty
good
topic.
E
B
B
D
D
Yeah
so
defined
a
set
of
threats
and
then
my
guess
at
likelihood
and
impact
for
that
could
be
attacking
a
pure
protocol
or
sorry,
a
protocol
that
purely
communicated
from
sender
to
receiver
without
using
an
intermediary
server,
which
is
one
flow,
that
the
requirement
stock
lays
out
the
as
you
can
see
with
the
last
one.
We
don't
have
mitigations
for
some
of
these,
and
some
of
them
might
not
be
mitigatable,
and
perhaps
these
mitigations
aren't
you
know
fully
preventing
any
any
impact
here.
D
A
H
D
I
So
I
think
it's
important
to
keep
track
of
like
which
of
these
mitigations
actually
fall
in
the
scope
of
the
protocol.
Right,
not
everything
will
and
some
the
stuff
that
doesn't
you
know.
Maybe
that
goes
into
an
Implement
implementer's
section
or
implementation
advices,
or
something
like
that.
But
but
you
know
we
gotta
make
sure
that
we
don't
get
scope
creep
just
because
we've
identified
a
threat
right,
because
we
can't
deal
with
everything.
I
H
Yeah,
there's
no
mitigation
for
the
last
one.
We
could
rely
on
device
attestation,
which
you
know
Google
and
apple
both
have
on
our
phones,
but
that's
a
really
hard
thing
to
kind
of
this.
It's
another
just
like
try
to
do
your
best
right,
like
we
can't
put
it
in
the
protocol
and
it
doesn't
necessarily
even
solve
it
since
it's
not
perfect.
F
Yeah,
so
the
mitigation
to
the
last
one
might
be,
as
Eric
mentioned,
in
the
chat
credential
replication,
which
is
a
life
cycle
management
for
the
credential,
and
it
often
involves
interaction
with
provisioning
entity.
In
addition
to
that,
second
and
third
can
be
addressed
by
introducing
second
Factor
authentication
during
the
revisioning
flow.
So
when
the
transfer
finalized
and
now
we
either
interact
with
with
a
credential
entity
and
during
that
time,
second
Factor
might
be
solution
to
the
problem.
I
I'll
just
go:
go
on
the
Queue
to
signify
that
I'm
speaking
as
in
the
individual
there's.
One
thing
that
kind
of
jumps
at
me
is
that
that
you're,
using
RSC
2119
language
in
the
first
mitigation
and
not
the
other
two
I'm
wondering
whether
that's
International
or
not.
Maybe
it's
not
right,
but
you
should
probably
kind
of
look
at
that.
I
I
D
On
the
first
one,
I
think
that's
more
of
an
artifact
that
I
was
copying
from
two
different,
no
stocks,
that
I
wrote
on
two
different
days,
so
that
is
not.
That
was
not
intentional.
So
thanks
for
catching
that
on
the
second
one,
yes
I
agree,
a
lot
of
these
will
wind
up
either
being
ux
problems
or
device,
anti-abuse
device,
identities
or
service
identity,
abuse,
detection
problems.
B
D
The
perspective
I
was
taking
that
was
try
to
Define
all
the
threats
involved
in
this
transaction
from
user
to
user.
Some
of
those
will
be
mitigated
in
general
by
the
protocol
and
the
communication,
most
I
suspect
will
not,
but
just
trying
to
document
what
they
are
and
what
we
are
trying
to
mitigate
and
what
we
are
not.
C
C
E
D
Yeah
I
think
I
also
question
the
practicality
of
this,
but,
as
it
has
a
been
described
to
me,
you
would
send
say
the
key
over
your
over
SMS
to
your
friend
and
also
when
they
arrived
at
the
door.
There
would
be
a
pin
that
they
could
use
to
unlock
the
key
or
you'd,
send
the
pin
over
email
and
the
invitation
over
over
SMS
or
something
like
that
to
have
a
separation
between
the
two.
D
C
So
I
think
the
only
question
will
be
whether
when
we
finally
get
to
protocol
design
does
the
protocol
have
to
incorporate
this
as
a
feature,
or
does
it
merely
have
to
be
something
you
could
do,
but
that
was
out
of
out
of
scope
for
us,
like
you
know,
for
instance,
you
know,
while
you
type
it
in
because
a
provisioning
server
is
under
your
business,
another
person's
business,
so
I
think
it
was
like
that
like
this
is
all
fine
but
like
when
we
you
know
we'll
have
to
remember
this
later.
Would.
B
Yeah
no
problem
so
the
next
section,
so
that
was
the
full
review
of
our
requirements
and
our
threat
model
document
so
really
appreciate
all
the
feedback
there.
So
the
next
piece
is
were
just
some
quick
reviews
of
our
one
pagers.
So
just
to
know
again,
these
were
more
of
thought.
Experiments,
not
necessarily
that
these
are
going
to
be
our
full
Solutions.
B
B
The
solution
for
our
page,
for
both
like
signal
signal
and
GSS
API
I
think
were
similar
and
could
be
useful,
I
think
for
Signal.
It
didn't
feel
as
like
directly
applicable,
because
it
seems
that
the
for
signal
is
anticipating
you
having
some
semblance
of
a
user
account
that
you
know
you
base
your
encryption
off
of
and
with
with
webdav.
You
don't
need
those
like
like
ideas
of
like
accounts,
which
is
just
nice,
because
then
the
intermediary
server
has
like
no
no
ties
about
who's.
B
C
So
I
think
these
were
actually
answers
to
slightly
different
questions,
but
I
think
that
the
the
web
job
one
I
think
was
an
answer
to
the
question.
I
think
when
Brad
or
iPhone
or
did
was
like
how
do
we
do
essentially
what
the
original
protocol
did,
but
maybe
with
standardized
techniques
like
when
Richard
and
I
sort
of
said
well,
why
not
signal
I
think
that
was
in
tempting
to
answer
your
question
of?
C
Why
can't
you
just
send
the
whole
thing
in
one
chunk,
like
your
transport,
so
I
think
once
we've
conceded,
that
we
need
back
and
forth
that
I.
Think
that,
like
signal,
like
anything
that
looks
like
it,
smells
like
a
messaging
system,
it's
like
I
mean
that's
the
answer
to
how
you
send
the
initial
URL.
But
it's
not
answer
the
whole
thing
and,
and
the
way
you've
described
it
is
that
that
that
whatever
changes
in
the
URL
of
our
properties,
which
signal
with
me
or
iMessage
would
meet
or
whatever
it
would
be
right
and
I.
C
Think
honestly,
the
GSS
thing
I
think
probably
like
we
could
just
take
off
the
table.
That
I
think
there
was
a
I
think
there
were
sort
of
like
I
think
when
the
people
I
was
the
person
who
voted
it,
but
I
think
the
person
who
floated
it
was
kind
of
saying
like
that.
This
whole
General
apparatus
smells
like
GSS
in
terms
of
credential
management,
but,
like
you
know,
and
when
you
replace
you
know,
CCC
and
the
whole
thing
with
GSS
and
I.
C
C
Is
not
really
like
a
relevant
consideration,
so
I
think
you
know
I
think
you
know
it's
worth
looking
it's
worth
exploring
this
question
whether
web
guys
can
actually
have
the
job
done
and
if
it
does,
that
seems
like
an
attractive
option
and
if
it
can't,
then
we
need
to
decide
something
else
or
steal
something
else,
but
I
think
we
can
probably
take
the
other
two
I
probably
are
not
really
like
not
really
operating
for
the
purpose.
Conversation.
B
Yeah
and
I
I
agree
with
you
Eric.
It
makes
a
lot
of
sense
that
you
know
there
are
suggestions
about
what
we
were
trying
to
do,
but
I
honestly
think
for
me
I,
you
know
I
was
writing
this
web
dev
one
pager
and
it
did
feel
like
look
while
we're
having
discussions
with
requirements
and
talking
about
web
dev.
Webdav
did
actually
seem
like
it
fit
a
lot
of
our
requirements,
so
I
think
as
you
as
you
sent
out
in
the
email.
B
So
I
don't
know,
I
appreciated
all
the
feedback,
because
I
I
had
not
even
heard
of
webdav
and
if
we
had
known
about
it
before,
maybe
we
would
have
just
done
this
from
the
get-go,
but
yeah.
That's
that's
that's
kind
of
all.
We
did
for
the
one
Pages.
It's
not
these
documents
don't
have
to
be
adopted
by
the
working
group
or
anything
like
that.
They're
just
very
helpful
for
us
to
discuss
it,
how
it
would
work.
H
I
Yeah
I
was
just
gonna,
say,
I.
Think
maybe
it's
time
to
do
that,
and
the
question
is
whether
we
do
it
in
in
the
before
or
at
the
1
16
timeline.
But
me
and
Patrick
will
talk
to
the
80s
about
that
and
and
yeah
it's.
It
will
definitely
be
a
call
on
the
list
either
way
because
there
I
don't
think
there
will
be
enough
people
in
your
grandma,
too
I
have
a
get
a
sense
of
the
room.
There
I
know
the
you
guys
won't
be
able
to
travel
to
your
column.
B
I
Yeah
and
if
we
can
get
that
revved
onto
the
list,
I
think
that's
kind
of
a
good
place
to
kind
of
that's
a
good
I
I.
My
feeling
is
that
there's
this
is
has
now
gotten
quite
a
bit
of
feedback,
even
though
there
are
a
few
people
who
have
sort
of
provided
feedback.
It's
still
a
lot
of
seniority
going
into
all
of
this
review,
so
I
I'm,
I'm
kind
of
comfortable.
So
we'll
see
if
the
working
group
agrees.