►
From YouTube: IETF114 UTA 20220727 1730
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
it's
time
to
start
welcome
to
uta
at
itf
114,
your
chairs,
one
of
which
is
on
site
and
the
other
is
remote.
You
agree
my
co-chair
is
right
there
hi
very
good
so
with
the
usual
reminders
of
note.
Well,
please
note
the
note
well
well
and
also
on
the
itf
code
of
conduct.
A
That's
well
be
nice
to
each
other
speak
clearly
at
the
mic
and
stick
to
the
topic
at
hand
is
one
way
of
expressing
it
and
for
this
meeting,
mask
is
required
in
the
meeting
room
with
that.
A
We
have
a
a
reasonably
full
agenda
today.
There
there's
a
lot
of
stuff
to
cover.
We
do
need
a
couple
of
note
takers.
We
need
a
well
a
normal
note
taker
and
if,
if
possible,
somebody
to
go,
watch
tulip
and
and
channel
any
discussions
to
the
mic,
that
can't
be
anyone
who
can't
sort
of
be
you
know
either
remote
or
using
voice
remote
or
in
person.
So
we
get
some
volunteers
to.
A
Oh
perfect
man.
Thank
you,
so
ben
schwartz
like
volunteered
to
take
notes.
This
is
this
is
really
good
all
right
with
that
here's
our
agenda
today
we
are
going
to
start
with
rich
we're
going
to
talk
to
us
about
the
ip
address
issue
and
then
honda's
to
talk
about
iot,
and
I
see
hannah's
here
already
joe
I
haven't
seen.
I
haven't
seen
joe
online.
Oh
there,
you
are
perfect
right,
so
we
actually
have
everybody
here
that
needs
them
here
so
rich.
A
B
There
we
go
okay,
hi,
I'm
going
to
leave
after
my
session,
not
because
my
ego
is
so
big,
but
because
there's
a
conflict.
Okay,
next
slide
all
right.
So,
like
two
weeks
ago,
three
weeks
ago,
martin
thompson
proposed
that
we
add
support
for
ip
addresses.
There
is
the
subject:
alt
name
extension
in
pcx
has
a
type
for
ip
addresses,
the
obvious
thing
to
call.
It
is
ip-id
similar
to
dnsid
and
the
other
terminology
used
in
6125
and
61-25
bis.
B
Rfc
9110,
which
was
presumably
martin's
for
bringing
it
up,
has
text
about
validation.
The
rule
is
very
simple:
a
reference
id
matches
if
the
ip
address
matches
fairly
straightforward,
it's
not
uncommon
in
http,
if
you've
ever
typed,
you
know
http
colon,
slash,
127001,
you've
done
it,
presumably
there's
more
mechanisms
that
are
going
to
come.
B
Http
alternate
service
and
some
of
the
other
mechanisms
that
are
being
added
to
http
are
more
likely
to
include
more
of
these
kinds
of
things
and
there
may
even
be
other
uses
outside
of
http.
I
don't
know
next
slide,
okay,
so
the
issues
it
is
admittedly
late.
Martin
said
so
in
his
comment.
It
might
make
the
draft
more
widely
applicable.
I
don't
know
I.
C
B
I'll
take
him,
it
was
had
his
word.
The
simple
wording:
change
does
have
ripple
effects
through
the
document,
for
example
in
the
front
near
the
front
of
the
dock.
It
says
here's
the
rules
and
then
you
have
to
add
like
an
escape
patch
for
step
three
that
says,
but
if
it's
an
ip
address,
do
this
it's
just
editorial
where
it's
missing
so
the
goal
is.
We
should
want
to
seek
working
group
consensus
whether
or
not
to
do
this.
It
wasn't
clear
if
there
was
consensus,
chairs
thought
there
was.
B
B
Is
I'm
going
to
be
kind
of
busy
with
nom-com
for
the
next
five
months
so,
but
I
have
a
co-author
a
little
bit
busy.
I'm
just
gonna
pick
all
the
old
incumbents
and
do
them
again
anyhow.
Next
next
slide.
B
So
the
current
text
in
the
out
of
scope,
section,
which
this
obviously
would
go
away,
is
identifiers,
such
as
ip
addresses,
are
not
discussed.
Protocols
other
than
http
may
want
to
consider
and
then
points
to
9001.,
not
whatever
9000,
something
as
a
validation
model.
I
think
that's
reasonable
description
of
the
issues
looking
for
you
know
what
the
working
group
wants
to
do.
B
B
D
Alessandro
gadini
cloudflare,
we
do
have,
you
know,
use
cases
for
https
and
other
secure,
tls
connections
to
ip
addresses,
specifically,
for
example,
the
cloudflare
resolver
with
the
1.1.1.1
address.
So
ideally,
I
would
want
to
see
this
supported.
D
E
Martin
thompson,
out
of
the
queue
now
I
put
that
that
pull
request
together,
and
I
do
sort
of
appreciate,
where
you're
coming
from
rich
after
having
tried
that
it
is
a
little
bit
more
work
than
simply
just
adding
sort
of
one
bullet
point
and
removing
the
we
don't
do
ips
from
the
from
the
front
matter.
E
It's
not
my
document,
so
I
don't.
I
wasn't
able
to
identify
everything.
I
don't
think
very
confidently,
but
I
think
probably
the
most
interesting
aspect
of
this.
E
Yeah
example
yeah,
and
some
of
that
was
a
little
fiddly,
but
other
than
that
the
changes
are
pretty
straightforward,
that
what
you
would
imagine
goes
in
here,
so
hopefully
what
I've
got
there
would
be
enough
to
get
you
ninety
percent
of
the
way.
Unfortunately,
the
last
ten
percent
is
always
the
hardest
part.
E
You
to
do
it
yeah
to
some
extent
http
already
has
it
has
what
it
needs,
but
I
don't
think
the
text
in
rfc
9110
is
particularly
good.
Now
that
I've
looked
at
it
again,
I'm.
F
E
Looking
at
it
going,
oh
that's
gee
we
could
have
done
a
better
job
with
that,
and-
and
this
document
here
is,
is
that
much
better
job?
Okay,
so
I
like,
like
others,
I
think
I
think
the
worth
work
is
worth
doing,
even
if
it
means
one
more
cycle
and
a
little
bit
of
complication,
I'm
happy
to
help.
I'm
I
tried
to
help,
but
that's
about
the
extent
of
my
ability,
I'm
afraid,
because
yeah
you
know
the
document
better
than
I
do
sure.
B
Yeah,
I
don't
want
to
overstate.
I
don't
want
to
sound
like
a
grumpy
old
man,
so
I
don't
want
to
overstate
my
concerns
about
it.
I'm
really
whatever
the
working
group
wants
is
fine.
You
know,
I
should
also
mention
we're
about
to
submit
a
draft
that
shows
how
to
use
ip
addresses
in
sni
fields.
B
A
So
all
right
so
quick
sense
of
the
room
and
I'll
I'll
use
the
hand
raising
tool
if
people
really
want
me
to,
but
otherwise
I'll
just
sort
of
do
it.
This
way
in
this
room.
C
A
C
D
G
B
A
Because
so
I
I
would
actually
want
don't
want
the
working
group
to
block
on
this
right.
So
if
we
we
want
to
sort
of
either
proceed
with
like
a
a
clear
commitment
from
authors
to
to
kind
of
come
back
with
a
separate
document
or
like
we
proceed
with
this
pr
or
we
decide
that
this
is
not
work
worth
working
on
at
all.
So
I
don't
want
us
to
hang
in
limbo
here
so
martin,
you
wanna.
E
Yeah
I
wanna
ask
alexi.
Why?
Because
I
think
the
y
is
more
important
here
at
this
point
than
just
saying
this
one
or
the
other
one.
E
G
Well,
I
think
your
comments
about
certain
things
wouldn't
apply
to
be
addresses.
It
just
made
me
concerned
and
if
it
doesn't
fit
quite
right,
you
know
just
make
it
a
separate
document.
So.
E
Yeah,
so
the
reason
that
I
think
this
document
is
a
better
place
for
that,
aside
from
having
everything
in
one
place,
is
a
nice
and
one-stop
shop
for
people
who
are
looking
to
reference.
These
things
is
that
there
are
some
interactions
with
the
existing
things,
and
that
was
the
complicated
part
of
getting
the
work
done.
E
It's
not
super
complicated
or
anything,
but
having
an
extra
document
that
comes
in
and
surgically
amends,
the
the
various
pieces
of
of
an
existing
document
to
to
put
ip
addresses
in
there
is
somewhat
more
complicated
than,
and
then
I
think
getting
it
done
here
now
that
the
patient's
open.
G
Okay
yeah,
my
coverage
is,
I
haven't
reviewed
your
pr
yet
so
maybe
I
can
commit
to
doing
it
within
next
few
days
or
something
like
that.
A
All
right
does
anybody
feel
strongly
against
progressing
with
pr54.
A
B
A
A
I
Hi,
are
there
name
constraint
issues
that
perhaps
would
add
some
complexity
for
ipid?
Do
we
have
a
specification
for
ipid,
name,
constraint,
processing
and
also
does
that
live
here,
or
would
that
be
5280
and
refinements.
B
So
the
doc
right
now
talks
not
at
all
about
name
constraints
which
I
think
are
kind
of
horked
anyway.
Right
so
presumably
would
be
50
20
50
to
80
bis,
which
is
never
going
to
happen.
B
E
So
so
the
answer
there
is
that
there
are
no
names
name
constraints
defined
for
ip
addresses.
Nor
do
I
expect
there
to
ever
be
given
rich's
point
about
5280
being
set
in
stone
in
a
way
that
I
think,
is
probably
not
a
bad
thing
entirely.
B
A
E
Yeah,
so
I
was
going
to
suggest
that
now,
let's
not
expect
rich
to
do
all
of
the
work.
I
think
peter
was
interested
in
spending
a
little
bit
of
time
on
this
one.
The
the
editors
can
collab
if
they
want
to
ask
me
to
do
something,
I'm
willing
to
do
that
if
alexi
reaches
a
different
conclusion
and
wants
to
propose
an
alternative
way
once
he's
had
a
look
at
it.
If
anyone
else
wants
to
do
the
same,
we
can
do
that,
but
that's
okay.
I
think
at
this
point
I'd
propose.
E
We
leave
it
with
the
editors
to
sort
through
what's
there
and
if
we
get
more
feedback
about
it
from
people
who
have
committed
to
review,
then
we'll
we'll
discuss
that
all
right.
A
That's,
I
think,
I
think,
that's
an
excellent
idea
all
right.
Let's
just
let's
do
that
and
then
continue
this
confirm
on
the
list.
Okay,
all
right
and
please
people
who
have
stood
up
and
said
that
they
wanna
that
they
are
volunteering
to
review
the
current
pull
request
or
you
know,
contribute
other
material.
Let's
try
to
get
that
done
as
quickly
as
possible,
so
we
can
get
the
ball
rolling.
B
Yeah
one
thing
I'll
mention
is:
if
you
haven't,
please
read
the
current
draft
because
I
think
it's
maybe
I
have
an
inflated
opinion
to
myself,
but
it's
pretty
clear
and
simple
about
how
to
do
things,
which
is
important,
I
think,
for
the
community,
and
so
then,
when
we
do
add
ip
addresses,
we
want
to
make
sure
that
we
don't
lose
that
clarity
and
simplicity
more
than
we
have
to.
A
C
Yeah,
just
briefly,
I
looked
yesterday
5280
and
it
does
define
name
constraints
for
ip
addresses.
They're,
like
other
gaps
with
search
and
ip
address,
that
we
someday
will
want
to
deal
with
what
name
constraints
at
least
does
seem
to
be
intuitive.
A
A
It
for
for
your
slots-
let's
see
here
next
on
our
agenda
iot
profile
on
this.
H
Next
slide,
okay,
so
the
first
one
is
so,
as
you
know,
in
dls1.3,
to
use
the
serial
rtd
feature,
you
have
to
come
up
with
an
application
specific
profile
to
describe
how
you
deal
with
sort
of
the
needed,
replay
protection,
and
so
in
an
earlier
document.
H
We
added
that
feature
and
also
did
sort
of
discuss
this
and
and
announce
it
on
the
co-op
list
where
it
was
actually
debated,
and
it
turned
out
that
the
co-working
group
right
now
doesn't
see
interest
in
or
need
for
the
serial
rtd
feature
in
dls
for
some
of
their
uses.
H
So
with
that
in
mind,
we
decided
to
take
it
out
from
this
document
actually
park
it
into
a
separate
specification
that
maybe
just
temporarily
as
or
people
are
just
happy
with
the
way
dls
is
because
there
are
obviously
some
ups
and
downs
of
using
the
zero
rtd
feature.
So
that's
where
we
are
today,
at
least
so
it's
not
like
not
gone
forever,
but
at
least
for
now,
so
that
makes
the
document
shorter.
H
So
that's
a
plus,
because
there's
a
you
need
to
define
a
couple
of
additional
co-op
options
to
make
that
feature.
Work.
Okay,.
H
The
other
one,
which
is
a
little
bit
more
tricky,
is
the
recommendation
on
the
the
domestic
ecdsa
which
we
sort
of
took
over
from
the
previous
dls
and
dtls
1.2
iot
recommendations,
as
well
as
from
what
the
the
dls1.3
specification
says.
H
So
the
recommendation
there
is
to
use
deterministic
ecdsa
and
but
then
it
seems
that
the
sort
of
focus
or
the
excitement
has
changed
again
in
terms
of
that
feature,
and
there
are
obviously
currently
discussion
in
cfrc
on
adding
the
noise
or
randomness
back
into
the
ecdsa
function,
as
I
will,
as
you
will
see
on
the
next
slide.
But
the
point
here
is
that
there
are
attacks
and
specifically
exploiting
the
weakness
that
the
that
random
number
generation
is,
of
course,
a
challenging
topic
on
iot
devices
and
non-iot
devices.
H
Specifically,
if
you
have
access
to
those
devices-
and
you
can
mount
fault
injection
attacks,
of
course,
iot
devices
are
often
you
or
the
attacker
often
has
physical
access,
so
those
attacks
would
be
applicable
and
even
though
we
see
a
increase
in
sort
of
hardware
based
features
for
security,
including
random
number
generation,
there
is
at
least
the
perception
that
those
are
not
as
good
as
they
they
could
be,
which
I
don't
want
to
quantify,
because
it's
obviously
depends
on
from
product
or
I'm
sure
that
the
features
vary
from
product
to
product.
H
So
I
don't
want
to
make
a
general
statement,
but
at
least,
if
you
look
at
those
attacks,
there
are
cases
where
devices
have
had
limited
randomness
in
and
obviously
that,
when
applied
to
some
of
the
our
protocols
and
also
the
the
the
signature
mechanisms
that
causes
problems.
H
What
I
personally
on
next
slide,
I
struggle
then
with,
is
to
actually
make
good
recommendations,
because
even
a
protocol
like
dls
there's,
so
we
need
sources
of
randomness
in
various
places
and,
for
example,
not
just
with
ecdsa,
but
also
with
the
ephemera
different
helmet
or
with
the
with
the
randomness
that
is
sent
around
in
a
clientele
sub-hello
exchange.
But
in
my
belief,
if
you
don't
have
any
randomness,
then
you
are
set
yourself
up
for
problems.
H
But
what
should
the
recommendations
be
in
that
case,
and
so
thomas,
who
is
also
working
on
the
generic
utah
dls
1.3
recommendation
document,
which
is
sort
of
separate
from
the
iud
recommendation
there?
Obviously,
there
are
some
recommendations
being
made
which
are
now
sort
of
carried
over
to
into
this
document.
H
So
it's
easy
to
write
those
document,
those
recommendations
in
some
sense,
it's
another
story
to
actually
ex
implement
them
in
in
real
hardware
and
real
software
on
iot
devices.
But
I
think
that's
that's
as
much
as
as
we
can
do
at
this
point
in
time.
H
Okay,
thank
you.
Thanks
to
michael
richardson,
I
don't
see
him
right
now
in
the
room,
but
he
has
done
a
very
detailed
review
in
response
to
a
presentation
I
gave
at
the
iot
ops
meeting
at
the
last
idf,
and
this
is
one
that
we
addressed
already
it's
one
that
concerns
the
use
of
intermediate
ca
versus
subordinate
ca,
which
we
were
a
little
bit
relaxed
on
on
using
the
terminology
from
rc
49
49.
So
we
addressed
that
one.
H
As
you
will
see
later,
he
had
a
couple
of
other
reviews
which
we
addressed
already,
but
he
didn't
indicate
whether
he
is
happy
with
them.
So
we
didn't
incorporate
them
into
the
documentary
waiting
for
his
final
assessment
before
we
are
going
to
do
that
next
slide.
H
Okay,
so
a
few
open
issues,
one
is
what
we
call
the
feature
disparity
is,
and
that
was
also
discussed
on
the
tls
mailing
list.
Not
just
on
the
utah
list
is
with
certain
features
that
were
they
are
different
between
1.2
and
1.3,
which
are
kind
of
subtle,
for
example,
on
the
slide.
This
concerns
the
renegotiation
which
apparently,
some
people
used
in
dls
1.2
to
check
the
certificate
status
at
a
later
stage,
so
the
for
long-lived
tls
connections
they
are
apparently
which
are
which
are
used
in
industrial
iot
networks.
H
Checking
again,
we
went
through
the
discussions
on
the
dls
list
and
tried
to
capture
some
of
it
in
this
issue
that
is
linked
here,
but
it's
not
so
easy
to
to
really
make
a
recommendation
on
what
to
do
about.
Some
of
those
different
features.
Clearly,
renegotiation
is
done,
is
is
gone,
but
should
it
should
there
be
some
some
extensions
being
added
back
to
dls
to
enable
some
of
those
features
or
is
the
solution
that
has
been
used?
H
Actually
not
the
right
approach
to
begin
with,
and
that's
specifically
on
that
front,
the
long-lived
dls
connections
and
using
that
the
renegotiation
feature
to
check
the
status
of
certificates.
Is
that
actually
the
best
way
to
do
I'm
not
sure
in
either
case
the
dls
extension
is
not
something
that
we
can
incorporate
or
new
extension
incorporate
into
this
document
anyway,
and
for
the
other
one
it's
even
if
we
make
that
recommendation.
H
E
Yeah,
honest:
have
you
considered
the
use
of
the
exported
authenticators
for
this
purpose.
E
So
it
would
require
something
at
the
application
layer
that
you
would
essentially
have
one
side
challenge
the
other
other
side
to
to
present
an
exported
authenticator,
and
you
would
that
other
side
would
then
produce
what
is
effectively
a
certificate
and
a
signature
using
that
certificate
over
something
exported
from
the
various
secrets,
and
that
would
allow
you
to
refresh
your
view
of
the
currency
of
the
certificate
that
was
used
on
the
connection.
Maybe
you
don't
need
to
provide
a
certificate.
You
just
provide
the
authenticator,
but
okay,
that's
recently.
That's.
H
A
that's
a
interesting
approach.
I
don't
think
that
was
actually
proposed
on
the
list.
I
went
through
the
discussions
and
didn't
don't
think
I
saw
that
one
it's
probably
worthwhile
to
explore,
but
it
was
stephen
fries
from
siemens
who
brought
this
up
because.
J
E
Will
definitely
double
check
things.
Yeah,
there's
a
number
of
things
you
can
do
that
might
help
so
the
the
re-keying
that
happens.
The
key
updates
allow
you
to
refresh
keys
and
give
you
some
degree
of
post
compromise
security,
but
this
would
allow
you
to
refresh
the
credentials
what
you
don't
get
is
fresh
entropy
for
the
session.
So
you
don't
get
the
ability
to
do
another
dippy
helmet,
for
instance.
That
may
actually
be
a
feature
from
the
iot
perspective.
I
don't
know
so.
Yeah.
H
H
What
the
right
answer
is:
yeah,
there's,
probably
a
it.
Probably.
What
we
would
need
is
almost
like
a
problem
statement
with
assumptions
to
find
out
like
what
specific
attacks
do
we
care
about,
and
and
do
we
care
about
like
like
what
keys
are
we
expecting
to
double
check
whether
they
are
compromised?
Is
it
a
long-term
key?
H
Is
it
something
like
if
we
do
a
key
update,
for
example,
clearly
we
wouldn't
recognize
whether
the
the
certificates
used
in
a
mutual
dls
exchange
have
been
compromised
and
and
so
on
and
so
on,
and
so
so,
maybe
maybe
that's
sounds
like
a
good
idea
to
actually
use
that
example,
as
as
a
trigger
to
debate
what
exactly
the
requirements
are.
Yeah.
K
Hi,
hannes
good
to
see
you
yeah
just
to
shed
some
light
on
the
requirements,
so
the
requirement
goes
back
to
to
one
of
the
tls
usages
that
we
have
in
power
system,
automation
and
there.
It
is
a
way
that
currently,
we
used
in
the
renegotiation
feature
in
tls
1.2
to
trigger
the
certificate
as
a
certificate
revocation
check.
K
So
that
means
that
we
basically
have
some
kind
of
timer
in
the
application
and
once
the
timer
is
up,
the
certificate
gets
rechecked.
We
can
do
the
certificate.
We
can
do
the
the
key
update
in
tls
1.3
using
the
post
handshake
messages,
but
the
certificate
check
would
still
need
to
be
done
and
in
dls
1.3
we
had
the
possibility
to
basically
take
the
certificate
that
comes
out
of
the
handshake
and
then
give
it
up
to
the
application
and
the
application
can
do
the
revocation
check
again
now.
K
So
that
was
the
basic
requirement
there
and
the
requirement
comes
from
the
fact
that
once
in
a
while
the
certificate
for
long
I'm
sorry,
the
certificate
for
long-lived
connection
is
required
to
be
to
be
checked
for
the
for
its
revocation
state
to
ensure
that
it
is
still
valid.
Why
is
the
sessions
running.
H
Thanks
thanks
jeff
yeah
that
was
good
back
on
so
in.
We
obviously
have
to.
I
Victor
de
carney,
google,
I
have
a
question
for
stefan
actually
why
or
rather
what
threats?
If
you
could
explain
on
list
or
if
not
now,
do
we
want
to
know
whether
the
certificate
is
expired?
Given
the
sessions
already
established,
it'd
be
good
to
know
what
the
actual
reason
is
beyond
just
doing
the
thing
we've
been
doing.
H
A
Yeah
yeah,
stefan
you
you
want
to
come
back
to
this
in
in
a
minute
or
two
and.
A
It
into
the
chat,
honest
has
a
few
slides
to
go
so
yeah.
H
Yeah,
so
in
any
case,
regardless
of
what
the
conclusion
is,
we
need
to
sort
of
like
say
some.
I
think
we
need
to
say
something
in
a
document
and
explain
like
for
those
who
who
have
been
using
dls
1.2
what
that
means
in
1.3
as
they
move
over
okay.
Next,
one.
H
So
this
is
the
one
I
mentioned
previously.
There
were
two
items:
client
certificate,
validation
and
also
sni,
hiding,
which
are
two
separate
issues.
Waiting
for
michael's
input
won't
go
into
those
details,
so
obviously
in
the
item.
I
would
ping
him
during
this
week.
So
hopefully
he
has
some
cyclers.
H
And
the
other
one,
what
one
other
issue
or
two
other
issues
are
related
to
profiling
of
timers.
That's
something
we
did
in
the
previous
profile
for
1.2
when
we
noticed
that
the
use
of
dtls
this
is
a
dtls
feature.
The
default
recommendations
for
the
timeouts
were
not
really
adequate
for
some
of
the
iud
networks,
specifically
mesh
networks
which
have
a
high
latency
and
potentially
high
loss
rate,
and
so
we
we
went
through
a
long
effort
to
sort
of
adjust
those
timers.
H
Of
course
the
1.3
is
a
little
different,
so
we
have
to
figure
out
what
the
timers
are
and
then
also
with
the
rrc
sort
of
the
the
checking
or
the
the
document
that
we've
been
working
on
in
the
dls
working
group
to
do
the
the
the
checking
needed
for
the
path,
validation
for
the
connection
id
changes.
H
A
All
right
so
we're
looking
at
a
couple
more
iterations
before
we're
ready
to
shepherd.
H
At
least
at
least
definitely
one
to
address
those
comments
as
you
like,
it's
we're
getting
down
to
sort
of
coming
to
the
end
on
this
yeah.
Okay.
So
all
right.
A
All
right,
thank
you
all
right,
and
that
gets
us
to
joe
see
if
I
can.
No,
I
didn't
want
to
share.
Let's
try
that
here
we
go
back
to
syslog
all.
L
A
L
Back
to
says
slog
again,
so
you
can
go
to
the
next
slide
yeah.
This
just
is
a
document
that
chris
and
sean-
and
I
are
working
on
the
kind
of
summary
here
is.
This-
has
recently
been
adopted
as
a
working
group
item,
which
is
fantastic,
we're
basically
updating,
cipher,
suites
and
and
transport
protocol
for
for
these
various
rfcs
and
really
what
prompted
this
was.
L
The
iec
tc57
wg15
group
was
reusing,
was
referencing
these
specs
and
the
the
specs
reference
some
older
cyber
suites
and
tls
versions,
which
they
in
order
to
be
compliant
with
the
specs.
They
would
have
to
implement
the
old
things
they
don't
want
to
do
that,
obviously,
for
for
good
reason,
so
we're
kind
of
we
we
fixed
up
these
particular
problems
in
the
zero
zero
draft.
L
And
you
know
recent
versions
of
tls,
including
tls,
one
three
next
slide
the
only
major
change
in
the
zero
one
draft
is
around
zero
rtt.
L
We
decided
that
we
shouldn't
use
zero
rtt
with
and
we
should
be
explicit
about
it
with
syslog
syslog
doesn't
really
have
a
replay
protection
and
in
many
cases,
zero
rtt.
It's
not
really.
I
don't
we.
We
didn't
feel
this
would
be
a
very
widely
used
feature
either,
because
connections
tend
to
be
long-lived,
so
we
say,
must
not
use
early
data
next
slide,
so
we've
already
published
a
zero
one,
so
we'd
love
to
get
some
more
review.
A
A
Phone
number
can
I
get
a
few
of
you
to
like
say?
Yes,
I
will
review
this,
so
we
can
get
victor
on
this
right
right,
that's
good!
So
we
can
get
victor
and
hannes
on
the
record
having
having
volunteered
to
review
that
sort
of
gets
us
that
much
closer
to
working
group
last
call
and
like
shepard.
That's
very.
A
Great,
that's
it
which
takes
us.
It
gets
us
to
open
mic
for
this
meeting
and
if
nobody
has
anything.
J
Ben
schwartz
on
the
topic
of
ip
address
identities
and
certificates.
I
I
wanted
to
mention
that
the
add
working
group
has
run
into
an
interesting
situation
where
it
would
be
very
convenient
if
there
were
a
way
to
mint
a
certificate
that
claims
all
the
ip
addresses
in
a
subnet.
J
So
so
that
somebody
who,
for
example,
an
isp
that
owns
a
wide
ip
range,
could
have
a
certificate
that
says
yes,
I
am
willing
and
able
to
terminate
traffic
for
for
all
of
the
all
of
the
identities
and
this
all
the
ip
address
identities
in
this
range.
J
A
And
this
is
related
to
the
the
public
suffix
licks
list
stuff
right.
J
So
the
the
motivation
to
briefly
the
the
motivation
is
that
the
the
add
ddr
mechanism,
if
the
if
the
home,
gateway's
dns
server,
is
identified
by
a
public
address
like
a
public
ipv6
address
as
opposed
to
a
link
local
address,
then
the
encrypted
dns
server
must
present
a
certificate
that
covers
that
ipv6
address,
and
so,
if
an
isp
wanted
to
operate
an
encrypted
dns
service
for
all
of
its
users,
then
in
this
configuration
they
would
first
of
all
per
eric's
comment
that
they
would
need
some
way
in
the
sni
to
find
out
which
ip
address
the
client
is
trying
to
connect
is
trying
to
find
a
substitute
for,
and,
secondly,
they
would
need
separate
certificates
for
for
every
single
ip
address
of
every
single
dns,
resolver
and
all
of
their
customers
home
gateways.
J
I
Victor,
yes,
hi
victor
mccartney.
I
have
a
question
I
guess
for
for
the
working
group
in
terms
of
where
to
propose
something
I'd
like
to,
I
think,
having
possibly
an
extension
for
a
tls
client
to
tell
the
server
to
solicit
its
certificate
because,
as
we
know,
tls
client
certificates
are
optional.
If
the
server
doesn't
ask
for
them,
the
client
can't
present
them,
and
yet
some
servers
for
interoperability
reasons
prefer
not
to
ask
for
them
by
default.
I
If
a
client
knows
that
it
is
desirable
to
present
a
certificate,
but
the
server
is
likely
not
to
solicit
them
by
default,
there
could
be
a
need
for
a
message
for
a
client
to
say
hi.
I
have
a
certificate
in
in
the
client,
hello
or
somewhere
early
on
without
disclosing
much
detail
about
it,
because
but
privacy
issues
until
it
goes
into
certificate
extensions
in
tls103
and
is
encrypted.
I
So
I'd
like
there
to
be
an
early
message
to
say:
please
grab
my
certificate,
I'm
interested
for
this
in
email,
where
I
could
do
it
in
an
esmtp
hello,
but
it
kind
of
seems
like
the
wrong
layer.
Should
I
take
this
to
the
tls
working
group
to
utah,
should
I
just
do
it
in
the
esmtp
which
unasks
the
question
but
kind
of?
Does
it
at
the
wrong
layer
any
thoughts
or
comments.
M
A
M
M
E
I
was
just
going
to
say:
there's
nothing,
stopping
someone
in
any
working
group
here
or
even
groups
outside
of
the
ietf
from
defining
tls
extensions.
That's
not
the
problem.
The
problem,
I
think,
would
be
the
charter
of
this
group,
which
I
think
probably
maybe
doesn't
include
the
ability
to
do
that
without
a
rechartering.
M
A
Yeah,
certainly,
a
group
that
had
had
a
life
expectancy
far
beyond
sort
of
the
initial
set
of
best
practice
documents
that
I
think
people
were
envisioning.
I
I
would
encourage
you
to
write
something
up,
draft
up
and
presented,
and
we
can
talk
about
that
option
here
or
in
the
whatever
working
group
makes
sense.
So
I
I
you
know
personally,
I
think
it
sounds
interesting
too.