►
From YouTube: IETF104-SAAG-20190328-1350
Description
SAAG meeting session at IETF104
2019/03/28 1350
https://datatracker.ietf.org/meeting/104/proceedings/
A
A
C
A
A
A
This
is
what
our
agenda
is
looking
like
today,
we're
gonna
use
to
do
the
usual
working
group
reports
and
we've
got
a
couple
of
talks
before
the
open
link
and
thank
you
to
all
the
working
group
chairs
who
sent
there
there's
some
reason
ahead
of
time.
Oh
gosh,
I'm
Way
ahead
of
myself,
so
I'm
been
kaduk,
and
this
is
our
new
security
dating
ruined.
A
D
Yeah,
so
the
issue
is
that
we
have
a
draft
for
configuring,
IP,
SEC
and
the
way
they
made.
The
yang
model
is
by
just
copying
the
entire
ini
registry
coding,
some
yeah,
some
shed,
some
algorithms
that
are
considered
deprecated
like
special
export
grade
40
bit
discs,
and
so
the
thing
is
not
how
to
tell
them
not
to
cook
that
stuff
it.
The
air
literacy
is
dynamic,
you
were
having
in
any
document,
might
add
a
new
algorithm
to
iron
and
then
what
we're
going
to
suppose?
D
Do
you
night
when
SF
read
and
make
a
new
version
of
our
document
and
make
obsoletes
RFC
every
time
somebody
changes
their
anniversary,
so
we're
looking
for
a
way
to
make
this
more
structured
so
that
you
don't
have
to
rev
our
own
RFC
just
follow
the
IANA
somewhere
some
some
way.
You
know,
I,
don't
actually
recall.
A
E
No,
no,
the
problem,
Michael
Richard.
The
problem
is
that
you
wind
up
with
a
new
in
the
yang
model
that
lists
all
the
items,
and
so,
unless
we
have
changes
to
yang
that
says,
here's
the
Ayane
registry
XML,
that's
the
appropriately
list
of
things.
Then
Ayane
can't
really
eat.
My
can't
really
manage
that
module
without
creating
a
new
RFC
from
it,
because
there's
an
enumeration
in
the
yang
module
that
lists
the
choice.
D
Now,
of
course,
we
could
get
rid
of
the
enumeration.
Just
leave
the
number
there
and
yeah
and
tell
them
yeah
go
to
the
number
in
the
IANA
registry,
and
so
if
a
new
number
is,
is
there
then
it's
just
the
you
nth
and
we're
fine
with
it,
but
but
that's
not
what
we'd
like
to
do,
but
if
we
have
to
we'll
do
it.
F
Paul
Hoffman
I
was
just
gonna,
say:
that's
exactly
what
you
should
do.
This
comes
up
every
five
or
ten
years
for
every
kind
of
thing
that
we
do
yeah,
at
least
in
the
security
area.
So
I
work
for
I
can
I.
Definitely
don't
work
for
the
Ayane
part
of
I
can
if
there
is
something
that
I
Anna
needs
to
do
for
this,
it's
probably
going
to
be
generic
and
it's
perfectly
reasonable
to
ask
the
I
Anna
staff.
How
to
do
this,
and
even
if
it's
like,
oh
they're,
gonna,
have
to
do
this
new
procedure.
F
I
Anna's
here
to
serve
the
IETF
in
many
ways
that's
doable,
but
I
think
the
actual
answer
is
simply
say:
this
needs
to
be
alive.
We're
not
going
to
keep
it
alive,
we're
gonna
point
over
there
and
maybe
give
an
example
but
stop
there.
But
if
there
is
something
that
I
am
is
supposed
to
do
generically
for
this,
it
is
reasonable
for
the
IETF
to
ask
Diana
and
that
can
be
discussed.
I.
G
I'm
gonna
suggest
that
this
discussion
be
this.
It's
this
Elliott
I'm
going
to
suggest
that
this
discussion
be
directed
to
the
yang
chairs
for
an
expert
view
of
this.
There
is
a
language
issue
here:
Michael's
right,
there's
a
language
issue
here.
It
just
can't
be
done
purely
through
an
I
n
action
unless
you
use
a
unless
you
get
rid
of
the
enumerated
type
field.
So
I
would
talk
to
somebody
like
Kent,
for
instance,
or
one
of
the
other
young
people
to
just
sort.
This
I
think.
A
H
A
I
K
Really
wow
I
really
should
send
you
an
update,
but
the
the
NTP
working
group
NTS
is
done
and
we
also
have
two
other
security
related
drafts,
one
on
rough
time
and
one
on
a
concept
called
Chronos.
So
there
is
a
fair
amount
of
security
work
related
to
time
going
on
in
the
NTP
working
group
and
I
didn't
send
a
note.
So
thank.
G
Is
a
working
group,
but
we
haven't
there's
a
side
meeting
that
sort
of
continuing
at
various
ways.
I
think,
then
you
were
there
for
it.
There
was
a
IOT
onboarding
meeting.
There
are
security
aspects
of
IOT,
onboarding
I,
think
that
are
actually
pretty
important
and
we're
gonna
actually
have
an
interim
discussion
on
the
week
of
the
15th
of
April
I
think
it
is
scheduled.
I'll
check
my
calendar,
but
if
you're
not
on
the
IOT
onboarding
list
and
you'd
like
to
participate,
feel
free
to
join
and
I
will
remind
people
again
coming
up
to
that.
J
Wes
heard
Icarus
I,
the
other
one
to
notice
the
KSK
rolling
long
term
discussion
being
held
in
conjunction
with
I
Anna.
Excuse
me,
I
can
is
going
on
at
the
moment.
There
was
a
buff
this
morning
about
it.
We're
buff,
it's
really
a
sight
meaning
more
like,
but
a
security
review
of
that
area
would
certainly
be
good.
A
A
A
Trigger
meal
all
right,
so
the
the
surprise,
the
secret
you've
been
all
waiting
for.
Oh
and
I
had
to
balance
the
workgroups
between
us
and
I
will
be
keeping
most
of
the
working
groups
as
responsible
ad
and
Roman
has
his
list
there
as
well.
So
we
look
forward
to
seeing
you
in
the
coming
meetings
and
now
we
can
move
on
to
our
talks
so
come
on.
N
Hello,
okay,
I'm,
going
to
talk
about
miss,
finding
attack,
same
device,
fearing
protocols,
and
the
background
to
this
presentation
is
that
intersect,
these
pads
in
Bangkok,
we
describe
ideas
for
a
new
protocol
and
a
request.
Carla
asked
the
question
about
the
miss
binding
and
my
first
thought
was
well.
How
is
that
relevant?
Because
this
is
a
deep
pairing
protocol?
N
So
what
is
miss
finding?
It's?
Basically
any
situation
where
you
have
a
node,
a
that
thinks
it
is
authenticating
to
another
node
E,
but
in
fact
it
is
authenticating
to
someone
else
here
be,
and
why
is
this
happening
because
the
node
E
is
being
dishonest
and
tricking?
A
daughter
indicated
to
the
wrong
end
point:
this
kind
of
attacks
have
been
known
in
the
key
exchange
protocols,
at
least
since
1992,
with
the
station-to-station
paper
by
DC
and
others,
and
these
attacks
have
largely
motivated
the
design
of
the
Sigma
protocol
family,
which
includes
Ike
one
and
two.
N
N
N
So
here
is
two
versions
of
the
attack
against
diffie-hellman
against
poorly
designed
diffie-hellman
protocol.
So
in
the
first
picture
a
is
won.
T
wants
to
talk
to
e,
but
he
is,
he
is
evil
and
he
tricks
a
to
actually
talk
to
B,
but
he
never
knows
about
that
and
in
the
second
picture,
same
kind
of
attack
where
the
victim
who
is
misled
about
the
inside
rest
well
is
the
responder
is
the
victim
who
was
misled
and
so
B
things
is
connecting
to
it.
N
N
So
how
serious
are
these
miss
pining
attacks?
Well,
it's
a
little
bit
difficult
to
understand
this,
because
it's
not
a
failure
of
confidentiality.
You
see
the
big
victim
actually
wants
to
talk
with
the
corrupt
node,
so
any
secrets
that
the
victim
will
send
over
the
secure
connection
would
go
to
the
attacker
anyway,
but
it
is
a
bit
related
to
problem
related
to
authentication.
It
can
lead
to
failures
of
data
authentication
or
or
we
can
just
call
it
entity,
authentication
failure.
N
So
this
is
not
really
something.
I
can
easily
relate
to
my
experience
of
everyday
use
of
IOT
devices,
for
example,
but
then,
as
a
person
who
has
done
some
formal
verification
of
protocols
and
modeling
I
think
it
is
well
responding,
is
a
violation
of
a
well-defined
security
property,
so
some
kind
of
correspondence
property.
So
he
in
the
previous
cases.
N
It
should
be
the
case
that
if
a
and
B
share
a
system
key
K,
then
I
should
think
that
it
shares
the
key
with
B
and
B
should
think
that
it
shares
the
key
with
a
and,
if
this
end
of
the
case,
we
have
miss
finding.
It's
also
easy
to
has
been
relatively
easy
to
solve
this
problem
by
binding
endpoint
identifiers
to
the
authentication
or
to
the
key.
However,
that
requires
that
they
must
be
a
endpoint
identifier.
N
This
we
must
have
credentials
for
authenticating
those
endpoint
identifiers,
and
on
top
of
that,
one
endpoint
must
know
what
identifier
it
expects
or
access
from
the
other
endpoint,
and
that
is
not
the
case
in
typical
device
pairing.
So,
let's
see
how
the
device,
bearing
so
I'll
first
just
quickly
run
through
the
Bluetooth
or
indications
of
the
two
familiarize
yourself
with
the
pictures.
So
here
the
user
has
two
devices
a
and
B
makes
be
discoverable
on
device,
a
searches
for
discoverable
devices,
selects
B.
N
Then
key
exchange
takes
place
in
the
background
and
the
two
devices
as
part
of
that
key
exchange
show
to
60s
it
codes
to
the
user.
This
is
the
outer
pan
communication
and
the
user.
If
they
are
equal,
accepts
touch
it
six
digit
code
and
right
now
the
devices
are
paired.
This
is
what
happens
when
things
go
well
in
bluetooth
pairing.
So
then,
let's
see
the
miss
burning
case,
so
in
Miss
binding,
as
always,
one
of
those
devices
has
been
corrupted.
N
So,
as
you
see,
this
is
not
really
an
attack
against
Bluetooth,
it's
an
it
would
work
for
any
kind
of
outer
pension,
all
authentic,
listening
device
pairing,
it's
an
attack
against
the
user
interface
level
and
not
against
the
protocol
details.
But
let's
still
look
at
the
Bluetooth
button
protocol.
So
why
doesn't
Bluetooth
detective
is
binding
and
could
it
detect
well,
the
device
is
here,
have
no
verifiable
identifiers
at
all.
There
is
the
Bluetooth
device
name
which
the
user
can
set
for,
which
can
be
edited
over-the-air.
N
Also,
there's
a
there's
general
binding
to
the
Bluetooth
or
MAC
addresses
of
the
devices,
but
one
device
doesn't
know
what
the
matter
is
of
the
other
should
be
so.
The
authentication
is
really
based
only
on
the
user's
physical
access
to
the
two
devices
and
that's
why
we
can't
bind
to
that
identity
of
physical
access.
N
So
then
we
were
wondering:
Bluetooth
has
been
analyzed
so
many
times
by
researchers
and
and
others,
and
there
are
formal
models
of
Bluetooth.
So
why
was
this
attack
not
code?
There
are
so
many
suggested
attacks
that
we
could
find
in
the
literature
of
kind
of
marginal
weaknesses
in
Bluetooth
or
things
that
could
go
wrong,
but
not
this
exact
one.
At
least
we
couldn't
find.
B
N
We
modeled
brew
to
blue
toad
in
the
probative
form
of
modeling
and
verification
tool,
and
the
trick
there
to
get
this
attack,
which
we
already
knew
about,
was
to
define
the
use,
the
physical
channel
that
the
user
uses
for
communicating
with
the
device
as
the
physical
device
identity.
And
then
we
could
express
a
correspondent
property
between
the
user's
intention
to
peer
pair
two
devices
here,
a
a
1
and
B
1
and
then
the
completed
pairing,
which
is
between
some
different
pair
of
devices.
N
Okay.
So
it's
easy
to
model
protocols
when
you
know
the
attack
that
you're
looking
for.
But
interestingly,
this
formal
modeling
yielded
another
attack
which
we
call
double
B's
finding
and
there's
a
picture
of
it.
So
in
this
case,
in
the
other
room,
there
is
no
attacker,
but
there
is
another
user
with
two
devices
of
her
own
and
each
user
wants
to
pair,
at
the
same
time,
their
own
two
devices.
N
So
what
did
we
learn
here?
Well,
I.
Think.
The
main
lesson
is
that
all
the
by
sparing
protocols
are
vulnerable
to
miss
finding
if
the
devices
have
no
very
fybel
identifier
and
if
authentication
is
based
only
on
physical
access.
Another
view,
though,
to
this
is
to
think
about
it
as
a
trusted
path
issue.
N
So
that
it's
about
device
pairing,
then,
as
I
told
in
the
beginning,
we
were
looking
at
the
bootstrapping
protocol
that
connects
a
IOT
device
to
the
cloud
and
the
example
I'm
going
to
use
here
is
EAP
noob
our
own
protocol.
But
we
don't
go
to
the
details
of
the
protocol.
So
the
only
thing
you
have
to
need
to
know
that
it's
an
EAP
method,
where
user
assisted
out
of
an
authentication
is
used
for
connecting
a
new
smart
device
to
the
authentication
server
somewhere
in
the
cloud,
and
here
is
the
architecture.
N
N
N
Well
now
that
occur
would
like
the
user
to
pass
his
out-of-band
message
to
the
server
to
register
that
Veronal
device.
How
is
that
going
to
happen?
Well,
the
Ithaca
relays,
the
out-of-band
message
to
the
compromised
user
interface,
which
keeps
it
to
the
user,
and
then
the
user
delivers
the
wrong
out-of-band
message
to
the
cloud
and,
as
a
result,
the
wrong
device
gets
registered
to
the
cloud
server
and
associated
with
that
users.
Account.
N
So
why
is
EAP
no
more
vulnerable
to
this
attack?
Again,
it's
a
question
of
user
physically,
identifying
the
peer
device
and
that
there's
no
other
authentication.
So
it's
not
the
flaw
in
the
subtle
details
of
the
protocol,
designs
and
missing
field.
It
is
an
inherent
weakness
in
pairing
protocols
that
d'lai
relying
on
the
physical
access
for
out
in
the
case
and
the
same
kind
of
weakness
would
appear
in
any
other
period.
Mister
device,
bootstrapping
protocol
registration
protocol,
for
example,
DPP.
When
Wi-Fi
gets
it,
it
will
be
vulnerable
to
the
same
attack
the
the
only
place.
N
N
So
if
you
have
a
trusted
execution
environment
in
a
device,
you
can
create
the
secure
connection
to
it,
authenticated
it
may
attach
to
the
integrity
of
the
software
on
the
same
other
software
on
the
same
device
and
all
looks
good,
but
you
have
really
no
way
of
knowing
that
your
the
secure
connection
is
to
the
heart
of
the
same
device
that
you
are
touching
with
your
hands,
and
this
problem
may
be
relevant
to
two
working
groups
that
idea,
threats
and
deep
rats.
I
believe
is
meeting
still
today.
N
Okay
I
have
two
more
slides,
just
the
summary
of
how
what
we
can
do
to
mitigate
attacks
and
and
and
then
the
final
summary
so
I,
don't
think
there
is
any
way
of
avoiding
these
attacks
completely,
but
there's
some
things
that
we
can
do
to
make
that
occurs
life
more
difficult.
So
one
thing
is
to
bind
their
system
keys
to
any
context,
data
that
we
may
have
available
so,
for
example,
channel
binding.
N
If
the
user
knows
that
this
is
an
authentic
device
by
a
specific
vendor
unmodified
and
the
user
now
has
a
way
such
as
pressing
a
reset
button
of
communicating
to
the
real
real
registration
or
pairing
process
in
that
protocol,
then
that
might
solve
the
problem.
I
think
the
main
should
main
defense
that
we
have
is
asset
tracking.
N
Okay,
so
to
summarize
I
believe
now,
all
after
this
investigation
that
all
device,
pairing
and
bootstrapping
protocols
are
vulnerable
to
miss
binding.
If
the
device
authentication
is
based
purely
on
physical
access
and
if
device
identity
either
is
not
cryptographically
authenticated
or
even
if
it
is
cryptographically
authenticated,
but
the
other
endpoint
doesn't
know
what.
N
Identifier
and
said
we
have
ways
of
mitigating
the
attacks,
but
no
complete
solution,
and
my
question
or
point
for
discussion
for
the
audience
is
whether
we
should
now
think
that
Bluetooth
and
other
barring
protocols
are
inherently
insecure
and
the
same
for
the
provisioning
and
and
smart
device
bootstrapping.
Thank
you.
O
B
O
The
issue
frequently
with
trying
to
securely
bind
a
transaction
happening
on
an
out-of-band
channel
to
some
sort
of
session
being
authenticated.
Who
are
you
trying
to
prove
say
that
you
know
you've
got
your
your
phone
and
you're
approving
a
transaction
here?
Have
you
have
you
looked
at
that
use
case
at
all
and
and
and
does
the
same
work
it
seems
relevant
somehow
I.
N
Think
it's
a
good
point.
I.
We
haven't
considered
that
if
you're
thinking
like
using
mobile
phone
to
confirm
a
bank
transaction,
yes,
that
it
is
a
little
bit
different,
because
there
you
usually
have
to
to
weigh
out
indication
for
the
invention
or
first
with
the
existing
pre-established
credentials.
Whereas
here
we
have
no
pre-established
trillion
cells,
so
there
might
be
some
a
similar
aspect
of
miss
pining.
If
we
assume
that
the
pre-established
credentials
have
been
compromised
but
I'm
not
sure
if
that
yeah
its.
If
it's.
O
N
P
Daniel
con
Gilmore
ACLU.
Thank
you
for
this
work.
I
think
we
really
need
it.
It's
really
nice
to
see
somebody
doing
this
kind
of
abstracted
thinking
which
we
need
more
of
in
terms
of
thinking
about
how
these
protocols
fit
together.
I
apologize
that
I
have
not
read
the
details
of
what
you've
written,
but
my
concern
is
of
excellent.
Thank
you.
Much
appreciated
memorize
that
number
before
isn't
done.
The
slides
are
in
the
data
track.
Thank
you.
P
B
Q
N
That's
the
whole
point
of
me:
that's
better!
That's
the
nature
of
miss
pining
attack,
so
the
type
of
attacks
that
we
were
investigating
are
ones
where
one
of
the
users
two
devices
is
compromised.
One
of
the
two
endpoints
that
the
user
wants
to
connect
to
each
other
and
authenticate
to
each
other
ie.
One
of
them
is
compromised
and
that
compromised
device
plays
the
tricks,
and
course
is
the
connection
to
go
to
another
device.
The
third
one,
okay,.
Q
R
A
positive
worldview
and
max
Potter
CableLabs,
thanks
for
the
work
I,
really
appreciate
that
as
dkj
said
after
thinking
and
thinking
about
alphab
and
channels,
is
something
that
we
should
start
doing.
One
of
consideration
and
goes
into
what
you
just
say
when
you
reply,
it
seems
to
me,
there's
a
a
problem
with
we're
trying
to
authenticate
one
channel
and
we
rely
on
the
another
channel
which
we
don't
require.
Any
authentication
at
all,
so
the
out-of-band
channel
usually
is
very
the
security
of
that
is
Petach,
nor
think
about
using
SMS
or
something
similar.
R
R
R
R
Little
bit
too
permissive,
if
you
want
to
try
to
avoid
this,
if
you're,
ok
with
this,
because
you
say
well,
I'm
activating
my
device
I'm
home,
there's,
nobody
really
around
I'm
fairly.
Ok
with
it.
That's
that's
one
argument,
but
in
other
environments
like
in
where
you
have
many
many
devices,
every
time,
work,
environments,
wide
area,
networks
etc
that
maybe
this.
B
N
N
N
Well,
if
you
do
this
tracking
of
connections
between
like
if
your
device
is
report
to
let's
say
your
central
server
and
where
you
can
see
or
on
the
device,
you
have
a
user
interface
where
you
can
see
what
everyone
is
paired
with,
then
you
would
see
that
there
is
some
redundant
appearing
with
the
device.
That's
not
you
didn't
think
you
have
no.
B
N
So
so
the
attackers
device
in
the
other
room
would
not
be
one
of
your
devices,
so
you
would
kind
of
see
that
you
have
an
extra
device
one
and
one
that
failed
to
pair
and
then
another
one
and
then
another
endpoint
that
that
seems
to
be
paired.
So
if
you
have
this
global
view
of
things
tracking
your
devices
and
their
connections,
their
names
that
then
there's
many
places
here
where
you
might
catch
that
something
is
wrong.
B
A
N
So
I
think
I
can
can
of
course
yeah
relay,
but
then
the
point
of
this
miss
pining
should
be
that
I
mean
otherwise
you
can
just
do
relay
attacks,
and
the
point
of
miss
panning
should
be
that
eventually
you,
the
attacker,
doesn't
you
know?
Maybe
this
device
compromised
device
is
thrown
away
and
into
the
shredder,
but
I
I
understand
you're,
like
I.
Think
you
make
valid
points.
B
N
B
A
S
So
what
Daniel
Franco
Akamai?
So
thank
you
for
this
talk,
because
I
have
a
new,
up-to-date
case
study
as
to
why
really
simple
lightweight
tools
like
proration
tamarins,
don't
matter,
I
get
a
lot
of
back
incredulity,
sometimes
that
these
that
these
things
actually
funk
find
anything
business
already
obvious
and
well,
if
you're
teaching
this
stuff
long
enough,
it
eventually
becomes
obvious,
but
25
years
after
natives
rotor
we're
still
ready
to
connect
with
this
a
bug.
My.
N
My
okay,
thank
you
for
the
question.
I
really
want
to
answer
this
because
my
view
of
this
very
fighters
has
long
been
that
they
don't
find
any
new
attacks.
It's
the
smart
person
using
them
who
finds
them,
but
they
do
work
as
debugging
tools
for
obvious
mistakes,
but
in
this
case
I
think
it's
the
first
time,
I
actually
found
a
new
kind
of
attack,
the
double
Miss
finding
using
one
of
those
tools
and
every
protocol
I
have
designer
try
to
model.
T
So
I'm
John
Matson
Erickson
I'm
planning
to
tell
you
what
tree
DPP
is
up
to
when
it
comes
to
Tai,
Chi
encryption,
know
and
see.
If
anybody
in
the
idea
have
said
similar
problems,
thoughts,
IDs,
wenscombe
to
high
performance,
encryption
and
foggy
will
do
many
things,
but
one
of
the
things
it
is
it
will
do
is
to
vastly
increase
the
amount
of
data
that
you
can
send
over
cellular
networks,
but
first
going
back
a
little
bit
history.
So
these
are
all
the
current
algorithm
used
or
are
used
by
three
DDP
seller.
T
Today
you
might
not
know
all
of
them,
but
probably
all
of
you
have
used
these
algorithm.
They
will
probably
continue
to
do
so
so
for
4G
and
paaji
early
releases,
a
5d
20
people,
20
people
relies
on
a
s
encounter
and
CMAC
mode
and
also
on
snow
3G,
snow
3d
bus
passes,
standardized
for
3d,
also
used
in
4d
5d
and
has
been
back
ported
to
2g
and
after
a
s,
deaths
or
so,
for
maybe
cha-cha
is
probably
one
of
the
most
deployed
used
and
analyzed
ciphers
in
word.
T
T
This
might
not
be
reached
by
early
implementation,
but
later
releases
of
IG
will
probably
significantly
surpass
this.
This
is
what
was
done
with
4G.
Another
requirement
is
network
function
virtualization
five
years
we
will
mainly
be
deployed
as
software-defined
virtual
networks
with
various
degrees
of
specialized
hardware
or
to
say
at
this
point
exactly
what
so,
basically,
all
the
current
Albert's
are
too
slow
to
do.
20
gigabits
per
second
in
software
with
good
performance.
T
Yes,
CMAC
has
similar
performance
as
AAS
CBC
mode
it
you
cannot
reach,
it
cannot
reach
20
giver.
You
get
around
nine
on
a
single
core
is
256
DCM,
on
the
other
hand,
has
excellent
performance.
You
can
reach
over
20
on
a
single
core
because
we
also
paralyze
it.
So
this
is
obviously
one
of
the
main
candidates
for
three
DP
be
going
forward,
but
three
DP
P,
as
you
seen
before,
like
to
have
backup
outwards.
We
don't
want
to
rely
on
one
algorithm.
We
want
to
have
several
Edwards
implemented
everywhere,
safe
a
weakness
in
found.
T
T
The
other
reasons
than
performance
that
3gpp
is
looking
at
in
choosing
new
algorithm
is
usage
by
government
there's
a
lot
of
government's
interesting
use
in
5g,
and
they
have
requirements
to
have
the
tuna
56-bit
Albert's
everywhere,
and
the
third
reason
is
to
make
that
with
future-proof.
If
you
design
new
Algirdas,
no
reason
to
not
go
with
tuna,
basically
kiss
as
a
related
activity.
T
T
Snow
was
designed
by
the
cryptographic
team
at
Lund.
University
alone
is
a
town
in
southern
Sweden
and
they
have
now
updated
the
previous
version
of
snow.
Maybe
a
new
version
called
snow.
We
and
these
teams
led
by
Professor
Tomas.
He
wants
all
I'm
not
going
very
much
in
detail
of
how
this
cipher
look
at
all
the
snow.
Ciphers
looks
very
much
the
same.
They
have.
They
have
a
linear
pot
with
one
or
two
linear
feedback
shift
registers.
They
have
a
nonlinear
part
called
a
finite
state
machine
and
the
design
creature.
T
The
revelation
when
trying
to
see
how
fast
they
could
get
snow
3d
to
run
on
in
software
on
modern
hardware.
They
realized
that
by
updating
the
cipher
slightly,
they
could
make
it
run
significantly
faster
to
assign
the
criteria
for
snowy
is
to
build
on
the
old
versions
and
all
the
analysis
done
for
that
and
design
it
to
be
as
fast
as
possible.
On
modern,
CPUs
and
I
mean
things
to
make.
This
happen
is
to
use
the
avx2
registers.
T
T
This
is
less
light.
So
what
have
the
team
in
Lund
University?
They
have
C.
They
have
achieved
quite
outstanding
performance
in
software
on
mainstream
laptop
single
thread.
Single
core
snoby
performs
60
gigabyte
per
second
note
that
this
is
only
encryption.
It
does
not
include
integrity.
Having
integrity
would
slow
this
down
slightly
I,
don't
have
any
exact
numbers,
so
we
also
performs
extraordinary
well
in
Hardware,
straightforward
implementation
reached
700
megabits
per
second,
and
they
expect
it
to
reach
over
Towson
well
in
a
seven
millimeter
process.
T
T
T
We
don't
have
any
measurements
for
that
yet
then
the
authors
tell
me
that
these
currently
cm
is
the
performance
bottleneck.
Here
they
are.
The
paper
published,
uses
GCM
for
integrity,
so
they
say
that
they
will
evaluate
if
there's
any
faster
options,
for
example,
polyethylene,
65
or
anything
else
published
lately.
T
T
After
probably
a
lot
of
ping
pong
with
license,
and
then
the
final
decision
lies
in
3d
BBS
a
tree
to
decide
what
is
used
conclusions
here
is
that
we
see
that
by
designing
new
ciphers
for
modern
CPUs,
you
can
reach
extremely
good
performance
and
I
would
like
to
know
if
anybody
else
have
any
have
any
thoughts
about
high
performance,
encryption
in
virtualized
environments
and
especially
what
I
think
a
SDTM
is
probably
a
default
choice.
But
what
should
you
use
as
a
backup.
A
R
R
So
since
this
is,
you
know,
network
traffic
that
they
were
protecting
and
we
expect
users
to
actually
protect
that
communication
with
TLS
etc
at
a
higher
level.
For
for
our
use
case,
it
is
my
suffice,
but
we
actually,
we
were
just
talking
with
the
with
some
people.
At
least
we
might.
We
might
look
into
that
for
general
access
networks,
so
that
might
be
something
that
we
can
collaborate
on
yeah,
but
great.
U
Kenny
Patterson
and
thank
you
very
much
for
this
nice,
informative
presentation,
I'm.
Sorry,
we
didn't
have
time
for
it
at
CFR
G
earlier
in
a
week.
I
just
wanted
to
make
a
point
that
you
compared
SC
CH
2,
CFR,
G,
there's
somewhat
different.
So
as
usage
in
particular
has
actually
has
financial
resources
to
Commission,
independent
crypt
analysis
and
I
was
what
I
should
want
leads
to
a
question.
Do
you
think
they'll
do
that
in
this
case
or
Phi
key
I
will.
T
V
Hi,
this
is
Sean
Turner,
you
lit
it
to
the
I,
guess,
IPR
licensing
rules
and.
V
One
of
the
the
main
things
that
they
pick
is
that
if
they
pick
one
and
then
this
later
comes
over
to
the
ietf-
that
they
have
reasonable
licensing
terms,
I
would
hate
for
them
to
pick
something.
That's
crazy.
That
ends
up
in
causing
lots
of
problems
over
here
for
us
being
unable
to
adopt
it
for
whatever
reason,
yeah.
D
T
D
C
R
Hey
max
hey
max
palin
CableLabs,
I
recently
started
a
discussion
on
the
mailing
list
around
some
encoding,
but
some
some
things
and
that
we
are
working
on
in
lamps,
especially
or
we
trying
to
propose
in
lamps,
is
the
use
of
multiple
public
keys
and
multiple
signatures
in
certificates
to
actually
allow
us
to
deploy,
hybrid
PK
eyes
might
use
different
algorithms.
This
four
can
be
used
for
post
quantum
resistance
today
or
could
be
just
combining
two
different
algorithm
for
compatibility
in
general.
The
approach
here
is,
but
you
can
combine
different
algorithm
as
you
as
you.
R
This
can
be
used
for
algorithm
agility
or
what
called
the
third
ability
or
agility
in
the
future.
One
of
the
things
that
came
up
in
the
discussions
are
is
the
fact
that
these
certificates-
and
this
is
a
tendency
that
we
see
from
the
FRG
for
all
the
the
algorithms
that
you
know
we're
trying
to
come
up
with
for
next
generation.
We
see
an
increase
in
key
sizes
and
signatures
this
besides.
R
The
idea
of
combining
with
traditional
crypto
is
a
problem
that
I
would
like
to
bring
up
to
this
in
the
security
area
and
starving
may
be
looking
into
what
is
the
impact
over
many
other
protocols
right?
The
most
noticeable
one
is
TLS
that
historically
might
have
problems
with
big
certificates,
and
another
point
that
I
was
trying
to
bring
out
is
that
it's
not
just
certificates
that
will
be
increased,
it's
gonna
be
CR
else
is
gonna,
be
your
sis
be
responsive
everything.
R
The
tendency
in
cryptography
is
to
have
bigger
the
need
for
bigger
authentication
data,
then
it's
smaller
and
I,
don't
know
if
we
should
bring
out
the
discussion
about
trying
to
design
systems
that
will
take
this
in
consideration.
Maybe
not
today,
but
in
the
near
future,
because
I
saw
that
a
tendency
is
well
certificates
now
are
small.
We
can
make
it
smaller
and
smaller
and
smaller,
but
this
is
a
gift
that
we
got
from
ECDSA
and
I.
Don't
think
this
is
going
to
repeat
itself
in
the
future
and
I
really
need
to
plan
now.
R
C
A
Yeah
I
mean
I,
don't
have
a
crystal
ball,
but
the
trends
say
I
agree
with
you.
The
current
trends
seem
to
point
towards
at
least
the
potential
for
larger
signatures
and
cryptographic,
objects
and
I
think
you're
right.
If
we
do
need
to
be
thinking
on
10-year
time
horizons
we
got
to
be
planning
about.
What's
gonna
be
affected,
you
know.
Are
we
gonna?
Have
our
cryptographic
handshakes
they're,
just
a
lot
harder
to
do
because
they
fill.
R
Yeah,
that's
exactly
the
point
and
I'm
just
a
little
worried
today
that
you
know
when
I
see
you
know,
protocols
that
are
being
in
developed
or
discussion
happening
is
that
it's
a
set
that
the
fact
that
certificate
should
be
small,
and
this
is
definitely
for.
According
to
my
experience,
I
don't
have
a
crystal
ball
absolutely,
but
my
experience
that
probably
is
gonna,
be
a
lot
bigger
and
we're
talking
about.
In
some
cases,
40
Kay's,
not
just
few
hundred
bytes,
more
and
and
impact,
could
be
very,
very,
very
irrelevant
to
this
community.
R
So
I
need
to
deploy
this.
This
infrastructure
and
I
would
like
to
remove
the
the
Internet
Protocol
be
able
to
deal
with
that
we
are
between
in
our
infrastructure.
We
don't
have
this
problem
because
we
can
handle
our
protocol.
So
it's
easy,
but
when
we
expose
this
technology
to
the
open
Internet
we
need.
We
need
to
be
able
to
say
yeah.
This
works
with
the
elastin,
so
you
can
protect
your
yourself
with
other
algorithms,
not
just
the
one
that
we
used
today.
R
D
Okay
and
there's
this
idea
of
doing
a
Sunday
tutorial
next
idea
for
the
one
after
that
about
writing
security
considerations,
because
we
all
know
some
people,
don't
do
it
very
well,
so
I
volunteered
for
that
and
Linda
number
wanted
to
help,
and
so-
and
we
appreciate
that.
That's
wonderful
right!
So
what
I
plan
to
do
is
make
a
really
rough
chapter
kind
of
outline
and
put
it
on
github
then
send
a
message
to
the
cyclist
and
they,
more
importantly,
the
second
tier
list
and
have
people
look
at
that
post:
pull
requests
and
stuff.
D
C
C
C
Unfortunately,
despite
not
being
an
ad
he's,
fixing
everyone
else's
protocols
right
now,
regardless,
so
when
you
go
out
and
kind
of
in
the
hallway-
and
you
see
him-
please
do
thank
him
for
all
the
hard
work
he
did
both
inside
our
security
community
and
how
he's
made
sure
that
that
is
leaked
out
and
do
everything
else
that
the
IETF
is
doing
so.
Please
track.