►
From YouTube: IETF93-DANE-20150720-1850
Description
DANE meeting session at IETF93
2015/07/20 1850
B
A
B
C
B
Thank
you.
So
this
is
the
iat
ethnic.
Well,
please
note
it
well,
hopefully
you
have
already
understood,
read
it
and
understood
it
I'm
not
going
to
try
and
summarize
it.
If
you
don't
understand
any
of
it.
Please
go
talk
to
your
lawyer
and
legal
counsel
and
some
other
stuff.
It's
as
important
things
and.
C
B
Earlier
but
the
battery
has
almost
run
up
a
Mexico
thing,
so
welcome
to
Dane
dan
York
said
that
he
will
be
the
Java
scrub.
Somebody
said
they
would
do
minutes.
Thank
you.
David
will
be
doing
minutes.
B
Okay,
then
them
6lowpan
peoples
taken
off
things.
Well,
we
can
just
hand
around
the
blue
sheets
without
for
that
wrinkly
blue
sheets.
Oh
well,
please
fill
them
in
the
Secretariat
shout
at
me
of
fun.
We
don't!
This
is
going
to
be
our
agenda.
Oh
yes,
for
the
mic
lines.
We
will
always
let
the
jab
escribe
get
priority
because
it's
hard
enough
to
work
remotely.
So
if
there
is
remote
people
with
Jebel
comments,
they
javascript
jumps
to
the
front
of
the
line.
B
Also,
we
are
going
to
be
asking
for
people
to
commit
to
review
two
things.
If
you
put
your
hand
up
and
commits
to
review
something
we're
going
to
point
at
you,
because
we
can't
always
see
shut
your
name
out
loudly
and
we
will
repeat
it
before
you
know
describe,
etc.
We
also
don't
want
to
end
up
in
a
situation
where
you
know
scribe
or
minutes,
take
a
doesn't
know
people's
names
and
so
in
forgetting
who's
going
to
do
reviews.
This
is
our
agenda.
Does
anybody
have
any
agenda
bashing?
C
C
C
C
The
we
want
to
get
the
estimate
based
on
feedback
we
have
got
in
the
last
few
days
and
based
on
the
number
of
reviews
we
have
got.
Thank
you
to
everyone
who
has
sent
in
reviews
to
the
s/mime
document.
We
are
going
to
try
to
finish
it
before
the
next
I
ATF
meeting
and
have
it
out
of
her
hands.
So
we
are
going
to
be
able
to
start
on
the
many
lists
discussing
the
important
questions.
C
C
D
E
E
The
root
of
the
DNS
and
the
client
then
obtains
this
DNS
Chad's
chain
in
one
go
authentic,
eights
the
chain
and
then
uses
the
Dane
record
to
performed
an
authentication
of
the
server.
Oh
one
thing
I
should
mention
is
that
the
crux
of
this
idea
is
not
actually
knew
so
you
may
remember
a
few
years
ago,
Adam
Langley
did
something
called
was
equally
nsx
stapled
certificates,
where
he
did
the
same
thing.
E
He
embedded
a
chain
of
DNS
SEC
records
in
an
x.509
certificate
in
a
custom
extension,
so
this
is
a
kind
of
reimagining
of
the
of
the
same
ideal
of
the
implementation,
substantially
different
we're
proposing
to
do
the
same
thing,
solving
the
same
set
of
problems
but
using
in
the
form
of
a
TLS
extension,
which
we
think
is
a
more
dynamic
and
maintainable
way
to
do
the
same
thing
all
right.
So
this
is
the
format
of
the
data
that
is
returned
in
the
extension
so
for
people
non
TLS
people.
E
E
Ok,
RF
set
structures.
Each
of
those
structures
contains
a
DNS
or
are
set
together
with
an
accompanying.
Are
ours
are
sick
at
the
NS
that
signature
over
that
are
set
and
the
records
are
ordered,
starting
from
the
target
record
the
day
in
TLS,
a
record
typically
going
all
the
way
up
to
the
to
the
configured
for
snipers
are
normally
the
route,
sir.
E
Alright,
so
here's
an
example
to
illustrate
so.
The
hypothetical
Jane
enabled
HTTPS
over
at
dub
dub
dub
example
com
because
were
to
deliver
this
chain.
It
would
look
like
the
following
sequence
of
DNS:
RR
sets
the
Dan
record
first
and
then
example,
comms
DNS
key
and
the
srr
sets
followed
by
the
same
for
calm
and
then,
lastly,
the
root
of
the
DNS,
and
each
of
these
is
come
accompanied
by
an
rrc
okay.
So
what
is
a
rationale
for
this
delivery
mechanism
for
the
NS
record?
So
a
number
of
things.
So,
if
we
deliver.
F
E
Records
in
one
go
to
the
client.
The
client
then
no
longer
has
to
perform
all
these
additional
dns
lookups
in
order
to
get
the
day
in
record
and
the
signatures,
so
it
avoids
the
associated
latency
penalties
associated
with
you
and
all
these
lookups.
The
other
important
thing
is
if
the
TLS
client
is
behind
a
middle
box
that
prevents
it
from
being
able
to
successfully
issue,
DNS
SEC
enabled
queries
or
gain
queries,
and
this
solves
that
problem
too.
E
And
lastly,
the
TLS
client
can
then
independently
authenticate
the
DNS
SEC
signed
record
without
needing
access
to
a
provision
validating
resolver
to
which
it
has
a
secure
connection.
So
I
forgot
to
put
it
on
the
slide,
but
last
point
means
address
is
actually
the
DNS
SEC
last
while
security
problem
or
you
may
have
a
stub
resolver
with
an
unprotected
path
to
a
valid
okay.
I,
see
a
question
so
I'm
going
to.
Let
you
interrupt
me.
A
E
A
Sub-Site
dog,
but
you
get
the
answers
back
and
you
look
in
the
answers.
Come
back
and
do
the
validation
soft
in
the
application
layer
is
it?
So
are
you
going
to
send
the
do
bit
outside
if
you're
doing
DNS,
second,
the
application
or
in
a
library
the
applications
calling
right?
There
is
no
problem
right.
E
F
E
Yeah,
okay,
so
there
may
be
other
possible
use
cases,
so
the
one
that
I
thought
of
which
isn't
in
the
draft
right
now
is
the
case
of
link
layer
on
medication
reading
it
or
to
that
one
exit,
beep
and
you're,
using
an
eve
method
that
employs
two
LS,
then
in
that
case
the
client
has
no
ability
to
issue
any
DNS
queries
at
all,
in
fact,
no
queries
other
than
the
encapsulated
Satori
protocol
that
is
allowed
to
eat.
So
this
would
possibly
address
that
vistes
too.
E
So,
what's
happening
on
the
server
side.
Well,
the
TLS
server
has
to
build
the
DNS
equal
dedication
chain
and
maintain
it.
It
returns
the
chain
in
the,
in
effect
an
extension
if
the
client
asks
for
it
and
then
it
caches
and
we
uses
the
chain
across
multiple
TLS
connections,
but
it
has
to
maintain
the
freshness
of
the
chain
by
periodically
rebuilding
the
chain.
E
As
TTL
and
signature
validity
periods
of
component
records
in
the
chain
dictate
on
the
client
side,
we
as
currently
written
the
client
sends
an
a
DNS
SEC
chain
extension
with
empty
with
no
data
and
it
obtains
the
chain
from
the
server
authenticates.
It
with
its
locally
configured
trust
anchor
and
then
uses
the
Dane
record
to
performed
an
authentication
of
the
service.
E
The
other
thing
that
it
has
to
do
is
perform
trust,
anchor
maintenance
maintenance
in
case
the
first
anchor
rollover
happened.
So
there
are
a
number
of
possibilities
for
doing
that.
Both
RC
5011,
which
we
talked
about
at
the
NFL
quite
a
bit.
It
could
do
it
itself
or
it
could
obtain
this
service
from
an
external
process
like
an
operating
system
provided
service
it.
E
You
know,
we
need
to
think
about
this
problem
a
little
bit,
because
if
the
client
is
actually
stuck
behind
a
middle
box
that
does
not
allow
it
to
issue
queries
for
sign,
dns
PR
sets,
it
may
not
be
able
to
successfully
for
perform
5011.
So
maybe
one
of
the
other
things
that
were
discussed
like
Joe
athletes,
ultimate
trust
anchor
publication
mechanism.
That
might
be
a
solution
for
this
okay,
so
some
future
work.
We
need
to
deal
properly
with
see
names
and
D
names
right
now.
E
A
E
Potentially
tricky
case
is
that
of
wildcards
not
actually
sure
if
it
will
be
common
to
see
TLS
a
records
that
are
synthesized
from
wild
cards,
but
if
they
are
wild
cards,
the
DNS
ecru
for
wild
cards
is
a
little
bit
trickier
because
you
need
not
only
the
signature
over
the
wild
card
name,
but
you
also
need
an
insect
proof
that
denies
the
existence
of
the
actual
the
explicit
record.
So
that's
another
thing
that
our
chain
doesn't
accommodate.
E
Yet
thinking
about
it
for
the
future
and
under
consideration
for
a
future
revision,
the
client
could
cash
DNS
records
that
it's
previously
seen
and
then
offer
those
up
in
the
extension
that
it
sends
to
the
server
and
then
server
could
potentially
deliver
a
shorter
chain
with
those
records
admit
it.
If
we're
concerned
about
the
size
of
the
chain,
to
do
sighs,
optimizations,
of
course,.
A
E
The
expense
of
additional
implementation
complexity
and
work
on
both
the
client
and
servers
servers,
and
so
the
few
more
slides.
So
let
me
do
that
before
you
take
questions.
So
one
of
the
things
we're
trying
to
do
is
we're
trying
to
develop
some
prototype
code
to
help
us
validate
our
protocol
design
and
there's
a
browser
implementation.
The
pipeline.
We
should
be
able
to
talk
about
that
soon,
but
I
was
I,
attended
the
IGF
hackathon
on
Sunday,
so
just
to
prove
that
I
did
a
little
bit
of
work.
E
I
hoped
up
a
little
TLS
server
that
send
out,
with
extension,
consumes
this
extension
and
sends
back
a
chain.
This
is
for
one
of
the
servers
that
I
operate
and
I
just
wanted
to
give
you
a
sense
of
the
size
of
the
data
in
the
chain.
This
is
about
three
thousand
bikes,
so
I
don't
know
if
that's
bigger,
scary
or
okay
I
mean
I've
17
certificate
chains
longer
than
that,
but
in
case
we
have
to
do
any
optimizations.
We
should
consider
whether
that's
weathers,
what
doing
it
or
not?
Ok,
that's
all
I.
C
E
G
A
G
Mentioned
this
on
list,
you've
got
CNN
and
DNA
and
as
things
and
wild
card
right,
but
SR
SRV
offers
additional
challenges,
particularly
because
we
don't
know
with
an
SRV
look
up
well,
if
you're
trying
to
validate
the
remote
peer,
you're,
often
validating
multiple
pieces
of
the
DNS
check,
so
like
you're
trying
about
it
dot
tcp,
you
got
yep
well
that
results
to
mail,
but
you
know
something
else.
True
yeah
and
you
don't
even
have
the
hint
of
S&I
or
anything
like
that
to
decide
which
chain
to
mmhmm.
E
G
Sorry,
my
impression
was
that
if
you
wanted
to
use
Dane
in
a
in
an
SRV
context,
the
advantage
of
doing
is
that
you
could
just
clarify
the
entire
chain,
including
from
the
right
you're.
Looking
for
imap
my
purposes
for
your
career,
you
know:
example.com
mail
account
right.
Well,
Jane
can,
if
Dane
doesn't
plug
the
SRV.
Oh
that.
E
A
A
We
want
to
have
those
things,
and
I
personally
would
favor
an
approach
where
we
keep
dns
below
TLS
and
just
say
we
sent
it
in
the
dane
record
as
an
auxiliary
additional
record
with
the
DNS
request.
So
we
don't
have
to
do
a
second
request,
which
is
a
problem
sure,
but
I
wouldn't
really
put
this
into
the
TLS
handshake.
G
E
Right
so
I
agree,
there's,
certainly
additional
complexity,
which
is
I
am
my
personal
inclination
is
I,
agree
with
you,
but
there
that
doesn't
solve
the
use
cases
for
all
possible
applications.
There
are
some
applications.
The
three
points
that
I
mentioned.
If
they
can
address
them,
it
will
be
unwilling
to
do
the
NS
a--
today,
so
we're
leaving
out
entire
application
communities
if
we
don't
try
to
at
least
offer
a
solution
to
problems
in.
H
H
Our
our
sets
providing
non
delegation
of
intermediate
nodes.
Oh
sorry,
if
excluding
should
should
are
our
sets,
proving
non
delegation
of
intermediate
nodes
between
the
RR
set
and
signing
zone
apex
be
included.
My.
E
Biology,
Victor,
okay,
so
proving
non-secure
delegations
you
mean
so
I
think.
If
that's
the
case,
then
you
will
end
up
at
the
end
of
the
chain
with
a
usable,
DNS,
ex-im
TLS
a
record.
So
in
that
case
I
would
say
the
server
decides.
It
cannot
build
a
chain
because
a
client
can't
use
it
to
authenticate
this
over
anyway.
The
DNS
SEC,
so
I
would
exclude
that
r.I.p
paul.
I
Walker's
yeah,
so,
as
I
told
to
practice
all
four,
I
would
really
like
to
see
the
dns
format
being
used
because,
if
you're
shipping,
a
binary
blob
team
on
she'll,
just
do
a
dns
block,
because
that
gives
you
interoperability
but
tools,
libraries
and
a
lot
of
other
things
that
makes
debugging
easier
and,
with
my
dry
draft
author
hat
up
on
the
dns,
the
query
ching
draft,
it
would
be
really
nice
because
that
draft
will
will
cause
the
code
to
be
written
for
this.
So
you
don't
have
to
write
your
tools
to
generate
all
these
chains.
I
E
A
E
Good
point
so,
on
the
second
point,
so
the
Edenist
chain
query
things
I
agree
that
would
make
implementation
of
building
to
change
much
easier.
So
once
that's
available,
I
mean
I
haven't
actually
seen
any
implementations
of
it.
Yet
I
think
I
would
propose
the
server
implementers
use
that
to
get
it
there
are
actually
existing
dns
library,
libraries
today
that
already
can
build
that
chain.
For
you
I'll
give
you
an
example
of
the
project
involved
in
the
get
dns
library
which
can
do
that
right.
Well,
I'm!
E
So
are
the
initial
implementation
that
I
did
just
used
a
function
from
the
get
dns
library
to
build
the
train
return
it.
So
obviously
it's
doing
additional
individual
queries.
Whether
the
chain
query
can
get
it
in
one:
go
from
an
upstream
resolve
all
right
yeah.
So
that
would
be
an
optimization
we
could
get
out
of
that
mechanism
when
it's
available
on
your
first
point:
yeah.
Okay,
so
let
me
go
back.
I
actually
agree.
So
me
being
more
a
DNS
person.
I
would
have
liked
to
see
the
structure
be
entirely
DNS
wire
format.
E
Then
I
could
generate
the
entire
structure
straight
out
of
a
DNS
library
and
pump
on
the
client
side
pump
it
into
a
dense
library,
but
we're
working
with
some
application
communities
who
we
want
to
do
want
to
see
a
little
bit
structure,
so
they
can
know
how
to
what's
in
the
chain
and
parse
it
right.
So
well
we're
continuing
to
have
a
discussion
about
that
right.
This
is
an
early
draft,
so
happy
to
get
your
input
and
happy
to
hear
input
from
other
people.
A
E
F
I
am
a
lazy
application,
yeah
Burke,
Mozilla,
tough
workout
work
on
this
I
think
Oh.
Some
of
the
things
people
are
seeing
in
this
are
as
a
result
of
trying
to
make
this
as
easy
for
the
client
side
as
possible.
A
lot
of
the
reason
this
stuff
is
desirable
is
that
you
have
applications
out
there
that
might
be
using
TLS
and
we
might
still
be
using
get
a
tour
info
and
not
doing
any
DNA
fancy
penis
stuff.
They
might
not
have
it
be
in
this
library
so
and
it
really
for
Dane
purposes.
F
I
came
to
this
by
analogy
with
the
certificate
format
in
TLS,
which
requires
you
know
somewhat
aspirationally
I
grant,
but
it
requires
that
the
certificates
be
presented
in
validation
order,
so
the
server
cert
first
then
the
cert
that
issued
that
then
inserted
issued
that
so
that,
if
you're
writing
up
pride
of
this,
you
can
just
blow
through
straight
through
validate
straight
through
and
it's
lasting
the
trust
anchor
Bob's.
Your
uncle
you're
done
like
I,
said
it's
somewhat.
F
G
E
D
Pinnacle
so
two
hours
ago,
in
the
DNS
of
meeting,
we
learned
about
efforts
to
do
a
case
k
rollover
mm.
We
have
a
new
user
for
trust
anchors
here
for
the
left,
trust
anchor.
Yes,
have
you
considered
making
the
design
team
aware
of
potential
new
customers
for
50
11
or
whatever
they
come
up
with
I.
J
J
Warren
or
esteem.
Co-Chair
is
actually
a
co-author
on
a
draft
to
do
this
over
dns
to
actually
keep
the
layers
clean.
Like
some
people
want
where
we
can
return,
multiple
records
and
one
of
the
things
that
we're
doing
there
I
should
disclose
them.
A
co-author,
too,
is
that
we
are
also
a
pending
records.
Like
images
duh
example.com
really
went
to
ww
at
some
point,
I'm
sure
that
this
will
come
up
in
your
space
as
well.
As
you
know,
many
records
can
come
in
there
with
all
the
other.
Are
six
as
well.
J
E
Right
so
on
your
point
about
whether
or
not
necessary
to
clean
include
the
root
dns
key
in
the
chain.
We
went
back
and
forth
on
that
question
and
the
reason
it's
in
there
right
now
is
for
the
purposes
of
doing
trust
anchor
rollover.
It
needs
to
be
able
to
see
the
dns
chiaro
said
it's
flags
if
the
client
is
doing.
E
C
E
B
E
Alright,
so
this
second
presentation
is
about
client
certificates
in
dainty,
LSA
records
and
here's
a
draft
if
you
haven't
seen
it
so
what
we're
proposing
to
do
is
we
use
the
TLS
a
record
but
modify
the
owner
name
of
the
record
a
little
bit
to
make
it
more
appropriate
for
for
client
systems.
Where
you
don't
have
you
don't
need
the
port
number
probably
don't
need
to
distinguish
transports,
TLS
reverses,
DTLS,
etc.
E
So
the
simplified
format
we
were
proposing
is
just
the
domain
name
of
the
client
prepended
with
one
underscored
label
which
contains
the
application
service
and
the
rationale
for
encoding
the
application
service
in
the
owner
name
is
that
you
might
have
a
situation
where
you
have
the
same.
Client
device
wants
to
maintain
distinct
credentials
for
distinct
applications,
and
this
here's
a
one
specific
example
of
your
client
system
device,
one
example.com
and
it's
an
SMTP
plant
and
the
our
data,
the
TLS.
Your
record
is
nothing.
E
Is
exactly
the
same
as
specified
in
RFC
698,
and
so
the
authentication
model
for
client
certificates
is
that
the
client
has
an
identity
in
the
form
of
a
domain
name,
and
this
identity
does
not
necessarily
have
any
relation
to
its
network
address,
because
clients
don't
often
have
fixed
reply
have
fixed
addresses.
Even
the
client
has
a
public
and
private
key
pair
and
a
certificate
binding
the
domain
name
to
the
public
key,
and
there
is
a
signed
TLS,
a
record
in
the
DNS
corresponding
to
the
domain
name
and
certificate.
A
E
Application
prevention
from
each
other
and
have
that
isolation
and
certificates
that
work
as
well.
Alright,
so
the
other
thing
that
we
think
is
probably
going
to
be
needed
to
make
this
scheme
work
really
well
is
a
client
signaling
mechanism,
and
so
the
server,
for
example,
may
want
an
explicit
indication
from
the
client
that
the
client
has
a
certificate,
and
it
also
has
a
corresponding
TLS
a
record
so
as
to
avoid
doing
unnecessary
DNS
queries
in
band
with
the
TLS
a
keyless
entry.
E
In
some
manner
to
the
server
and
lastly,
I
wasn't
aware
of
this,
but
I
think
Victor
in
for
me
that
there's
actually
apparently
there's
a
lot
of
deployed
client
software
today
that
reacts
very
badly
to
an
unexpected
client
certificate
request
and
we
need
to
be
able
to
accommodate
these.
So
you
know
one
way
of
doing
this
is
to
have
an
application.
Specific
mechanism
to
signal
gain.
Client
identity
to
the
server
could
be
like
a
new
smtp
command
command,
but
the
most.
A
E
E
E
You
recognize
you
see,
that's
what
I
meant
to
say
so
the
client
requirements
they
have
to
have
assigned
TLS
a
record
published
corresponding
to
the
domain
name,
insignificant
clients
name,
must
appear
in
the
certificate
in
one
of
the
identity
feels
that
I
mentioned
and
in
the
future,
if
we
manage
developed
is
TLS
extension,
it
would
signal
this
in
the
in
decline
for
message
in
the
tail
accession.
The
server
requirements
are
that
the
server
sends
a
certificate
request
message
in
the
TLS
handshake.
E
It
extracts
the
clients
identity
from
the
certificate
that
is
presented
to
it
by
the
plant,
and
then
it
constructs
the
corresponding
TLS,
a
query
name
issues
the
query,
authenticates
the
TLS
a
record
and
then
matches
the
data
field
of
the
TLS
a
record
to
the
certificate.
All
of
that
succeeds,
the
quietest
so
I
think
that's
all
I
had
more
details
are
in
this
draft
and
I
would
take
questions.
A
Yes,
hello,
Clement
rumpa,
wouldn't
it
make
sense
to
do
the
same
that
you
did
in
your
previous
draft,
where
the
way
you
include
the
chain
in
in
the
TLS
handshake
also
for
the
client,
so
a
client
could
prepare
its
own
chain
of
RS
6,
sign
our
records
and
send
that
with
its
credentials.
Since.
E
Yeah,
since
you
already
have
that
GI
right,
so
it
would
certainly
be
possible
to
do
that.
What
I
would
say
is
so
you're
saying
the
client
builds
a
chain
and
sends
it
to
the
server
right,
so
I
think
it
would
be.
It
would
solve
more
problems
if
the
server
did
that,
because
the
client
has
to
verify
the
server
as
well,
because
the
client.
A
E
E
That
would
work
I
mean
the
question
is
whether
the
server
actually
needs
to
do
that
or
whether
can
just
do
a
few
DNS
queries
right.
So
DNS
servers
generally
I,
don't
have
the
same
set
of
constraints
that
the
client
has
weather
stuck
behind
middleboxes.
That
makes
it
difficult
to
perform
certain
types
of
DNS
queries,
but
yeah
I
mean
it
would
be
possible.
I
suppose.
E
You
might
be
able
to
do
it
from
the
client
end,
but
not
for
the
front
for
the
server
end,
because
the
server
the
way
gain
in
smtp
works
is
that
it
uses
the
client
uses
the
presence
of
a
TLS,
a
record
for
the
server
to
know
whether
to
enforce
TLS,
a
authentication,
TLS
authentication
to
prevent
downgrade
attacks.
So
you.
H
I
G
Which
is
to
the
other
books
are
aware:
there's
potentially
a
privacy
concern
right
with
stuffing
the
clients
identifiers
in
the
client
and
in
the
client,
hello
for
TLS.
So
at
the
moment,
GLS
through
version
1.2
right.
All
of
the
handshake
messages
are
in
the
clear
yeah,
but
in
particular
the
client.
Hello
can't
even
really
we're
in
we're
going
to
hopefully
protect
more
of
the
handshake
messages
in
TLS,
1.3
yeah,
but
the
client
can't
really
protect.
G
E
I
agree
so
in
the
in
the
pre
TLS
client
identity
thing
that
I
proposed
in
this
draft.
The
client
would
present
the
certificate
only
if
the
server
Center
certificate
request
right,
but
right
now
it
could
be
the
case.
If
we
develop
this
tension,
the
client
is
always
automatically
explodes
exposing
the
climate
identity.
E
In
the
extension
time,
I
mean
at
one
way
of
possibly
dealing
with
that
problem
is
the
client
has
some
privacy
and
security
configuration
rules
that
cause
it
not
to
use
that
extension
unless
it
has
to,
with
a
certain
set
of
servers
that
it
plans
to
use.
Do
this
form
of
authentication
but
yeah
I
mean
I,
guess
tell
us.
1.3
is
working
on
encrypting,
more
and
more
of
that
more
and
more
of
attention
right.
So
I
don't
know
if
that
will
address
the
problem
or
not.
C
This
concludes
the
pre
TLS.
A
meeting
feel
okay
and
some
of
you
may
have
noticed
a
devious
plan
by
people
raha
like
the
document
editors
of
this
and
I'm
document,
and
each
years
to
start
a
discussion,
the
devious
plan
succeeded.
We
got
people
to
react,
we
got
reviews
of
a
document,
so
I
will
add
this
trick
to
my
my
bag
of
tricks.
So
I'm
open
TBT,
GP,
GP
document
15.
C
Yes,
so,
as
I
specify,
is
basically
ready
to
exit
or
go
into
the
RCMP
HQ
soon,
hopefully,
and
it
and
the
SYM
document
proposed
different
locations
to
store
the
names.
This
is
maybe
okay,
there's,
maybe
not,
but
we
are
in
the
protocols.
We
are
actually
has
three
different
dimensions
where
we
can
add
information
about
how
the
keys
are
used
or
what
they're
all
kind
of
keys.
They
are
and
mom,
that's,
okay,
maybe
maybe
not
so
the
question
is:
can
we
reduce
these
notes
open
for.
I
So
funny
enough,
some
people
were
suggesting
is
in
the
early
early
times
when
we
did
some
of
these
maps
and
he
said
why
don't
you
use
the
cert
wrecker
type
and
you
can
do
subtyping,
it's
going
to
be
awesome
and
then
the
author
of
the
cert
are
our
type
told
me.
No,
you
should
not
do
this.
Subtyping
was
a
mistake
and
now
that
same
authors
or
working
group
care
for
Dane
and
asking
if
we
should
do
something
again,
no.
I
H
They
can't
do
raw
zone
entry
and
they
have
to
go
and
do
this
and
have
to
pick
from
whatever
the
DNS
operator
is
yeah,
as
foreign
is
making
signs
of
shooting
them
self
up
there.
That
I
mean
so
I
guess.
My
question
is
right:
now
we're
sort
of
in
a
stage
where
we're
out
there
trying
to
go
and
get
these
DNS
operators
to
put
TLS
a
in
there
so
that
we
can
at
least
get
TLS
a
records
in
and
now
my
concern
with.
H
All
of
this
is
it
now
after
we
do
that,
we've
got
to
go
back
and
try
to
get
them
to
add
s5a
and
we've
got
to
add
them
to
get
them
to
add
openpgp
and
that
and
go
and
get
them
to
add.
Whatever
is
the
next
thing
we
decide
we
want
to
be
gained
like
that.
Doesn't
use
TLS
a
so
I
guess.
My
concern
is
just
my
as
Paul's
la
cama.
My
point
is
I'm.
H
D
Oh
pittock
organic,
so
my
world
view
of
the
DNS
heck
is
a
bit
tiny,
so
I
have
like
40k
domains
to
watch.
The
vast
majority
of
those
domains
unisex
signed
is
currently
completely
run
by
registrar's
behind
the
scenes,
which
is
in
response
to
the
New
York's
comment
that
somebody
is
manually
entering
domain
names
and
record
somewhere.
The
majority
of
deployment
we
see
is
behind
the
scenes.
I
appreciate
the
observation
that
there's
a
bunch
of
interfaces
that
that
offer
manual
intervention,
but
this
is
probably
not
the
future,
at
least
for
us:
it's
not
the
present.
D
So
can
we
please?
Can
we
please
have
an
assessment
of
the
say,
the
volume
or
the
the
numbers
that
we're
talking
about
we've
had
we,
we
do
have
Indiana
second,
also
in
Dane.
We
do
have
kind
of
a
history
of
solving
geek
problems,
right,
geek,
being
the
early
adopter
or
even
before
that.
So,
let's
not
solve
the
early
adopter
problems,
let's
let's
go
to
scale,
and
that
also
means
I'm.
D
Sorry
to
say
that
a
bit
of
patience,
but
we
also
see,
is
there's
a
an
increase
in
the
NSF
deployment,
but
actually
adding
TNS
a
records
takes
time
because
people
need
to
develop
processes
and
you
can't
just
get
go
there
and
give
them
the
tsa
and
enter
this
manually.
People
actually
care
about
doing
key
rollovers
for
their
certificates,
and
that
takes
time
again.
D
So
the
response
to
lack
of
deployment
or
too
slow
deployment
is
not
necessarily
more
protocol,
because
that
sends
an
interesting
message
out
to
the
masses,
taking
somebody
else
at
the
proposal
that
we
take
the
August
off,
maybe
at
September,
so
so
troubling
the
development
work
or
throttling
protocol
developments
might
actually
beneficial
two
deployments.
Even
though
that
might
sound
paradox,
then.
H
You're
responding
to
Peter,
then
Peter
I
totally
want
automation.
You
know,
I
mean
I
I,
don't
want
to
have
any
of
these
manual
interfaces
round.
I'm.
Just
saying
right
now,
certainly
when
we're
in
these
earlier
days
of
Dane
deployment
as
we're
trying
to
get
people
out
there
using
it.
What
I'm
seeing
is
a
whole
lot
of
different
web
provisioning
interfaces
that
people
have
to
use.
You
know,
as
as
as
I've
had
a
number
of
people
come
to
me
and
say:
I
want
to
get
Dane
deployed
for
my
domain.
What
do
I
have
to
do?
H
J
Often
so,
I
really
think
that
whatever
we
do
is
going
to
get
deployed
at
about
the
same
rate.
That
is,
if
it's
a
little
bit
harder
for
people
to
do
by
hand,
people
will
work
harder
on
tools
if
it's
very
good
for
tools,
people
figure
out
I,
do
things
by
hand.
Similarly,
for
the
consumers
of
these,
you
know
we
had
originally
said.
J
Oh
openpgp
should
be
separate
from
s
mine
to
these
reasons,
and
now
we're
thinking,
oh,
maybe
they
should
be
combined,
and
you
know
what
it's
just
software
and
people
who
are
motivated
to
make
this
work
are
going
to
make
it
work.
We
might
make
a
dumb
decision
that
could
delay
developer
by
three
months
or
six
months
that
doesn't
matter
arguing
about
this
and
saying
I
predict
this
with
no
data
is
going
to
take
longer.
I
H
A
Is
probably
not
a
problem
from
for
Dane
working
group
because
it's
generally
problem
with
any
new
our
five
so
but
we
may
maybe
the
NS
up
should
develop.
You
know
some
description
of
the
NSA
code,
so
you
can
just
download
I,
don't
know
xml
file
to
your
crappy
GUI
and
get
all
the
new
record.
Something
but
I
don't
think
the
den
group
is
the
right
place
to
service
pack
Henderson.
A
A
Nameservers,
don't
need
to
know
the
quant,
don't
need
no
the
structure
of
these
records.
They
are
a
big
blobs
as
far
as
nameservers
of
them,
so
they
have
been
for
a
decade
now,
but
the
project
I'm
not
opposing
that
it's
about
the
user
interface
and
that's
the
problem.
You
can
do
I
think
that
even
windows,
server,
2003
or
something
patient
can
add
actually
at
arbitrary
record
if
you
use
in
a
sub
day,
so
it's
actually
about
user
interface.
Sorry.
H
C
I
It's
I
thought
we
only
talked
about
the
names.
I
didn't
talk
about
the
RR
type.
So
now
let
me
talk
about
the
archive,
if
already
seeing
in
the
suggestions
of
how
people
want
to
do
as
mine
that
it's
completely
different
from
openpgp
key.
So
we
should
definitely
keep
this
app
retired.
As
for
the
look
of
mechanism
which
I
get
this
special
label-
yes,
okay,
so
further
further
for
the
lookup
location,
clearly,
there's
a
benefit
of
doing
it
to
say
at
the
same
location,
because
both
problems
are
identical.
B
So
we
need
some
more.
We
would
like
some
more
reviewers
for
the
s5
document.
We've
yeah
either
now
or
you
know
when
it
gets
updated,
but
we
actually
want
to
take
names
this
time.
Our
brilliant
thing
of
you
know
we're
going
to
cancel
this,
and
this
anybody
comes
along
has
generated
a
bunch
of
interest.
A
lot
of
people
seemed
as
though
they
wanted
to,
or
were
willing
to
actually
work
in
it
and
review.
Would
you
please
put
your
name
your
hand
up
if
you
are
willing
to
okay
for
the
scribe?
That's
poor
voters
rush.
C
B
B
B
A
I
J
I
C
I
J
And
further
the
two
drafts
currently
don't
agree
and
there
was
general
agreement
to
whatever
the
first
draft
did.
The
second
draft
would
do
so.
We
aren't
going
with
the
current
drafts
at
all
we're
waiting
for
paul
to
feel
like
he
has.
What's
you
know
the
consensus
in
the
work
group
in
his
and
in
yaakov,
and
I
will
immediately
do
go
to
that.
Okay.
A
I'm
being
a
lone
patient,
but
I
did
hear
I
mean
I
think
it
might
be
reasonable
to
ask
the
working
group.
How
would
they
feel
about
trying
this
since
we're
going
experimental
rather
than
waiting?
Another
cycle
of
rate
trying
to
raise
discussion
again
because
we're
all
here
to
try
to
get
a
consensus
call
so
Paul
knows
what
others
knows
what
to
do
in
this
job?
Oh,
is
it
I
thought
they
were
closing
out
this
agenda
I.
B
A
Asking
about
the
special
label
so
they're,
both
in
the
same
namespace,
which
I
don't
think
we
finished,
and
so
I,
don't
think
we
have
guidance,
had
what
happens
with
Paul's
dwellers
draft
and
then
the
Paul
Hoffman
jakub
job
so
seems
like
calling
consensus
on
your
special
label
about
whether
to
unify
the
Q
namespace
would
be
worth
it
so
that
people
can
solve
that
and
finish
with
that
with
this
island,
rather
than
waited.
My
miss
I
mean
maybe
I'm
just
too
tired
to
get
this
right
mode.
I
I
So
so
we
can
talk
about
the
different
proposals
that
are
out
there
now
and
then
we
can
maybe
a
plea
all
agree
or
not.
So
so
let
me
just
like
rephrase
it,
and
so
the
two
current
proposals
that
I'm
aware
of
our
the
sha-256
truncated
version
of
the
name
versus
the
base,
32
encoding
of
this
split
name
and
I,
think
your
salsa
version
where
we
said
if
it's
a
ski
down
lower
case
and
if
its
ID
and
and
normalized
and
then
hash
for
the
sort
of
three
options
and
I
have
no
real
strong
preference.
H
I
It's
sorry,
let
me
clarify
it.
It's
of
these
three
options.
The
base
32
split
option
is
the
only
one
that
will
support
online
signers
and
people
being
able
to
do
fuzzy
matching
and
other
things
compared
to
the
ones
that
do
hashing,
where
you
are,
the
only
have
one
shot
unless
you
do
multiple
great.
I.
J
This
is
pavan,
no
he's
the
only
one
who's
talk
talk
about
it,
so
my
preference
in
fact
is
still
is
to
go
with
the
base
32.
It's
not
a
strong
preference
I'm.
Definitely
against
trying
to
do
the
ascii,
vs,
I,
DNA
thing,
I,
don't
think
we've
thought
about
it!
Well
and
there's
some
eai
stuff
there
that
could
be
really
ugly.
I
mean
I,
think
it
can
be
done,
but
it
would
take
a
while
to
get
it
done.
J
Well,
I
acknowledge
John's
concern
about
how
things
go
and
I
also
believe
that
whatever
we
do
isn't
going
to
work
well
enough
and
that
some
of
the
protocol
is
going
to
be
needed,
and
given
that
I
think
that
the
base
32
1
is
sufficient
for
now.
If
we
completely
blow
this,
we
can
fix
it
later.
That
will
that
will
be
bad,
but
it
will
not
be
a
tragedy
waiting
forever
and
trying
to
do
things
for
people
whose
size
of
Audis
we
don't
know,
is
I.
Think
a
worse
thing
to
do
all
you.
H
Might
want
stay
here
so
two
relays,
one
from
John
Levine,
no
normalization
defined
for
utf-8
local
parts
and
John
Paul
to
said
correct
behind
and
then
the
second
one
is
Victor.
It
says
online
signing
without
fuzzy
matching
works
with
or
without
hashing.
It's
the
fuzzy
matching
that
requires
base32
and
then
forces
online.
Signing.
A
B
E
G
G
Concerns
with
the
base,
32
is
just
that
the
anyone
who's
observing
the
query
can
see
the
exact
email
address,
that's
being
sent
without
having
to
do
a
dictionary
attack
against
the
National.
So
so
that's
the
right
if
it
was
with
the
hashing
anyone
who
retrieves
the
query
it
has
to
do
a
dictionary
attack
against
the
hash
to
figure
out
what
email
address
was
used
with
base32.
You
can
just
unpack
it
and
find
the
email
address.
So
the
DNS
query
now
leaks
the
email
address
directly
but
against
a
powerful
attacker
with
the
simple
email
scheme.
G
J
G
Sorry,
the
other
privacy
concern
that
we're
generally
thinking
about
what
this
stuff
is,
whether
you
can
just
enumerate
all
the
email
addresses
on
a
host
by
doing
DNS,
queries
and
I
think
they
have
the
same
properties
in
that
case,
because
if
you
know
what
you're
looking
up,
you
can
do
either
basically
to
encoding
or
passion.
So
the
only
concern
is
whether
someone
is
observing
active
DNS
traffic
hopefully
be
protected
by
deprived
at
some
point,
but
it
isn't
now
whether
they
can
identify
the
email
addresses
direct.
B
So
I
think
that
three
hubs
are
going
to
be.
I
am
ok
with
base32.
This
is
an
acceptable
thing
to
me.
The
next
time
will
be.
I
am
NOT.
Ok
with
base32.
You
know
this
is
horrendous,
don't
do
this
and
the
third
option
will
be.
We
don't
know
enough
to
be
able
to
make
a
useful
decision.
I
believe
that
that
one
means
we'll
never
know
enough
to
be
able
to
make
a
useful
decision,
but
it's
dad
sure.
B
B
G
B
As
far
as
I
can
see
from
this,
we
have
no
conscious
consensus
on
what
we
should
do.
It
seems
that
people
like
the
base
32
more
than
dislike
it,
but
an
equal
number
of
people
think
that
we
can't
make
a
decision
yet
I,
don't
know
how
we
get
to
a
point
where
we
can
make
a
decision.
I
mean
we
might
need
to
okay.
My.
G
Impression
of
the
last
home
was
that
there
are
many
people
who
were
unclear
on
what
the
issue
was
or
how
to
resolve
it,
not
that
they
thought
that
it
was
totally
unsolvable
and
it
seemed
like
there
was
a
much
stronger
hum
saying.
Base.
32
is
probably
okay
than
saying
my
god.
Please
do
not
do
this.
Is
it.
B
In
that
case,
let
me
please
repeat
the
last
time:
if
you
think
that
we
should
not
make
a
decision
now
that
it
would
be
bad
for
us
to
decide
on
base
32
or
bad
for
us
not
to
decide
and
base32,
basically
bad
for
us
to
make
a
decision.
This
is
not
you
don't
understand.
What's
going
on,
I
definitely
fall
in
the
last
camp.
If
you
think
that
we
should
not
make
a
decision,
cheese
ham
now.
B
I
C
B
And
please
people
really
really
really
participate
in
this
actual
discussion.
Armor
I
realize
we
did
a
really
bad
job
here
of
the
whole
humming
thing
I
apologize
for
that,
but
we
really
need
to
actually
get
this
as
a
clear
question,
get
to
a
useful
answer
and
move
on
with
us,
because
you
have
Paul
has
been
doing
this
for
a
long
time.
We've
been
doing
this
for
a
long
time.
We're
tired
of
it.