►
From YouTube: IETF104-TLS-20190325-1120
Description
TLS meeting session at IETF104
2019/03/25 1120
https://datatracker.ietf.org/meeting/104/proceedings/
B
C
C
C
C
Hey
we're
on
slide
two!
This
is
the
note.
Well
it's
early
in
the
week.
Basically,
the
plan
is
participating
in
the
ITF.
You
agreed
that
it's
a
bunt
to
follow
the
idea
of
process
and
policies,
we're
recording
the
session,
and
you
say
if
the
microphone
can
be
held
and
used
against
you.
If
you
have
IPR,
you
need
to
disclose
it.
If
you
talk
about
it
at
the
microphone,
the
whole
nine
yards
there's
a
bunch
of
links
on
there.
C
If
you
have
any
problems
with
anything,
you
can
go
to
the
buds
team
to
discuss
that
and
again
I
said.
Like
all
the
links.
Are
there
next
requests
hey
minute,
ticker
we
got
one.
Thank
you
very
much,
sir.
We
got
jabber
scribe.
Please,
the
blue
sheets
are
going
around.
Please
sign
them.
That'll
be
great,
please
make
sure
to
state
your
name
at
the
microphone
when
you
get
to
the
microphone
talk,
let's
keep
it
professional
at
the
mic
and
must
be
succinct.
C
We
have
a
lot
of
presentations
and
we
want
to
make
sure
we
keep
people
on
time.
So,
let's
just
kind
of
try
to
stick
to
our
meeting
time
as
much
as
possible.
Next,
the
agenda
we
have
two
sessions.
Here's
today
the
demarcation
obviously
is
administrators,
is
what
we're
doing
now,
and
then
we
have
some
chair
stuff
that
we
want
to
talk
about
and
a
working
group
draft
and
then
a
bunch
of
non
working
group
drafts
at
the
end,
and
then
we
have
this
another
session
on
Wednesday
I.
Believe
right,
which
is
the
next
click
tomorrow.
C
D
D
So,
following
the
footsteps
of
the
HP
working
group,
kind
of
set
a
good
example
for
having
a
single
location
for
all
their
working
group,
information
and
pointers
to
relevant
documentation,
whatnot,
we
create
a
new
website.
As
you
can
see,
there
are
some
bits,
the
documentation
that
could
be
filled
out.
Should
you
have
the
time
and
effort
and
the
best
way
to
do
that
is
probably
just
file
pull
requests
on
the
github
repository
for
the
website.
D
We
have
pointers
to
the
active
documents
that
the
working
group
is
working
on
currently
and
sort
of
an
experiment,
we'd
like
to
sort
of
try
to
see
if
we
can
collate
a
bibliography
of
sorts
of
the
relevant
research
and
the
academic
research
on
you
know
the
attacks
and
formal
analysis
of
TLS,
similar
to
the
free
event
or
bibliography
for
papers
in
non-unity
and
hosted
here
such
that
academic
coming
to
the
area,
could
have
a
single.
You
know
point
of
reference,
for
you
know
getting
up
to
speed
with
research.
D
That's
been
happening
outside
of
like
reading
PhD
theses
and
dissertations.
We
also
have
pointers
to
a
point
or
two
implementation.
Page
currently
is
just
what
we
had
for
the
1.3
implementation
that
Martin
spun
up.
So
we
hope
to
fill
that
out
with
more
information
about
more
TLS
tax
and
the
features
that
provide
going
forward.
So,
of
course,
if
you
feel
so
compelled
to
submit
a
PR
with
information
about
your.
E
D
Particular
stack
that
would
be
greatly
appreciated,
and
then
we
will
try
to
keep
all
this
as
up-to-date
as
possible
and
and
if
you
have
any
you
know,
feedback
or
suggestions
for
what
we
could
add
change
remove.
Of
course
we
would
welcome
to
hear
them
and
we
hope
that
going
forward,
this
can
kind
of
help.
I
said
sort
of
consolidate,
focus
one
particular
page
for
newcomers
and
existing
contributors
to
working
group.
So
that
said,
I
think
we
should
just
sorry,
oh
yeah.
That
would
be
useful,
wouldn't
it
at
TOS
wgo
org
at
us.
D
G
F
G
F
F
F
An
empty
value
is
sent
just
the
presence
of
it
is
all
you
need
need
one
bit
want
to
mix
it
in
or
you
don't,
and
so
that's
the
very
simple
syntax.
That's
provided,
there's
a
it
basically
invokes
some
rules.
That
say
you
have
to
include
those
other
otherwise
optional
elements
in
the
handshake
in
order
to
select
the
PSK,
that's
going
to
be
used.
F
F
So
last
meeting
I
was
asked
what
proof
has
been
done,
whether
this
provides
any
additional
security
or
adds
any
fragility,
and
so
I'm
offering
some
informal
reasoning
about
that
at
this
point,
the
first
is
that
the
authentication
is
still
based
on
the
signature,
so
there's
no
change
there.
Second
is
the
key
schedule,
without
this
extension
in
the
initial
handshake,
you're
actually
computing
an
extract
of
zero
zero.
So
that
is
essentially
a
constant
here.
F
H
I
Jonathan
Hoyland
CloudFlare
not
not
to
bang
the
drum
a
formal
analysis,
but
it
is
a
little
bit
more
complicated
than
just
saying.
Oh
yeah,
it
looks
fine
I,
think
I
think
getting
a
formal
analysis
wouldn't
be
particularly
harder
than
what's
already
been
done.
Just
extending
the
work
that's
been
done,
but
it
might
be
an
idea
to
actually
find
someone
to
do
it.
F
J
K
B
B
F
D
L
M
N
Experimental
Oh,
my
name
is
Eric
Zhu
I'm
from
the
University
of
Hamburg
and
I'm,
a
PhD
student
there
and
I'm
doing
research
and
the
topic
of
TLS
and
session
resumption,
especially
so
I
looked
recently
into
the
performance
of
TLS
session
resumption
across
as
an
I
values
and
I
observed
that
the
draft
of
TLS
1.3
is
recommending
against
it.
But
at
least
it
is
clearly
pointed
out
what
are
the
security
issues,
and
it
is
also
allowed
within
the
draft
to
do
so
and
as
a
problem
why
it
is
recommended
against
it.
N
If
x.509
certificate
is
valid
for
these
host
names
or
if
it
is
practical
to
do
till
as
session
resumption
across
these
host
names
and
also
another
metric
which
I
want
to
introduce,
is
and
that
when
you
retrieve
a
website,
you
find
that
you
have
multiple
TLS
connections,
which
you
establish
sequentially
and
on
average
these
are
for
sequential
telecentric
for
the
Alexa
top
1k
sites.
So
have
a
quick
look
on
the
performance
against
when
you
do
till
a
session
resumption.
N
N
However,
I
come
to
the
conclusion
that
this
is
not
a
new
problem,
as
user
visits
can
also
be
linked
across
different
host
names,
we
are
redirects
if
they
use
a
unique
identifier
or
hyperlinks
if
they
contain
a
unique
Handler
and
also
the
feature
of
connection
we
use
of
HTTP
to
provides
the
same
privacy
feature.
Another
same
privacy
concern.
E
L
Thanks
for
presenting
this,
it's
good
to
see
that
presumption
actually
works,
otherwise,
it'd
be
silly,
so
I
think
I
mean
this
is
an
idea
has
been
floating
around
for
a
while
pick.
Your
facility
have
flirted
a
while
back
so
I
think
it's
worth
considering
all
I
had
a
technical
question
about
the
design
in
your
specification,
which
is
on
that
a
little
unclear
for
me,
the
document,
whether
you
thought
the
extension
when
EE
or
insert
it,
goes
in
E
right,
the
server's
extension:
where
does
it
go
in
the
EE
PIP?
Okay?
L
L
Domains
that
share
the
same
San
in
HTTP
about
fashion
coalescence,
so
I
think
you'll
want
to
like
be
clear
on
what
the
DNS
status
is.
So
one
thing
you
might
say
is
I
could
resume
and
I
wouldn't
have
to
do
it.
A
new
DNS
request,
so
we
probably
have
to
come
down
on
that
one
where
the
other,
so
this
is
a
topic
of
the
Sabres,
came
with
HTTP
as
well.
N
Shall
explain
what
I
want,
but
it
is
sufficient
to
this
place
and
the
alternative
I
think
would
be
that
we
provide
an
entire
list
for
which
names
session
resumption
should
be
supported
and
I
think
that
there
are
security
considerations.
Well,
it's
more
difficult
to
implement
this
approach
and
like
one
bit
and
then
we
take
the
sand,
values
and
use
them
for
session
resumption.
I
think
it
has
security
benefits,
as
nobody
is
going
to
mix
up
the
the
groups
or
some
list
which
I
provided
yeah.
L
Well,
I
think
I'd
like
to
hear
from
server
operators
what
they
think
about
this.
The
last
thing
I
was
going
to
say
is
we
seem
to
be
turning
accumulate,
one
bit
flags
and
it
might
be
worth
and
like
that
says,
typically
were
too
much
about
the
size,
the
TLS
handshake,
but
sometimes
they
do
and
I'm
wondering
if
it
might
be
worth
while
I'm
defining
a
generic
extension.
L
O
So
one
of
the
reasons
that
we
don't
generally
recommend
resuming
crossnize
is
that
often
you'll
get
a
wildcard
certificate
like
star
dot,
example.com,
and
then
this
is
valid
for
all
of
the
example
of
calm
servers,
but
only
some
of
them
are
actually
co-located
on
the
same
server.
So
that's
kind
of
argues
against
the
one
bit
solution,
because
the
server
knows
what
other
domains
it
is
responsible
for.
O
N
O
I
might
be
fine
if
it's
a
different
server
than
these
pretty
properties
are
different.
It's
usually
not
it's
really
not
a
good
idea
to
just
do
certain
resumption
to
random
servers
within
an
organization
just
because
they
went
to
the
economic
and
operational
experience,
you're,
getting
just
one
certificate
for
the
entire
organization
and.
N
N
H
H
One
small
and
one
serious,
the
small
one
is
I
would
use
new
session
ticket
extension
for
this,
because
this
is
an
extension
which
changes
behavior
of
a
ticket
and
not
the
handshake
itself,
and
the
second
one
is
so
currently
the
draft
proposes
to
limit
resumption
to
ten
minutes,
which
is
a
solution
to
issue
which
you
correctly
pointed
out
exists.
However,
as
if
also
pointed
out,
this
is
an
issue
which
is
orthogonal
to
privacy
issues
or
reasoning
across
domains
as
in
for
re
identifying
user.
H
H
H
H
M
M
There
is
the
provision
at
the
HTTP
two
layer
of
what's
called
an
Origin
where,
if
you
define
what
the
origin
is,
then
perhaps
that
might
be
a
way
to
define
which,
if,
if
a
site
has
listed
a
set
of
origins,
then
that
is
likely
a
set
of
safe,
SN
eyes
to
resume.
But
without
that
additional
signal
you,
you
may
end
up
in
a
situation
where
you
connect
to
a
server
on
a
subdomain
that
that
server
just
doesn't
have
the
ability
to
answer
for
yeah.
M
B
L
M
L
D
Everyone,
so
this
is
just
an
update
on
the
external
piece
game,
Porter
draft
that
we
talked
about
last
time.
We
had
some
input
from
David
Benjamin,
so
I
added
him
as
an
author
toothless,
thank
you
or
to
the
draft.
Thank
you
very
much
for
the
input
and
contributions
just
to
reiterate
the
problem
statement
here
and
11.3
draft
or
spec.
It
says
that
this
case
must
only
be
used
well,
in
particular
hash
function,
whereas
in
the
table
point
two,
we
have
no
such
restriction
on
any
PSK.
D
D
Has
some
Associated
ID
anyway,
that
you
would
use
if
you
were
going
to
use
it
in
TLS
1.2
the
import
functionality
that
we're
specifying
is
basically
a
way
to
construct
a
different
identity
for
the
PSK
that
you
would
advertise
on
the
wire.
That's
the
composition
of
the
external
identity,
associate
with
sk
a
label,
a
generic
label
right
now,
which
is
we
specify
as
a
protocol,
specific
string,
so
TLS,
1,
2
or
TLS
1
3.
D
Whatever
version
of
the
handshake
is
currently
in
use,
so
for
quick,
it
would
be
jealous
1
3
as
well
as
well
as
the
hash
algorithm
that
you
want
to
use
this
particular
PSK.
For
so,
if
you
support,
chat,
56
and
show
384,
you
would
have
one
PSK
being
split
into
two
with
two
different
identities
advertised
on
the
wire
and
a
question
that
was
raised
in
the
bump.
Version
of
the
draft
was
whether
or
not
you
want
to
have
the
hash
algorithm,
as
currently
specified
in
the
identity.
D
But
this
is
more
of
just
an
encoding
question,
so
we
could
probably
sort
that
out
later,
just
as
an
example
of
how
the
diversification
works,
as
I
said,
to
have
an
external
PSK
with
an
Associated
hash,
you
basically
hkpf
it
based
on
the
imported
identity,
with
the
protocol
string
and
the
ash
out
rhythm
as
such,
and
you
get
in
this
case
three
particular
PS
case.
It
would
be
advertised
on
the
wire.
There
was
a
question
raised
last
time
as
to
what
is
the
exact
overhead
of
this
particular
technique.
D
So,
for
example,
we're
low-power
embedded
devices
in
which
you're
using
PS
KS
an
external
PS
case.
You
don't
want
to
add
more
bytes
to
either
any
message
of
the
handshake,
but
if
you're
just
supporting,
if
you
control
both
ends-
and
you
only
want
to
support
one
particular
hash
algorithm-
the
over-
it's
actually
quite
small-
it's
just
the
size
of
the
label
and
the
number
of
bytes
needed
to
encode.
D
Of
course,
a
Condon
is
this
particular
approach
with
this
design.
It
means
that
if
we
were
to
rev
the
version
or
increase
our
add
a
new
hash
function
or
hash
algorithm,
the
number
of
PS
case
advertised
on
the
wire
would
increase
based
on
that
particular
new
value.
So
that's
not
the
best,
particularly
because
it
could
get
out
of
control
quite
quickly,
but
assuming
that,
in
a
scenario
in
which
you
have
external
PS
case,
you
have
a
key
management
system
to
distribute
these
oughta
ban
that
you
know
what
algorithms
and
functions
and
protocol
fair
assurance.
D
The
other
side
supports,
so
you
wouldn't
run
into
this
particular
problem
of
generically,
just
advertising
everything
and
finding
one
that
sticks.
So
that's
the
the
rationale
that
we're
using
here
and
greatly
with
the
draft
changes.
Since
oh,
we
added
some
text
to
clarify
the
language
around
that
a
single
hash
function
must
only
be
ever
be
used
for
a
PS
guy.
Just
to
make
that
absolutely
clear.
D
Many
clear
that
whenever
you're
deriving
a
PSK
it
you
would
only
drive
one
for
each
supported
hash
algorithm.
So,
for
example,
if
you
had
two
cipher
suites
I
shared
the
same
hash
oven,
you
would
not
derive
two
PS
K's
on
for
whatever
reason,
so
the
casing
example,
if
you
have
a
s
GCM
with
256
in
chess,
are
probably
two
shots
of
physics.
D
You'd
only
derive
one
PS
k,
whereas
if
you
had
different
hash
algorithms
in
different
size
weights,
you
could
use
more
clearly
and
we
made
concrete
how
we
would
actually
support
this
with
TOS
1.2
and
backwards
versions
as
well.
There
was
also
another
issue
that
was
raised
with
respect
to
privacy
of
external
PSK
identifiers,
in
particular
in
the
context
of
I,
think
it
was
DNS
service
based
service
discovery.
Thank
you,
Christian
I,
assume
here
somewhere
yeah,
so
I'd
love
to
know
in
the
draft,
basically
describing
the
sketch.
That's
in
the
DNS
SD
document.
D
With
the
you
know,
using
the
time-based
nonce
rotation,
it's
not
like
something
you
can
implement
as
written,
but
just
sort
of
a
note
that
says
you
know
using
external
PS
case
with
sticky
identifiers
is
possibly
a
privacy
problem.
There
are
possible
things
you
could
do
to
get
around
this,
such
as
mechanism,
as
described
in
the
DNS
SD
draft
and
very
likely
you
might
just
sort
of
point
to
that
particular
draft.
Assuming
it
goes
forward
and
say,
perhaps
just
do
this
particular
thing,
so
there
was
some
interest
in
in
this
last
time.
D
Q
R
Yeah
John
Watson
Erickson
20
pp
adopted,
mandated
TLS
1.3
already
last
release.
I
actually
thought
about
this
problem
just
a
couple
of
weeks
ago
trying
to
figure
out
what
pretty
PPS
some
PSK
use.
Cases
moves
also
difficult,
but
what
should
be
do
exist
exactly
this
to
confirm
with
Tillis
1.3
and
PS
case.
I
would
very
much
like
guidance,
something
like
this
guidance
from
the
TLS
working
group
on
how
to
do
this.
R
One
question
one
of
the
motivations
here
is
in
the
introductions
that
this
was
not
done
in
the
TLS
were
103
draft
because
use
the
same
key
SK
with
different
hash
function,
because
it's
hard
to
analyze
it
does
this,
make
it
easier
to
analyze.
Now,
if
I
have
used
the
default,
sha-256
hash
function,
I
could
use
sha-256
to
derive
a
key
for
using
in
sha
384.
I
I
L
I
L
So
the
the
rationale
I
mean
we
can
certainly
I
tend
to
get
some
analysis
of
this,
though
I
think
we
had
some
formal
analysis
in
Karthik,
but
the
the
rationale
here
is
that
the
that
the
hash
function
in
the
can
you
go
back
to
the
this
shows
generation.
The
purple
know
the
next,
like
the
purpose
of
this
hash
function.
L
Here
right
it's
just
to
provide,
it
is
basically
to
act
as
a
PRF
with
respect
to
the
output
keys,
and
so
it's
and
so,
and
so
that
the-
and
so
that's
that's
totally
decoupled
from
the
hash
function
use
later.
So
that's
why
that's
why
it's
safe
to
use
the
that's,
why
it's
safe
to
use
the
same,
the
same
hash
for
multiple
output,
algorithms!
Well,.
I
D
B
S
So
what
I
want
to
do
here
is
just
cover
our
use
case
motivations
and
to
talk
about
some
of
the
trade-offs
in
the
design.
There's,
definitely
some
things
that
need
to
be
done
on
the
wire
format.
Encoding
we've
had
a
lot
of
discussion
on
the
list
already.
Thank
you
for
the
people
who
did
read
that
and
give
that
feedback.
We
will
take
that
into
account,
but
I
think
we'll
punt
the
rest
of
that
discussion
to
the
next
Rev.
S
S
So
the
goal
here
is
that
if
we
can
detect
that
there
is
an
that
we
can
seed,
what
are
keep
alive.
Timeouts
are
going
to
be
earlier
on,
of
course,
not
detecting
that
there's
net
doesn't
remove
the
need
for
keeper
lives.
There
could
be
a
stateful
firewall
involved,
but
essentially,
if
we
do
positively
identify
that
we
are
behind
a
net,
we
may
want
to
bias
some
of
the
heuristics.
S
The
other
use
case
that
we
thought
of
here
is
that
if
we
detect
that
we
are
not
behind
a
net,
we
are
much
more
likely
to
believe
that
our
client
IP
address
is
effectively
a
public
address
and
we
are
using
it
as
a
unique
identifier.
This
plays
into
any
privacy
and
considerations
that
we
have
for
other
protocols.
S
Did
we
have
a
yeah,
so
net
remaining
detection,
I
already
discussed,
and
the
other
item
that
we
have
is
if
we
can
detect
what
our
public
IP
address
actually
is?
If
we
are
behind
an
ad,
we
can
do
better
metrics
collections
on
knowing
what
ASN
we
are,
and
so
we
can
do
better
correlation
of
what
performance
issues
or
other
functionality,
issues
that
we're
seeing
when
we
are
trying
to
debug
things
in
the
wild
from
the
client
perspective.
S
S
Do
this
within
existing
connections
that
we're
doing
to
the
web.
The
constraints,
of
course,
are
that
we
only
want
to
send
this
type
of
information.
That's
in
an
encrypted
way.
Protocols
like
I
already
do
net
detection,
but
they
have
to
do
hashing
on
that,
because
that
would
otherwise
be
visible
to
everyone
on
that.
They're
sending
it
to
this
is
another
way
to
do
and
that
detection
effectively,
but
it
gets
you
less
information
on
the
client
side.
S
Another
goal
is
another
constraint,
essentially,
is
that
we
only
want
to
ever
be
sending
the
publicly
perceived
addresses
the
clients
should
never
send
their
own
internal
private
address
because
that's
definitely
a
privacy
leak,
and
then
the
other
constraint
is
that
we
cannot
rely
on
the
validity
of
the
information.
The
other
side
can
certainly
lie
to
you
at
any
point.
You
should
not
be
making
security
decisions
based
on
the
address.
You
are
told.
That
would
be
a
terrible
thing.
S
This
is
mainly
just
like
a
hint
to
improve
heuristics
and
metrics,
so
the
specific
protocols
that
are
being
proposed
are
a
in
TLS
to
have
a
client
address
extension
in
which
asymmetrically
the
client
requests.
What
is
my
public
address
and
the
server
sends
that
to
them
pretty
simple
in
quick.
We
are
talking
about
doing
a
symmetric
request
in
which
you
can
essentially
either
peer
can
request
what
is
my
publicly
perceived
IP
address
and
then
that
gets
sent
by
the
peer
to
it.
S
S
This
also
is
only
benefiting
the
client
it's
unclear.
If
the
server
really
wants
to
be
able
to
support
this,
they
may
be
a
little
bit
more
complex,
but
if
we
have
use
cases
that
could
certainly
be
added.
Another
interesting
point
is
that,
because
at
least
the
way
it's
currently
defined
in
the
draft,
it
only
is
happening
during
the
handshake.
It
doesn't
take
into
account
protocols
like
MP
TCP,
in
which
you
are
going
to
be
rebinding
to
different
addresses.
That
would
lead
to
saying.
S
What's
my
public
address
and
then
you
get
a
response
back
so
the
limitations
here
are
that
still
you
can't
detect
stateful
firewalls
that
don't
translate
your
addresses,
but
you
can
handle
multipath
migration
of
your
bindings
and
this
is
can
actually
be
a
really
useful
way
of
adding
ways
to
help
connection
migration
realize
when
migration
has
happened
because
of
a
net
reminding
versus
an
explicit
decision
to
switch
different
networks,
and
so
that's,
essentially
it
we'd
love
to
hear
any
feedback
or
thoughts
of.
If
this
is
useful.
E
S
S
A
different
level
so
I
think
in
the
case
of
quick,
it's
a
little
clearer
because
I
believe
to
some
degree
this
is
kind
of
a
transport
handshake
question:
that's
nice,
because
we
already
have
an
encrypted
transport
there,
because
it's
all
kind
of
baked
in
putting
this
in
like
TCP,
would
not
be
something
that
we
could
easily
extend
and
also
we
want
to
make
sure
the
information
is
encrypted.
The
other
direction
you
go
is
that
you
put
it
inside
protocols
that
run
on
top
of
TLS,
and
you
just
redefine
it
for
each
of
those
use
cases.
T
Hi
Daniel
Congo
moire
ACLU.
So
thanks
for
bringing
this
work
here
I
do
you
think
this
is
you?
This
looks
useful,
I'm
a
little
bit
curious
about
when
you
I
appreciate
that
you're
aware
of
the
problem
with
a
server
lying
and
that
you
said
you
obviously
wouldn't
make
any
sort
of
security
decisions
on
this
basis
and
yet
I.
T
So
you
see
this
address
change
only
40
less
only
during
the
handshake
right,
so
it
seems
like
there's
some
sort
of
cross
TLS
session
thing.
Potentially
that
would
be
going
on
where
you
might
live.
You
might
observe
a
rebinding
with
one
TLS
session
that
your
address
has
changed.
That
might
be
different
from
another
it
sorry.
S
S
I
think
it's
much
easier
if
you
are
lying
to
assume
that
you're
going
to
get
a
mismatch
of
your
addresses,
someone
randomly
guessing
what
your
public
IP
address,
really
is
that
you
think
it
is,
is
probably
a
lot
harder
to
do
so.
It
may
be
easier
to
detect
and
trust
that
you're
not
actually
behind
a
net.
So.
T
T
S
B
Q
J
Hello:
everyone,
my
name
I,
come
from
a
hobby
today,
I'm
going
to
introduce
our
dropped
using
I,
didn't
hear
the
Republic
key
or
TRS
yeah,
the
the
this
relaxing
experience,
our
motivation
actually
with
the
feel
T
as
123
I
support
using
your
public
key
yeah.
You
know
handshake
practicals
I've
had
a
to
advantage.
First
is
a
simple
in
the
authentication,
no
safe
great
genes
involved
in
the
verification.
J
Nature's.
The
second
is
a
life
within
the
communication
actually
stated
normally
takes
about
one
device
and
a
Republican,
maybe
just
a
few
tens
of
bytes.
So
it's
a
quite
lightweight
in
communications,
also
in
the
storage.
So,
however,
issues
with
using
Republic
keys
I
need
to
maintain
binding
lease
for
the
public
key
and
identity.
You
mentioned,
we
have
a
huge
network
with
millions,
a
few
hundred
millions
of
devices
so
the
to
maintain
such
a
huge
fighting.
Lisa,
not
easy
task.
J
So
to
solve
this
issue
of
a
proposal,
user
identity
based
cryptography
yeah
in
fact
identifies
the
signature
to
you.
Don't
deserve
from
matine's
such
a
huge
binding
lease
in
a
public
keys
and
identity.
So
I
have
to
use
these
nerves
for
this
TSI
PC,
actually
vs.
We
can
use
it
for
the
telecom
operators.
You
know
currently
telecom
all
teachers,
the
use
SIM
card
for
the
authentication,
that
is
the
device
and
the
server
they
have
maintained,
symmetric
keys
in
the
SIM
card
and
the
home
server
to
the
mutual
authentication.
J
So,
however,
this
required
the
server
to
maintain
a
huge
database.
So
one
possible
solutions.
We
use
the
apt
SITC.
Then
we
can
reduce
the
least
two
manifolds,
maybe
just
a
few
records
and
the
past
real
question
list.
Actually
in
the
5g
networks
eap-tls
are
we
been
supportive
and
yeah
currently
support
with
safe
acade?
The
second
you
see
scenario
is
actually
we
can
use
the
TSI
pc
over
the
internet
for
the
LG
services,
so,
for
example,
the
server
can
essentially
the
clients
with
item
he
pays
signatures.
J
So
I
read
who
MCS
that
the
post
use
case
we
I
will
be
use
the
IPC
for
LTE
networks,
not
for
the
browser
and
server
communication
scenarios.
So
in
this
step
at
least
rivers
identity
based
protocols,
including
senator
from
I,
also
a
Kiev,
and
actually
some
of
them
are
for
the
crimson,
Everson
and
self,
some
for
the
supporting
particles.
J
So
you
can
yeah.
If
you
are
interesting,
you
can
go
into
the
teacher
of
these
particles
so
to
use
a
identity
as
a
public
key.
We
might
need
to
extend
that.
Yes,
one
point
three
to
support
IPC
yeah.
Firstly,
it
need
to
support
I
think
he
has
a
Republic
key.
Second,
we
need
to
support
I
I,
be
a
signature
algorithm
in
place
of
a
republic
key
signature,
R&D
use
so
currently
our
jobs
support
for
IPS
algorithm
first
is
e.
Si
si
si
it
is
specified
in
RFC
65
7.
It
is
elliptic
curve
based.
J
I
PSI
worsen,
the
second
to
the
first
one
from
iso
IPS,
one
IPS
and
chinese
IPS.
They
are
pioneer
parent
based,
IPS
August.
So
we
to
support
ideas
or
tears.
We
need
to
extend
the
signature
scheme
data
structure
by
supporting
each
signature
algorithm
with
codes
buns,
so
here
released
for
possible
code
points
that
can
be
reserved
for
it
yeah.
This
is
shows
the
data
structure.
We
extend
to
support
the
IPS
yeah.
J
We
use
the
data
structure
used
by
the
public
key
to
carry
the
public
key
and
every
smile
in
Ferris,
for
example,
the
original
subject:
RPG
field
we
filled
with
the
identity
and
for
the
algorithm,
fill
the
OID
of
IPs
whitney's,
pull
there
and
nutation
structures
defined
to
carry
the
PKG
parameters.
You
know
with
ideas
away
from
the
centralized
PKG
that
generated
priorities
for
the
devices,
so
they
might
need
to
exchange
a
parameter
straight.
The
server
increases
angle,
our
ideas.
B
J
Running
towards
the
end,
so
you
might
wanna
okay,
maybe
just
this
is
a
hunting
practice.
We
just
say
yeah
put
some
EC
CSI
and
also
how
they
change
yeah,
the
Republic
key
information
on
ideas
over
the
country
particles.
So
we
also
have
some
working
at
UT
as
g17
and
they
cover
some
more
aspects
of
the
IPS
errantly,
including,
for
example,
the
security
requirement
and
IPC
algorithm
and
the
key
management,
and
also
I
was
a
latino
particles,
last
slice,
the
people
we
authorities.
J
C
So,
to
be
clear,
he's
not
worked
asking
for
working
group
adoption.
This
is
kind
of
a
hey.
What's
going
on
so
I
believe.
The
way
forward
here
is
that
the
code
point
registry
is
clear
that
its
specification
required
so
and
anything
will
do
including
an
internet
draft,
so
I
believe
the
way
forward
here
is
this
draft
is
going
to
be
forwarded
to
the
designated
expert
list
and
they
will
take
it
and
see
what
happens
and
go
from
there
that
that's
basically,
the
idea
is
there's
anyone
here,
that's
screaming
for
working
group.
C
Okay,
so
I'll
get
with
you
to
make
sure
we
understand
exactly
what's
gonna
happen
where
you're
gonna
send
the
email.
Excuse
me
to
get
the
draft
to
the
designated
experts
to
make
sure
that
we
get
the
Co
point
thing
going
and
we'll
go
from
there
and
we'll
see
you
all
tomorrow.
Thank
you
very
much.
Okay.
Thank
you.