►
From YouTube: IETF110-ADD-20210311-1200
Description
ADD meeting session at IETF110
2021/03/11 1200
https://datatracker.ietf.org/meeting/110/proceedings/
A
A
recession:
do
we
at
some
point,
do
we
want
to
take
a
five
minute
bio
break,
or
do
we
just
want
to
yeah
push
on
through.
A
B
B
A
Yeah,
I
don't
see
the
west
coast,
I
say
a
few.
I
see
tommy
paulie,
hello,
tommy,
a
few
west
coasters.
A
C
A
C
A
A
And
I'll
pull
that
up
in
a
minute.
So
so
just
so,
people
have
a
heads
up
we'll
be
talking
about
this
and
I
believe
we
were.
D
D
Sorry
say
that
again
we
we
updated
the
the
slides
and
they
I
sent
you
a
now
to
to
to
to
accept
them.
Oh.
A
C
E
Yeah,
the
slides
were
updated
just
to
highlight
the
comments
that
we
received
yesterday
and
the
possible
solutions
that
we
thought
about
and
what's
the
next
steps
to
address
them.
A
All
right,
so
I've
got
to
look
up
I'll
I'll
watch
out
for
the
slides.
So
should
we
get
started
with
the
front
matter.
A
Okay,
so
welcome
to
80d
session
two
at
itf
110.
We
have
a
a
longer
block
today,
so
we're
going
to
try
to
find
a
natural
place,
probably
at
about
the
one
hour
mark,
to
take
a
five-minute
break
for
everybody,
to
grab
a
coffee
or
or
do
whatever.
Beware
no
well
applies.
This
is
an
official
itf
session.
So
please
familiarize
yourself
with
the
provisions
of
it.
A
If
you
are
not
already
aware,
I'm
glenn
dean,
I'm
your
co-chair
for
add,
and
mr
david
lawrence
is
my
co-chair,
say
hello,
david
hello,
and
so
this
is
the
agenda.
For
today,
we've
done
noteworld.
We've
done
subscriber
selection
agenda
bash.
We'll
have
open
microphone
at
the
end,
so
I
think
pretty
much.
If
there's
topics
people
want
to
bring
up,
that's
the
opportunity
right
there.
A
This
is
hello
from
the
chairs,
mr
our
new
incoming
aed
barry
oliva
has
handed
off
to
eric
vick
the
responsibilities
as
the
ad
for
the
ad
working
group
eric.
Would
you
like
to
say
a
few
words.
C
Yes,
thank
you.
Glenn
simply
want
to
say
hello
to
this
working
group,
which
is
quite
close
to
another
one
again
before
which
is
deprived,
so
I
was
following
it
for
far
away
so
apt
continue
working
with
glenn
and
and
dave
on
this
one
and
then,
of
course,
all
the
working
group.
A
Thank
you
eric,
so
that
brings
us
the
where
we
left
off
on
monday
and
so
forth.
Tuesday.
C
A
Yes,
of
course,
we
absolutely
do
want
to
thank
thank
barry
because
barry's
done
a
wonderful
job
he's
so
we've
been
in
business
now,
for
I
think
about
a
year
and
barry
was
instrumental
in
getting
us
over
the
goal
post
of
getting
formed
as
a
working
group
and
he's
been
a
wonderful
ad
to
work
with.
So
thank
you
very
much
barry
for
the
great
work.
B
Sure
I
was
going
to
break
out
into
tune,
but
I
can't
imagine
that
would
have
gone
over
so
well
yeah.
I
don't
actually,
aside
from
singing
show
tunes,
I'm
a
little
short
on
filling
up
airtime,
so.
A
B
Lean
towards
well,
I
I
can
actually
say
I
was-
I
was
in
quite
a
few
musicals
throughout
my
middle
school
and
high
school
career
music
man
fiddler
on
the
roof.
You
know
all
the
all
that
era,
the
great
grand
thera
musicals.
B
D
Yeah
you
can
go
to
the
next
one.
Please.
D
Yes,
so
thank
you,
dean
at
the
yeah
for
I'm
sorry
for
this
delay
to
start
the
decision,
so
we
just
right
after
the
the
first
session
we
had
last
last
time
we
we
we
tried
to
to
capitalize
on
the
I
would
say
on
the
on
the
comment
that
we
received
so
far
and
the
the
various
comments
we
received
during
the
decision
and
also
the
some
of
the
consideration.
We
have
ordered
the
draft
and
we
would
like
to
to
make
a
proposal
so
that
we
can.
D
We
can
make
some
progress
for
the
yeah
for
the
for
for
the
specification,
of
course,
this
this
proposal
does
not
mean
that
all
will
be
will
be
frozen,
but
at
least
we
will
have
something
we
we
would
like
at
the
end
of
the
meeting
to
to
have,
I
would
say,
a
base
so
that
so
that
we
can
we
can.
We
can
adjust
on
the
future,
but
at
least
the
sum
of
the
key
feature
can
be
can
be
covered,
so
the
the
memphis
portal
will
be
will
be
structured,
as
shown
in
this
slide.
D
So
we
we
the
first
key
consideration
that
we
heard
they
would
say
at
least
for
the
the
last
meeting.
Is
that
yeah?
If
we,
if,
if
dnsec,
is
supported
by
the
client-
and
we
have
the
record
that
are
signed
at
the
at
the
server
side,
so
the
information
that
will
be,
I
would
say
sufficient.
So
for
the
for
the
for
the
client
to
to
discover
the
the
resolvers
will
be
the
idiot
itself
and
a
list
of
ip
addresses.
D
And
then
once
this
information
is
supplied
to
the
client,
the
client
can
use
the
svc
bqs
to
resolve
the.
I
would
say,
the
the
domain
name
and
this
information
will
be
sent
to
the
api
that
is
provided
in
this
information.
D
But
the
as
we
all
know
that
dns
sec
is
not
that
supported
by
some
of
the
clients,
and
we
we
may
also
have
they
would
say,
design
which
is
not
signed.
So
we
have
the
the
the
the
next
step
is
that
if
the
nsx
is
not
supported,
so
what
what
are
the
the
key
information
that
will
be
required
by
the
medic
client
so
that
it
can
securely
retrieve
the
information
that
would
be
needed
for
for
for
for
the
process.
D
So,
in
addition
to
the
edn,
the
the
name,
information
that
is
already
the
present
in
the
in
the
previous
step
and
also
the
the
list
of
ip
addresses,
we
will
need
an
ultimate
port
number
because
we,
for
instance,
for
dns
or
tls
or
even
for
for
quick.
D
We
may
not
have
the
same
port
number
used
for,
for,
I
would
say,
binding
the
service
and,
in
addition
to
that,
we'll
also
need
to
to
convey
to
in
the
dhap
option
the
information
about
the
type
of
the
encrypted
dns,
which
is
supported
by
by
the
server.
This
one
is,
is
needed
in
order
to
avoid
having
the
problem
to
to
go
through
all
the
variant
of
the
integrated
dns
services
that
are
supported
by
the
client.
D
So
all
this
from
this,
this
for
information
can
be
at
least
required
to
be
returned
in
the
shape
option,
and
then,
once
we
have
this
formation,
the
the
client,
if
it
support
dns
over
or
over
tls
or
if
it
support,
also
dns
over
quick,
and
in
addition
to
that,
it
supports
also
the
damage
over
https
in,
in
that
case,
the
we,
the
client,
will
establish
a
secure
connection
using
the
information
that
is
provided
in
this
previous
step,
so
that
to
to
to
retrieve
the
list
of
the
ui
templates
from
the
from
the
server.
D
But
if
the
the
client
is
only
supporting
the
in,
in
that
case,
the
client
must
request
a
list
of
era
templates
from
the
from
the
from
the
dhcp
server.
This
is
this
is
important
to
avoid
having
the
external
attacks
against
the
the
svcp
carriers
and
also
the
if
in
case,
the
the
the
request,
the
svcp
requests
are,
get
blocked
somewhere.
So
this
is
basically,
I
would
say,
the
the
the
overall
sketch
of
the
proposal
that
we
would
like
to
propose
for
the
for
the
working
group.
B
Well,
let's
sit
here
for
a
second
we've
got
some
confusion
going
on
in
chat
and
people
that
want
to
jump
in
with
couple
questions,
so
tommy
paulie,
please.
First.
F
All
right
yeah,
thank
you
for
updating
the
proposals.
I
I
like,
like
the
first
half,
I'm
not,
it
sounds
like
you
know.
This
is
kind
of
a
hybrid
in
which
we
have
the
stuff.
We
were
talking
about
tuesday
and
the
stuff
that
was
existing
and
that's
being
conditional
on
dns.
Can
you
explain
a
bit
more?
Why
I
don't
recall
why
dnsec
should
matter
here
really,
because
if
we
have
the
name,
then
we
can
do
a
secure
upgrade.
F
D
Yeah,
I
think
this
point
particularly
tommy
was
discussed
on
the
mailing
list
and
the
clarification
was
already
given
there.
Is
that
you,
for
instance,
if
you
can,
if
the
nsx
is
not
supported,
then
someone
can
return
to
you.
I
would
say
some
queries
and
then
it
can
directly
to
another
fake
server
which
is
claiming
to
I
would
say,
on
the
name
and
so
on.
So
but
but.
F
Then,
unless
this
name
that
the
network
is
giving
out
is
fundamentally
compromised,
so
let's
say
it's
cloudflare
dns
or
it's
your
xfinity
dns
or
something.
If
that
is
that,
if
people,
if
rogue
dns
servers,
have
valid
certificates
for
that,
then
people
are
going
to
have
a
bad
time
connecting
to
that
dns
server
in
general.
But
assuming
that
that
is
valid
and
people
are
when
they're
using
the
svcp
record
results
they're
using
the
the
name.
E
Hello,
yeah
tommy
you're,
right
that
if
dhcp
gives
you
an
adm,
tls
certificate,
validation
would
happen
and
there
is
no
possibility
of
an
attack.
But
the
attack
that
we
discussed
in
the
last
minute
of
yesterday's
meeting
was
a
scenario
where
the
dns
response
is
modified
in
a
way
to
show
that
there
is
a
dohd
or
dioco
server,
but
the
parameters
are
set
in
a
way
that
the
client
doesn't
connect
to
it.
It's
basically
spoofing
attack,
but
it
says
the
servers
are
available
and
the
client
tries
to
connect
to
that.
E
E
F
E
So
so
we
so
there
are
multiple
types
of
denial
of
service.
We
are
just
talking
about
an
attack
of
denial
of
service
where
you
get
tampered
responses
and
the
client
thinks
the
server
is
available.
It's
supporting
the,
but
it's
still
not
able
to
connect,
and
it
just
gives
up
and
falls
back
to
do
53,
but
in
case,
if
there
is
a
denial
of
service
where
somebody's
blocking
it,
the
client
would
be
sure
that
hey
there
is
an
attacker
which
is
blocking
it.
But
in
this
case
the
client
would
be
thinking
hey.
Maybe
it's!
E
E
Attacks
that
you
can
see
that
in
one
case,
the
client
has
no
knowledge
why
it
was
blocked
from
assets.
F
If
I
received
this
scenario
that
you're
describing
in
which
I
received
indication
that
I
support
encrypted
dns
with
a
name,
I
looked
up
the
record
and
I
failed
to
connect.
I
would
treat
that
as
an
attacker
and
I
think
we
would
need
to
let
the
user
know.
I
don't
think,
there's
any
reason
to
have
a
client
assume
that
oh,
they
just
have
an
old
version.
I
think
that
should
look
like
an
attack
and
we
should
mandate
that
anyway
I'll.
Let.
B
Thank
you,
tommy
ecker,
please.
G
Thank
you,
so
I
think,
like
maybe
like,
let's
just
take
a
step
back
here
and
make
sure
we
all
agree
on
the
basic
assumptions.
The
first
biggest
assumption
is
whatever
stuff
you
got
in
this
you
know
in
in
in
this
message
is
authentic,
correct.
G
H
G
Okay,
good
and
so,
and
the
server
has
no
way
knowing
the
client's
capabilities,
but
the
client,
but
the
server
knows
it.
It's
correct.
So
when
you
say
if
dnsec
is
not,
support
is
supported
by
the
client
or
dsa
is
not
supported
by
client.
I
don't
understand
what
that
means.
G
D
This
is
something
that
we'll
discuss
on
the
next
slide
to
see
how,
because
the
as
a
function
of
the
capabilities
of
the
client,
the
this
this
will
trigger,
I
would
say
the
some
of
the
information
that
will
be
requested
by
the
client
itself
to
the
server
and
also
how
it
will
handle
some
of
the
information
that
we
receive
from
the
from
the
server.
The
server
does
not
need
to
to
be
aware
of
the
capabilities
of
the
client
itself.
G
G
E
Yeah,
so
I
think
if
you
go
over,
the
dns
sec
is
not
supported.
Then
dnsec
is
supported,
just
becomes
a
sub
case,
but
we
just
wanted
to
cover
why
why
the
difference
is
required
in
case
of
dns,
occasionally
not
required.
We
can
just
go
with
this
case,
but
it
was
just
to
illustrate
the
purpose
why
the
svcb
query
was
not
sufficient
and
you
had
to
rely
on
something
else
because
of
clients
which
were
not
doing
that,
but
the
proposal
could
be
just
sticking
to
the
later
ones
without
sure.
G
So
this
this
brings
me
to
a
final
point,
which
is
what
we
are
now
doing
is
adding
like
tiny
little
pieces
of
svcb
into
this
into
this
message.
To
get
to
the
point
where
we're
satisfied
and
bringing
back
to
my
point
yesterday,
let
us
add
all
of
that
svcp
here
and
they
really
didn't
know
analysis
whatsoever,
determine
what
pieces
of
svcb
we
have
to
manage
and
we
will
not
have
to
do
the
thing
we
want
to
do.
The
next
slide,
which
is
required
dot
and
all
we'll
have
to
do-
is
import
svcb.
G
So,
instead
of
trying
to
do
like
a
bunch
of
like
when
we
first
agreed
to
accept
this
set,
this
work,
I
said-
and
I
believe
the
number
said:
let
us
not
create
a
situation.
We
have
a
a
disjoint
set
of
information
or
an
overlapping
set
of
information
which
is
in
this
record
and
which
is
svcb.
The
original
puzzle
was
designed
to
have
exactly
one
thing
which
was
the
adn,
so
it
was
like
easy
to
analyze,
but
now
what
you're
doing
is
you're
creating
a
whole
pile
of
new
stuff
which
we
have
to
analyze?
G
B
I'm
done:
okay,
excellent,
eric
and
anterio
and
med.
I
I
hope
you
will
very
much
take
those
comments
into
consideration
and
now
ralph
weber.
J
Yeah,
though,
think
the
initial
draft
was
very
simple
in
the
way
that
it
had
kind
of
the
ip
address
and
then
a
bitmap,
and
then
you
connect
it
and
be
done,
and
I
agree
that
dhcp
should
be.
That
should
be
like
that.
You
get
the
information
and
you
can
with
that
information
make
a
connection
to
a
dns
server.
J
H
So
to
me,
the
the
core
sticky
question
here
that
that
we
need
to
address
is
what
happens
if
you
are
a
doe,
only
client
and
your
network
hands
you
a
resolver
that
says
and
says
this
resolver
supports
encrypted
dns
and
you
you
chase
the
information
about
that
resolver
and
find
that
it
only
does
dns
over
tls
or
any
other
combination
of
protocols,
you're,
a
dot,
only
client
and
the
network
hands
you
an
encrypted
resolver.
That
appears
to
only
support
doh.
H
There's
there
are
various
options
there.
You
know
the
obvious
options
are
to
fail,
open
or
fail
closed
and
they're
both
bad.
They
both
they
both
create
some
either
secure
serious
security
or
operational
challenges.
Note
that
we're
talking
about
dhcp,
there's
no
negotiation
here
between
the
the
client
and
the
dhcp
server.
Really
the
dhcp
server
is
just
informing
the
client.
H
So
I
think
that
to
me
is
the
is
the
core
thing
that
we
we
want
to
resolve
here.
G
I
think
I
think
there's
perhaps
I
want
to
think
by
agreeable
thanks
for
that,
thanks
for
sharpening
that
so
much
I'll,
let
you
start
a
tiny
bit
more,
which
is
that
there
are
two
questions.
One
question
is
you
have
the
information
authentically
another
question?
G
You
got
that
information
authentically
and
the
attack
you
propose
on
the
mailing
list
involves
having
the
information
not
authentically,
but
if
you
have
information
authentically,
I
think
I
actually
don't
agree
with
tommy,
which
is
if
I
join
a
network
and-
and
I
only
speak
doe
and
network
says
well,
I
only
I
only
have
doke.
That's
like
oh
well,
that
was
kind
of
sad.
You
know,
but
I
mean
but,
and
I
just
go
ahead,
but
I
mean
the
the
the
point
of
this
mechanism.
G
Is
I
mean
the
the
point
of
this
mechanism
after
all,
is
to
allow
you
to
discover
that
networks
do
have
upgraded
security
and
take
advantage
of
that,
and-
and
so
you
know
if,
if
we
were
willing
to,
if
we
were
willing
to
have
the
assumption
that
the
client
would
actually
refuse
to
connect
an
armored
secure
resolver.
Actually,
it's
probably
much
much
simpler
right,
because
then
you
wouldn't
have
to
trust
me
this
information
at
all.
G
So
so
I
think
that
the
you
know,
so
I
think
my
understanding
is
assumption
is
the
client
wants
to.
I
don't
want
to
say
opportunistic.
That's
not
quite
right,
but
the
client
wants
to
discover
if
the
network
supports
secure,
resolver
and
then
use
it,
but
also
not
use
it
if
it
does
not
have
one
so
so
I
think
if
the
information
is
authentic,
the
answer
is
actually
I'm
not
sure
if
you
want
to
call
fel
open,
but
it's
a
continuous
53.
H
So
I
I
am
perfectly
okay
with
that.
I
just
want
to
be
clear
about
the.
What
the
result
of
that
is.
The
result
of
that
in
this
design
is,
that
is,
is
essentially
what
what
muhammad
has
has
put
on
the
slide,
which
is
that
at
a
minimum
you
you
need,
you
need
the
dhcp
server
to
enumerate
for
you,
the
the
set
of
protocols
supported
by
the
server,
so
the
client
cannot
insecurely
discover
that
set
of
protocols
using
only
the
adn.
H
G
H
And
and-
and
I
and
I
agree
with
eckerd
that
if
you're
going
to
include
that
kind
of
information,
then
you
should
probably
ship
the
whole
configuration.
B
Thank
you,
ben
jim
reid.
Please.
K
I'm
getting
a
bit
confused
with
this
discussion
because
I
think
we're
diving
too
much
in
detail
when
things
like
the
threat
model
is
really
not
clear
and
fully
understood.
I
mean
what
are
the
risks
here
about
using
dna?
Where
are
the
requirements?
Maybe
we
need
to
step
back
a
little
bit
even
further
from
what
echad
mentioned
a
few
minutes
ago?
B
Thank
you,
jim
glenn,
did
you
have
something
you
were
going
to
say.
A
Yeah,
so
not
wearing
a
hat
here.
I
just
want
to
point
out
that
you
know
the
device
of
this
dhcp
server.
We're
talking
about
right
now
will
be
an
older
legacy,
cp
device
in
most
cases,
so
it
just
strikes
me
as
we
should.
I
think
always
keep
in
mind
that
we
need
to
keep
that
portion
of
the
things
simple,
and
you
know
I'm
getting
these
things
upgraded
is
going
to
be
very
difficult.
A
B
Thank
you
glenn,
terry.
Please.
E
Yeah
I
mean
I,
I
understand
the
proposal
of
putting
in
the
entire
svcp
dns
response
in
the
thcp
option,
but
what
we
realized
was
when
we
started
looking
into
the
dhcp
options.
The
way
the
dhcp
options
were
supposed
to
be
designed.
E
It's
supposed
to
be
really
simple,
and
if
you're
supposed
to
put
the
entire
svcp
recorder,
it
seems
to
be
deviating
from
the
guidelines
that
were
set
with
regard
to
dhcp
option
set,
and
this
needs
to
be
definitely
discussed
in
a
much
larger
form,
probably
in
other
working
group
where
dhcp
options
are
being
defined.
But
if,
if
svg
options
were
put,
we
don't
have
to
do
all
of
this
and
it's
very
straightforward.
E
But
the
concern
why
we
put
all
of
this
in
in
a
format
that
would
be
acceptable
by
the
tcp
working
group
was
to
keep
it
as
simple
as
possible
and
if
svcp
record
is
the
way
to
go,
and
if
this
working
group
and
the
dhc
working
group
has
no
issues.
I
I
think
that's
the
easiest
way
to
get
this
done.
F
Back
yeah
I'd
like
to
maybe
kind
of
call
on
eckhart
to
clarify
the
the
thing
that
was
he
said
last
time
and
what
he
has
in
chat
around
using
the
hash.
So
would
that
essentially
just
be
a
hash
of
this,
so
that
we
would
query
the
scp
svcb
records,
but
we
would
be
able
to
detect
if
someone
is
messing
with
them.
F
F
Right
and
if
you
know
the
hash,
then
you
can
validate
that
you
have
the
correct
set
of
bonuses
and
then
that's
the
limit
that
you'll
ever
have
of
all
the
information
you
ever
have
to
put
into
ecp
or
any
other
protocol.
E
E
B
H
Hi,
so
I
wanted
to
first
say
in
terms
of
simplicity:
I
think
move
okay
in
terms
of
management.
I
do
not
think
shipping
a
hash
of
the
record
or
record
set
is,
is
really
an
option
here.
These
these
things
are
dynamic.
So
if
the
client
does
a
lookup,
there
is
no
particular
guarantee
that
it
gets.
H
The
exact
record
set
that
that
was
previously
seen
by
the
dhcp
server,
so
that
you
know
you
could
easily
get
mismatches
that
are
are
not
due
to
any
kind
of
attack,
and
that
would
result
in
a
in
the
client
essentially
going
offline.
H
The
I
do
not
think
that
shipping
these
records
creates
a
lot
of
operational
complexity
or
implementation
complexity,
because
they
are
opaque
to
the
to
the
dhcp
server.
You
know
the
dcp
server
just
basically
needs
the
domain
name,
and
it
can
fetch
this
record.
Although
there's
some
some
security
questions
about
the
bootstrap
process
there,
but
but
it
doesn't
need
to
look
inside
the
record.
It
just
needs
to
plop
the
record
into
this
dhcp
option
if
the
concern
is
really
about
record
size.
H
I
also
think
that
we
don't
need
to
worry
too
much
about
that
service
b
is
tightly
optimized
for
size,
because
dns
records
are
also
under
considerable
size
pressure.
So
it's
a
very
efficient
encoding
they.
So
I
floated
an
a
suggestion
on
the
mailing
list
to
ship
entire
dns
responses,
essentially
with
multiple
records
in
the
standard,
full
dns
wire
format.
H
So
if
your
entire,
if
an
entire
large
subnet,
you
know
it
could
thousands
of
of
devices
or
even
more
could
be
served
by
a
single
dhcp
server,
that's
handing
everybody
a
single,
a
fixed
set
of
ip
addresses
for
a
dns
server.
That
is
which
they
are
then
holding
on
to
for
for
days.
At
a
time,
that's
going
to
interfere
with
the
ability
of
typical
cdn
style
load,
balancing
which
is
allowed
with
service
b.
H
H
But
but
if
we
can
omit
the
ttls,
then
we
can
also
talk
about
an
even
more
compressed
representation
where
you
just
ship.
The
the
service
b
contents
essentially
resolved
service
be,
and
that's
really
very
compact.
It
should
be
fine.
B
Okay,
thank
you
ben
I'll,
observe
I
I
plan
on
taking
just
kirsty
and
ecker
for
comments
eliot.
If
it
can
be
really
quick,
I
suppose
you
have
snuck
in
under
the
wire.
We
spent
a
long
time
on
this
slide.
Then
we
still
have
quite
a
few
things
to
get
to
in
the
session.
So
I
think
there's
been
a
lot
of
great
discussion
here
and
it's
certainly
now
kind
of
well
encapsulated
to
bring
to
the
list
to
to
hammer
out
the
details
so
kirsty,
please.
L
Thank
you
I'll,
be
quick.
Sir
elliott
can
speak
I'd
just
like
to
go
back
to
a
point.
I
don't
think
was
really
addressed
very
well,
which
is
in
order
to
know
kind
of
what
security
things
we
should
be
using
here.
We
need
a
clear
threat
model
and
to
know
what
you're
trying
to
protect
from
who
and
what
the
assumed
capabilities
are
of
your
various
attackers.
So
I'd
really
like
to
have
a
lot
more
discussion
on
what
problem
this
is
solving
and
what
you're?
Assuming
of
your
attackers
thanks.
G
Kirsty
ecker
glad
to
have
you
back.
Yes,
I
was
cleverly
trying
to
make
a
contribution
to
sag,
so
anyway,
I
mean
I
basically
agree
with
what
ben
was
saying.
You
know
that
there's
like
there's
some
version
of
the
world
where
the
hash
like
adds
value
but
like
it's
like
where
you
can't
like
fit
things
in
like
in
the
record
or
because
like
for
some
reason,
people
don't
think
like
any
structure
on
the
record
is
good,
which
I
don't
understand
why
that
would
be,
I
think,
putting
it
in
lining.
M
Please
good
afternoon,
good
morning,
I'm
just
typing
as
fast
as
I
can
just
one
quick
comment
about
what
ben
said
or
our
refinement
rather
dhcp.
Ttls
are
all
over
the
map
in
in
in
enterprises
in
in
home,
in
homes
and
elsewhere.
They
range
from
five
minutes
to
hours.
I
don't
think
anybody
uses
longer
than
hours
these
days,
except
in
specialized
cases.
So
far
as
I.
M
E
M
Then
is
is
where
I
would
find
agreement
with
ben
is
that
if
you
have
to
match
the
dns
ttl
to
a
a
dhcp
lifetime
or
an
ra
lifetime,
one
of
the
important
things
to
think
about,
then,
is
who
owns
each
of
those
values
in
terms
of
how
they're
set,
and
that
should
receive
a
little
bit
further
consideration.
And
thanks
for
the
time.
B
Thank
you
elliot,
glenn
and
med
on
to
the
next
slide.
Please.
D
Yeah,
thank
you.
So
thank
you
for
all
for
sending
this
comment
to
you
yeah,
so
the
in
the
next.
So
this
is
this
is
reflecting
what
we
call
the
simplified
proposal.
This
is
based
on
some
of
the
inputs
from
from
then
so
he's
basically
proposing
that
he
to
consider
the
to
make
the
the
support
of
dot,
I
would
say
mandatory,
but
for
this
one
we
we
have
an
issue
as
we
we
can
see
in
the
next
slide.
Please.
D
Is
that
this
is,
this
is
basically
updating
the
existing
rfcs
and
it's
it's
really
where
to
to
require
to
monitor
some
capabilities
on
the
tank
that
we
are
trying
to
to
discover
and
they,
and
we
think
that
this
is.
This-
is
not
an
option
for
us
and
and
also
this
is
this
is
beyond
the
the
working
group
charter.
D
B
Yeah
and
yeah,
med
and
theory,
would
you
like
to
address
that
yeah.
E
Yeah
I
mean,
if
you're
taking
the
direction
of
putting
the
svcp
parameters
in
the
dhcp.
I
think
rest
of
the
slides
are
basically
discussing
if
you
have
to
mandate
dot
based
on
what
we
were
discussing
in
the
mailing
list
yesterday,
but
they're
no
longer
relevant
for
the
discussion.
So
I
think,
if
there's
consistency
to
pick
that
approach,
we
can
update
the
draft
and
post
revision.
A
So
so
I
so
let
me
jump
in
here.
I
think
the
step
here
forward
is
take
this
to
the
list,
whatever
you
think
your,
whatever
consensus,
you
think
you've
sort
of
heard
here
to
our
med
post
it
to
the
list.
Let
the
list
discuss
it.
Let's
get
to
the
point
where
everybody
is
sort
of
understanding
what
the
proposal
is
at
this
current
state
after
this
discussion
just
took
place,
and
then
we
can
also
reevaluate
where
we're
all
at
okay.
I
think
that's
the
next
step
forward
from
this
discussion.
D
From
this
deck,
or
can
we
can
we
move
on
to
the
next
there's
only,
I
think
that's
where,
with
the
there
is
only
one
about
the
customization
of
the
year
tom
plays,
but
but
I
think
that's
that
will
be
covered
if
we
just
include
the
default
set
of
the
video
of
the
cpu
option.
So
I
think
we
are
done
for
this
one.
Okay,
thank.
A
You
all
right,
then,
so
we're
going
to
go
on
to
the
next
discussion
point
in
the
agenda,
which
is
dns
server,
information
with
assertion
token
who's.
Speaking
to
this
one,
dear.
E
Hello,
everyone.
Can
you
hear
me?
Yes,
yeah,
hey
thanks
next
slide,
please
yeah.
So
we
have
done
several
revisions
to
the
draft
and
we
have
received
several
comments
from
the
working
group
and
in
the
last
working
group
session,
how
we
had
presented
the
requirements
for
the
resolver
publishing
its
self
description,
and
we
have
updated
the
draft
to
align
with
district
requirements.
E
We
would
like
to
discuss
the
next
steps
for
this
draft
and
we
have
a
couple
of
issues
that
we
wanted
to
discuss
and
see
how
we
would
want
to
make
progress
next
slide.
Please.
E
This
draft
was
trying
to
publish
the
resolver
information
it
had
various
attributes.
I
mean
we
had
received
several
comments
from
the
working
group
and
the
current
list
that
you
see
is
the
one
that
had
pub
we
had
published
yesterday,
which
is
the
I
would
say,
the
minimum
set
of
requirements
that
there
was
consensus
on
that
should
be
supported
and
we
stripped
off
all
the
other
attributes.
So
that's
it's
very
clear.
E
As
you
see
it's
just
talking
about
the
dna
server
capabilities,
whether
it's
doing
doing
minimization,
it's
written
in
all
the
error
code
possible
error
codes
that
the
server
would
return.
So,
for
example,
a
client
would
know
that
hey
with
their
codes
like
blocked,
filtered
and
censored,
which
are
already
defined
in
rfc8914,
it
would
know
that
the
server
is
performing
filtering
client
auth
is
for
basically
identifying.
E
If
the
server
can
do
client
authentication,
we
have
changed
the
way
the
resolver
information
would
be
provided
and
based
on
the
comments
that
we
received
from
tommy,
it's
changed
to
a
simple
generic,
unstructured
resolver
information
which
would
provide
probably
the
aps
being
used
by
the
duh
server.
What
kind
of
templates
it
supports?
Any
contact
information
in
case
if
the
server
is
not
reachable
or
it's
very
slow,
so
it's
mostly
for
troubleshooting
and
other
purposes.
E
E
E
So
there's
one
question
right:
how
do
you
convey
the
result
of
information,
so
the
draft
has
been
always
relying
on
res
info
resource
record
type
for
zero
five
version,
but
then
we
saw
that
that
draft
was
so
even
though
it
was
adapted
in
dns
of
working
group.
It
got
expired
and
we
don't
see
any
progress
happening
on
that.
E
Then
we
were
thinking
of
looking
into
svcp
resource
record
types,
but
that
doesn't
suit
like
the
right
resource
record
type,
but
because
it's
supposed
to
just
give
the
alternate
equivalent
services
point
to
them
and
that's
the
discussion
we
are
having
with
ben
and
now
the
issue
that
we
have
now
is
hey
is:
do
you
want
to
revive
that
resin
photograph
or
we
can
just
add
a
very
similar
resource
record
type
within
this
route,
which
just
supposed
to
publish
the
information
in
json
format,
and
we
make
progress
of
it.
H
B
H
That's
what
this
is
right.
This
is
this
is
like
version.bind.
This
is
server
debugging
info
that
is
designed
to
be
more
or
less
human
readable.
Just
you
know.
So
we
have
a
pattern
for
that,
but
I
assume
everybody
will
hate
that
so
leaving
that
aside,
I
I
do
support.
B
No
one
else,
so,
let's
move
on
to
the
next
slide.
Please.
E
Yeah
thanks
thanks
for
that.
Another
issue
was
the
resolver
assistant
information
I
mean
yeah,
I
mean
we
had
quite
discussed.
Why
do
you
need
that?
And
what
are
the
advantages?
It's
basically
talking
about
cryptographic,
assertions
that
would
be
provided,
along
with
the
resolve
of
information
for
the
client
to
validate
whether
it's
this
is
always
actually
hosted
by
and
legitimate
organization.
E
If
some
legitimate
organization
had
done
any
audit
on
this
dns
server
for
it
to
know
that
hey,
it's
not
being
host
by
an
attacker,
so
ben
had
suggested
that
keep
this
draft
simple
and
keep
this
resolver
assistant
token
separate,
so
that
we
can
discuss
the
need
for
it
and
what
kind
of
threats
it
addresses
and
what
what
sort
of
scenarios
it
is
required
and
whether
there
are
other
mechanisms
where
we
can
do
this
out
of
band
without
having
to
embed
it
within
the
within
a
jwt
right.
E
So
that's
a
question
again
back
to
the
working
group.
If
the
working
group
wants
this
graph
to
just
specifically
stick
to
the
resolve
information
that
we
just
saw
and
take
this
out
of
the
draft
and
discuss
it
and
probably
debate
if
this
is
something
that
we
want
to
solve,
or
is
this
the
right
way
to
solve
it
and
are
there
any
better
ways
of
doing
it?.
M
Yeah
hi
tierra
just
a
a
stupid
little
thing,
but
can
you
please
everybody's
going
to
get
confused
with
rat
because
of
rats
and
remote
attestation,
and
it's
really
these
areas
are
really
close,
just
like
something
else,
sorry
to
take
the
working
groups
time
with
this,
but
you
know
it's
hard
enough
to
read
this
stuff
without
getting
lost
in
acronyms
it.
It
is
no
need
for
a
policy.
E
C
E
A
So
so
so
my
suggestion
here
is,
I
think,
in
order
to
us
track
this
and
manage
it.
I
think
a
separate
draft
would
be
the
the
right
path
here.
If,
if
the
group
makes
the
decision,
we
can
always
fold
it
back
in
into
the
the
main
work,
but
I
think
a
separate
draft
would
allow
us
to
track
and
discuss
it
more
effectively,
so
sure
for
what
it's
worth
for
mature
view.
E
A
E
On,
I
think
that's
about
it,
I
I
think
probably
it's
too
early
called
for
working
competition
based
on
this,
because
we
have
work
to
do
and
we'll
probably
show
you
guys
draft
split
this
draft
into
two
and
then
we'll
take
it
to
the
list
so
yeah.
Thanks
for
all
the
comments
and
looking
forward
for
further
comments
after
we
posted
the
questions.
A
Okay,
thank
you
so
we're
at
4
46
here
46
minutes,
14
minutes
a
hour.
Do
we
want
to
take
a
short
break
now,
since
it's
the
natural
sort
of
place
or
do
we
want
to
trudge
on
with
the
next
draft.
E
Yeah,
I
I
will
speak
I'll
speak
to
this
one
as
well,
so
we
just
published
this
a
few
weeks
back
and-
and
there
was
tremendous
response
from
the
working
group
thanks
for
that
next
slide.
E
E
Yeah,
we'll
just
I'm
not
going
to
go
into
too
many
details
with
the
proposed
mechanism,
we'll
just
talk
about
the
goal,
scope
and
the
issues
so
that
we
can
discuss
more
on
the
issues
and
next
steps.
Next
slide.
E
This
is
again
what
we
had
presented
as
one
of
the
emerging
requirements
in
the
interim
working
group,
so
I'll
just
reiterate
that
without
taking
too
much
time,
that's
to
discover
local
names.
This
is
very
similar
to
what
was
done
in
the
abstract
me
working
group,
where
the
vpn
client
would
discover
the
internal
domains
and
the
other
one
was
to
discover
if
the
network
allows
splitting
its
configuration
next
slide.
E
Yeah
the
scope
was,
is
pretty
limited
to
networks
where
the
client
can
authenticate
the
identity
of
the
network,
so
it
has
some
pre-existing
relationship.
E
This
draft
is
the
scope
of
this
draft
currently
is
restricted
to
vod
devices
joining
an
enterprise
network
without
any
mdm
and
configuration
profile,
because
if
they
have
that,
then
those
secure
mechanisms
mdm
can
be
used
to
provision
the
domain
with
the
provision,
the
device
with
the
internal
domains
or
the
configuration
profile
could
be
used
to
solve
that
problem,
and
in
this
case
the
user
trusts
the
network
to
override
the
dns
settings
similar
to
the
b.
E
If
you
are
using
any
vpn
today,
you
can
disable
vpn,
let's
say
in
my
enterprise
network
or
my
home
network
next
slide.
Please.
E
E
Provisioning
domains
is
supposed
to
provide
the
dns
resolver
information,
so
it
also
gives
you
an
option
of
web
dvds,
where
the
client
would
be
provided
the
well-known
uri
of
the
http
server,
which
would
have
the
additional
information,
and
that
is
where
we
are
providing
the
internal
domains
and
to
let
the
client
know
whether
they're
private,
only
or
they're
public,
but
because
you're
attached
to
the
network,
you
get
to
see
a
different
version
of
the
content.
E
Yeah,
this
is
a
very
simple
format,
example
that
we
picked.
The
first
three
are
already
defined
in
the
pvd
web,
pvd
rfc.
So
the
this
draft
is
just
talking
about
the
domain
names
and
to
say
whether
they
are
really
internal
or
they
are
not
internal,
but
they
you
get
to
see
a
different
view
of
the
content,
because
you
are
attached
to
that
specific
network.
E
Yeah
the
this,
this
specific
issue
had
a
lot
of
discussion
in
the
working
group
that
how
does
the
client
know
that
the
network
is
not
lying
right?
I
mean
it
needs
to
know
that,
so
the
the
network
doesn't
want
to.
E
And
look
into
the
dns
request
responses
to
see
what
the
client
is
doing.
So
what
would
be
the
best
way
for
the
client
to
know
that
the
server
is
not
lying,
so
this
was
a
suggestion
that
came
from
ben.
E
I
have
already
posted
in
revised
draft
to
say
that
the
the
easiest
way
for
it
to
do
is
if
it
has
a
pre-configured
resolver,
then
just
to
insect
three
n63
is
the
most
recommended
way
of
getting
an
authenticated
response
to
say
that
the
domains
doesn't
exist
and
if
indeed
the
response
is
insecurity,
then
it
proves
that
the
domains
don't
exist
and
the
network
is
not
lying
to
you.
E
The
draft
also
talks
about
a
scenario
where,
let's
imagine
if
the
public
resolver
is
not
reachable
or
the
client
has
not
pre-configured
with
a
public
resolver,
then
probably
one
possible
way
that
we
saw
the
ike
split
dns
draft
was
talking
about,
is
to
pre-configure
top
weld-on
domains
and
dles,
which
needs
to
be
constantly
updated
to
see.
E
If
the
server
is
lying,
it's
not
a
foolproof
technique,
but
it
can
be
possibly
used
by
an
implementation
in
case
if
the
resolver
is
not
available
or
it
could
just
hard
fail
and
decide
that
hey
since
somebody's
blocking
that-
and
I
can't
validate
that
I'll-
just
hard
fail
and
not
do
anything.
So
the
draft
is
leaving
those
options
open
so
that
the
working
group
can
give
us
more
feedback.
E
A
So
question
yeah:
I
have
one
question,
so
are
you
considering
the
two
scenarios
where
or
actually
I
see
three
scenarios
here?
One
is
the
the
domain
does
truly
does
not
exist
in
the
global
dns,
and
so
of
course
that
will
be
testable
and
fail,
but
you
could
have
a
situation
where
somebody
publishes
a
non-signed
version
of
that
domain
in
order
to
try
to
hack
the
the
private,
the
private
hosted
domain
network,
and
so
you
put
a
lot
of
dependency
down
on
the
environment
to
be
able
to
detect
and
do
a
validation.
A
That's
case
number
two
case.
Number
three
is
the
the
owner
of
that
domain
has
both
an
internal
and
external
versions
of
it,
but
those
two
different
versions
are
not
aligned
in
in
their
record
sets.
E
Yeah,
so
to
answer
that
question
right
I
mean
we
have
another
issue
where
we
talk
about
domains
which
are
public
and
you
have
a
different
view.
So
that's
a
different
topic
and
that
will
be
covered
in
a
separate
way
that
ben
had
suggested
we
had
updated
the
draft,
so
that
is
dealt
with
a
different
technique.
So
there
are
actually
two
and
three
techniques
that
we're
just
talking
about
two
techniques
here,
for
this
is
only
for
private
domains.
E
We
have
another
for
another
technique
for
public
domains
and
maybe
we'll
go
over
that,
so
that
we
can
take
more
comments
so
that
it
would
give
a
perspective
of
all
the
techniques
that
are
discussed
in
the
draft.
E
The
next
slide
yeah,
it's
the
next
slide.
Yes
yeah.
This
is
this
is
a.
This
is
something
that
we
had
discussed
in
length
and
read
during
the
working
groups
mailing
list,
so
one
technique
that
was
proposed,
which
was
very
straightforward,
was
what
happens
in
case
if
you
have
a
different
version
of
the
public
domain
in
the
attached
network.
So
in
that
case
the
client
needs
to
know
that
the
network
is
in
in
fact
claiming
authority,
and
it
is
indeed
the
owner
of
that
sort
right.
E
So
the
technique
that
we
are
aware
updated.
The
draft
is
to
say
that
the
client
just
does
in
ns
query
lookup
to
get
the
name
servers
to
see
that
if
the
name
servers
match
the
adn
of
the
discovered
network
provided
resolver,
then
it
pretty
much
sure
that
hey
the
network
is
actually
he's
claiming
authority
of
the
domain
and
and
the
ns
response
record
is
proving
that
and
then
what
the
client
can
do
is
authenticate.
The
network
provided
resolver
as
usual,
using
the.
E
H
Hi,
so
thanks
a
lot
for
making
all
these
changes,
I
I
really
at
a
technical
level.
I
really
like
this
version
of
the
draft.
I
think
it
it
maintains
it
does
something
new.
I
think
it
achieves
a
a
version
of
split
dns
that
maintains
a
new
interesting
security
invariant.
I
really
appreciate
that.
H
The
thing
that
I'm
missing
here
is-
and
that
I
think
we
should
ask
for
here,
is
whether
there's
essentially
client-side
implementer
interest.
You
know.
Are
there?
Is
there
anybody
who
who
who
implements
a
client
whose
behavior
would
actually
be
affected
by
this,
that
that
is
interested
in
supporting
it
because
most
clients,
the
simple
clients,
are
don't
need
this?
F
I
agree
that
for
the
default
status
quo
cases
you
know
people
are
either
using
the
default
network,
resolver
or
they're,
using
something
that
they've
hard
coded
to
override
that,
but
on
the
client
I
would
like
to
move
to
scenarios
where
we
can
have
a
more
private
and
stance
by
default
for
certain
categories
of
traffic
that
doesn't
necessarily
use
anything
that
the
network
provides,
unless
we
can
prove
that
the
network
is
authoritative
for
something
and
essentially
the
the
model
that
you
have.
F
If
you
don't
have
a
secure
way
to
validate
that
a
network
does
have
access
to
some
private
domain.
Is
that
you
try
over
some
other
mechanism?
You
realize
it
doesn't
exist
there,
and
then
you
fall
back
to
going
locally,
which
works
but
is
inefficient,
so
this
would
be
or
something
solving
this
area
not
just
for
dns,
but
saying
that
this
network
has
kind
of
special
authority
over
a
given
domain
would
be
a
useful
thing
on
our
client.
B
Thank
you
before
we
move
on
the
feedback
that
I'm
hearing
is
that
tyro
is
on
the
right
track
with
all
of
this.
If
somebody
has
pushed
back
on
that,
now
would
be
the
time
to
jump
in
and
let
us
know.
E
Yeah
yeah,
I
I
think
we
have
addressed
so
far
all
the
comments
that
we
have
received
and
we
would
write
more
feedback.
Maybe
after
that
we
can,
if
there's
really
I've
seen
interest
in
the
from
the
working
group
so
very
very
best
for
working
with
adaption
of
the
draft.
A
Well,
it
seems,
like
we've
reached
a
happy
place
for
a
five-minute
break
in
order,
so
everybody
that
would
be
three
minutes
after
the
hour
so
come
on
back.
Let's,
let's
give
you
if
I
give
you
two
five
minutes
after
that,
we're
sorry.
A
A
All
right
moving
on
the
next
one
is.
A
Hang
on
here,
oh
wow,
my
gosh,
okay,
back
to
the
agenda,
so
we
are
now
moving
to
the
open
microphone
section
of
the
the
show
and
for
those
who
do
not
have
comments
for
the
the
microphone.
I
I
offer
you
this
fun
happy
cat
to
stare
at
for
the
next
few
minutes.
While
we
have
a
barrage
of.
A
Conversations
so
this
is
open
mic.
You
can
talk
about
any
topic
around
edd.
This
is
you
know.
Usually
this
crowd
is
not
very
shy.
So
I
imagine
we're
gonna
have
some
good
conversations.
O
Somebody
has
to
be
first,
I
mean,
I
think,
it's
really
encouraging
to
see
that
we're
potentially
getting
to
the
point
where
we've
got
solutions
around
both
split
dns
and
so
the
private
ip
address.
Dns
forwarder
use
cases,
because,
if
we're
going
to
get
to
the
to
solve
the
85
problem
that
eric
auth
highlighted
via
one
of
his
colleagues
at
the
virtual
interim,
it's
incredibly
important.
We've
got
solutions
for
both
of
those.
O
So
it
feels
like
we're
on
the
cusp
of
making
good
progress
in
both
those
areas
which
is
encouraging.
B
B
E
I
saw
the
proposal
from
the
issue
that
ben
had
raised
for
the
air
draft
with
regard
to
using
the
specially
assigned
domain
name
and
how
it's
possible
to
do
both
authenticated
discovery
and
opportunistic
discovery
for
cases
where
there
is
a
legacy
router
whose
firmware
cannot
be
updated.
This
is
where
probably
its
firmware
can
be
updated,
but
just
to
update
the
dhcp
server
configuration
where
and
the
cases
were,
a
scenario
where
the
router
is
doing
dns
filtering.
In
that
case,
what
would
be
the
fallback
mechanism?
E
So
I
I
think
that
that
changes
that
here
proposed
should
address
the
cases
of
all
the
you
know:
legacy
router
scenarios.
So
I
I
think
I
think
I
think,
having
more
discussion
on
that
at
making
progress
and
probably
either
adding
that
to
the
ddr
draft
or
separate
draft
would
make
a
quick
progress
on
that,
because
that's
looked
like
an
a
straightforward
proposal
to
me.
B
B
B
A
So
let
me
bring
up
one
point
that
I
I
that
I
know
has
been
some
side
conversations
you
went
on
about
based
upon
comments
from
session
number
one,
and
that
is
around
the
rfc
1918
cp
devices
places
using
ecg
nav
stuff,
like
that
and
the
ability
for
some
of
the
proposed
approaches
to
work
and
support
that
environment.
So
this
is
primarily,
you
know.
It
seems
like
a
lot
of
european
isps,
have
their
cps
defined
in
this
way.
It's
present
in
mobile
devices
mobile
some
mobile
setups.
B
Up
yeah
tara,
please.
E
Yeah,
so
so
I
I
can
talk
it
from
doctor
from
my
company's
perspective.
What
we
do
right,
I
mean
we
offer
both
enterprise
and
consumer
security
services,
network
services
and
one
of
the
one
that
we
offer
for
consumer
network
security
is
offering
network
security
services
on
home
routers.
So
we
deploy
our
network
security
services
on
both
managed
and
managed
devices,
and
because
we
are
running
a
network
security
service
there.
E
These
routers
are
quite
easily
upgradable
because
we
have
to
keep
upgrading
the
stack
to
address
new
vulnerabilities,
getting
new
signatures
so
that
we
can
handle
new
threats.
So
that's
the
reason.
One
of
the
interest
is
for
us
to
host
at
ot
forwarder
on
the
home
router,
so
that
we
can
still
enforce
security
policies
either
it
could
be
anomaly,
detection
or
it
could
be
filtering.
E
Any
managers,
domains
or
enforcing
mud
policies
is
of
great
interest
to
that
and
we
just
shipped
our
product
doing
that.
So
so
that's
the
reason.
I
see
that
we
see
both
the
scenarios
where
there
are
routers
which
are
upgradable,
but
we
also
see
some
combination
from
isps
where
there
are
legacy
routers
and
whose
firmware
cannot
be
updated
and
we
don't
give
any
security
services
other
than
relying
on
the
isp
to
do
some
security
protection.
E
In
that
case,
which
is
probably
at
a
home
network
level
and
not
at
a
device
specific
level,
especially
for
iot
devices,.
K
Thanks
david,
I
agree
with
what
glenn
was
saying
that
the
case
and
the
use
cases
around
things
to
do
with
rc,
1980
nets
and
cgnat
is
something
this
working
group
can
look
at.
I'm
not
sure
we
can
do
much
of
a
discussion
about
it
here
and
now,
because
I
think
the
first
thing
we'll
need
to
do
well.
One
of
the
things
we're
going
to
have
to
do
is
have
a
draft
that
talks
to
these
particular
concerns
and
to
some
try
and
crystallize
some
of
the
major
issues
around
it.
K
I
think
another
thing
that
needs
to
be
done
in
that
area
is
more
engagement
and
involvement
from
the
operators
of
those
kind
of
networks,
also
maybe
some
enterprise
networks
as
well,
and
because
I
think,
if
we
try
to
second
guess,
what's
going
in
there
between
sambas
will
have
some
insights
into
this.
But
if
we
try
to
second
guess
how
things
are
done
in
those
settings,
the
chances
are
we'll
make
mistakes,
and
that
would
not
be
good,
so
yeah.
I
think
this
is
a
work
item
for
further
considerations
at
some
point
for
the
working
group.
K
I'm
not
sure
we
can
do
much
of
a
discussion
right
now
in
this
open
mic
session,
something
else
just
changing
the
subject
slightly
quick
I'll
just
mention
while
here
is,
I'm
certainly
suffering
from
a
bit
of
confusion
about
the
number
of
documents.
I've
gotten
where
the
status
is
just
down,
what
needs
to
be
done
to
progress
them,
and
maybe
I'll
delegate
this
upload
to
steam's
working
group
chairs,
and
maybe
they
can
post
a
summary
to
the
list.
K
I
mean
it'd,
be
a
good
idea
to
know
as
to
what
we
think
when
documents
might
be
in
a
position
to
already
be
considered
safe
for
working
group
adoption
or
to
be
progressing,
maybe
say
for
discussion
at
the
next
meeting
that
I
think
will
be
very
quiet.
That
would
be
very
helpful,
particularly
because
the
discussion
we've
just
had
them
a
little
bit
confused
about
the
status
of
some
of
the
drafts.
Thanks.
O
I
Regarding
the
1918
private
address
issue,
I
think
it
was
interesting
ben.
We
talked
about
this
on
tuesday
ben
mentioned
that
he'd
he
had
a
fpr
and
he's
moved
that
into
the
into
the
ddr
repo.
I
I
I'm
very
supportive
of
that.
I
I'd
really
be
interested
to
see
if
the
the
authors
can
incorporate
that
or
something
like
that
in
the
in
the
next
version
of
the
draft,
because
it
I
think
that
really
that
really
addresses
the
the
issues
around
private
id
addresses
and
legacy
cpes
which,
as
we
said,
if
they're
not
currently
in
the
draft.
F
Hello
just
to
respond
to
that.
I
I
totally
agree
that
addressing
that
case
is
very
important
and
I
think
we
do
want
to
merge
something
in
around
that.
F
Personally,
I
think,
if
you
look
at
the
discussion
there,
I
I
think,
there's
I
have
a
bit
of
concern
around.
You
know
mandating
a
five-minute
retry
timer
on
all
clients,
so
I
think
the
particular
mechanism
needs
more
discussion
and
input
from
the
group.
So
I
would
ask
that
people
do
look
at
that
proposal
and
try
to
think
about
different
ways.
We
can
solve
that
problem.
A
So
from
from
the
chairs
here
ben,
I
see
you're
up
next
in
the
queue
since
you
were.
I
was
going
to
make
a
suggestion
that,
since
you
are
the
one
that
submitted
the
pull
request
and
in
the
fact
that
we
do
want
to
have
primary
discussion,
go
on
on
the
list
and
not
just
over
in
the
world
of
github,
would
it
be
possible
for
you
to
maybe
post
to
the
list
a
a
pointer
to
that
pr
and
and
some
pros
around
it.
H
So
I
I
did
yesterday,
I
believe,
send
send
the
link
to
the
list
and
sent
maybe
a
one
sentence
summary.
H
I
can
certainly
expand
on
that,
a
little
more,
the
as,
as
tommy
pointed
out,
there's
a
you
know,
probably
the
most
well,
there's
a
few,
a
few
different
aspects
of
this
proposal
that
aren't
entirely
trivial
and
one
of
them
is
this
question
of
you
know:
what
does
it
mean
to
to
get
an
authentication
anchor
from
an
untrusted
source?
H
So
you
get
a
reference
identity,
a
the
name
of
a
resolver,
something
you
can
validate,
but
you
get
it
from
a
dns
server
operating
on
a
private
ip
address,
and
so
you
have
no
particular
security
mechanism
there,
except
that
whoever
is
operating
that
dns
server.
If
you
don't
upgrade
to
encrypted
dns
will
still
see
all
of
your
queries
and
so
then
there's
this
question
of
what
is
it?
You
know
what
does
it
mean
to
do
that
upgrade
securely,
and
I
think
the
answer
is
the
the
upgrade
is
is
secure.
H
H
If
there's
a
transient
attacker,
then
you
have
to
be
careful
not
to
give
them
permanent
access
when
maybe
they
would
have
disappeared
after
a
few
minutes
and
and
then
you
would
have
been
back
in
a
secure
state,
so
I
set
this.
I
just
typed
in
this
arbitrary,
originally
requirement
now
downgraded
to
should
level
recommendation
that
says
you
should
just
repeat
this
process
every
five
minutes,
so
if
there's
an
attacker,
they
can
only
who
can
briefly
redirect
you
to
an
encrypted
server.
E
To
respond
to
ben
right
I
mean,
and
typically
what
I
have
seen
is
this
there's
more
of
a
chances
that
there
is
a
transient
attacker,
who's,
probably
hosting
an
evil
twin
or
there's
a
device
which
is
compromised
rather
than
an
attacker,
which
is
which
is
always
persistent,
in
which
case
there's
nothing
to
do
so.
I
think
handling
the
case
of
either
picking
an
timer
which
is
random
or
basically
having
trust
on
first
use,
where
you
pin
the
information
and
you
next
time
come
in
and
you
change
see
a
change.
E
Then
you
have
some
suspicion,
so
there
could
be
various
ways
where
you
could
identify
that
transit
and
I
think,
that's
far
more
important
case
than
probably
a
very
less
scenario
where
an
attacker
has
taken
over
the
network
and
is
always
there
to
snoop
your
dns
traffic.
B
Thank
you,
cheerio
jim
marine.
Please.
K
It's
ben
made
a
very
good
point
there
about
the
differentiation
between
transient
and
persistent
attackers,
and
I
wonder
how
we
can
address
that
in
our
documents.
Is
this
something
we
have
to
think
about
more
generally
or
do
we
incorporate
that
into
the
security
considerations
of
the
internet
drafts
and
rfcs
that
we
produce?
K
Maybe
after
says
this
particular
threat
or
security
security?
Defense
mechanism
will
be
reasonable.
O
A
F
Please
yeah
I
mean
just
to
that
point
yeah.
I
agree
that
these
type
of
considerations
belong
in
smaller
documents
or
in
the
existing
documents.
I
think
this
particular
point
we
were
talking
about.
Probably
just
does
belong
in
the
security
considerations
or
something
as
part
of
ddr
and
then
the
reason
I
got
in
queue.
F
I
was
looking
at
the
pr,
and
so
when
we're
talking
about
transient
attacker
case,
you
know
what
we're
trying
to
do
by
reconfirming
this
discovery
process
is
make
sure
that
we
didn't
get
tricked
on
the
first
time
when
we
learn
about
this
encrypted
resolver.
Maybe
it's
an
evil
encrypted
resolver,
and
so
we
keep
trying
to
reconfirm
it,
presumably
again
using
that
unsecured
path.
F
What
stops
the
transient
attacker
from
then
blocking
the
message
later,
because
the
pr
currently
says
you
know
we
should
repeat
the
process
and
confirm
if
it's
still
valid
and
we
must
stop
using
the
encrypted
resolver
if
it's
no
longer
designated.
So
this
allows
essentially
any
attacker
to
just
drop
one
of
the
discovery
responses
and
get
the
clients
to
tear
down
their
encrypted
channels.
F
So
I
think
it'd
be
great
to
have
something
where
we
can
eventually
ratchet
up
to
a
level
of
security
where
we
do
not
fall
back
down.
I
don't
know
what
the
answer
for
that
is,
but
I'm
a
bit
concerned
about
that
attack
I
see
ben
is
in
the
queue.
So
let's
talk
about
it.
H
Sure,
but
as
a
matter
of
threat
modeling,
I
I
have
assumed
that
any
adversary
who
is
capable
of
of
selectively
dropping
packets
on
the
network
is
also
capable
of
injecting
packets
and
therefore
they
are
the
the
your
the
attacker
you
described
is
the
persistent
attacker
is
that
the
oh.
H
F
Right
the
concern
that,
like
that,
could
also
happen
by
accident,
I
could
end
up
not
getting
the
response,
because
there's
packet
loss
or
some
other
thing
and.
H
Sure,
right
I
mean
you
know,
dns
does
have
retry
it
doesn't.
You
know
it
doesn't
just
try
once
and
fail,
but
but
that's
a
that's
a
certainly
a
point,
a
reasonable
point
you
could
have.
You
could
have
a
20
second
outage.
H
B
H
Sure
I
mean
I,
I
do
think
that
the
I
do
think
that
the
text
attempts
attempts
to
do
that.
I
I
guess
I
you
know
I
would.
If
people
want
more
detail,
I
would
encourage
them
to
to
review
the
text
specifically
and
and
if
they
think,
there's
a
missing
element
there
then
we
can
certainly
add
it
on
the
topic
of
ratcheting
up.
I
guess
there's
an
interesting
sort
of
broader
use.
Case
question
here:
you
know,
can
you
imagine
connecting
to
a
network
and
at
some
point
you
know
surfacing
to
the
user?
C
H
Use
verizon
fios,
secure
dns
when
you're
on
this
network,
and
then
you
know
user
enables
and
now
you're
you're,
somehow
how
locked
in
into
a
more
secure
configuration.
I
hadn't
hadn't
really
considered
that
use
case.
F
Yep
that
was
me
deco,
I
was
just
gonna
say
we
do
have
examples
of
implementations
that
have
lists
of
resolvers,
that
they
trust
or
have
used
previously,
and
maybe
those
ones
are
opportunities
to
be
a
bit
more
sticky.
M
Hi
there,
okay,
so
two
points.
M
First,
I
like
the
idea
of
ratcheting
up
but,
as
that
sounds
like
a
draft
into
itself
which
somebody
could
write
and
when
they
do
write
it,
it
would
be
useful
to
look
at
two
different
use
cases:
the
ratcheting
up
where
there
is
a
common
user
interface,
your
your
phone
or
your
laptop
and
the
more
in
the
and
the
iot
use
case
where,
if
it's
a
wearable
or
something
like
that,
where
it
doesn't
really
have
a
convenient
user
interface,
what
would
be
the
recommendations
there?
M
The
second
point
I
have
is,
I
think
these
conversations
in
open
mic
would
really
do
better
in
having
been
prepared
for
on
the
agenda,
so
that
everybody,
because.
M
B
Yes,
I'll
observe
in
part
that
ecker
also
was
kind
of
dual
booked
for
meetings
during
this
session
and
he's
in
the
queue.
But
before
we
move
on,
I
want
to
address
that
specific
comment.
We
had
anticipated
that
some
of
the
earlier
discussion
was
going
to
take
longer
and
that
we
wouldn't
be
filling
a
full
hour
of
open
mic
time.
B
I
do
agree
with
you
that
we're
probably
not
focused
enough
on
this
and
we
might
be
heading
toward
giving
you
back
some
time
before
the
end
of
the
session,
but
now
that
ecker
is
back.
We
certainly
want
to
hear
his
comments.
G
Well,
thank
you.
I
guess
I
I'm
I'm
I'm
personally
a
little
skeptical
of
the
you
know
the
the
you're
on
a
you
know,
network
of
this
type.
You
always
want
to
do
this
in
the
future
that
we
found.
G
We
found
attempting
to
determine
what
kind
of
network
people
are
on
and
then
precision
those
things
fairly
fraught
and
in
particular,
it
seems
like,
like
it's
not
quite
clear
to
me
how
that
really
works,
because
the
the
attacker
is
like
quite
likely
to
take
control
off
the
network,
to
attempt
to
impersonate
you
to
claim
you're
not
in
on
the
network
where
you've
just
ratcheted
up,
so
I'm
not
really
sure
how
that
works
so
well,
I
understand
certainly
the
desire
to
just
kind
of
tofu,
I'm
not
I'm
not.
B
B
Record,
I'm
gonna
toss
it
back
to
glenn
now
to
see
whether
he
kind
of
agrees
with
the
conclusion
that
we've
probably
done
about
all
the
useful
work
that
we
can
do
on
unprompted
here
in
the
working
group
and
we'll
probably
move
towards
the
close
of
the
agenda.
A
Yeah
that
sounds
perfect
good
morning
everybody.
So
I
think
this
is
the
most
subdued
I've
ever
seen
add.
I
think
it
may
be
a
factor
of
the
early
morning
here
on
the
west
coast.
B
P
Yeah
hi,
I
just
want
to
to
understand
why
eckerd
does
not
think
that
any
user
interaction
is
possible
or
likely
to
happen.
Is
that
a
problem
of
interface
that
are
missing
or
is
that
that
we
cannot
rely
on
the
end
user
or
yeah?
That's
basically
I'd
like
to
understand
a
little
bit
more.
What
he
thinks
why
he
thinks
those
kind
of
interactions
not
possible.
G
Sure-
and
I
can
try
again
so
as
I
understand
the
setting
is
that
I
joined
network
one
and
it's
and
and
I
discovered
that
there's
a
secure
resolver
on
network
one,
and
then
I
get
some
interface
that
says:
hey
if
you
you're
a
network
one
do
you
want
to
like
permanently
use
the
security
over
on
network
one,
and
so
I
think,
there's
several
problems
here.
G
One
is
actually
determining
which
network
on
you're
on
turns
out
to
be
like
really
kind
of
annoying
and
difficult,
and
we
struggle
with
that
a
lot,
and
so
we
have
a
lot
of
heuristics
around
it,
but
like
we'd,
be
reluctant
to
pin
on
that
until
we
can
be
absolutely
certain.
G
The
second
is
that
an
attacker
who
controls
that
network,
the
network
you
join,
seems
likely
to
be
able
to
pretend
you're,
not
on
network
one,
and
so
in
the
precise
case,
when
you're
you
know,
when
you
need
the
security,
this
is
the
attacker
will
be
able
to
downgrade
you,
so
I'm
not
sure
how
that
works
either.
So
I
mean
I'm
not
saying
this
can't
be
can't
be
done.
Q
Now
that
I've
got
my
computer
configured
to
actually
do
the
right
thing,
I'm
with
ecker
on
this
the
one
question
that
I
would
ask
that
so
daniel
commented,
you
know
so
he's
worried
about
end
user
behavior
in
at
least
50
percent
of
cases.
The
end
user
is
going
to
be
a
computer
that
is
being
accessed
by
somebody
else,
and
I
think
it's
quite
going
to
be
quite
common
to
have
the
the
user
of
the
service
be
a
computer
at
each
end
of
things
or
a
computer
process.
Q
C
Said
I.
F
Just
want
to
be
clear
that
when
I
was
describing
before
kind
of
ratcheting
up
the
security
I
I
don't
think
that
basing
this
on
any
type
of
ui
interaction
is
probably
the
right
direction.
Like
so
far.
The
only
example
I
can
think
of
where
it's
a
very
clear
case
is
that
we
should
allow
an
implementation
to
say
that
if
I
have,
you
know,
insecurely
discovered
a
particular
resolver
that
I
already
have
an
affinity
to,
and
I
trust
that
I
do
not
need
to
reprobe
every
five
minutes,
let's
say
or
allow
that
to
be
downgraded.
F
If
it
is
working
fine-
and
I
already
have
a
strong
reason
to
use
it,
so
I
think
we
can
come
up
with
other
mechanisms,
but
I
I
think
that
trying
to
dive
into
ui
here
is
a
dangerous
route.
E
So
I
think,
if
you
look
at
the
resolver
attestation
information
that
we
had
in
the
draft
it
talks
about
cryptographic,
assertions
that
would
prove
that
it's
it's
actually
hosted
by
a
legal
entity
and
that
doesn't
require
any
ui
and
the
client
can
make
a
decision
whether
it's
actually
hosted
by
an
attacker
or
legal
entity.
But
yeah.
The
legal
entity
could
itself
be
having
a
bad
privacy
policy
and
it
could
be
smoking
on
the
data,
but
it
reduces
the
threat
vectors
where
it's
very
easy
in
today's
world
for
an
attacker
to
get.
E
You
know
a
public,
ip
or
a
domain
and
just
host
a
server
and
act
as
an
evil
twin
or
compromise
one
of
the
devices
and
host
an
encrypted
dns
server.
So
it
at
least
addresses
those
kind
of
scenarios
and-
and
it
does
not
involve
any
ui,
so
it
did
work
even
for
headless
iot
devices.
A
Okay,
I
think
that's
it
okay,
everybody,
so
the
loss
that
I'll
share
before
we
let
everybody
go.
We
have
not
yet
planned
out
any
kind
of
interim
meeting
between
itf
110
and
its
111.,
so
stay
tuned.
There's
been
some
discussion,
but
at
this
point
no
plans
have
been
laid
down
so
nothing
to
announce
there
and
then
the
rest
of
it
I'll
say
as
we're.
Moving
into
the
phase
where
we
have.
We
now
have
two
working
group
documents
that
have
been
adopted
for
active
work.
A
We've
got
one
adopted
for
informational
purposes,
those
are
hosted
in
the
group's
github
repositories,
but
let's
make
an
extra
effort
because
I-
and
this
has
been
discussed
on
the
list,
but
I
wanted
to
sort
of
say
to
the
group:
let's
make
sure
we
make
a
conscious
effort
to
keep
the
discussions
active
on
the
list
and
not
just
slip,
because
it
would
be
easy
to
do
slip
into
doing
everything
over
on
github,
because
that
includes
people
and
it
doesn't
allow
for
full
participation
by
the
group,
so
just
be
conscious
of
it
and
make
an
extra
effort
to
be
extra
verbose
onto
the
list
about
this
stuff.
A
So,
thank
you
any
last
words
david
or.
A
Okay,
well
then,
good
good
day,
everybody
and
we'll
we'll
see
you
at
itf
111,
if
not
before,.