►
From YouTube: IETF96-SAAG-20160721-1400
Description
SAAG meeting session at IETF96
2016/07/21 1400
B
E
F
E
G
E
E
C
C
C
Thank
you.
Okay.
Here's
our
normal
agenda,
an
agenda,
Bosh
time.
Anybody
want
to
bash
the
agenda
nope.
Okay,
so
we
have
the
usual
thing
with
the
reports.
A
pub
no
meeting.
No
reports
should
be
safe
there,
no
so
I'm
5s,
and
then
one
document
left
and
I
chatter
with
the
chair
and
if
they,
if
they
finish
it
great,
otherwise
we're
close
them
and
then
they
won't
finish
it
ace.
Did
you
send
reports
acme.
C
C
C
H
gifted
I
to
NSF
did
ipsec
yeah
how's
a
thank
you
kit,
moon,
yes,
lamps
hasn't
happened
yet,
but
is
rose
in
the
room.
So
lamps
is
a
new
working
group.
It's
looking
at
sort
of
some
minor
changes
in
maintenance
kind
of
stuff
for
picnics
and
that's
fine
with
a
very
tightly
scopes
charter
and
the
intent
is
to
keep
the
tarp
chatter
tightly
scopes.
Always
mile.
J
Two
meetings
this
week
is
came
here
and
we
started
working
group
last
call
on
two
documents.
One
is
the
native
apps
best
current
practice
document,
which
you
should
pay
attention
to,
because
it's
the
way
how
I
make
de
Oro
us
is
built
on
native
lines
on
smartphones
tablets
and
other
operating
systems.
We
had.
We
also
had
at
least
from
the
participants
in
room
good
feedback
on
adopting
the
work
of
dough
combining
for
hours.
J
We
had
some
discussions
on
other
security
aspects
could
make
some
resolutions
they
ever
need
to
put
that
back
on
the
mini.
Yes,
okay,
thank
you.
Thanks
for
sending
the
reports.
K
C
Friends
to
transcend
one
right,
I
know
you
didn't
meet
with
the
agenda
report.
Nothing
happened:
okay,
okay,
so
the
list
of
related
things
I,
think
any
symptom
from
zero
g
already
are
and
is
Taylor.
Somebody
here
to
talk
about
the
IV
program
turns
out
not
so
we,
the
IAB,
have
a
security
and
privacy
program
and
we've
gotten
them
to
start
sending
reports
like
this.
Yes,.
L
It's
in
the
report,
so
the
imv
has
a
privacy
and
security
program.
You
can
review
the
program
page
on
the
IV
programs
page
it's
currently
working
on
and
web
pki
document,
some
mitigations
documents
and
some
stuff
around
them.
What's
the
last
thing,
I
just
lost
it.
It's
out
of
my
head,
Oh.
M
Oh
two
brief
ones:
d
parent
is
probably
never
going
to
meet.
We
decided
or
on
the
mailing
list.
Who's
decided
that
it
probably
that
there
was
not
enough
agreement.
There
was
going
to
be
an
informal,
a
group
that's
meeting
this
week
and
that
didn't
happen
and
deprived
didn't
meet
this
time,
but
we're
actually
seeing
we've
seen
in
other
working
groups
a
fair
amount
of
implementation,
work,
implementation
status,
work
where
there's
being
very
good
interoperability,
okay
and.
C
L
So
t-burr
are
you?
Oh
there
you
are
ok,
so
I
actually
don't
have
a
slide.
All
I
want
really
wanted
to
do.
Is
introduce
Tibor
and
explain
the
context
of
this.
The
network
and
distributed
system
security
symposiums
held
in
February
each
year.
It's
a
academic
security
program,
and
this
year
we
had
a
Tron
workshop,
TLS
ready
or
not.
The
purpose
of
this
research
of
this
workshop
was
to
bring
together
research,
academic
researchers
with
a
specific
group
of
people
that.
G
L
That
are
working
on
the
protocol
development.
We
had
a
very
successful
workshop
and
part
of
the
reason
why
I
want
and
t-bars
going
to
tell
you
a
little
bit
about
his
research,
but
my
ask
for
all
of
you
all
is:
are
there
other
opportunities?
You
know
what
is
the
next
place
where
we
have
a
protocol
where
we
really
want
security
people
to
take
a
quick
look
at
it
and
I
want
you
all
to
think
about
that
and
send
suggestions?
Yes,
I.
L
Security
workshop
right,
so
so
this
is
what
what
I'm
interested
in
is
specifically
workshop
ideas.
There
is
a
call
for
workshops,
that's
out
for
ndss
and
what
might
be
the
right
context
for
that.
So
without
further
ado,
I'd
like
to
introduce
tivo
llego
from
ruin,
University
to
talk
about,
he
was
selected
as
our
are
very
fancy
name
best
contribution
to
the
IETF
at
that
workshop,
Award.
L
O
Yeah,
so,
first
of
all,
thanks
for
the
introduction,
thanks
also
for
rewarding
us,
so
this
fall
very
encouraging
for
my
co-authors,
EULA's
omo,
offski,
York
shrank
from
University
and
myself
and
yes,
I
would
like
to
talk
about
the
security
of
TLS
1.3
against
weaknesses
in
a
pkc
as
one
version
1.5
encryption
scheme.
This
is
a
research
result
that
we
have
presented
last
year
to
AC
MCCS
conference,
which
is
one
of
the
four
large
security
conferences
in
the
academic
world.
Okay,
next
step
is
okay.
O
What
we
should
keep
in
mind
throughout
this
talk,
two
facts
that
I
want
to
kind
of
point
out
or
remind
you
of
the
first
one
is
that
the
current
version
of
TLS
is
version
1.2.
So,
as
you
all
might
know,
version
1.2
is
currently
under
development,
but
this
does
not
mean
that
everybody
is
using
this
most
recent
version.
The
most
widely
used
version
is
still
is
1.0,
which
is
from
1999.
So
it's
about
as
old
as
windows,
98
second
edition
and
I
guess.
O
Yeah
next
like
this,
so
I
do
not
want
to
go
too
much
into
the
details
of
ours
apkc
as
one
version
1.5
encryption.
One
reason
is
that
I
do
not
want
to
repeat
his
name
over
and
over
again
because
relatively
complex
just
briefly
hours,
a
pkc
as
one
encryption
is
the
most
right
use
mechanism
to
transport,
a
key
from
a
client
or
server
when
a
TLS
connection
is
initially
set
up
and
it
was
used
in
all
TLS
versions
up
to
1.2
in
TLS
it
is
red
deprecated.
O
So
it's
not
used
anymore
and
I
guess
many
cryptographers
will
agree
that
this
is
finally
the
right
decision,
and
many
people
have
been
waiting
for
this
for
a
long
time
and
one
reason
why
it's
a
good
decision
to
deprecate
here,
because
he
is
one
in
TLS
1.3-
is
that
it
doesn't
provide
forward
secrecy.
But
the
second
important
reason
is
that
this
encryption
scheme
is
vulnerable
to
attacks
like
most
importantly,
blyton
bahasa
text
and
it's
extremely
difficult
to
implement
security
against
all
these
attacks.
O
The
natural
question
that
we
looked
at
in
this
work
is
now:
is
it
sufficient
to
remove?
Because
he
has
one
encryption
from
TLS
1.3
in
order
to
protect
against
its
weaknesses.
There
is
an
seemingly
obvious
answer
and
the
answer
is
yes,
of
course,
it
must
be
secure
because
it
doesn't
use
this
encryption
scheme,
but
it
turns
out
the
disbelievers
fault
somewhat
surprising.
O
The
most
popular
and
probably
most
currently
most
important
example
is
the
famous
drone
attack
that
you
might
have
heard
about,
which
was
kind
of
announced
earlier
this
year,
end,
which
is
going
to
be
presented
by
any
more
Avilan
and
his
co-authors
at
the
using
security
symposium
in
middle
of
august.
I
think
so.
O
This
constant
stream
of
publications,
which,
like
kind
of
allowed
to
apply
variants
of
this
original
version
bhai
take
over
and
over
again
gives
no
reason
to
assume
that
this
is
the
stream
of
papers.
This
is
going
to
end
very
soon,
or
so
so
it
makes
sense
to
analyze
the
security
of
cryptographic
protocols,
under
the
assumption
that
such
a
text
will
remain
a
realistic
threat
for
protocols
and
encryption
schemes
in
the
future.
Next,
please,
so,
how
will
it
heal
is
1.3,
we
typically
use
in
practice.
So
here's
an
example.
O
First
of
all,
we
have
one
web
server
and
the
web
server
implements
two
different,
or
at
least
two
different
versions
of
TLS.
One
is
e,
up-to-date
version
1.3
the
most
current
version
and
second
is
any
old
version
which
is
used
for
backwards
compatibility
reasons
such
as
TLS
1.0,
for
example,
and
on
this
slide
here
the
server
uses
the
same
hours
a
certificate
and
in
particular
the
same
hours,
a
public
key
for
both
cycle
suits.
This
will
be
very
important
for
a
check,
and
this
is
a
standard
deployment.
O
Setting
and
I
will
comment
on
this
later
in
more
detail,
and
then
we
have
two
different
types
of
users.
One
type
of
users
are
like
Lisa
Simpson,
so
she's
very
smart,
and
she
uses
only
the
most
recent
state
of
the
art,
crypto
algorithms,
because
she's
a
rare
of
place
in
Bahasa
taken
any
all
these
bad
things
that
can
happen
there
and
there
are
other
users
like
rife
and
wife
is
not
as
smart
as
Lisa.
O
So
he
uses
this
old,
outdated,
TLS
version
1.0
and
by
our
assumption
that
this
blight
in
Baja,
like
attacks,
may
appear
over
and
over
again,
we
may
assume
that
at
least
rafts
connections
maybe
become
insecure
at
some
point
in
the
future.
But
at
least
Lisa,
who
uses
only
an
exclusively
the
most
state-of-the-art
crypto,
may
expect
that
he
American
connections
are
secure.
It
turns
out
to
disbelieve
this
fault,
so
next
piece
and
here's
how
the
attack
works.
O
So
the
attack
is
a
man-in-the-middle
attack,
which
means
that
the
the
attacker
controls
basically
the
network,
so
it
is
able
to
inject
arbitrary
messages
and
drop
messages.
So
what
what
the
attacker
does
is
the
following:
when
Lisa
initiates
her
TLS
one
consummate
connections,
so
she
sends
a
client,
hello
and
exchange
keisha
message
message.
Then
the
attacker
responds
as
if
the
server
would
have
responded.
O
O
It
should
not
be
possible
to
compute
this
message,
but
by
performing
bison
bahas
attack
against
the
old
TLS
version,
pls
band
10,
it
is
able
to
forge
the
required
signature
again.
I
do
not
want
to
go
too
much
into
detail
yeah.
So
what
the
etiquette
does
in
principle?
Is
it
leverages
the
weakness
of
the
old
version
in
order
to
compute
the
certificate,
verify
message
for
the
new
protocol
version?
Ok,
and
this
is
possible.
Finally,
there
are
two
more
messages:
server,
finished
and
client
finish
finished
and
designed
independent
of
the
service,
long
term
secret,
so
yeah.
O
Finally,
the
attacker
has
successfully
mounted
a
man-in-the-middle
attack
against
the
TLS
1.3
connection
attempt
of
Lisa.
So
this
shows
that,
even
though
Lisa
does
not
even
use
pkc
as
11.5
encryption,
she
is
still
vulnerable
to
attacks
against
this
encryption
scheme,
which
is
somewhat
surprising
and
which
should
be
considered
I
guess
in
the
design
of
protocols.
Next
slide,
please.
O
So
how
relevant
is
this
attack
when
most
examples
of
blyton
velocitek
tend
to
be
relatively
say,
impractical,
because
such
attacks
usually
take
around
arm
in
the
in
the
order
of
several
hours
to
several
days,
or
maybe
even
weeks-
and
this
is
maybe
a
bit
too
slow
to
to
lead
to
practical
attacks
against
browsers
against
user
sitting
in
front
of
a
browse
and
waiting
for
a
connection
to
be
established.
But
every
now
and
then
example,
2
p.m.
where
such
a
blatant
baha
like
attacks
are
very
practically
and
again,
the
most
most
most
recent
and
most
important.
O
Currently
most
important
example
is
to
brown
it
dramatic
by
I
vomit
I,
who
showed
that
it's
possible
to,
fortunately
required
signature
into
a
verify
message
in
a
single
minute
on
a
single
CPU,
so
without
special
purpose:
high
performance
on
fire,
also
by
leveraging
server
weaknesses
that
occurred
in
openssl
in
all
open
openssl
versions
from
1998
up
too
early
2015.
So
this
is
really
aim.
O
I
guess
this
discounts
really
is
a
practical
and
valid
attack
and,
according
to
the
paper
by
noon,
one
OVR
Madaya
about
twenty
six
percent
of
the
https
servers
on
the
internet,
we're
vulnerable
to
this
attack
yeah
next
piece.
So
how
can
we
prevent
this
attack?
And
this
is
the
the
the
aspect
of
this
attack
that
I
personally
found
most
interesting,
because
the
attack
itself
is
relatively
simple,
but
it
turns
out
that
it's
extremely
difficult
to
prevent,
at
least
with
the
tools
if
we
currently
have
on
the
internet.
O
So
there's
one
natural
solution,
which
is
called
key
separation
and
key
separation,
means
that
we
use
separate
keys
for
separate
protocol,
its
separate
protocol
version,
separate
algorithms
and
so
on
and
so
on.
And
if
you
want
to
employ
this
technique,
then
we
can
try
to
do
this
by
by
having
tues
US
server
certificates
at
a
webshop.
One
is
the
green
certificate,
which
is
the
sign
to
TLS
version
1.3
and
the
second
one
is
the
red
certificate
which
is
assigned
to
teal
as
1.0,
and
now
we
may
hope
that
this
protects
Lisa
against
this
backwards.
O
Compatibility
attack
that
I've
just
described
since
these
are
accepts
only
the
green
certificate,
which
belongs
to
the
new
TLS
version
1.3,
and
this
makes
the
vulnerability
of
the
old
TLS
version,
which
uses
a
different
set
of
certificate
and
a
different
key
useless.
Ok,
this
is
the
intuition
how
we
might
hope
to
to
protect
against
such
attacks.
Unfortunately,
it's
this
doesn't
work
so
next
slide.
O
So
one
issue
that
we
have
is
that
certificates
do
not
contain
any
information
about
protocol
version,
so
lisa
has
no
way
of
telling
whether
the
certificate
that
she
has
received
belongs
to
the
TLS
1.3
implementation
of
the
server
or
to
the
TLS
1.0
implementation
of
the
server
next
slide
please.
So
this
is
only
one
of
several
moments
ever
further
difficulties.
Let
me
start
with
the
second
one.
O
So
actually,
there
is
a
possibility
to
kind
of
to
achieve
some
weak
form
of
gear
separation
in
X
549,
and
this
is
because
x509
and
supports
to
distinguish
between
sign,
only
certificates
and
encrypt
only
certificates,
and
this
would
at
least
have
prevented
the
attack
that
I've
described
in
this
talk
here.
So
this
cross
for
chocolate,
egg
between
Tillis,
1
and
0
and
TLS
1.3.
O
However,
this
makes
only
sense
if
under
one
hand,
browse
and
supporters
and
at
the
one
workshop
I
talked
to
at
least
one,
but
also
developer,
who
told
me
where
okay,
we
know
oui
in
order
to
assess
this
possibility,
but
we
do
not
check
it
because
it
will
kind
of
break
user
experience
and
usability.
So
we
really
know
this
content.
This
is
one
problem
and
the
second
problem
is:
we
do
not
only
need
to
kind
of
employee
key
separation
at
a
client.
G
O
But
also
at
the
server
side-
and
we
looked
at
some
major
server
implementation,
so
in
particular
we
looked
at
Apache
with
mod
ssl
and
engines
and
it
turned
out
that
in
party
mode
ssl
we
were
not
able
not
even
able
to
somehow
configure
the
server
and
a
way
such
that
it
uses
different
certificates
for
different
protocol
versions
and
engines.
This
doesn't
mean
that
it's
impossible,
it's
just
that
we
try
it
heart
and
we
didn't
find
out
how
it
could
work
and
I
guess
many.
Many
other
server
operators
could
have
the
same
problem
and
four
engines.
O
It's
the
case
that
it's
possible
to
configure
only
one
single
certificate,
so
yeah.
So
there
are
many
different
problems
on
client
site
on
server
side
and
on
the
protocol
level,
which
makes
it
very
difficult
to
employ
key
separation
practice.
Next
is
ok,
so
to
summarize,
I
first
would
like
to
say
that,
finally,
removing
our
say,
pcs,
one
version
1.5
from
TLS
is
a
very
good
decision
and
yeah.
O
O
The
reason
is
that,
even
though
we
have
no
understood
throne
and
may
I
may
be
able
to
fix
drown,
at
least
in
a
large
fraction
of
web
servers
on
the
internet,
they're
really
most
likely
be
a
drone
to
20
attack.
What
something
else
which
kind
of
brings
us
all
these
problems
with
plasma
has
to
take
back
once
again.
Yes,
so
that's
the
end
of
my
talk,
thanks
for
your
attention
and
I'm
happy
to
take
your
questions,
which
there
are.
G
P
Lot
of
another
question,
but
a
quick
comment
not
only
browsers
but
HSM
vendors
should
really
also
look
into
this,
because
if
you
have
an
HSN
for
things
like
DNS
like
we
are
you
only
signing
data,
you
really
want
to
mark
the
key
to
say
never
encrypt
anything
to
avoid
the
whole
class
of
attacks,
and
they
don't
seem
to
do
that.
So
if
there's
people
in
room,
you
can
talk
to
these
vendors,
please
do
yeah
yeah.
Q
Rob
well
sign
just
another
quick
comment:
adding
an
extension
to
x509
saying
you
know
only
this
is
the
util
has
1.3
flyers,
unlike
that,
adding
extensions
is
not
difficult
just
matter
specifying
them.
The
hard
part
is
getting
about.
You
use
them,
of
course,
but
yeah
writing
the
spec
for
would
take
an
hour.
R
I
think
yeah
you
have
near
the
other
hard
part
is
getting.
The
ca
is
to
issue
two
certificates
at
the
same
time,
we're
now
the
usual
thing
is
to
get
just
one
certificate
learn,
and
you
have
to
ask
specially
to
get
to
at
the
same
time,
for
the
same
domain.
O
So
maybe
just
just
run
comment
on
the
comments.
I
agreed
it's
completely
difficult,
I
guess
we
should
decide
if
you
want
to
fix
this
problem
or
not
and
I
mean
if
you
want
to
fix
it
and
then
we
have
to
do
something
about
it
and
I
mean
if
it's
difficult,
then
then
we
have
to
check.
Take
a
difficult
problem.
Somehow
so.
S
T
I,
don't
work
two
options
you
haven't
discussed
where
we
could
simply
deprecated
the
rse
key
exchange
all
together.
This
kind
of
has
been
made
more
difficult
because
Google
decided
to
deprecate
diffie-hellman,
which
leaves
us
with
less
compatibility
options,
but
it
certainly
is
on
the
long-term,
a
reasonable
thing
to
do
and
what
would
also
be
possible
with
the
key
separation
is,
if
you
would
say
you
configure
a
server
that
does
que
les
1.3
only
with
let's
say
at
255,
19
and
RSA
only
with
other
protocols,
I'm,
not
sure.
If
going
into
that
direction.
T
O
T
I
O
Are
there
are
examples?
We
are,
for
example,
using
DSA
keys
for
encryption,
stuff
and
settings
where
their
chosen,
ciphertext,
attacks
or
stuff
like
this
so
and
I.
Think
the
root
of
the
problem
is
that
that
we
should
use
different
keys
for
different
algorithms,
let's
see
setting
which,
which
is
considered
in
theory
and
I.
Guess
it's
the
only
manageable
setting,
because
if
you
want
to
kind
of
analyze
the
possible
interdependent
interdependencies
between
different
algorithms.
F
U
You
go
okay.
There
we
go.
My
name
is
Tom
Gallagher
I'm
from
NSA's
information
assurance
Directorate.
My
goal
today
is
to
generate
some
discussion
about
port
scanning
of
private
networks
from
inside
the
browser
and
I'm
going
to
kind
of
frame.
This
talk
around
the
WebSocket
protocol.
Beware
that
this
does
affect
other
protocols,
but
I
chose
to
framed
around
web
sockets
and
you'll
see
why,
as
we
continue
next
slide,
so
just
a
quick
overview,
I'll
give
background
about
in
browser
port
scanning
for
those
who
aren't
familiar
with
it.
U
I'll
talk
about
the
existing
mitigations
for
it
and
the
weaknesses
of
those
mitigations
and
then
finally,
I'll
propose
a
stronger
solution
that
was
mitad
via
internet
draft
shortly
before
the
cutoff
deadline.
So
this
is
a
base.
Assumption
I
think
we
can
all
agree
here
that
if
there's
an
attacker
that's
on
the
internet,
they
should
not
have
any
visibility
at
all
into
a
private
network.
That's
behind
a
properly
configured
firewall.
U
If
we
don't
all
hold
that
basic
assumption,
then
this
discussion
will
go
crazy
places
so,
as
we
make
sure
we're
on
the
same
page
there,
so
just
as
a
reasonable
kind
of
extension
to
that
assumption.
If
there's
a
single
device
on
a
private
network,
that's
browsing
to
an
attacker
controlled
web
server,
then
the
attacker
still
shouldn't
have
any
visibility
into
this
private
network.
Just
because
there's
a
single
device
browsing
to
that
server
next
slide
we're
a
little
cut
off
here.
U
The
way
this
works
kind
of
as
a
high
level
is
that
javascript
is
allowed
to
make
requests
to
arbitrary
IP
address
in
port
combinations,
and
then
it
can
time
the
response
of
those
requests.
Now
these
are
all
considered
cross-origin
requests,
so
they
are
protected
by
the
same
origin
policy,
but
the
timing
of
the
responses
of
those
requests
aren't
protected
at
all
by
that
policy.
U
So
an
attacker
can
then,
and
for
hey,
I,
got
a
quick
response
from
this
request,
so
there
must
have
been
something
actually
responding
at
that
port
or
it
took
a
very
long
time
to
get
a
response,
so
there
must
have
actually
been
a
timeout
that
occurred
there
next
slide,
please
so
looking
at
this
it
a
little
more
detailed
level.
This
is
some
JavaScript
code
that
will
actually
do
some
port
scanning
it
just
iterates
over
that
small
array
of
port
numbers
at
a
very
one,
specific
IP
address.
U
If
you
were
to
run
this,
like
I,
did
I
branded
on
a
small
test
Network
and
the
results
are
down
there
at
the
left.
It's
very
clear
that
ports
80
for
45
and
1234
we're
all
responding
because
there's
a
very
short
period
of
time
that
the
response
occurred.
Even
though
I
can't
tell
what
the
response
was
because
of
the
same
origin
policy
I
know,
there's
a
service
responding
at
those
port
numbers.
For
that
IP
address
within
the
private
network,
so
like
that
this
is
a
known
technique.
U
Browsers
do
try
to
mitigate
this
in
some
to
some
extent
and
there's
two
strategies
that
are
used
to
mitigate
it
blocking
and
throttling
on
one
hand
blocking
is
this
way
of
identifying
what
are
sensitive
ports
and
then
saying
that
there
can
be
no
outgoing
traffic
to
those
ports
at
all
and
throttling.
On
the
other
hand,
it
just
kind
of
reduces
the
speed
by
limiting
the
open
connection
number
of
open
connections
that
are
possible,
which
makes
doing
any
kind
of
scanning
of
a
wide
range
of
ports
kind
of
in
feasibly,
slow,
yes,
who's,
question.
V
Would
you
then
be
able
to
circumvent
the
same
origin
policy
know
what
I
mean
I'm
attacking
from
that
pop-up
of
example,
calm
and
I
prepare
in
my
soul
seriously
subdomains
that
all
include
all
RFC
1918
addresses,
I
synthesize
them
and
then
I
try
WebSocket
on
those
I
hostnames,
rather
than
the
IP
addresses.
So.
U
V
Is
a
thicker
I
prepare
its
own
file
that
on
my
server,
that
includes
all
the
RSC
1918
addresses
for
host
names,
yeah,
ok
and
then
I
use
on
the
client
on
the
attack
entity.
I
use
those
prepared
host
names
to
scan
through
in
the
same
stone
from
which
the
original
that
came
from
yeah.
Would
that
allow
me
to
circumvent
the
same
origin
policy
and
even
go
farther
than
what
you're
describing
that's.
X
C
U
Ok,
so
moving
on
then
mentioned
we
have
blocking
and
throttling
in
browsers
as
far
as
mitigation
for
port
scanning.
There
are
a
lot
of
limitations
to
those
mitigations,
though
on
one
hand,
you
have
blocking
essentially
a
black
listing
type
of
strategy.
You
don't
have
a
whole
lot
of
consistency
amongst
the
major
browser
vendors.
Looking
at
the
major
browser
vendors
there's
about
60
different
port
numbers
that
are
considered
sensitive,
that
are
blocked
from
this
type
of
strategy,
but
only
six
of
those
16
are
actually
consistently
blocked
along
all
major
browser
vendors.
U
This
is
not
a
whole
lot
of
consistency
there.
It's
also
hard
to
be
confident
about
it,
about
adding
additional
port
numbers
to
be
blocked,
because
it's
hard
to
predict
what's
going
to
need
to
be
connected
to
a
browser
at
some
point
in
the
future,
so
can't
really
be
confident
about
that
throttling.
On
the
other
hand,
it
does
a
pretty
good
job
of
making
port
scanning
inefficient.
U
If
you
were
to
throttle
it,
so
you
could
just
do
one
IP
address
port
number
per
second,
it
would
still
take
you
about
two
hundred
and
eight
days
to
map
out
the
entire
private
IP
space,
which
most
attackers
probably
aren't
willing
to
do.
But
realistically
attacker
doesn't
need
to
map
out
the
entire
IP
private
IP
space.
U
They
could
space
this
out
over
multiple
sessions,
multiple
users
and
take
months
to
do
it,
because
network
architecture
doesn't
change
very
frequently
so
for
them
to
have
mapped
out
your
network
and
to
know
what
kind
of
services
you're
running
and
where
they're
running
could
be
very
valuable
for
them.
And
then
the
last
issue
that
I
have
with
throttling
is
this
WebSocket
technique,
which
I
alluded
to
earlier
and
I'm
going
to
talk
about
more
on
the
next
slide.
U
So
with
the
advent
of
html5,
there's
two
new
capabilities
that
were
human
being
and
they
both
effects
this
in
browser
port
scanning.
On
one
hand,
you
have
web
workers,
which
are
these
child
processes
that
can
be
spawned
from
JavaScript
and
on
the
other
hand,
you
have
web
sockets,
which
is
just
this
communication
protocol
that
can
be
used
from
within
javascript.
U
So
the
issue
here
is
that
most
browsers
will
actually
place
the
throttling
limit
on
each
browser
process.
But
now
javaScript
can
create
its
own
processes.
So
if
a
browser
thinks
it's
limiting
you
to
say,
10
open
connections
at
a
time,
but
you
can
create
256
web
workers.
You
actually
have
an
effective
scanning.
A
space
of
two
hundred
or
sorry
2570
different,
open
connections.
You
can
have
at
a
time
so
ports
that
you
can
be
scanning
simultaneously
next
slide.
U
Please
so
because
of
these
kind
of
limitations
to
the
current
mitigations
feel
like
there
needs
to
be
a
stronger,
stronger
mitigation
in
place
here,
and
this
is
this
kind
of
solution
that
I
came
up
with
it's
pretty
straightforward
right
now.
The
only
way
that
port
scanning
works
is
by
looking
at
the
difference
in
timing
between
the
responses
of
of
two
or
two
different
requests.
U
So
if
instead,
we
made
this
a
fixed
latency
for
web
sockets,
when
that
opening
handshake
fails
just
at
a
fixed
latency
is
when
you
report
the
error
back
to
the
JavaScript
environment,
then
there'd
be
no
way
to
distinguish
this.
Opening
handshake
failed
because
I
wasn't
talking
to
a
WebSocket
server
or
this
opening
handshake
failed
because
I
wasn't
talking
anything.
There
was
nothing
there
to
respond
to
me.
So
if
we
had
that
fixed
latency,
then
there'd
be
no
way
to
tell
anymore
here
to
the
next
slide.
U
So
obviously
there's
a
disadvantage
to
this.
If
we're
talking
about
fixing
the
latency
we're
talking
about
increasing
the
latency
overall
you'd
have
to
take
the
the
error
condition
where
you're
talking
to
a
non
WebSocket
server
and
you'd
be
holding
that
error
until
the
timeout
latency
occurred.
But
I
really
don't
think.
U
You
can't
talk
to
you
WebSocket
server,
so
I
don't
think
there
could
be
some
fringe
cases
where
that
does
impact
regular
usage,
but
I,
don't
foresee
those
I
think
it's
a
worthy
sacrifice
to
increase
the
security
here
annexed
silence
the
benefit
of
doing
the
strategy.
If
we
revisit
the
code
from
earlier
on
the
left
side,
you
see
that
was
the
code
pre
the
results,
pre
mitigation.
You
can
clearly
tell
again
port
80
for
45
and
1234.
They
all
responded
very
quickly
after
the
mitigation.
U
The
response
times
are
too
similar
because
they're
all
held
to
some
fixed
latency.
Now
it
could
be
off
a
little
bit
based
on
when
the
browser
actually
gets
around
to
reporting
the
air
back
to
JavaScript,
but
in
general,
there's
no
distinction
between
what
was
responding.
What
wasn't
responding
so
what's
next!
That
?
really
is
a
question
mark
in
my
mind,
because
I
don't
know
I'm
new
to
the
IETF.
This
is
actually
my
first
meeting,
so
I
did
submit
an
internet
draft
where
it
goes
from
there
I'm,
not
sure.
U
In
the
end,
it
would
be
great
if
browser
vendors
could
consider
adopting
this
strategy
and
incorporating
it
to
kind
of
protect
the
the
end-user
more
from
this
type
of
behavior
and
in
general,
if
the
individuals
in
this
room
and
other
members
of
the
screw
Thierry
advisory
group
would
kind
of
more
strongly
consider
this
issue
of
in-browser
port
scanning
when
you're
doing
reviews
of
secure
of
different
protocols
that
are
going
to
be
used
in
browsers.
Just
if
there
are
security
considerations
that
are
added,
or
maybe
some
guidance
to
implementers.
U
Z
Fleming
injury
isn't
just
one
comment
on
one
of
your
assumptions.
You
said
that
you
didn't
think
that
it
was
going
to
be
an
issue
to
increase
the
latency
on
an
error.
There
is
a
use
case
scenario
that
we
have
today,
which
we
refer
to
as
connectivity
checking
where
there's
a
number
of
candidate
addresses
that
we're
trying
to
figure
out
which
one
actually
works.
That
could
be
a
scenario
where
it
might
actually
have
an
impact
because
you're
just
trying
to
successfully
go
through
the
list,
two
figure
one
figure,
one
out
that
actually
does
work
for
you.
U
Are
you
trying
to
connect
the
things
that
are
that
our
web
socket
servers
are
ready
in
that
case?
Does
not
the
primary
use
case
today,
but
it's
already
cooked
food?
Okay
is
if
it
if
it
is
something
where
what
what
increasing
is
the
latency
for
the
error
case,
where
you're
connecting
to
something
that
isn't
actually
a
WebSocket
server,
if
you're
looking
at
something
where
you're
trying
to
connect
to
something
that
was
supposed
to
work
and
just
times
out
that
latency
is
actually
going
to
stay
about
the
same.
AA
G
AA
Mcmanus
I
work
on
a
Firefox
thanks
for
doing
this,
I
have
another
room
area
to
get
right
up
close
to
the
mic,
and
that
really
distracts
me.
So
thank
you.
This
is.
This
is
really
useful,
so
we
I
can't
speak
of
the
other
browsers.
We
actually
do
rate
limit
the
website
and
stuff
globally,
so
you
won't
get
the
worker
bonus
on
our
platform,
although
I'm
with
you
I,
don't
think
that's
really
going
to
be
the
limiting
factor
for
most
attackers
with
respect
to
like
essentially
slowing
down
and
creating
fixed
delays
on
error
conditions.
AA
That's
a
little
tricky
because
there
are
positive
use
cases
for
those
things.
This
is
how
failover
is
dong,
hun
groups,
all
kinds
of
other
things,
and
you
go
damage
applications
by
doing
that.
So
there
is
some
pushback.
When
those
kinds
of
implementations
happen,
we
do
not
rate
limit
errors
or
connection
rates
or
anything
like
that.
It
all
on
xhr,
which
is
really
probably
the
much
larger
vulnerability
here
and
I,
don't
know
of
anyone
who
does
and
I'll
leave
it
there,
rather
than
pointing
out
another
vulnerability.
AA
S
Victor
duchovny
finally,
remember
stating
my
name
so
might
not
be
better
to
teach
the
browser,
the
boundaries
of
the
internal
and
external
network
somehow
and
not
allow
external
origins
to
refer
to
an
internal
resource
period
and
do
that
instead,
it's
so
degree
of
capella
and
after
Richards.
U
So
I
think
that's
that's
a
really
good
point.
I,
don't
think
you
can
totally
say
an
external
couldn't
connect
to
an
internal,
so
I
think
there's
use
cases
where
that
would
be
beneficial
I'm.
Not
really
a
big
fan
of
like
warning
prompts,
but
that
could
be
some
sort
of
application
where
hey
your
browser
is
about
to
connect
to
a
local
IP
address.
You
know:
do
you
want
that
to
happen?
I'm
not
sure
how
difficult
that
be
or
what
impact
would
have
on
the
user.
So.
I
There
has
been
some
discussion
about
doing
something
like
cores
for
stuff
that
goes
going
from.
You
know,
say
an
externally
loaded
page
trying
to
talk
to
some
internal
services.
There's
a
couple
of
challenges
with
that.
One
is
that
you
have
got
a
bunch
of
existing
legacy
stuff
that
might
break
whenever
we
we
tried
in
Firefox
a
year
or
so
ago,
just
like
disallowing
that
sort
of
thing
and
got
like
huge
complaints
and
was
unable
to
we
weren't
able
to
ship
it.
So
there's
issues
of
that
sort.
I
It
also
turns
out
to
be
non-trivial
to
distinguish
when
you're
talking
to
an
internal
thing,
I'm
sure
you're
familiar
with
these
DoD
networks
that
use
public
league
routable
IP
addresses
for
internal
networks.
Does
that
sort
of
issue?
There's
large
enterprise
networks,
that
kind
of
look
like
the
gnats
that
create
they
create
the
appearance
of
things
being
private,
address
space
and
they're,
actually
talking
as
a
public
internet,
so
submissions
of
that
character,
but
the
w3c
web
app
site
group
is
having
some
ongoing
discussion
about
this.
I
There
is
interest
in
finding
some
sort
of
solution
that
may
ultimately
be
the
more
productive
path
to
having
some
like
explicit
internal
external
separation.
So
I'll
try
with
you
afterward.
We
can
I
think
that
would
probably
be
a
good
group
to
talk
about
this
sort
of
stuff
us
all
get
choked
up
with
them
later.
Okay,
great
thanks
great.
N
AB
I
say
about
it:
hello,
everybody,
I'm
averse
little
mother
friend,
I,
was
assigned
by
their
study
group
1704
itu
standardization
sector
to
make
a
presentation
here
for
their
information
of
the
people
who
are
in
progress
in
the
study
group
17
and
the
maybe
could
consider
some
collaboration
of
cooperation
or
use
of
information
which
will
be
presented
or
prepared
in
this
study
group
next
slide.
Please
I.
AB
Will
have
her
I
have
a
deck
of
slides,
which
a
little
bro's
very
quickly
I,
just
pointing
at
the
some
things
which
I
would
like
to
stress
upon
next
slide.
Please,
the
structure
of
study
group
17
is
Hallie
resembling
the
same
average
here
for
the
equivalent
of
four
working
groups
are
so-called
questions,
which
are
nearly
equally
a
procedure
to
chart.
Read
next
slide,
please,
so
they
formed
in
over
working
parties
next
slide,
please.
AB
So
the
main
thing
which
I
would
like
to
point,
but
that
slide
is
there
well
vary
a
lot
of
coordination
between
different
standard
bodies
and
study
group
17
I
left
only
one
slide
on
this
topic
and
the
this
topic
I
will
tell
about
later
next
slide.
Please
so,
and
then
just
a
few
words
about
working
groups,
and
I
will
point
to
the
documents
which
are
on
the
development
now,
which
could
be
of
interest
for
RIT
of
people
here
in
the
question.
AB
2
I
would
like
to
point
out
to
the
X
sdn
sec
to
document
from
the
server
security
of
software
different
networks.
Next
slide.
Please
here
have
a
question
free,
well,
I
I
would
like
not
to
point
any
topic
thanks
ly,
please
and
the
slider
question,
for
it
is
interesting:
walk,
alter,
X,
dot,
nessa
as
witches
for
their
communication
protocols
and
requirements
for
the
information
of
the
incidents
between
networks.
It
can
be
source
of
some,
inter
so
for
variety
of
people.
Next
slide,
please
here
so
again,
I
idols
skip
it
next
slide.
AB
Please
so
here
in
the
cloud
computing
forever
has
several
things
which
could
be
interesting
so,
for
instance,
CC
that
data
sec.
So
next
slide,
please,
for
where
question
10,
it's
a
very
broad
question
and
very
interesting
one,
the
huge
cooperation
between
itu
and
our
star
guitars
in
body
its
concern
to
the
identity,
menaced
management.
The
problem
is
sure
which
is
arising
quite
high,
now
live.
There
are
internet
of
things,
development
and
are
other
things
which
you
can
colonel
connected
to
the
security
over
applications
and
all
of
it
and
there's
a
rail
sings
next.
AB
So
the
there
are
several
interesting
work
walks
in
the
question
six.
I
will
point
to
IG
sec,
one
either
sec
to
concern
clear
their
Internet
of
Things
security.
I
TS
sec,
1
and
its2
concern
concern
clear,
intelligent
transport
systems
so
again
Sdn
sec
1,
which
is
her
another
document
carrier
to
connect
the
SDN
security
and
were
which
is
developed
in
this
working
group.
Next
slide.
Please
here.
AB
AB
So
you
know
all
of
these
stuff
witches
were
under
the
development
in
with
you,
11,
it's
a
x509.
It's
a
sand
dot,
one
at
that
or
or
I
did
next
slide.
So
now
there
there
develops
new
religions
of
all
of
these
documents
and
the
gang
it
can
be
communicated
to
diff
and
can
be
made
some
propositions
for
their
these
revised
documents.
Next
slide,
please.
So
this
cannon
they're
one
of
the
documents
is
X.
Oig
are
IOT
for
about
the
possible
usage
regime
methods
for
their
IT
identification.
Next
slide,
please.
AB
So
this
is
a
question
12
mostly
they
were
formal
description
languages
for
a
tasting
tour
or
something
like
that.
It
could
be
of
some
interest
for
groups
which
are
trying
to
describe
such
processes
and
to
have
some
train
box
or
use
cases
for
that
next
slide,
and
so
pro
continuation
of
the
documents
which
are
now
developed
in
the
question
12th
next
slide.
So
the
here
will
be
two
slides
just
to
mention
our
other
study
groups
or
the
standardization
sectors
for
in
which
study
group
17
is
working
through
the
close
cooperation
on
the
security
issues.
AB
You
can
see
half
of
released
here
next
slide,
and
here
I
will
would
point
to
the
specific
study
group
theories,
15
and
study
group
20,
and
you
study
group,
which
was
formed
for
Internet
of
Things
and
is
now
starting.
It
works
in
that
direction
next
slide.
So
just
several
links
for
all
of
those
who
want
to
understand
it
more
precisely
and
to
learn
more
for
free
next
slide
and
I
can
be
over
the
contact
for
all
the
questions
which
are
consuming
study,
group,
17
and
cooperation
and
collaboration
with
its
works.
Thank
you.
Thanks.
M
This
is
actually
for
the
ids.
Are
you
gonna
have
upload
these
slides
because
there
are
a
couple
of
things
in
the
middle
that
scared
the
bejesus
out
of
me.
I
didn't
know
that
they
had
opened
up
some
new
things
so
actually
having
these
would
be
really
I
was
I
was.
I
was
in
the
process
of
doing
that
when
the
network
start
a
thing
for
me,
so
I
would.
N
N
C
AB
C
G
L
T
Yeah
and
talk
about
a
little
research
we
did
on
the
security
of
TCM
ciphers.
First
of
all,
I
have
to
excuse
on.
He
couldn't
be
here
today,
originally
wanted
to
drews.
Together,
can
you
so
I
read
this
blog
post
from
adam
Langley
somewhere
in
in
december.
I
think
where
he
pointed
out
that
there's
a
potential
problem
with
aes
GCM
in
TLS
and
that,
specifically
that
it
needs
an
8-byte
nonce.
T
Well,
you
and
nonce
is
a
creation
for
number
used
once
and
adam
langer
says
that
like
dia,
only
secure
way
to
do
this
is
to
use
a
counter
and
if
you
use
a
random
nonce
that
may
be
risky
and
that
he
checked
the
top
two
hundred
thousand
implementations
and
found
no
none
that
got
this
wrong
and
I
thought
there's
like
I
have
this
idea
that
if
there's
something
you
can
get
wrong
and
it
TLS
implementation,
then
someone
will
get
it
wrong.
So
I
dr.
T
next
slide,
yeah!
So
specifically
in
GCM,
if
you
have
a
nonce,
that's
if
you
use
the
same
nonce
two
times,
that's
the
same
key,
then
you
have
two
potential
attacks.
One
is
relatively
straightforward
that
by
X
or
in
the
two
you
get
the
X
Orion
of
the
plain
texts
which
leaks
some
information,
and
if
you
know
something
about
the
data
you
may
decrypt
something
and
the
other
one
is
attacked
from
anto
Andrew.
He
mentioned
this
attack
in
a
comment
on
the
GCM
standardization
process
that
you
can
extract
the
authentication
key
of
the
GCM
mode.
T
T
This,
that's
secure
is
to
just
use
a
counter,
so
you
could
start
with
0
and
use
one
and
because
it's
64
bits
and
that,
if
you
go
to
the
full
64
bits,
that's
not
likely
that
you
will
repeat
annonce,
you
could
choose
them
at
random
and
that
as
earlier
Adam
Lang,
we
said
and
yeah
that
this
is
risky.
If
you
encrypt
large
amounts
of
data
I
try
to
like
get
some
numbers
on
how
large
they
really
have
to
be
you're
really
going
into
the
area
of
terabytes.
T
But
there
may
be
situations
where
this
happens,
or
at
least
where
you
get
to
a
risk.
That's
so
high
that
you
find
it
unacceptable,
and
then
you
can
just,
of
course
repeat
your
nonsense.
All
the
time,
like
all
the
sending
the
same
value
for
loans,
which
is
completely
broken
and
next
slide-
and
this
is
the
RC
TLS,
1.2
and
I-
think
this
is
really
a
problem
at
expect
because
it
tells
the
implementer
okay,
each
value
of
the
nonce
explicit
must
be
distinct
for
each
distinct
invocation
of
the
TCM
encryption.
T
So
it
tells
the
implementer
what
he
needs
to
achieve,
but
he
doesn't
tell
how
to
do
it.
So
what
I
had
was
like
before
just
use
the
counter
and
then
everything's
safe,
that's
not
written
in
the
standard.
The
standard
just
assess
you
have
to
choose
distinct
nonces,
but
gives
no
guidance
how
to
do
that
properly.
Yeah,
so
I
think
this
is
an
example
of
how
specs
shouldn't
be
written.
They
should
be
more
explicit
or
should
avoid
such
pitfalls.
AC
T
T
Okay
next
slide,
we
did
an
Internet
wide
scan
and
we
found
a
small
number
of
horse
with
repeating
notices.
I
spend
a
lot
of
time
trying
to
track
them
down
and
find
out
which
devices
they
were
am
I.
Follow
that
a
couple
of
member
from
rattler
and
some
of
them
from
that's
not
just
closed
yet,
but
they
were
used
by
Visa
Visa
only
reacted
after
us
technique.
T
Yeah
sorry
I
had
a
slide
for
the
effect
devices,
so
next
slide,
so
the
spec
for
TLS
1.3
and
also
for
the
church
or
20
cipher.
They
are
more
explicit
in.
They
are
explicit
in
how
you
generate
that
nonce
and
it's
not
sent
over
the
wire,
which
essentially
means.
If
you
get
this
wrong,
then
your
implementation
won't
be
able
to
speak
with
other
implementations.
T
So
you
will
immediately
notice
yeah,
it's
like
then
there's
kind
of
the
bigger
debate
of
if,
on
the
base
of
an
algorithm
level,
these
issues
can
be
avoided,
which
is
under
the
there's
the
idea
of
having
a
synthetic
I.
We,
which
kind
of
the
that
you
have
an
initialization
vector
that
you're
not
setting
in
the
implementation,
but
that
kind
of
gets
generated
out
of
the
algorithm
and
there's
currently
some
debate
about
standardizing
ASG
cm
as
I.
T
We
I
think
there
are
some
disagreement
on
what
exactly
nonce
misuse
resistance
means
and
but
yeah
there's
development
in
that
direction.
So
even
on
the
algorithmic
level
itself,
these
issues
could
be
avoided
next
time.
Yeah,
so
I
conclusions
would
be
okay,
specs
should,
if
possible,
avoid
such
short
pitfalls
for
implementers,
which
in
this
case
was
possible.
T
I
think
we
need
better
testing.
Yeah
I
think
I
was
much
further
than
just.
AC
T
AD
We
offer
a
document
on
the
generation
of
ID's,
which
is
essentially
tease
me.
We
were
not
talking
about
non-citizens
being
specifically,
but
it's
the
same
topic.
So
my
question
is:
if
you
had
looked
at
it
because
for
I
mean
as
far
as
I
can
see,
it's
like
there's
like
the
part
of
the
advice
that
we
have
in
our
document.
Like
answer
some
of
these
questions.
Okay,
so
you
save
it
as
a
document
on
how
to
generate
IVs,
yes,
not
specifically
for
TLS,
because
it's
a
problem
at
the
last
citizen.
AD
AD
AD
With
presented-
and
we
gave
examples
that
I
mean
this
is
just
yet
another
example
of
why
these
that
are
generated
in
an
improper
way
at
some
point,
that
happened
for
port
numbers,
TCP
is
ends
fragmentation,
ideas
and
so
on.
So
in
this
case
you
have
a
particular
problem.
Particular
security
problem,
but
at
the
end
of
the
day,
boils
down
to
the
same
thing,
IDs
being
generated
in
the
wrong
way:
yeah,
okay,
so
I'll,
definitely
clear
up
a
look
at
that:
okay,.
S
AE
Hi
everyone,
so
my
name
is
Joe
Hall
I'm
here
talking
about
our
draft.
The
survey
of
worldwide
censorship
techniques
next
slide
so
just
to
hopefully
me
dekho,
who
follow
me
I,
can't
see
so
in
ITF,
91
I
came
in
presented
a
very
rough
draft
of
a
basically
a
descriptive
document
that
talked
about
all
the
ways
that
global
sensors
were
messing
with
protocols
across
layers.
AE
Really.
The
motivation
here
is
to
provide
sort
of
a
reference
document
for
protocol
designers
that,
if
you
care
about
resilience
to
this
kind
of
approach
to
this
kind
of
an
attack,
a
censorship
kind
of
a
attack,
you
might
learn
something
about
how
to
how
to
make
your
your
protocols
more
resistant
to
those
kinds
of
things.
Since
that
time,
we've
had
a
ton
of
really
good
feedback.
We've
worked
through
a
series
of
issues.
AE
So
just
quick
over
here
are
some
of
the
changes
we
made
when
I
presented
it
I
said,
there's
sort
of
three
elements
of
any
sort
of
censorship
activity
and
I
called
them
aggregation
identify
identification
and
prevention.
This
is
sort
of
from
a
center
literature
that
talks
about
this
kind
of
stuff
that
was
very
confusing
to
everyone,
and
so
since
then,
we've
added
other
off
authors,
Nick
Finster's
group
at
Princeton
and
we've
sort
of
come
up
with
prescription
identification
and
interference.
AE
Prescription
is
deciding
what
you
want
to
block
identification
is
during
the
network,
interaction,
classifying
traffic
that
you
want
to
block
via
some
sort
of
technique
that
we
describe
and
then
interference
is
make
decision
to
block
or
two
rate
limit
or
impair,
or
something
like
that.
The
traffic
that
you've
identified
we've
added
a
whole
bunch
of
different
points
of
control
that
sensors
may
seek
to
interfere
with
in
a
variety
of
ways,
including
certificate
authorities.
AE
These
new
network
features
like
content,
distribution,
networks
and
and
services
themselves
which
we're
starting
to
see,
like
you
know,
whats
app
in
Brazil
three
times
now,
even
though
the
higher-level
judges
immediately
say
that
that's
a
disproportionate
activity,
we
also
removed
a
pretty
problematic
statement
where
we
had
used
as
an
example
just
the
TLD
CH.
Just
for
whatever
reason.
I
don't
remember,
but
we
didn't
mean
to
imply
Switzerland,
actually
sensors
anything,
and
so
we
just
changed
it
to
something
like
that.
Foo
or
something
like
that
and
there's
the
DNS
interference
section
was
just
horrible.
AE
AE
You
know
if
you
send
a
packet
to
an
unallocated
IP
in
China
with
ITF
torg
in
it
you
get
no
response,
but
if
you
put
a
blocked
or
sensor
domain
like
facebook
com,
you
get
a
meaningless
nonsense,
IP
address
back
and
then
there's
lying,
which
is
where
a
sensor
may
specifically
tell
an
operator
of
a
recursive
resolver
you're
not
allowed
to
check
the
authoritative
for
these
kinds
of
endpoints.
You
need
to
go
this
place
next
slide.
AE
AE
Please
read
it
and
let
me
know
if
anything
out
or
if
we're
not
being
precise
enough
in
places
one
big
to
do
is
that
it
seems
like
both
in
the
the
three
sections
of
sort
of
the
types
of
the
sort
of
flow
of
that
a
sensor
would
take
to
censor
stuff,
we're
going
to
actually
break
it
up
into
layers,
because
it
just
makes
more
sense.
We've
done
that
with
the
identification
piece,
but
it's
not
yet
done
with
interference
piece.
It's
just
some
refactoring
that
takes
time.
AE
One
question
I
have
for
folks
it's!
You
know.
We
saw
this
with
the
attempted
coup
in
Turkey,
where
some
of
the
stuff
is
evolving
right
now,
and
so
the
document
in
a
sense
needs
to
learn
about
that
stuff
over
time.
To
really
be
helpful,
and
you
know
in
when
the
coup
is
happening,
we
were
sitting
there
watching
a
whole
bunch
of
different
types
of
techniques.
We
saw
DNS
filtering
happening.
We
saw
route,
miss
announcements
as
well
to
block
stuff
across
different
ISPs
all
at
the
same
time.
It's
totally
unclear
to
me.
AE
You
know
if
they
were
all
ordered
to
do
that
if
they
just
thought
that
was
probably
a
pretty
good
idea,
give
it
was
going
on
or
what
I
have
no
idea
how
to
tell
what
was
happening
there.
We
have
gotten
at
an
IR
TF
in
the
human
rights
protocol
considerations.
Group
I've
thought
about
you
know
putting
this
document
into.
AE
There
is
sort
of
a
descriptive
reference
document
that
might
be
useful,
but
we
got
some
feedback
that
it
would
benefit
from
the
IETF
process
from
actually
having
folks
look
at
it,
having
a
call,
and
so
that's
why
I'd
like
to
consider
getting
security,
80
sponsorship,
one
of
our
wonderful
security,
IDs
and
I'd
like
this.
As
I
said
in
honolulu,
if
you
were
there,
I'd
like
this
to
be
the
first
of
a
stream
of
documents
that
might
be
helpful
in
you
all
to
designing
your
protocols
so,
for
example,
traffic
analysis.
AE
I
know
that's
a
huge
subject
that
is
not
nearly
as
sort
of
as
easy
intractable,
as
you
know,
blocking
and
filtering,
and
those
kinds
of
things
or
censorship.
Maybe,
but
I
think
it
would
be
helpful
because
a
lot
of
it
there's
people
amongst
us
that
know
quite
a
bit
about
traffic
analysis,
there's
people
that
have
no
clue
about
it
and
it
may
be
helpful
to
have
something
lying
around
that
can
be
useful
to
the
people
who
are
designing
protocols
that
might
want
to
refer
to
it
or
otherwise,
learn
from
it.
I
think.
C
C
R
R
R
So
there's
some
outdated
information
mentioned
of
protocols,
algorithms,
our
concept
of
privacy
has
evolved
and
in
part
by
publishing
a
needle
RFC,
but
in
general
there
are
changes
in
the
internet
environment
from
what
it
was
in
2003
this
pervasive
monitoring.
Just
as
an
example.
Now
we
are
considering
using
adding
draft
gone
to
numeric
IDs.
Second
situations
into
this:
it's
not
decided
yet
what's
up
to
the
list
and
perhaps
adding
something
about
opportunistic
security,
some
special
cases
that
we
think
need
to
be
handled.
R
There's
extension
documents,
there's
lots
of
documents
that
extend
some
existing
protocol
and
then
you
get
the
security
considerations.
It
says:
oh,
the
master
document,
then
it's
all
in
there
yeah
it's
fine
and
sometimes
that's
okay.
Sometimes
it's
not,
and
you
want
to
have
guidance
about
when
it
is
okay
and
when
it
is
not,
and
also
there
are
some
use
usage
documents
for
specific
applications
of
general
generalized
frameworks,
and
we
think
need
some
text
above
that
so
next
slide.
Okay,
so
example
of
outdated
information,
section
4
52
recommends
using
SSL
or
TLS.
R
1.0
SMI
is
described
there
as
something
that
is
too
new
to
have
seen.
Why
deployment
one
section
before
that
recommends
using
aah,
where
aah
is
pretty
much
pulled
out
of
most
ip6
tax?
By
now
it
also
states
that
both
h
and
ESP
are
mandatory
for
ipv6
and
that's
been
relaxed
for
royalty
at
least
well.
It
has
been
relaxed
in
general
because
of
the
needs
of
IOT
there's
no
mention
of
algorithm
selection,
no
mention
of
algorithm
agility,
no
mention
of
aedes.
R
Theirs
is
quite
a
bit
of
mention
of
non-repudiation
that
most
of
us
have
decided.
That
is
not
really
a
meaningful,
meaningful
concept
and
there's
a
example
of
making
secure
purchases
over
s.
Mine,
I,
don't
think
that's
taken
off
so
well
so,
and
there's
something
section,
three
point
two
point
one
password
sniffing
it
mentions
protocol
such
as
telnet
pop
and
then
TP,
but
no
mention
of
HTTP
are
all
off.
Both
are
pretty
much
vulnerable
to
this,
so
next
slide.
R
R
It's
the
fact
that
this
corporate
laptop
that
Kathleen
has
there's
Matt.
No,
no
sorry,
you
don't
connect
it
at
work.
I
know
I
like
this
one,
ok,
so
the
phones
we
all
have
here
going
to
go
on
to
the
corporate
Wi-Fi
network
sometime
next
week-
probably
ok,
so
so,
whatever
malware
they
pick
up
here,
bring
to
the
place
behind
the
firewall
and
there's
a
lot
of
UDP
based
protocols
that
we
didn't
have
in
2003
and
the
TLS
that
also
wasn't
available.
R
2003,
hey
so
next
time,
so
the
plan
we
run
term
to
submit
a
0-0
draft
by
September-
probably
a
lot
earlier,
probably
very
early
August.
That
will
lead
just
the
3550
to
changing
the
author
names
and
doing
whatever
is
necessary
to
get
it
past
the
ID
nets,
and
then
we
hope
to
have
an
extensive
discussion
on
the
sag
mailing
list
and
publish
two
or
three
revisions:
bye,
bye,
soul
and
need
to
revise
the
exam
examples,
make
more
weekly,
more
modern
and
have
more
discussions
at
the
IKF
97.
R
Hopefully,
I
ITF
last
call
early
next
year.
So,
like
it
says,
their
comments
are
silver
text
is
gold,
so
please
send
it
to
us
and
neck
site
yeah,
so
one
finger
for
now.
The
discussion
is
going
to
happen
on
this
cyclist.
If
we
see
that
the
volume
is
very
great
and
we
might
want
to
the
mailing
list
all
for
on
our
own.
AF
Now,
that's
turned
out
to
be
useful
to
appoint
people
to,
and
I
suggest,
not
as
an
alternative
to
doing
this
kind
of
update
periodically,
but
that
this
document
points
at
a
wiki
page
in
the
security
area
that
has
hot
issues,
things
that
have
changed
since
the
last
version
of
this
BCP
put
it
put
the
pointer
in
the
document
and
then,
as
things
develop,
you
can
start
listing
them
there,
while
you're
preparing
the
next
revision
so
that
people
are
alerted
to
it.
That's.
M
Paul
Hoffman,
this
is
actually
a
question
for
the
80s
I
have
proposed
before
and
gotten
some
good
some
positive
response
and
negative
response
on.
The
idea
of
that
must
and
should
should
not
appear
in
the
security
considerations
unless
they
are
duplicates
of
stuff
before
and
maybe
not
should
I
start
this
before
the
00,
or
should
we
wait
for
the
zeros
or
I?
Don't
want
to
get
it
in
too
late
because
a
lot
of
people
agreed
with
me,
but
a
lot
of
people
didn't.
When
would
you
like
that
to
come
up,
send.
N
C
So
unless
you
heard,
and
the
authors
are
planning
on
putting
a
0-0
out
by
what
did
you
think
early
august
early
august?
So
if
this
week
is
a
good
time
Johnson
and
but
sooner
is
better
for
anything.
So
if
you
any
issues
and
raising
this
one
kind
of
caveat,
I
would
look
at
this
and
came
out
much
shorter,
because
I
think
that'd
be
more
useful,
but
I
I.
AG
C
L
Y
L
I
can't
get
much
closer
okay.
What
I
wanted
to
do
is
mention
the
kryptek
workshop.
The
easiest
thing
to
do
is
to
go
to
cryptic
God
is
and
then
at
the
there'll,
be
a
link
there
to
the
Berlin
workshop
and
then
there's
a
wiki
that
has
four
presentations
and
some
additional
details
there,
and
if
you
have
any
thoughts
comments
or
it
want
to
contribute
to
the
project.
Technically,
that
would
be
great,
hey.
AA
Matt
Miller
just
wanted
to
let
everybody
know
that
right
after
the
next
session,
we
are
having
the
ledger
Boff.
This
is
about
a
distributed
web
payments
ledger.
This
is
work
that
was
that's
a
group
from
ripple
and
originated
in
w3c
community,
our
brain
to
the
ITF,
to
see
what
they
think.
So,
if
you
have,
if
you
have
interest
or
comments
or
questions,
please
join
us
in
potsdam,
one
right
after
this.
S
Hi,
the
selected
company
I'm
monitoring,
Dane
deployment
these
days
and
I
noticed
that
many
folks
are
still
running
rather
obsolete.
Dns
SEC
servers
that
historically
have
been
adequate.
They
returned
correct
answers
for
valid
data,
but
they
rather
fail
badly
at
denial
of
existence,
and
this
is
important
for
Dane
and
email,
because
bad
denial
of
existence
looks
like
a
man-in-the-middle
attack,
downgrading
the
non-existence
of
your
TLS,
a
records
and
the
like.
So
it
will
start
to
cause
email,
delivery
problems
for
the
few
and
the
brave
or
starting
to
implement
Dane.
S
AH
You're,
unsure
for
a
quick
advertisement
will
just
republished
the
RFC
on
running
code,
the
implementation
status
section
as
a
bcp.
It's
RFC
17,
9
42
and
please
use
it
in
your
internet
draft.
So
if
you
have
an
implementation
or
implementations,
please
document
them
for
the
benefit
of
the
working
groups.