►
From YouTube: IETF116-ADD-20230330-0730
Description
ADD meeting session at IETF116
2023/03/30 0730
https://datatracker.ietf.org/meeting/116/proceedings/
A
C
Well,
I
assume
my
co-chair
is
online
and
we've
got
a
scribe
and
it's
4
30.,
and
this
I
think
is
the
last
session
of
the
day.
So
this
is
between
you
and
a
glass
of
wine.
So
keep
that
in
mind
and
I'll
how
we
ask
questions
and
how
we
have
conversations
priorities.
Okay,
so
let's
get
started
hello,
I'm,
Glenn,
Dean,
I'm,
one
of
your
co-chairs.
This
is
the
add
session.
C
C
C
C
C
B
C
C
D
So
everything
the
the
ID
for
add
amazing.
Just
to
summarize
the
next
point
right,
you
know
that
three
documents
were
stuck
in
the
queue
because
we
were
waiting
for
DNS
of
documents
that
were
waiting
for
encrypted
ech
and
encrypted
Sni,
with
the
help
of
the
nsops
and
Ryan
Kumari.
We
basically
remove
part
of
it,
so
we
need
to
redo
all
the
working
group
plus
call
that's
your
next
point
and
basically
to
release
all
those
documents
of
this
situation
that
was
blocked
since
last
August.
C
C
F
E
So,
on
the
right
side,
if
you
see
it's
it's,
we
have
the
subdomain
with
the
split
DNS
hyphen
challenge,
which
is
the
keyword
and
Then
followed
by
the
parent
domain,
and
the
token
is
having
the
Sha
of
the
384
of
the
salt,
which
is
being
generated
and
and
then
we
had
added
DNS
support,
DNS
support
for
that
as
well.
So
I
think
this
should
address
all
the
comments
that
we
have
received
so
far.
I
see.
G
A
B
A
A
We
want
to
make
sure
that,
particularly
with
these
structures
that
have
particular
lengths
having
done
similar
things
with
privacy
pass
tokens
and
stuff
and
structures,
there
can
be
a
lot
of
just
mistakes
in
implementations
by
not
reading
carefully
how
long
fields
are
supposed
to
be
and
how
things
are
supposed
to
be
hashed
Etc,
so
some
test
vectors
at
the
end
would
be
really
really
helpful.
That.
H
G
I
think
you
know,
I
I
wrote
this
text
and
I
have
some
questions
about
how
it
works.
I
would
I
would
really
love
some
input
from
folks
who
have
a
deep
understanding
of
of
dnsc
and
an
open
mind
about
making
some
interesting
changes
to
it
about
whether
this
can
work
as
as
specified
I
think
it
can,
but
I'd
like
to
get
some
more
input.
C
E
Yeah,
this
is
just
a
bunch
of
updates
that
we
did
as
part
of
addressing
the
comments
during
the
working
group.
Adoption
call
next
slide,
yeah
the
the
main
majorly.
We
got
two
comments
on
this
one
is
to
make
the
Q
name
and
URL
info
as
optional
attribute,
and
the
other
one
was
to
update
URL
info
I
think
we
have
taken
care
of
that
next
slide.
B
E
One
of
the
comments
that
we
got
was
the
URL
info
attribute
was
supposed
to
be
only
used
for
Diagnostic
information,
so
we
changed
that
to
be
should
making
it
more
normative
and
to
display
that
only
in
exceptional
cases,
if
the
encrypted
resolver
has
a
sufficient
repetition.
So
that
was
the
that
was
those
were
the
two
changes
that
we
did
to
the
draft
next
slide.
B
E
I
mean
this
draft
is
defining
the
basic
structure,
attributes
that
the
working
group
has
agreed.
We
could
add
new
attributes,
but
we
have
added
also
the
registration
policy,
which
is
specification
required
to
add
new,
more
attributes
if
there
are
any
objections
to
the
current
policy,
if
you
believe
new
attributes
to
be
added
you're.
Welcome
to
that
discussion.
E
C
C
Our
last
draft
of
the
day
we
are
making
great
progress,
so
this
next
draft
is
extended
talk
because
it's
fairly
new.
We
we've
talked
about
it
previously
out
of
the
earlier
prior
80d
session,
but
I
think
the
authors
have
made
some
extensive
work
right,
Tommy
and
so
Tommy
Jensen
from
Microsoft
is
going
to
present
Tommy
the
slides
are
up
and
ready
for
you
awesome.
Can
you
hear
me?
We.
I
I
Here
you
see
we,
the
new
text,
change
the
name
used
to
query
for
the
redirection
record,
away
from
the
sudn
that
DDR
used
to
the
name
of
the
resolver
itself.
There's
still
some
open
discussion
on
that,
but
that's
the
current
state
of
the
text.
We
added
some
guidance
on
how
to
handle
a
multitude
of
edge
cases,
redirection
chains,
multiple
redirects.
I
We
defined
how
to
determine
the
effect
of
TTL
of
a
redirection
which
really
comes
down
to
the
minimum
along
the
path
that
you
travel
added,
TLS
minimum
version
as
one
example
of
a
compat
requirement.
So
we
had
always
required
that,
if
you're
a
dozer
or
redirecting
to
another
server,
it
needs
to
at
least
support
doe
or
whatever
else
the
client
currently
had.
So
you
don't
send
them
somewhere.
They
may
not
be
compatible
with
TL's
minimum
version
same
thing.
I
I
So,
generally,
it's
not
a
good
idea
to
go,
creating
redirection
Loops
or
redirect
a
lot
novel
concept.
We
added
some
text
to
elaborate
on
that.
Self-Redirection
was
defined
as
based
on
name.
So,
if
you
refer
to
yourself
in
the
same
name
as
the
connection,
that's
a
self
redirection
and
we're
done
again.
Ben
pointed
out
on
the
list
that
we
can
get
the
best
of
both
worlds.
I
If
we
just
say
you
can
redirect
to
another
IP
of
the
same
name
if
the
client,
if
the
server
provides
a
set
of
ips,
that
don't
include
the
one
that
the
client's
currently
communicating
on
this
seems
reasonable,
but
this
is
the
current
state
of
the
text
so
I,
but
I
think
that's
reasonable
next
slide.
Please!
Thank
you.
I
Oh
in
one
point
I
did
forget
on
that.
One
is
when
you
self
advertise.
You
could
also
advertise
more
config
that
the
client
may
not
know
about
so
comparison
with
HTTP,
3
or
HTTP
redirects,
and
all
service
work
going
on
elsewhere.
So
alt
service
B,
which
actually
was
just
mentioned
a
couple
minutes
ago,
focuses
on
pre-connection
time
a
query
time
what
a
names
properties
are,
whereas
this
is
definitely
associated
with
a
connection,
because
the
server
wants
to
see
the
client
before
making
that
decision.
I
I
J
I
Right,
no,
that
that's
a
good
distinguisher
so
and
then
the
header
of
course
brings
us
into
that
scenario
of
well
now
we're
talking
dough
specific
and
we
want
to
address
the
problem
for
all
encrypted
all
TLS
based
encrypted
DNS
protocols,
but
yes,
you're,
absolutely
right,
two
different
forms
of
all
service.
Thank
you.
C
G
I
Why
are
we
redirecting
to
other
names
in
the
first
place
and
the
primary
scenario
that
we've
been
discussing
and
I
welcome
my
co-authors
to
speak
up?
If
other
details
come
up,
but
in
a
scenario
where
you're
using
this
to
replace
any
cast,
you
would
want
the
server
that
you're
configuring
widely
to
have
access
to
a
key
that
you
may
not
want
all
of
your
distributed
servers
to
have
that
way.
I
If
they
each
have
their
own
Keys
If
one
is
compromised,
it
can
be
revoked,
redirections
can
be
revoked,
but
the
main
server
is
not
compromised
containerized,
which
means
that
we
need
to
find
a
way
somehow
to
allow
one
server
to
redirect
to
another
where
the
name
ends
up.
Changing
Target
name
is
not
the
right
field.
I
I
Upstream
we've
been
talking
through
how
to
solve
that,
and
this
is
definitely
where
we'll
go
open
queue
for
ideas,
but
a
couple
we've
been
thinking
about
include
having
shared
search
between
the
servers,
which
has
its
own
limitations
or
having
the
client
do
something
like
full,
DNS,
SEC
validation
of
these
redirection
records,
which,
as
a
sub-resolver,
has
its
own
costs,
but
is
a
potential
solution.
So
with
that
said,
fire
away.
G
Hi
so
yeah
I
want
to
say,
I,
I,
understand
and
appreciate
the
idea
of
having
a
a
potentially
high
value
Global
certificate
that
you
don't
necessarily
want
to
plant
private
keys
for
inside.
All
of
the
all
of
the
various
geospecific
servers
that
you're
trying
to
redirect
to
you
know
that
that
seems
like
certainly
an
understandable
desire
here.
G
F
J
G
I
G
Yeah
I
so
overall,
my
my
view
is
that
there's
kind
of
a
a
simple,
safe
thing
to
do,
which
is
to
just
not
change
the
authentication
name
and
require
all
instances
of
the
service
to
prove
the
same
identity
and
to
me
it
seems
like
we
ought
to
solve
that
case,
because
it,
its
security
properties,
are
a
lot
simpler
and
clearer.
And
then,
if
we
still
need
this,
you
know
if
we
still
need
this
sort
of
more
aggressive
Mobility,
where
we
we
need
the
ability
to
redirect
users
to
some
other
service.
G
That
is
for
TLS
purpose
is
not
the
same
service
as
the
one
you
started
with.
Then
then
we
can
sort
of
come
back
to
the
design
and
think
harder
about
the
security
implications
of
that.
That
would
be
to
me
sort
of
the
easiest
way
to
to
do
this
because
there
are,
there
are
other
Alternatives
right
like
there
are
a
lot
of
systems
out
there
that
backhaul
the
handshake
to
a
a
secure
data
center.
G
So
if
you
have
so
maybe
you
have
a
box
that
you
don't
want
to
be
holding
the
private
keys
for
some
name,
but
but
that's
okay.
It
can
still
terminate
those
connections
by
holding
just
the
just
the
TLs
session
keys
for
those
sessions,
while
the
private
keys
for
that
certificate
are
held
in
a
data
center
that
that
adds
a
little
bit
of
latency
to
the
handshake.
But
but
then
the
rest
of
the
connections
are
fast
and
local.
L
L
Trusted
sphere
distribute
the
the
work
of
the
we
know
we've
seen
in
conversations,
although
I
can
put
words
in
the
mouth
of
anybody
implementing
this,
but
in
places
like
DNS
for
EU,
where
there's
an
interest
in
how
is
how
is
the
regional
trust
model
created,
or
at
least
that
was
in
the
part
of
the
initial
conversations,
whether
I
go
without
a
knowledge
of
no
but
where
one
company
can
actually
redirect
inside
to
another
company
by
basically
choosing
a
redirection,
the
model
initially
was
considering.
How
do
you
do
shared
anycast?
L
It's
going
to
be
impossible
to
share
certain
data,
but
it
is
possible
to
do
redirection,
so
I
agree
with
you
that
that
the
simplest
way
that
would
need
to
have
shared
identity
across
all
instances-
and
maybe
that's
something
we
have
to
think
about
as
maybe
there
are
two
different
models
here:
there's
the
simplistic
model
where
we
have
a
shared
identity
and
then
there's
a
second
or
a
different
version
of
this,
which
allows
transfer
across
domains
or
across
certs
in
some
fashion.
So
that's
definitely
worth
thinking
about.
H
H
G
The
handshake
is,
is
the
the
diffie-hellman
handshake
happens
to
some
Central
facility,
a
session
key,
a
diffie-hellman
output
is
generated,
and
that
is
moved
to
the
box.
That's
terminating
the
session
that
I
think
is
not
helpful
for
the
problem
space
that
Corey
I
think
was
just
telling
us
about
so
I
just
want
us
to
think
about
the
broader
picture.
Here
you
know
one
thing
that
that
seems
like
another
sort
of
category
of
architectures
to
consider
is
like.
G
Maybe
these
really
are
separate
problems,
and
you
know
maybe
this
this
question
of
of
having
lots
of
different
logical
services
that
you're
connecting
to.
Maybe
that
actually
looks
more
like
a
different,
add
Charter
item,
where
we've
talked
about
resolver
selection,
providing
information
to
the
user
so
that
they
can
choose
between
different
resolvers,
so
I
think
it
might
be
helpful
to
draw
a
clearer
line
between
the
thing
that
is
analogous
to
an
HTTP
300
reader
act
and
the
thing
that
is
analogous
to
http
alt
service.
H
M
M
Examples
number
one
is
obviously
you
know
the
Akamai
model,
where
you
want
your
okay,
sharing
your
certificate
to
maybe
large-scale
infrastructure,
that's
present
in
protected
environments,
but
the
problem
is
when
you
you
do
cross
into
those
unprotected
geopolitical.
You
know
danger
zones
where
you
do
not
want
to
share
your
certificates.
M
There
are
a
couple
of
different
approaches
we
can
take
here,
and
one
of
the
ones
we've
talked
about
internally
is
essentially
forcing
a
redirection
chain
to
follow
the
TLs
a
certificate
you
know
chain
model
so,
for
instance,
server
one,
the
very
first
server
you're
talking
to
is
going
to
have.
You
know
a
certificate
in
this
case
dns.quadline.net
server.
Two
then
also
has
to
have
dns.quadline.net,
which
follows
the
same
logic
as
the
is
required
inside
of
the
service
B
approach.
M
But
then
what
you
would
do
is
we
could
potentially
say
server
two
and
then
server
3,
you
know
being
the
final
redirect.
The
the
the
final
intended
server
would
actually
then
share
a
certificate
so
server,
so
the
certificate
on
server
one
would
be
present
on
server
one
and
server
two.
The
certificate
for
server
two
would
be
unpresent
on
server
2
and
server
3.,
and
therefore,
we've
maintained
an
unbroken
chain
of
TLS
authorized
right
certificate.
M
Authority
authorized
servers
in
order
to
ensure
that
there
is
an
unbroken
chain
of
of
trust
between
these
systems,
so
you're,
never
you're,
never
just
being
redirected
off
into
the
Wilderness
you're
not
being
sent
to
some
random
third
party
is
that
is
that
relatively
clear?
That's
that's
one
of
the
things
we've
talked
about.
We
have
two
other
models
that
we've
been
discussing,
involving
DNS,
SEC
validation
and
remaining
in
baliwick
and
a
few
other
things,
but
I
don't
think
we're
quite
ready
to
talk
about
those.
Thank
you.
F
With
Google
I
want
to
pile
on
to
the
hesitance
on
anything
that
does
redirection
of
the
the
auth
origin.
For
this
because
thinking
through
Chrome,
it's
there's
very
little
that
changes
such
things,
it's
basically
HTTP
300
redirects
is
the
one
thing
where
we'll
really
change
the
author
origin
and
it's
a
very
scary
thing.
The
tool
and
a
lot
of
security
people
concerns
about
making
sure
everything's
just
right
to
not
mess
it
up,
but
everything
else
that
has
redirection
is
that
is
the
primary
security
mechanism
that
keeps
everything
safe.
F
Is
you
just
do
not
change
the
auth
origin
once
you've
picked
the
domain
that
you
want
to
connect
to
so
if,
at
all
possible,
I'd
say
find
a
way
to
not
change
that
origin
and
only
stick
to
redirects
that
keep
the
origin
the
same.
If
that's
hard
yeah,
we
got
to
figure
out
hard
ways
to
make
that
work,
because
that
is
the
that's
the
easy
route
to
keep
things
secure
and
with
security.
You
want
to
keep
things
easy.
K
Yeah
I
guess
I'm
also
feeling
somewhat
uncomfortable
with
this
and
I
guess,
I'm,
not
sure
I'm,
not
sure,
I'm,
not
sure
how
much
I
think
the
threat
model
feels
well
understood.
So
you
know
these
servers,
which
are
low-key.
These
servers
are
located
in
some
data
center,
which
you
I
feel
like
have
limited
limited
control
over
and
you're
worried
about
compromise
by
hypothesis.
Otherwise,
you
will
need
to
show
the
regular
certificate
right.
That's
like
that's
like
the
setting.
That's
like
the
regular
private
Keys,
like
I,
said
we're
talking
about
right.
K
So
the
the
setting
of
concern
here
is
that
you
wish
to
is
that
you
know
I
I
asked
I
was
configured
with
ns.you,
know
quad9.com,
and
you
want
to
bounce
me
some
other
server
which
is
located
in
some
location
facility,
which
you're
sad
about
which
you're,
like
don't,
really
trust,
and
so
you
don't
really
want
to
have
the
same
certificate
as
ns.com.
That's
like
the
same
private
key,
that's
the
underlying
for
them
all
right.
K
L
K
L
I
mean
from
the
security
components
are
certainly
or
like.
How
do
you
share?
The
certificates
is
I.
Think
a
core
component
of
the
reason
but
being
able
to
share
across
domains
is
also.
There
are
also
policy
reasons
for
that,
as
well,
which
are
separate
from
what
we're
talking
about.
As
far
as
the
some
of
the
issues
underlying
search
sharing.
L
K
L
So
as
an
example,
it
might
be
the
case
that
you
wish
to
actually
transfer
this
resolution
to
if
you're
as
an
example
inside
of
a
large
corporation,
there's
a
single
name
that
everyone
in
the
corporation
uses
to
find
essentially
a
rendezvous
server.
They
connect
to
that
the
first
time
they
do
their
resolution.
They
are
redirected
or
they
create
a
redirection
policy
which
then
redirects
them
to
the
policy
resolver
inside
their
own
department.
So
that
may
be
a
different
domain
space.
L
In
other
words,
it
would
be
engineering.food.com
so
there's
both
the
the
reason
to
distribute
or
or
have
certs
isolated,
but
also
there
may
be
a
reason
to
actually
change
the
resolver
based
on
policy,
that
is,
that
is
top
down,
meaning
that
the
top
level
or
the
first
resolver
in
the
chain
trusts
wherever
it's
redirecting
the
the
end
user
to,
but
there's
a
slightly
different
policy
in
place.
But
again,
the
chain
of
trust
is
not
broken
because
you've
got
server.
K
K
I
guess
I
have
to
think
more
about
your
your
sort
of
like
chaining
architecture
or
like
overlapping,
the
search
but
I'm,
not
sure
that
does
what
you
think
it
does
so
like.
Maybe
if
you
have
the
document
where
it's
been
written
down
because,
like
maybe
that
would
secondly
read
read
and
reason
about
because
we
had
this
thing,
we
were
like
it's
a
and
then
a
b
and
then
B
right,
because
I
thought
I
heard
you
described
it.
This.
K
C
C
And
if
I
can
make
an
observation
here
in
suggestion
it
sounds
like
we
need
some
of
Ben
Schwartz's
famous
beautiful
diagrams,
to
explain
this
situation
so
I
don't
know,
then,
if
you
want
to
contribute
some
of
these
fancy
diagrams
to
this.
This
shading
idea
you,
you
came
through
us,
came
through
Forest
before
with
some
just
beautiful
diagrams
that
broke
through
the
Log,
Jam
and
discussion.
So
just
a
suggestion
and
okay
and
with
that
oh
Tim,
dropped
out.
So
then
I
guess
you're
up
yeah.
I
G
L
Yeah
yeah
and
by
the
way
I
said
I'm
putting
words
in
the
DNS
for
EU
folks
mouths.
When
that
was
initially
a
proposal
when
there
was
when
it
was
very
very
early
on,
we
kicked
around
a
whole
bunch
of
ideas
about
how
to
distribute
queries
or
how
a
centralized
name
would
actually
redirect
into
a
much
more
Regional
resolver
clusters
that
had
policies
that
were
trusted
but
may
be
different
from
that
of
the
central
one.
C
C
Okay,
thank
you
Tommy.
So
my
co-chair
and
I
tell
who's
online.
We've
been
showing
you
notes
here,
and
we
want
to
sort
of
take
a
non-binding
sort
of
survey
of
the
room,
so
I'm
going
to
put
it
up
on
whether
we
should
consider
adopting
this
draft
in
as
a
working
group
draft
for
for
the
EDD
group,
and
so
there
it
is.
C
C
Do
nothing
we're
just
we're
taking
a
general
sense.
Not
this
is
not
binding.
This
is
just
to
gather
a
sense
in
the
room.
Okay,
so
I
think
we're
sort
of
done
there.
So
what
I'm
pulling
out
from
in
a
non-binding
way
and
not
counting
the
no
responses
as
a
nose
but
26
people
did
think
that
we
in
fact
should
probably
go
ahead
and
and
adopt
this
as
a
work
group
draft
and
10
people
deliberately
did
not
raise
their
hand,
which
we
might
be
able
to
count
as
a
no
okay,
and
with
that.