►
From YouTube: IETF115-SECDISPATCH-20221110-1700
Description
SECDISPATCH meeting session at IETF115
2022/11/10 1700
https://datatracker.ietf.org/meeting/115/proceedings/
A
Okay,
welcome
everyone.
My
name
is
the
new
co-chair
along
with
the
Kathleen
and
Richard,
and
that
are
remote
this
time
and
let's
get
going.
A
The
note
well
applies
here,
obviously
so,
if
you're
not
familiar
with
this,
make
sure
to
familiarize
yourself
with
this,
because
this
covers
everything
that
we
do
at
the
IDF
tips,
if
you're
in
person,
please
use
the
the
on-site
tool
client.
A
A
Just
a
reminder:
the
sick
dispatch
just
recommends
next
steps,
it
doesn't
adopt
any
draft
and
there
are
a
number
of
possible
outcomes
here.
They're
listed
here,
I'm
not
going
to
go
through
this,
so
our
agenda
here
we
have
four
presentations
and
we
will
allocate
15
minutes
for
the
three,
the
first
three
of
them
and
the
last
one
will
have
maybe
five
minutes
if
we
have
time
and
then
maybe
at
the
end,
a
little
bit
of
summary
from
the
chairs
and
a
few
minutes
from
the
ad.
A
At
the
end,
any
comments,
questions
about
this
okay,
we
will
start
with
httpa
go.
B
A
Okay
and
it's
sorry
I
just
wanted
to
mentioned
that
tarot
is
taking
notes
for
us
and
thank
you
taro,
okay,
who's
gonna
present
is
it
on
sounds
fine.
C
Yes,
laser
Heights.
Can
you
hear
me
okay,.
C
C
Go
ahead,
yeah.
Thank
you.
Thank
you.
Yeah
hello.
This
is
Hans
for
joining
from
Intel
and
I'll
quickly.
Talk
about
the
future
possibility
to
initiate
building
trust
for
the
modern
internet
and
next
slide.
Please.
C
Go
ahead
yeah,
so
in
the
modern
Internet,
it's
common
to
see
end
user's,
identity
are
not
well
protected
and
third
party
can
easily
access
private
content
under
the
end,
identity
and
sub
identities
of
the
user.
For
its
purpose,
lack
of
trust
is
a
big
problem
and
we
hope
our
work
can
draw
attention.
Initialism,
discussion
and
accelerate
the
transformation
towards
the
perfect
vision,
which
is
the
trustworthy
internet,
I
think
in
the
long-term
future.
So,
following
the
end-to-end
principle,
here
we
are
proposing
an
L7
protocol
to
help
achieve
trustworthy
web
services.
C
D
C
C
C
C
C
E
C
Just
protecting
data
in
transit
or
storage,
but
also
protecting
data
and
use.
In
addition,
a
great
example
is
T,
which
is
an
emerging
technology
that
we've
proposed
to
protect
data
and
use
and
is
a
reasonable
endpoint
for
HTTP
message.
Exchanges
T
is
an
emerging
resource
for
web
applications.
Mostly,
it
goes
very
well
with
the
CPU
for
application
developers
to
Leverage.
C
Hence
we
think
that
there
is
a
strong
need
for
unifying
remote
adaptation
on
T
for
HTTP
protocols,
so
that
in
the
future,
application
developers
can.
D
C
Each
GPS
needs
certificate,
Authority
or
CA
to
verify
the
identity
of
the
website
and
by
website.
It
means
in
practice,
is
most
likely
the
website
good
way,
not
the
web
service
itself.
In
this
scenario,
if
the
web
service
is
the
endpoint
that
there
is
a
violation
in
the
num
principle
that
middleman,
including
CSP
or.
C
C
Currently
in
agps,
the
whole
website
behind
the
gateway
is
the
endpoint.
Now,
let's
take
a
look
at
httpi,
there
are
actually
two
scenarios
for
HPI
unilateral
GPI
for
one-way
hdbi
between
the
web
service
inside
the
T
and
the
user
ID
at
the
end
and
mutual
agpi
between
two
T's.
In
this
picture
we
only
show
the
first
case
of
unilateral
hdbi
just
for
a
simple
explanation:
hevi
works
with
child
State's
authority
to
verify
a
collection
of
identities
of
the
web
service
run
inside
the
T
directly,
including
genuine
Hardware
software
software.
C
Vendors
Etc
HBA,
can
also
provide
a
simple
and
unified
way
for
users
to
authenticate
the
web
services
to
build
trust
by
remote
adaptation.
Remote
hesitation
is
the
key
method.
We
propose
to
verify
all
sorts
of
identity
set
for
including
software
hardware
for
Final
Ground,
Lottery
Authentication,
and
that's
what
I
mentioned
previously
previously.
The
new
HTTP
method,
we
are
proposing
HTTP
a
test,
so
that
user
can
expect
the
thing
what
happened
as
it
is
in
the
remaining
HTTP
transactions.
C
Anxiety
in
this
scenario
of
a
GPI
web
service
is
the
endpoint
middleman
between
the
web
service
and
users
cannot
access
the
encrypted
content,
even
in
the
situation
without
TLS
protection,
and
they
cannot
Forge
the
identity
either,
because
hdpa
allows
an
endpoint
to
select
the
part
of
the
message
for
encryption.
We
call
that
selected
privacy
and
the
whole
communication
between
endpoints
will
be
protected
with
authentication
and
integrity
guarantee
through
the
T.
C
A
G
Hi
room
engineer:
Carnegie,
Mellon,
University,
no
hat
just
to
kind
of
clarify,
I'm,
sorry
I
came
up
and
down,
because
I
was
trying
to
understand
that
the
setup
here.
So
it
really
isn't
about
how
many
middle
boxes
are
here,
whether
it's
an
application,
Gateway
or
the
fact
that
the
tee
is
on
a
box.
The
setup
is
you
want
to
tunnel
from
the
te,
irrespective
of
how
many
middle
boxes
are
there
to
the
user?
That's
the
motivation
for
the
extra
headers.
C
H
Harness
hi,
honest
traffic
in
general,
if
you
put
a
TLS
Gateway
somewhere
in
front
of
your
web
services,
the
expectation
is
that
you
would
offload
the
TLs
service.
That's
why
you
put
that
in
front
of
it.
So
I
think
from
that
deployment.
Point
of
view.
Nothing
changes!
If
you
don't
want
that
offload,
then
let
your
TLS
go
all
the
way
to
the
end.
H
Having
said
that,
you
could
probably,
if
you
want
to
truly
have
it
end
to
end.
You
could
put
something
into
the
application
layer
which
would
be
simpler
and
wouldn't
require
modifications
to
the
HTTP
protocol
itself,
which,
and
you
could
also
sort
of
layer,
different
sort
of
TLS
protocol
on
top
of
the
application
as
well.
If
you
want
so
I'm
I'm
curious
on,
why
you
don't
want
to
just
go
the
simplest
route,
which
is
if
an
application
needs
it
put
that
information
into
the
application
and.
I
A
Hands
hold
on
Jonathan,
just
one
second:
do
you
have
an
answer
to
what
do
you
want
to
answer
honest.
J
J
Jonathan
hoyland's
crowd
player,
so
your
httpa
communication
is
giving
you
confidentiality
Integrity,
all
the
things
you
want.
Why
have
a
TLS
Channel
at
all
right
you?
You
can
just
do
this
over
like
raw
internet
packets
and
adding
the
TLs
channel
is
just
sort
of
adding
noise.
It
doesn't
really
help
anything.
J
K
J
C
So
for
the
to
as
channels
it's
not
necessary
for
httpi,
and
we
don't
necessarily
need
that.
So
this
is
the
kind
of
things
need
more
discussion.
I
think
that
essentially
the
users,
the
interest
that
what
they
are
interested
into,
a
verifying
the
identity
is
that
a
website
or
the
web
service
itself.
That's
kind
of
the
question
why
trying
to
enter
and
if
it's
the
web
service
itself,
nothing
really
related
to
the
website,
then
probably
httpa
is
good
enough.
C
J
C
Yeah,
you
can
put
it
that
way.
It
doesn't
rely
on
TLS.
B
B
So
I
don't
know
if
you
want
to
go
over
in
the
feedback
now
or
represent
a
few
more
slides,
but
if
you
could
kind
of
get
to
it
in
the
presentation
has
some
time
for
feedback.
That'd
be
great.
I
Yeah
I
was
gonna
say
that,
like
maybe
like
we're
going
to
have
any
discussion,
we
need
to
like
have
like
no
more
slides
or
one
more
at
the
most
so
I'm
happy
to
have
to
wait
for
it,
but
like
what
would
shares
like
to
do
sorry?
What
was
that.
A
C
I
Oh
good,
okay,
yeah,
so
yeah
I
think
this
is
the
wrong
layer.
My
question
is
somewhat
like
Jonathan's,
but
I
think
perhaps
more
straightforward.
I
The
right
place
is
the
TLs
layer,
not
at
the
HTTP
layer
like
I
understand
you
like
want
to
have
like
a
Gateway,
but
like
this
is
going
to
create
all
kinds
of
confusion
about
the
situation
in
terms
of
like
what
can
the
Gateway
do
and
what
the
game
we
cannot
do
if
you
have
a
lot
of
selective
encryption
or
selective
signature
like
there's
been
like
all
like
history
of
enormous
amounts
of
shenanigans
with
a
slice
of
signature,
it's
like
the
right
way
to
solve
this
problem
is
to
like
have
this
like
terminate
on
the
TLs
server
if
like.
I
If
this
problem
need
to
be
solved
at
all,
which
I
am
like
somewhat
skeptical
of
and
I,
think
so
saying
that
maybe
that
so
maybe
I'll
even
back
up
and
ask
the
question:
how
do
you
envision
this
being
deployed
so
do
this?
Is
this
for
the
web,
for
instance,.
C
We're
envisioning
this
for
the
web
instance.
Yes,.
I
C
Yeah
so
this
requires
like
we
need
to
build
some
share
library
and
then
have
some
browser
plugin
that
will
have
some
browser
plugin
to
pass
it
to
pass
that
information
for
this
complication.
No.
I
C
So
far,
I'm
not
quite
sure,
yet
this
is
still
kind
of
a
concept.
So
far,
okay,.
I
So
I
think
that
I
think
that's
the
for
me
that
we,
the
predicate
question
for
taking
this
up
for
ITF,
so
I
think
the
answer
from
my
perspective
and
perhaps
other
browser
vendors
have
similar
ways
is
come
back
when
someone's
some
browser
is
interested.
I
A
F
L
This
is
the
problem
when
you
can
sit
down
and
be
in
the
queue
so
I
I
have
significant
concerns
about
how
this
uses
HTTP
I.
Think
it's
maybe
an
extension
of
ecker's
comments
that
about
the
layering
I'm,
not
at
all
sure
that
this
is
an
appropriate
candidate
for
a
new
HTTP
method
and
I
encourage
you
to
read
both
the
HTTP
semantics
document
on
HTTP
methods
and
what
the
requirements
for
them
are
as
well
as
BCP,
56.
L
I.
Also
I
think
I've
communicated
this
poor
it.
This
is
not
a
good
name.
Https
was
probably
a
mistake.
I
think
this
is
an
extension.
If
it's,
how
did
that
happen
exactly
if
this
is
going
to
come
in
at
the
HBO
later,
which
I
think
is
a
big
if
it's
an
extension
to
http?
It
is
not
a
new
named
HTTP,
but
I
think
what
really
needs
to
happen
is
the
community
needs
to
have
discussion
about
use
cases
requirements.
L
M
Hi
I
just
wanted
to
encourage
you
to
look
at
the
existing
multi-layer
work
in
HTTP,
particularly
HTTP
connect,
UDP
or
math,
and
web
transport
that
seem
like
they
can
probably
Express
this
in
a
more
natural
way,
where
there's
a
a
TLS
session
to
the
Gateway.
If
there's
Gateway
level
logic
and
then
an
end-to-end
TLS
session
into
the
trusted
environment
inside
that.
F
Thanks
Ted
dispatch
outcome,
I
recommend
no
action
at
this
time.
I
strongly
agree
with
all
of
what
Mark
Nottingham
said
about
its
use
of
HTTP
I.
Think
the
method
is
completely
in
in
need
of
a
rethink
and
I
think
some
discussion
as
well
about
how
it's
using
the
headers.
If
it
stays
at
the
HTTP
layer,
it
needs
to
start
over
and
I.
Think
Mark
is
correct,
that
it
doesn't
belong
there
and
so
I
think
no
action
thanks.
K
I
agree
with
the
no
action
from
other
people.
I
also
think
that
there
are
some
pretty
serious
privacy
concerns
if
this
would
actually
apply
if
the
server
could
request
attention
from
the
client
I
heard
bi-directional
early
on,
and
this
strikes
me
as
some
kind
of
Mega
cookie
of
like
having
been
approved.
That
I
am
this
particular
device,
so
I
I
think
no
action.
There's
a
lot
of
unanswered
questions
here
and
I.
Don't
think
it's
fully
big
enough
freedom
to
start.
B
All
right
so
just
to
wrap
up
the
dispatch
outcome
here
sounds
like
there's
pretty
good
consensus,
there's
no
action
for
now
and
there's
some
good
feedback
that
there's
needs
to
be
a
little
bit
more
thought
of
how
this
fits
in
with
the
TLs,
the
web
transport
sort
of
architecture.
So
thanks
for
the
presentation,
Hans
and
next
up
is
thank.
N
P
Hi,
my
name
is
Graham
leggetts
I'm
brand
new.
So
please
be
nice
to
me
and
don't
jump
on
me.
Yeah
I
can
as
long
as
as
long
as
no
one
bites
me.
That's
fine
I,
wear
a
number
of
hats.
P
I
come
from
Apache
software
Foundation
did
a
number
of
a
lot
of
work
on
httpd
way
back
when
further
to
the
present
there's
a
project
called
a
red
wax
project
which
is
aiming
to
put
a
whole
lot
of
web-based
Technologies
anything
anything
that
crosses
Security
in
the
web,
like
Skip,
and
this
sign
public
key
and
challenge
we're
trying
to
find
things
that
are
broken
and
fix
them.
And
one
thing:
that's
broken
is
this:
so
if
you
can
jump
to
the
next
slide
quickly,.
P
You
no
am
I.
P
Okay,
go
ahead.
It's
reading
from
my
notes.
Sorry
about
that.
So
what
is
it
it's
an
asn1
structure?
It
contains
a
public
key
and
a
challenge,
as
you
would
imagine
from
the
title
and
they're
signed,
and
that's
basically
it
if
you
jump
to
the
next
slide.
What
I'll
do
is
go
into
some
history.
P
Some
people
might
be
old
enough
to
remember
the
1990s.
There
was
a
company
called
Netscape
and
they
invented
a
thing
called
a
web
browser.
Some
people
might
be
familiar
with
that
and
in
inside
that
web
browser
was
a
thing
called
the
Keygen
tag.
What
the
Keygen
tag
did
is,
if
you
embedded
that
on
a
web
page,
what
the
web
page
would
do
is
generate
a
key
pair
for
you
and
then
submit
proof
of
possession
of
that
key.
P
The
key
gen
mechanism
eventually
became
part
of
the
HTML5
specification.
You
can
jump
to
the
next
slide
quickly,
so
at
the
same
time
also
in
the
1990s
there's,
another
company
called
Microsoft
that
people
might
have
heard
of
they
invented
a
different
mechanism.
There
was
a
big
fight
between
the
Netscape
people
and
the
Internet
Explorer
people
same
problem
being
solved
problem
being
that
the
private
key
was
generated
in
the
browser
and
never
left
the
user's
possession
their
decision
on
how
to
solve.
P
It
was
to
use
a
certificate
signed
request,
and
that
was
the
thing
that
went
over
the
Internet.
This
still
exists,
you
can
have
it.
It's
called
it's.
It's
exists
inside
Internet,
Explorer
compatibility
mode.
If
you
use
Microsoft
Edge
anyway,
we
jumped
forward
if
we
jump
forward
one
slide
and
about
15
years
Firefox
and
Google
in
the
mid
2010s
said
yeah.
Now
we're
going
to
take
this
out
and
specifically,
they
took
out
key
gen
from
the
browsers
and
they
took
Keygen
out
of
the
HTML5
specification
justification
quite
valid,
really.
First
one.
P
P
It
is
not
a
standard
and
for
that
reason,
I'm
standing
here
now
I
hope
to
make
it
a
standard
just
so
that
at
the
very
least
we
can,
we
can
put
a
bit
of
History
under
this
piece
of
the
internet,
the
Sophie
jump
to
the
next
next
slide.
We
get
to
the
point
of
why
bother
doing
this
work
in
the
first
place.
P
It
exists
in
openssl,
exists
in
NSS,
it
exists
various
places
on
the
internet,
and
this
code
allows
you
to
create
a
message
and
that
message
allows
you
to
prove
that
you
possess
a
private
key.
We
don't
like
throwing
away
good
code,
it's
been
there
for
20
to
30
years.
It's
widely
deployed
in
all
sorts
of
operating
systems.
All
sorts
of
libraries
throwing
it
away
is
a
waste.
P
So
there
is
a.
There
is
still
a
need
for
this
problem
to
be
solved.
P
So
if
we
jump
to
the
next
slide
the
goals
of
this,
if
I
zoom
in
on
my
phone,
because
I
can't
see
properly
the
goals
of
this
is
to
formally
Define
the
spkoc
format
properly
to
the
standards
of
the
ITF
and
then
go
to
each
of
the
implementations
out
there.
Openssl
is
one
that's
already
been
done,
but
there
are
others
and
update
those
implementations
to
make
sure
that
they
are
clearly
indicated
as
following
a
standard
and
fix
any
shortcomings
in
them.
P
The
big
shortcoming
that
did
exist
in
openssl
was
that,
despite
signed
public
key
and
challenge
not
depending
on
any
particular
kind
of
hash,
the
guys
who
came
up
with
key
gen
said
md5
is
good
enough
for
everybody
and
they
hard-coded
that
into
keychain.
Obviously,
that
is
evil,
and
in
this
particular
spec
we've
we've
updated
it
to
indicate
2020's
practice
and
don't
hard
code,
your
your
hashes
and
the
end
goal
ultimately.
Is
we
want
people
to
be
able
to
use
this
message
to
prove
they're
in
possession
of
a
private
key?
P
If
we
jump
to
the
next
slide,
we
get
our
non-goals.
So
one
of
the
things
in
the
specification
is
that,
yes,
there
was
a
lot
of
history,
Netscape,
Microsoft
Etc.
At
the
end
of
the
day,
this
particular
speaker
specification
only
focuses
on
proving
you
have
a
private
key.
It
doesn't
go
into
Keygen.
It
doesn't
go
into
a
search
enroll,
which
was
the
name
of
the
Microsoft
implementation.
P
That
is
a
little
history
of
where
it
came
from
and
how
we
got
here,
however,
that
ultimately
isn't
important
in
the
spec.
We
do
not
want
to
change
the
format.
It
works
entirely.
Fine,
as.
E
P
A
D
St
John's,
one
of
the
things
we
encountered
fairly
recently
was
the
issue
about
dealing
with
proving
possession
of
non-signing
keys.
P
The
that
is
another
problem,
so
we
would
like
to
solve
other
problems,
but
our
primary
thing
is
to
make
what
exists
today
a
standard,
because
it's
I'm
quite
sure
that
whoever
invented
it
in
1990
whenever
intended
it
to
be
a
standard,
and
they
didn't
get
that
far.
So
we're
sort
of
coming
decades
later
and
sort
of
finishing
the
job.
P
There
are
certain
things
that
we're
probably
not
going
to
solve,
or
maybe
we
can
solve
in
a
further
iteration
of
this,
but
certainly
the
first
goal
out
of
the
door
is
to
standardize
what's
there
so
that
people
can
then
use
the
code
confidently,
knowing
that
it's
not
going
to
get
ripped
out
of
openssl.
So
on.
I
So
I
will
say:
I
have
some
doubts
about
the
merits
of
this
idea,
but,
like
fortunately,
we
don't
debate
those
I
agree
documenting
is
some
value
and
the
correct
menu
for
that
is
the
v80
sponsorship.
If
you
want
to
start,
if
you
want
to
screw
with
it,
then
we
can
talk
about
standardizing
it,
but
but
if
we're
just
gonna
like
rubber
stamp,
it
write
it
down
somewhere.
That's
already.
Okay,.
J
I
I
agree
with
Eric.
Obviously
the
connect
correct
thing
is
just
informational
RFC,
but
if
you
are
changing
something
I.E
changing
the
use
of
md5,
then
you
are
not
documenting
current
practice.
P
Anybody
who
implements
Keygen
today
would
need
to
have
a
field
that
says
what
kind
of
hash
would
you
like
to
give
me
this
in,
as
opposed
to
just
because
previously
it
was
an
oversight.
Whoever
did
this
20
years
ago,
they
just
hard-coded
mt5,
because
it's
good
enough
for
everybody,
so
all
it
needed
was
a
hash
equals
name
of
hash.
So
this
isn't
a
huge.
P
It
isn't
a
huge
blocker,
because
there's
nothing
in
spkc.
That
says
you
have
to
use
a
particular
hash.
There's
a
field
that
just
says
what
hash
did
you
use
so
from
that
perspective,
I
think
it
is
quite
we
have
to
be
quite
I
mean
we
as
the
Royal.
We
of
writing
the
spec
have
to
be
quite
careful
about
not
conflating
misuse
in
the
past,
where
someone
hard-coded
a
hash
to
what
this
spec
tries
to
achieve-
and
that's
just
here
is
a
message
format.
J
Hash
to
you,
you
can,
you
can
write
an
informational,
RFC
document
it.
If,
if
you
want
to
change
it,
there
are
about
a
billion
and
one
different
options
that
already
exist
today
that
do
basically
this.
Q
In
the
point
of
not
wanting
to
change
it,
there
are
a
couple
things
probably
which
make
an
awful
lot
of
sense.
That
should
be
there,
which
are
not,
for
instance,
a
time
stamp.
So
I
would
recommend
that
your
document
say
not
just
we're
following
the
format
not
changing
it,
but
also
how
you
deal
with
or
or
or
accept
that
you
don't
have
those
other
fields
that
you're
accepting
that
this
format
doesn't
have
them
and
why
it
is
an
acceptable
practice
not
to
have
them.
P
Yes,
I
think
that
this
sort
of
so
we
have
code
that
exists
today,
we've
specified
the
specification
of
how
the
code
works
today.
This
is
a
very
compelling
reason
to
change
it.
What
would
be
great
is
to
change
it
in
such
a
way
that
it
is
backwards
compatible,
but
certainly
yes
and
I.
What
I
would
like
to
do
is
get
your
guidance
as
to
where
we
go
next
in
the
long
term,
yeah.
Q
P
Yes,
okay,
because
essentially
The
Challenge
part
I,
think
the
idea
behind
the
challenge
was
that
that
was
your,
your
we're
not
going
to
we're
not
going
to
replay
this
somebody.
Q
A
P
R
A
K
Go
ahead.
Sorry,
so
this
is
for
dispatch
questions.
This
is
clearly
informational
because
No
One's
Gonna
Get
actual
Change
Control.
If
the
goal
is
just
to
write
it
down
and
I
really
think
I
mean
I'm
going
to
agree
with
Bob
that
the
lack
of
context
for
this
challenge
protocol
is
pretty
problematic
from
what
we
currently
know
about
how
to
design
protocols,
but
I'm
going
to
disagree
with
Bob
that
the
thing
to
do
is
to
write
down
here's.
K
How
to
do
it
right
within
this
I
think
the
thing
to
write
down
is
security
considerations
that
say
here.
It's
missing
all
this
context.
We
know
better
than
how
to
do
this
today.
You
shouldn't
use
this.
You
should
use
some
other
protocol
if
it's
going
to
be
written
down,
I
really
think
the
security
consideration
need
to
call
out
the
fact
that
this
is
is
missing.
Stuff
we've
learned
the
hard
way
over
the
last
15
years.
S
P
S
P
It
depends
that
there's
certain
things
like
if
you
have
an
app
of
some
kind-
probably
not
a
browser
because
generally
the
browsers-
don't
let
you
do
this,
but
if
you
had
an
app
of
some
kind
that
told
that
said
to
your
your
DNS
provider,
your
Dane
provider,
I,
would
like
to
roll
over.
My
key
and
I
would
like
to
prove
that
I
possess
the
old
key
I'm
going
to
tell
you
a
new
key
here's
proof
of
possession
of
my
old
key.
Please
update
my
new
key.
P
This
could
potentially
be
used
in
a
in
a
in
a
system
like
that,
without
inventing
from
scratch
a
mechanism
to
prove
that
you
possess
a
key.
So
this
this
code,
this
ability
is
built
into
libraries
all
of
the
rest
of
it.
If
you
wanted,
if
you
had
that
use
case
and
I
certainly
will
do
in
the
future,
is,
is
the
ability
to
go
I?
Have
this
key
and
I
can
prove
it
and
I
don't
need
to
write
that
from
scratch?
I
need
I
can
just
use
this
Library
function,
which
depends
upon
this
I.
B
A
B
Was
just
gonna
summarize
the
discussion
so
far
and
then
hand
it
off
to
Roman
yeah,
Stephen
Stephen's,
closing,
comment
and
understanding.
It
seems
like
there's
general,
you
know
the
general
direction
of
the
room
is
toward
you
know
open
estate,
his
sponsorship
at
the
informational
level,
but
I'll.
Let
Roman
comment
on
his
willingness
to
sponsor
it.
P
B
One
thing
I'll
also
capture
in
the
summary
for
the
minutes,
though,
is
that
it's
going
to
be
important
to
get
the
security
considerations
right
here.
I
think
there's
a
bunch
of
notes
in
the
chat
and
it
was
raised
by
by
Bob
and
I
forget
who
else
have
been
like
that
yeah?
This
is
clearly
something
that
has
sharp
edges
and
then
you
know,
if
you're
going
to
integrated
a
new
app
that
you
should
be
very
careful
with
it.
So
I
think
that's
I,
hope
the
the
authors
can
take
that
feedback
and
adjust
accordingly.
B
E
Hello:
everyone,
my
name,
is
Tom
Franco
I'm
affiliated
with
arpa2.net
I'm,
also
new
here.
So
thanks
for
the
opportunity
to
have
some
time
here
to
pitch
our
draft,
we
have
been
working
next
slide.
Please,
on
a
draft
about
a
TLS
extension
called
TLS.
E
Kbh
I
don't
have
the
time
to
go
into
all
the
technical
details,
but
I
really
would
like
to
have
some
feedback
on
the
idea
in
general,
Is
it
feasible
or
not,
and
where
it
should
land
either
in
a
work
group
or
in
an
independent
stream
or
not
at
all,
so
feel
free
to
roast
me
if
it's
bogus
so
I'm
going
to
give
you
a
short
introduction
into
TLS
kdh
what
it
is
describe,
some
abstract
use
cases
and
then
have
a
short
discussion
next
slide.
E
Please
so
we've
been
drafting
a
specification
on
a
TLS
extension
that
enables
kerberos-based
authentication
for
TLS.
We
call
it
kerberized
diffie-hellman
and
we
basically
combine
the
worlds
of
Kerberos
and
TLS
without
going
into
all
the
details.
The
idea
is
that
you
get
your
ticket
from
the
KDC
and
use
that
in
a
TLS
handshake
to
get
a
nice
Channel,
binding
and
and
use
the
ticket
to
mutually
authenticate
both
parties
next
slide.
Please.
E
We've
defined
two
modes
of
operation
kdh
only
that
means
that
you
use
only
the
the
client
ticket
to
a
mutually
authenticate,
the
server
and
the
the
client
and
KDA
enhanced.
That
means
that
you
have
a
regular
server
to
client
authentication
based
on
a
certificate,
for
example
x509,
and
you
enhance
that
with
a
client
ticket
to
have
Cobra's
authentication
as
well
next
slide
base,
please.
E
So
what
could
be
potential
use
cases
without
going
into
much
of
the
concrete
cases
kdh,
so
Kerber
space
authentication
could
be
an
alternative
to
a
pki
as
well
as
pre-shaped
keys.
So
it
depends
what
what
you
need,
what
your
security
requirements
are.
But
there
are
certain
use
cases
where
you
want
the
centrally
managed
system
where
you
have
a
KDC
to
to
manage
your
users.
E
A
nice
side
effect
of
of
kerberos-based
authentication
and
the
channel
binding
that
we
have
achieved
is
that
you
also
Harden
your
TLS
channel
for
for
Quantum
Computing
attacks,
because
you
can
see
that
with
a
symmetric
entropy.
So
that
could
also
be
an
interesting
use
case.
E
The
other
way
around.
We
can
protect
the
Kerberos
sessions
with
TLS
and
then
achieve
perfect
forward
secrecy,
which
was
also
not
possible
currently,
and
we
could
use
TLS
kvh
as
a
spinago
alternative
or
replacement
whatever
you
want,
because
we
we
achieved
basically
this
this
authentication
on
the
transport
level
instead
of
on
the
application.
Level
next
slide,
please
so
there
was
it
in
a
nutshell.
E
The
question
is:
is
this
a
viable
idea
is
it?
Is
it
feasible
is
applicable?
We
have
our
own
ideas
about
this,
but
your
experienced
input
is
very
welcome
and
if
we
should
proceed,
where
should
we
go
and
if
we
should
not
proceed,
then
too
bad.
I
Hey
Eric,
I
I,
don't
know
yet.
If
it's
viable,
it
should
go
to
TLS,
so
I
mean
I,
I
skim.
This
draft
and
like
I,
was
sufficiently
like
unsure
about
some
of
the
details
that,
like
that
that
may
become
an
illusion.
They
should
go
to
TLS
if
you
go
anywhere
just
like
you
know
like
so
the
the
bit
where
you're
like
we're
like
doing
your
own
signature
with
like
the
with
like
the
Mac
on
the
keys
and
stuff.
It's
like.
I
Maybe
it's
right,
maybe
it's
wrong
but
like
it's
got
to
be
like
we
have
to
look
at
it
more
carefully,
so
I
I
guess
you
know.
My
question
would
be
like.
F
I
I
I
think
I
think
now,
when
this
comes
to
say
you
lost
my
particular
question
will
be
he
was
interested
so
I.
Think,
like
you
know,
when
you
completely
lost,
you
should
be
prepared
to
say
like
these
are
the
following
implementers
and
they
want
to
use
it,
but
I
mean
conceptually
there's
no
problem
with
the
Kerberos
CLS
binding
and,
as
you
know,
we've
done
them
before
the
details,
obviously
matter,
and
so
the
question
of
whether
ITF
should
bother
to
like
invest
in
it.
I
It
kind
of
comes
down
to
like
you
know,
because
it
has
done
interest.
I
will
say
that
it's
possible,
you
can
get
it
down.
I
mean
I,
mean
I,
think
of
the
problem
a
little
bit
and
it's
possible.
You
can
get
it
down
to
be
a
very
small
extension,
in
which
case,
maybe
you
could
do
it
just
on
your
own
without
a
Taos
review.
But
if
it's
as
complicated
as
this
document
is
ends
up
having
to
be,
then
it
will
have
to
be
in
TLS.
A
I
A
N
E
Well,
primarily,
authentication,
but
of
course
you
can
also
do
authorization
with
with
Kerberos,
but
that's
up
to
the
the
end
applications.
So,
basically,
you
can
use
the
authenticated
channel
to
to
do
Kerberos
things.
N
N
If
you
want
this
for
machine
to
machine
communication
or
if
you're
looking
at
this
for
like
end
user
to
server
communication,
because
I
think
that,
if
you're
looking
at
it
for
like
end
user
to
machine
communication,
you're,
basically
going
to
run
into
the
same
problems
that
we
had
with
just
happy
and
espnego
and
I
would
say
that
this
is
not
worthwhile.
But
if
you're
looking
at
it
from
machine
to
machine.
My
immediate
question
is:
why
aren't
you
using
the
existing
just
happy
Channel
binding
mechanisms
with
TLS
and
like
let
TLS
do
TLS
stuff.
E
T
Yes,
so
lots
of
years
ago,
ipsec
had
a
similar
proposal
and
you
have
the
Kink
RFC
4430
kerberized
initiation
of
keys
is
kind
of
an
alternative
to
the
internet's
key
exchange,
and
this
saw
really
close
to
zero
implementation
and
close
to
zero
use
because
nobody
really
wanted
it.
So
for
this
proposal
is
there
any
real
I,
don't
know,
customers,
people
who
really
want
to
use
TLS
with
the
Kerber
squeeze.
E
Yeah,
that's,
of
course,
a
very
valid
question.
We
within
our
own
project.
We
have
some
some
use
cases
for
this.
We
also
heard
some
some
interest
from
the
the
radius
group
they're.
Also
looking
for
Alternatives
and
Kerberos
was
was
a
was
an
interesting
idea.
They
said,
and
we
also
reached
out
to
Microsoft
because
they're
doing
a
lot
with
active
directory,
Kerberos
single
sign-on
applications,
so
we're
still
discussing
that,
but
we
do
think
there.
There
is
a
group
of
users
that
might
be
interested.
E
J
So
the
the
obvious
dispatch
method
would
be
sent
to
TLS,
but,
having
just
looked
at
the
spec
this,
this
does
changes
to
the
TLs
key
schedule
and
changes.
It
breaks
some
of
the
assumptions
used
in
order
of
the
security
proofs.
J
So
if
you
do
do
want
to
do
this,
can
you
come
with
like
a
formal
analysis
and
a
proof
that
you
haven't
broken
everything,
because
I
don't
want
to
have
to
redo
that
to
ages
yeah.
E
E
J
Break
the
security
proof
right
so
there's
a
proof
that
TLS
is
one
secure
is
secure.
You
definitely
break
the
proof,
so
you'd
be
using
something
you
don't
know
is
secure,
which
is
not
the
same
as
is
not
secure.
E
Yeah,
no
that's
true,
and
that
that
should
be
checked,
of
course,
and
for
TLS
one
three.
We
we
generalize
the
mechanism
that
we
used
such
that
it
can
also
be
used
for
other
mechanisms
than
than
tlskdh
to
to
provide
entropy.
E
So
that
would
require
proof
for
every
every
new
mechanism,
but
that's
definitely
something
we
will
look
into,
and
we
also
have
capacity
within
our
project
to
do
so.
Yeah
yeah.
J
So
the
other
thing
I
would
say,
is
I.
Have
a
now
expired
draft
on
TLS,
extended
key
schedule
which
lets
you
inject
stuff
into
the
key
schedule,
with
a
proof
that
you're
not
breaking
anything
so
maybe
like
consider
using
that.
B
Yeah,
so
that
brings
us
to
the
end
of
the
queue
thanks
to
everyone,
for
your
comments
sounds
like
our
outcome
here
is,
is
no
immediate
action
this,
if,
if
there
is
some
work
to
do
here,
it'll
be
in
TLS
and
questions
are
heard
that
we
would
we
need
to
address
in
the
TLs
working
group
or
you
know,
is
there
an
audience
for
this?
What's
what's
the
market
for
it
as
it
were,
and
you
know
how
do
we
verify
that
it's
secure?
So
it
sounds
like
some
good
feedback.
B
I
think
that
kind
of
indicates.
The
next
steps
is
to
start
some
discussion
on
the
TLs
list.
So
thanks
for
the
presentation.
A
Yeah,
thank
you.
Richard
do
you
know,
provide
a
summary
and
and
then
I'll,
let
Roman
kind
of
wrap
it
up
here
for
us.
B
A
B
So
by
my
notes,
our
outcomes
today
on
httpa.
There
is
no
action
for
now.
You
need
some
some
more
thinking
about
how
to
integrate
with
the
the
stack
and
on
you
know
who
needs
to
be
engaged
on
that.
So
no
action
for
now
on
httpa,
secure,
routingly
skips,
because
we
didn't
have
a
presenter
s,
p,
k
c
a.
I
think
there
is
an
a
at
the.
E
B
A
c
there
we
go
that's
proof
of
possession
thing.
We
agreed
to
send
that
to
over
to
the
ads
for
80
sponsorship
as
informational,
with
a
bunch
of
notes
about
security
considerations
and
use
of
this
and
new
stuff,
and
on
tlskdh.
The
feedback
was
that
this
is
work
should
happen
in
TLS
if
anywhere
so.
Discussion
should
happen
on
the
TLs
list,
so
that
over
room.
G
Hi
everyone,
Roman
genillio
and
so
I'm
kind
of
speaking
on
behalf
of
kind
of
polymy,
probably
I.
Think
two
weeks
ago
you
saw
an
announcement
on
the
SEC
dispatch
list
about
how
we
are
rethinking
the
approach
to
leadership.
Sect
dispatch
is
one
of
those
standing
working
groups.
It
will
endure
hopefully
forever
it's
been
quite
a
bit
of
a
success
in
helping
us
manage
the
portfolio
of
things
coming
in
to
the
to
the
SEC
area.
We
hope
it's
been
made
it
a
little
bit
easier
to
bring
new
ideas
kind
of
for
those
proponents.
G
That
may
not
know
what
the
entry
point
is.
What
we
didn't
want,
of
course,
is
for
those
in
the
leadership
team
to
have
to
be
there
kind
of
permanently,
and
so
what
we've
defined
is
a
rotation
kind
of
schedule
that
that
we
published
and
so
notionally
going
forward.
The
thinking
was
that
we
would
be
looking
at
terms
pushing
around
kind
of
four
four
years
time
and
those
chairs
would
rotate
as
as
that
occurred.
Of
course,
if
something
changed
they
could
step
out
earlier.
G
So
we
made
some
kind
of
announcements
kind
of
relative
to
that,
so
welcome
to
rifat
kind
of
thank
you
so
much
for
your
willingness.
Willingness
to
serve
I
wanted
to
again
thank
publicly
Mohit
Who
had
who
had
stepped
out
a
little
bit
earlier
due
to
his
really
great
new
job
opportunities
and
with
the
rotation
that
we've
set
up
exiting
out
of
this
working
group
will
be
Richard.
Please
flip
your
your
video
on
and
the
long-term
plan,
starting
kind
of
this
time.
Sorry,
mid-summer
next
year
at
ITF,
117.
G
G
What
I
want
to
say
here
kind
of
enclose
is
Richard.
Please
get
on
the
video
I
wanted
to
say.
Thank
you
to
Richard
I.
Think
the
SEC
dispatch
process
has
been
really
an
amazing
addition
to
to
this
to
SEC
process.
I
know
as
an
idea,
it's
been
invaluable
to
get
your
community
kind
of
feedback
and
I
think
from
what
I've
heard
from
folks
trying
to
bring
new
work
here.
This
is
very
much
to
help
them.
That
does
not
happen
in
a
vacuum.
G
That
really
starts
with
kind
of
strong
facilitation
by
the
chairs
and
Richard.
You've
been
here
since
the
beginning
and
helping
us
first
launch
that
process
and
really
show
us
how
it's
done
in
the
since
we,
since
we
started
almost
four
and
a
half
years
ago.
So
as
you
step
down,
I
wanted
to
kind
of
say
thank
you
for
your
leadership
and
helping
us
manage
the
area
so
you're,
not
in
the
room,
but
we're
gonna
clap
for
you
anyway.
B
I
I
appreciate
it
Roman
back
when
I
was
art.
Ad
I
was
a
beneficiary
of
the
dispatch
process
in
the
art.
Our
art
area,
so
I
definitely
was
supportive
of
having
a
similar
thing
in
the
security
area
and
was
definitely
to
help
set
that
up
so
happy
to
help
and
happy
to
have
new
leadership
here.
B
So
thanks
again
to
your
thought
for
stocking
up
and
to
those
of
you
in
the
crowd,
you
know
I
think
we're
going
to
have
another
role
here
in
a
year
or
so
start
thinking
about
whether
this
might
be
of
interest
to
you.