►
From YouTube: IETF113-SECDISPATCH-20220322-1330
Description
SECDISPATCH meeting session at IETF113
2022/03/22 1330
https://datatracker.ietf.org/meeting/113/proceedings/
B
C
D
E
I
think
there
might
be
issues
when
there's
people
in
the
room
that
forget
that
their
video
turns
on
whenever
a
new
person
joins.
So
if
someone
joins
with
their
video
on
everybody
in
the
room
suddenly
gets
more
video
if
they're
using
the
full
client,
which
is
why
it's
better
to
not
use
the
full
client
when
you're
in
this
room
and
to
actually
use
the
light
client.
E
F
B
Feel
free
to
drive
if
you
like,
mohit
and
I
just
talked
in
the
back
channel
like
just
now.
He
had
he
had
asked
me
to
drive,
but
I'm
also
happy
to
have
you
drive
since
you
digital,
I'm.
B
Yep
we're
deciding
on
the
fly,
so
no,
no
problem
not
not
being
aware,
so
I
think
we're
at.
F
B
Yeah,
let's
see,
maybe
you
could
dress
through
the
in
here
life
was
audio
because
apparently
I'm
bad.
F
All
right,
so
we
are
at
time
so
paul
and
peter
yee
will
take
minutes
using
the
tool.
F
F
Please
note
the
notewell
and
then
the
sec
dispatch
process,
the
ground
rules,
so
sec
dispatch
recommends
next
step
for
new
work
and
it's
really
the
ads
that
can
make
that
final
decision,
along
with
the
community
sec
dispatch,
does
not
itself
adopt
drafts
and
some
of
the
possible
outcomes
include
direct
to
an
existing
working
group
propose
a
new
focused
working
group
ad
sponsorship.
If
an
ad
is
willing
additional
discussion
or
community
development
required
or
the
ietf
should
not
work
on
a
particular
topic.
F
All
right
and
so
now
agenda
bashing.
We
have
the
agenda
on
two
slides,
so
we
will
begin
with
what
I
thought
would
be
the
shorter
drafts,
the
ones
that
will
get
through
the
the
quickest.
So
they
may
not
take
a
full
15
minutes.
I
expect
they'd
be
rather
fast,
so
cypher
suites,
iana,
ssh
protocol
parameters
and
next
slide
just
for
agenda
bashing.
Thank
you
encrypted
client,
hello
deployment
considerations
that
one
might
be
more
discussion
and
architecture
for
trustworthy
and
transparent
digital
supply
chain.
F
G
Yeah
kathleen,
as
I
said,
over
email
this,
the
last
item
was
added
to
the
agenda
quite
late,
so
I'm
no
longer
able
to
do
the
presentation.
Okay,.
H
Hello,
this
is
joe
salloway,
I'm
presenting
this
draft
on
secure.
I
mean
updating
the
cypher
suites
in
secure
syslog,
along
with
chris
lombic
and
sean
turner.
Next
slide.
Please.
H
Okay,
it
turns
out
that
iec
working
group
wants
to
refer
to
syslog,
secure
syslog,
but
unfortunately
the
draft
is
pinned
to
tls
1.2
and
the
mandatory
to
implement
algorithm
at
that
time,
which
is
tls
rsa
with
aes
128
cdc
shot.
This
algorithm
is
now
deprecated,
and
so
we
want
to
fix
this
problem.
So
let's
go
to
the
next
slide.
H
What
can
we
do?
We
don't
necessarily
have
to
do
anything.
H
The
iec
working
group
can
update
their
documentation
to
to
reference
the
new,
updated
algorithms,
but
it
probably
would
be
better
if
we
maintain
the
rfc
and
updated
the
syslog
tls
and
dtls
algorithm
guidance
in
our
documents.
H
So
what
do
we?
What
changes
have
we
made
in
the
in
these
drafts?
First
thing
just
to
kind
of
justif
justify
why
we
made
that
change
updated
the
mandatory
to
implement
to
tls
ecdhg
rsa
with
aes
128
gsm
sha-256,
which
is
generally
accepted
as
a
good
one.
You
also
said
that
you're
allowed
to
use
tls
or
dtls13.
H
We.
We
also
will
need
to
add
some
recommendations
on
how
to
handle
zero
rtt
in
these
cases
and
then
we'll
have
a
section
that
discusses
the
changes.
H
A
Hi,
thanks
for
bringing
this
to
us
joe
to
bring
everyone
kind
of
up
to
speed
on
other
coordination.
We've
been
doing,
welcome
kind
of
all
the
feedback,
we're
gonna
get
at
the
mic
line.
Here
we
did
check
with
the
ops
area
to
see
whether
there's
any
existing
existing
kind
of
work.
That's
really
close
to
this
with
syslog.
They
said
no,
but
they
did
point
out
that
ops
wag
would
potentially
accept
this.
So
that's
an
option.
B
J
So
I
think
not
not
both
is
too
small,
not
ise.
It's
actually,
I
think
we're
about
not
80
sponsors
too
big,
so
that
probably
his
existing
working
group
wg
says.
Okay,
I
was
gonna,
suggest
uga,
but
I
think
those
would
be
okay.
I
I
don't
think
this
is
quite
as
true
I
mean
this
looks
approximately
right,
but
I
think
you
know
probably
there
would
be
a
little
bit
messing
around
so
like
probably
having
it
like
farm
down
the
road
google
useful,
but
I
think
either
or.
H
I
H
Rick,
okay,
it
sounds
like
then
we'll
discuss
with
the
relevant.
I
Hold
on
joe,
there
is
rich
eric.
K
E
B
You
have
something.
No,
I
was
just
gonna
help.
Some
up,
it
sounds
like
uta
is
kind
of
where
we're
headed
with
this.
J
Else
find
that
the
slides
look
really
goofy
and
are
cut
off.
A
I
This
is
me
taco
sharing.
Why
me
taco.
Do
you
want
peter
for
me
to
share
the
slides
from
from
my
machine
instead.
I
L
A
A
A
It
does
not
change
anything
that
actually
requires
a
standard
to
be
placed
into
the
registry,
so
this
is
just
a
bunch
of
minor
numbers.
If
you
will
next
slide,
please.
A
This
came
up
on
the
curdle
mailing
list
a
bit
over
a
year
ago
and
given
the
state
of
curdle
and
no
other,
perhaps
obvious
place
to
send
it
I'm
requesting
security
ad
sponsorship.
But
obviously
I
would
welcome
other
suggestions.
A
Yeah
hi,
I
wanted
to
to
jump
in
here.
We
we've
talked
about
it
internally,
kind
of
with
the
with
the
sec
ads
a.d
sponsorship
really
is
the
only
the
only
way
to
go
given
that
we
no
longer
have
kind
of
kernel,
so
we'll
talk
amongst
ourselves
to
figure
out
who
will
take
it
but
we'll
commit
to
ad
sponsorship.
B
M
Hi
everyone,
so
this
is
a
proposal
to
basically
look
at
the
sorry
look
at
the
ech
encrypted
client,
hello
standard.
That's
developing
the
extension
to
the
tls
and
really
just
give
some
insight
in
terms
of
the
potential
impact
on
end
users
specifically,
which,
as
far
as
we
can
tell
is,
is,
is
new
input
into
that
particular
discussion.
I
believe
paul
vixi
is
also
attending
the
meeting
one
of
my
co-authors
remotely
so
he'll
potentially
join
in
the
discussion
as
well.
M
Our
third
co-author,
david
wright,
isn't
with
us
either
in
person
or
remotely,
but
by
the
way
of
his
background,
he
works
in
the
education
sector
in
a
looking
at
some
of
the
security
and
privacy
issues
specific
to
schools
in
the
sector.
Next
slide,
please.
M
So
what
we've
done
is
to
gather
input
from
a
variety,
multiple,
multiple
stakeholders,
interestingly,
so
lots
of
stakeholders
to
really
get
an
understanding
of
where
and
how
they
see
ech,
impacting
specifically
in
terms
of
loss
of
visibility
of
the
smi
data,
which
clearly
is
one
of
the
intended
consequences
of
encrypting
it.
M
Our
view
is
that,
by
having
a
sort
of
a
better
understanding
of
those
impacts,
that
will
hopefully
lead
to
better
solutions,
as
the
standard
is
developed,
hopefully
that
we'll
work
with
minimal
disruption
to
end
users
wherever
possible,
or
at
least,
if
it's
necessary
to
encourage
sort
of
multi-stakeholder
engagement,
so
that
there's
awareness
before
the
ech
is
launched,
as
well
as
knowledge
of
the
likely
impacts
on
those
different
user
groups.
M
And
I
should
say
just
responding
to
a
comment
in
the
sec
dispatch
mailing
list.
In
case
it
wasn't
clear.
The
the
intent
of
the
of
the
paper
is
not
to
stop
deployment
of
ech,
but
but
to
provide
better
understanding
in
how
or
when
it's
deployed.
So
if
that
wasn't
clear
in
the
current
draft
apologies,
it's
also
worth
just
bear
in
mind.
It
is
an
initial
draft
and
we
certainly
will
welcome
additional
input
from
anyone.
M
We
have
already
so
requested
steps
from
a
number
of
interested
parties
that
could
potentially
provide
some
additional
sort
of
data
input
to
give
some
quantitative
insight
to
to
guide
the
literally
pretty
qualitative
qualitative
content.
So
far,
just
some
other
observations
just
to
call
those
out.
M
M
So
it
covers
current
security
and
network
operations,
as
well
as
management
practices,
and
you
see
I've
put
the
quote
from
that
rsc
which
really
highlights
that
for
enterprises
in
particular,
where
they're
managing
the
data
that
traverses
their
networks.
So
these
are
private
networks
as
opposed
to
public
networks.
M
They
they
really
do
have
an
expectation,
quite
so
often
of
of
being
able
to
specifically
directly
manage
what
traffic
is
allowed
traversed
to
traverse
those
networks
and
it's
quite
different,
an
expectation
to
what
might
be
expected
on
a
typical
public
network
and
then
final
comment
on
this
slide,
which
I
think
is
just
worth
unpacking,
which
is
for
onpath
security
actors.
M
M
So,
if
you
like,
this
is
where
we
get
into
a
bit
of
a
quandary
where,
by
trying
to
protect
privacy,
we
might
actually
weaken
privacy
if
we
don't
deploy
things
with
an
understanding
of
the
environments
that
we're
deploying
them
into
and
also
again,
depending
on
context
again.
M
For
some
networks,
such
as
a
home
network,
or
indeed
a
school
network
issues
like
content
filtering,
are
entirely
appropriate
sort
of
considerations
for
the
network
owner
an
operator
and
in
some
countries
actually
say
in
the
school
environment
which
again
I'll
come
on
to
the
school,
is
required
to
to
operate
content
filtering
so
in
any
protocols
that
defeat
that
are
actually
making
it
hard
for
the
network
operator
to
meet
their
regulatory
requirements
and
that's
clearly
an
issue
next
slide.
Please.
M
M
What's
characterized
as
unanticipated
uses
of
s,
I
information
in
section
2.1
and
a
very
brief
two-paragraph
assessment
of
alternative
options
for
those
usages
in
the
event
that
the
s
I
data
is
in
fact
encrypted,
and
if
you
like,
there's
a
suggestion
that
you
know
most
of
those
unanticipated,
unanticipated
usages
can
in
fact
be
delivered
through
other
means,
although
that's
not
really
sort
of
fully
covered
in
in
the
actual
text.
M
And
importantly,
in
this
context,
what
it
doesn't
do
is
to
take
into
consideration
issues
like
the
cost
of
those
alternative
solutions,
either
financial
cost
or
the
operational,
complex
complexity
of
those
solutions,
or
indeed
the
technical
capability
of
the
parties
that
might
be
expected
to
move
to
those
alternative
solutions
or
also
the
privacy
implications
for
end
users.
M
That
might
might
also
be
involved
in
that
move
because,
for
example,
if
you
end
up
having
to
do
deep
package
inspection
of
all
traffic,
that
isn't
necessarily
good
privacy
outcome
for
the
affected
users.
If
it's
a
consequence
of
something
which
is
intended
to
actually
enhance,
rather
than
weaken
their
privacy
next
slide,
please.
M
So
briefly,
we've
considered
in
the
paper
certainly
impact
on
a
couple
of
different
types
of
users.
Firstly,
schools
and
we've
called
out
specifically
in
the
u.s
and
the
uk.
Schools
are
required
to
operate
content
filtering
in
the
uk,
they're
required
in
a
blanket
way.
M
So
all
schools
are
required
to
do
so
in
the
us
they're
required
to
if
they
want
to
qualify
for
a
particular
type
of
federal
funding,
which
I
think
I'll
give
a
reference
to
in
the
current
draft
and
in
many
instances
they
use
sni
data
in
order
to
help
them
with
that
filtering
one
of
the
issues
here
is
they
move
to
what
will
typically
look
more
like
an
enterprise
grade
solution
as
an
alternative,
there's,
potentially
quite
a
considerable
expense
involved
in
doing
that,
and
also
I
know
from
firsthand
experience
that
the
technical
capabilities
of
the
support
people
in
schools
are
nowhere
near
those
of
technical
people
in
enterprise
environments,
so
it
will
be
potentially
beyond
the
capabilities
to
implement
effectively
and
reliably,
which
we
believe
is
important,
a
consideration.
M
So
then
you
get
to
some
of
the
alternative
options
for
them.
Well,
if
it's
available
in
disabling
ech
in
client,
software
will
potentially
be
helpful.
But
I
do
know
that
some
of
the
current
so
client
software,
so
developers
are
not
intending
that
it
will
be
an
option
that
can
be
disabled.
M
So
the
only
other
alternative
for
them
is
to
remove
that
software,
which
is
potentially
extremely
disruptive
and
very
expensive
if
they
got
a
long-term
usage
of
such
software
and
have
to
move
to
a
completely
different
platform,
and
also
certainly
in
the
school
environment,
potentially
just
moving
completely
away
from
bring
your
own
device
as
an
option
again,
because
it
becomes
just
too
difficult
to
to
administer
in
that
environment
and
again
that
that
is
potentially
also
disruptive.
M
Briefly
in
the
enterprise
environment,
again
sni
in
many
installations,
aids
content
filtering,
including
blocking
access
to
malicious
content
by
fishing,
etcetera
and
also
in
some
industries,
is
an
important
part
of
their
compliance
obligations
and
clearly
for
any
enterprise,
not
meeting
their
compliance.
Obligations
is
not
up
for
discussion,
because
the
cost
implications
for
that
will
be
quite
significant,
so
they
will
have
to
find
a
way
to
be
compliant
and
if
sni
makes
that
harder.
M
That's
going
to
be
an
issue
for
them,
you'll
say
also
byod
is
potentially
getting
an
issue
in
some
corporate
environments
and
certainly
a
weak
weakening.
Cyber
defenses
is
a
concern
which
I've
come
on
to.
I
think
on
the
next
slide,
and
of
course
not
all
enterprises
are
equal,
the
sort
of
resources,
be
it
financial
and
operational
in
a
large
enterprise,
very
different
to
those
available
in
a
small
enterprise.
M
M
And
then,
just
looking
at
the
threat
detection
point,
rfc
8404
highlights
some
of
the
issues
arising
from
increased
encryption
of
data
generally,
and
a
number
of
those
points
certainly
apply
here
and
I
don't
believe
have
been
considered
fully
yet
and
perhaps
more
directly
relevantly
that
there's
a
current
draft
indicators
of
compromise
which
talks
about
unsurprisingly,
indicators
of
compromise
and
the
highlights
some
of
the
issues
there,
where
you
start
to
compromise.
M
M
So
potentially,
therefore,
encryption
of
si
data
absolutely
poses
new
new
challenges
on
threat
detection
specifically,
and
these
don't
appear
to
have
been
considered
either
in
rst
before
or
the
current
ech
draft.
We
certainly
think
that
draft
ought
to
include
this
issue
in
its
security
consideration
section,
which
is
looking
rather
than
focused
on
this
particular
aspect
of
security.
M
Since
the
diagram
often
helps
to
sort
of
just
convey
the
general
point,
in
effect,
what
we're
trying
to
really
get
across
here,
there's
you
look
at
the
top
diagram
that
the
desired
effect
of
the
ecx
development
is
to
ensure
that
communication
from
a
user
to
their
target
takes
place
without
observation,
or
indeed
interference
that
so
that's
the
intent
behind
this
quite
clearly.
M
The
potential
actual
effect,
though
of
the
of
the
of
of
this,
if
more
thought
isn't
applied,
is
actually
it
might
prevent
some
of
the
defenses
from
kicking
in
so
they'll
be
unable
to
see
what's
happening
and
in
reality,
it's
going
to
aid
communication
with
malicious
content,
surveillance
by
client
software,
access
to
age,
inappropriate
content,
for
example,
in
a
school
or
home
environment
and
on
some
networks
access
to
csam.
M
So
if
you
like,
the
the
actual
effect
is
potentially
the
exact
opposite
of
the
desired
effect,
and
it's
worth
just
throwing
in
at
this
point
that
that
when
we
start
to
think
about
specific
special
use
cases
and
certainly
for
dissidents,
there
are
better
tools
available
to
avoid
being
observed
or
their
communication
interfered
with
tor
springs
to
mind.
I
think
kathleen
on
the
second
spatialist
today
pointed
out.
I
think
the
brave
browser
etc.
M
Tools
like
east
h,
don't
apply
here,
because
I
think,
already
about
two
years
ago,
the
great
firewall
of
china
began
blocking
tls,
1.3
and
encrypted
sni
anyway,
so
they're
just
blocking
it
completely,
so
it's
not
really
applicable.
In
that
context,
there
are,
as
I
say,
others
other
better
tools
for
that
purpose.
M
So
just
a
conclusion:
we
believe
that
the
paper
highlights
some
new
end
user
harms,
which
are
valid
or
potential
harms
which
are
valid
and
that
have
yet
been
fully
investigated
and
we'd
like
to
investigate
those
further
and
as
I've
just
outlined.
M
Sni
encryption
does
pose
new
challenges
for
threat
detection,
which,
by
definition,
risks
harming
end
user
security
and,
to
just
quote
a
section
from
rsc8890,
it's
not
good
practice
to
either
avoid
identifying
harms
or
when
they
have
been
identified.
It's
not
acceptable
to
ignore
them
when
they're
raised.
So
that's
why
we
believe
this
is
something
which
needs
to
be
dispatched
somewhere,
but
we'll
welcome
some
views
on
where
that
might
be,
and
also
any
questions
that
people
might
have.
M
So
brendan.
N
I'd
just
like
to
point
out
that
this
is
a
very
interesting
dichotomy,
because
we
have
an
entire
working
group
designed
explicitly
to
avoid
this
kind
of
inspection.
It's
called
mask,
and
on
top
of
that,
I'd
like
to
point
out
that
anytime,
your
security
depends
on
inspecting
an
encrypted
link.
You've
lost
before
you've
started.
N
M
Okay,
thanks
brendan
stephen.
O
Hi
steven
pearl,
so
I
guess
I
I
I'm
in
the
unfortunate
position
of
only
having
to
be
able
to
discuss
what
this
isn't.
I
think
it
isn't
new.
I
think
these
considerations
were
raised
previously.
It
isn't
deployment
considerations,
because
it's
basically
saying
ech
is
bad
deployment.
Considerations
would
be
how
you
do
it
and
or
maybe
how
you
do
it
better
and
that's
not
this
document.
I
don't
think
it
is
useful,
really
to
be
honest,
and
I
don't
think
it's
something
that
we
should
work
on.
So
it
isn't
something
we
should
work
on.
M
P
Hello,
tommy
polly
from
apple,
so
I
have
a
couple
points,
hopefully
to
help
with
the
dispatching
here.
So
first,
as
discussed
on
the
list,
all
the
references
to
the
for
the
users
rfc
are
in
conflict
with
the
meaning
of
that
rfc.
I
think
mark
did
a
really
good
job
of
explaining
that
clearly.
P
So
to
that
end,
I
think
this
form
of
the
document
is
not
a
good
foundation
to
progress
now,
if
we
want
to
have
discussions
around
ech
specifically,
I
think
that
belongs
as
comments
to
the
tls
working
group
as
brought
up
eight
seven.
Four
four
already
talks
about
this
area.
P
If
the
community
really
thinks
that
needs
revising,
you
could
imagine
this
document,
but
I
don't
expect
that
to
happen,
but
I
do
think
that
there
is
a
more
useful
way
that
we
can
talk
about
manageability
in
providing
better
signals
and
that
solution
shouldn't
be
to
prevent
encryption
or
esni,
which
is
trying
to
enforce
more
intentional
sharing
of
data.
But
instead
we
should
be
working
on
filling
in
the
gaps
for
where
intentional
sharing
of
data
to
trusted
parties
to
gain
access
to
a
network
or
other
things
where
that
should
happen.
P
So
the
iab
is
currently
working
on
a
draft
that
calls
for
more
engineering
work
on
new
mechanisms
for
signaling
that
is
intentional
and
trusted
to
replace
the
use
of
implicit,
implicit
signals
like
the
s
I
that
were
silently
being
used
for
management,
but
were
not
intended
for
management.
So
this
is
draft.
Iab
path,
signals
collaboration,
and
so
you
can
take
a
look
at
that
that
can
be
discussed
in
architecture
discuss,
but
it's
essentially
calling
for
the
need
for
more
work
in
the
ietf
on
this.
P
That
would
be
a
useful
proposal
to
have,
and
then
one
last
note
for
the
content
filtering
for
school
devices.
P
D
Ted
hardy
speaking
first
I'll,
join
tommy
and
saying
I
encourage
people
to
look
at
the
path
signals
draft,
I'm
one
of
the
other
co-authors
of
it.
I
actually
don't
think
we
had
considered
sni
as
an
an
explicit
path
signal,
but
certainly,
if
you're
going
to
send
it
as
an
explicit
path
signal,
it
would
be
a
fascinating
experiment
to
make
on
the
basic
thing
of
this
draft.
I
think
functionally
you're
trying
to
ask
the
community
to
reconsider
the
consensus
that
8744
represents.
D
D
I
think
tls
will
consider
it
very
quickly
indeed,
but
I
think
that's
probably
right,
because
I
think
that
your
characterization
of
this,
as
not
considered
or
not
considered
significantly
by
8744,
doesn't
actually
represent
the
discussion.
It
may
represent
the
text
in
the
actual
rfc,
but
it
was
considered
quite
extensively
in
the
production
of
8744
and
the
characterization
characterizations.
D
In
that
document,
I
think
show
a
consensus
that
there
is
no
way
to
tell
the
difference
between
an
on-path
attacker
and
an
on-path
manager
in
the
network
situation.
You're
trying
to
describe
where
you
have
no
control
over
the
end
devices
and
only
control
of
the
network.
D
If
you
go
back
a
slide
to
your
your
two
pictures
of
desired
effect,
there's
really
no
difference
from
the
point
of
view
of
the
external
observer
between
the
check
mark
and
and
your
guy
in
the
hat,
I
can't
tell
what
color
his
hat
is,
and
I
have
no
way
of
stopping
him
from
dressing
up
as
a
check
mark.
So
I
think
this
has
to
go
back
to
tls,
and
I
expect
you
will
find
there
that
they
believe
that
they
have
already
considered
it
appropriately
thanks.
Okay,.
M
Thanks,
I
have
to
say,
I
know
there
were
a
thousand
or
so
messages
in
the
mailing
list.
At
around
the
time
of
that
document,
they
seem
to
be
more
focused
on
the
technical
detail
of
the
of
the
protocol
rather
than
the
actual
end
users,
but
that's
a
discussion
that
can
certainly
be
had
kathleen.
F
So
I'm
not
going
to
argue
for
this
solution
in
particular,
however,
there
is
a
real
problem,
so
as
cto
for
center
for
internet
security,
we
support
all
of
the
u.s
state,
local,
tribal
and
territorial
organizations.
F
That
includes
schools,
but
it
also
includes
all
your
local
governments,
fire
departments,
police
departments,
basically
everybody
that's
under
resourced
and
so
to
do
something
at
scale
doing.
The
endpoint
is
just
very,
very
difficult
right
now
we're
using
dns
based
solutions
to
help
with
screening
with
those
types
of
organizations,
so
we're
not
using
sni,
but
the
problem
is
real,
because
schools
are
getting
hit
with
ransomware.
All
these
organizations
get
hit
with
ransomware.
They
get
shut
down
critical
services,
oh
including
hospitals,
so
that
it's
also
in
the
sltt
bucket.
F
So
there
is
a
problem
to
be
solved.
I'm
not
sure
how
we're
going
to
solve
it,
because
with
dough
there's
you
know
and
and
endpoints
that
aren't
connected
to
whatever
the
screening
service
is,
you
could
be
hit
by
malware
and
ransomware.
So
we
have
a
real
problem.
We
can't
just
expect
to
use
safe
browsing
and
get
beyond
it
and
to
manage
it
at
that
scale.
Right.
M
Yeah,
and
certainly
kathleen
that's
my
experience
of
schools
as
well,
and
equally
many
small
businesses
that
the
more
complex
we
make
stuff
the
harder
it
is
for
them
to
actually
have
any
effective
security.
And
that's
something
we
need
to
think
about.
Q
It's
me
I'm
marked
as
offline,
because
I
so
sorry
I
closed
my
laptop
when
I'm
walked
up
david's
davidskenazi.
Google,
I'm
gonna
make
a
comment
with
regards
to
dispatching,
but
first
I
think
kathleen
did
a
really
good
job
of
explaining.
The
problem
is
that
there
are
networks
today
that
don't
have
many
resources
and
have
to
do
something
to
protect
users,
and
I
I
I'm
sympathetic
to
that.
M
Well,
as
a
minimum,
the
more
consideration
is
given
to
these
types
of
users,
because
at
the
moment
the
voice
of
the
user
is
quite
hard
to
detect
in
a
lot
of
the
this
development
so
actually
bring
out
front
and
center.
M
Q
So
I
mean
more
discussion
is,
can
be
good
in
this
case.
I'm
not
entirely
sure.
We've
talked
about
it,
but,
like
discussion
doesn't
give
them
a
solution.
We,
like
I,
I
think
at
the
end
of
the
day,
what
you're
hoping
is
for
ech
to
not
happen,
and
even
if
you
were
to
be
in
your
view,
successful
here
at
like
making
the
atf
not
do
that,
even
though
you
know
we
are
and
we've
had
this
discussion
before,
that
won't
help
you.
The
technology
exists.
It's
out
there.
Q
So
I
would
really
strongly
encouraged
this
document
to
not
be
to
be
dispatched
as
not
looked
for
new
work
at
the
ietf.
This
has
been
discussed
as
the
people
in
the
cubiform
you
mentioned
and
is
only
an
attempt
at
making
a
technology
that
is
happening,
whether
the
itf
wants
it
or
not,
to
just
kind
of
delay
it
through
itf
process.
So
I
don't
think
it's.
This
document
is
helpful.
Okay,.
M
Thanks
david,
as
I
said
at
the
start,
this
is
not
about
stopping
the
deployment
of
the
vch
it's
about
a
more
thoughtful
way
and
how
it's
deployed,
rather
than
because
you're
right,
you
can't
put
it
back
in
the
box,
but
let's
think
how
to
do
it
so
that
it
doesn't
surprise
people
it
doesn't
amount.
It
doesn't
weaken
their
security,
which
is
where
what
we
risk
current
thanks.
Q
M
Okay,
ekka.
J
Howdy
erica
scorland
is
all
so.
I'm
also
surprised
to
hear
this
characterized
as
new
information.
I
don't
think
it
is.
Some
of
this
discussion
is
87
44..
It
was
discussed
quite
extensively.
This
is
about
the
third
document.
I've
seen
now
with
the
sort
of
general
content
of
wheat
of
people
on
path
to
a
bunch
of
inspection
and
encrypting
things
interferes
with
them.
This
is
the
con
it's
more
or
less.
The
content,
8404
844
actually
has
like
a
whole
section
of
sni
nancy
nancy.
J
Okay,
wait
had
a
document
about
this
as
well.
This
is
what
indicators
are
compromises
about
so
like
this
is
like
information
which
has
been
like
extensively
errored
and
discussed,
and
nevertheless,
there's
been
strong
consensus
to
perceive
with
with
this
work
on
penn
state
87
44..
So
so
I
I
guess,
I'm
not
really
sure
what
the
new
information
is
here.
You
know,
I
I
think
it's
you
know,
there's
some
discussion
about
8890.
J
I
think
many
of
us
perceived
that
we're
acting
in
the
interest
of
the
users,
so
I
think
it's
it's
pretty
hard
to
like
I.
I
don't
think
it's
really
fair
to
characterize
this,
as
the
voice
of
the
user
has
been
absent
and
you're,
bringing
the
voice
of
the
users
that
the
interest
that
this
seems
to
represent
such
understand
is
the
network
operators
as
much
as
users
who
believe
themselves
to
be
acting
in
the
the
interest
leaders.
Perhaps
so.
J
This
brings
us
that
into
the
main
point,
which
is
that
the
setting
of
concern
here
is
the
one
where
you
have
an
on
path
expect
inspection
element
which
does
not
have
effective
control
of
the
endpoint.
If
it
had
effective
control
of
the
endpoint,
it
wouldn't
need
to
do
local
inspection
escaping
suggests
it
could
merely
disable
ech
or
disabled
dns
separate
gps
either,
which
would
allow
to
inspect
the
domain
names
they're
going
through.
J
So
you
mentioned
that
you
thought
people
were
not
intending
to
allow
disablement
at
the
vch,
I'm
not
sure
who
you've
spoken
to.
We
have
not.
We
at
least
haven't
firmed
up
our
plans,
but,
as
I
met
as
I
mentioned,
on
on
on
the
chat
in
firefox
eca,
just
tied
to
doe
and
doe
is
easily
disabled
so
and
certainly
is
disabled.
J
When
there's
any
evidence
of
effective
enterprise
management,
so
the
correct
approach
in
this
case
is
to
for
the
it's
for
the
error,
enterprise
or
the
network,
to
attain
control
the
endpoint
and
have
doe
and
ech
disabled,
and
then
they
can
continue
to
do
the
inspection
they've
been
doing
all
along
and
if
you
can't
do
that,
then
you're
simply
indistinguishable
from
any
other
on-path,
attacker
or
sorry
from
any
on-path
attacker
and
so
like
which
the
purpose
of
like
this
exercise
is
precisely
to
prevent
on
path
attack
measurements
back
to
the
data
so
again
like
that
is
to
control
the
endpoint
that
distinguishes
legitimate
use
from
illegitimate
use.
J
In
this
case,
in
terms
of
dispatch
questions,
a
number
of
people
said
the
correct
place
for
this
to
go
is
a
tls.
If
there's
a
new
text,
you
think
is
appropriate
to
be
in
the
security
considerations
of
of
of
the
ech
draft,
then
I
would
suggest
you
suggested:
I'm
not
sure
what
that
text
want
to
be,
but
that
place
for
that
happens.
There.
M
And
just
to
clarify,
I
won't
embarrass
something
here,
because
that
wouldn't
be
fair,
but
certain
other
large
client
software
developers
have
indicated
that
they
don't
intend
to
allow
ech
to
be
disabled
in
their
deployment.
So
it
seems
like
mozilla
is
doing
things
in
a
different
and
arguably
better
way.
In
that
regard,.
J
Well,
as
I
said,
we
have
not
decided
what
we're
planning
to
do.
I
guess
perhaps
I
don't
know
which
which
developers
you're
talking
about
if
it's
chrome,
perhaps
davey
could
speak
to
it.
If
it's
not
chrome,
I
guess
it'd
be
helpful
for
you.
If
I
thought
it
was.
M
Okay,
thanks
jonathan.
R
Hoyland
cloud
player
I'd
I'd
like
to
know
how
you
consider
connection
card
lessing
in
the
scope
of
this,
so
given
that
certificates
are
not
visible
on
the
wire
with
tls
1
3.,
just
doing
sni
inspection
doesn't
give.
You
doesn't
give
you
the
ability
to
block
bad
websites
quote
unquote,
because
you
may
well
find
that
they
are
coalesced
to
some
other
website
and
unless
you
are
going
to
advocate
full
terminate,
re-establish
every
outbound
connection,
which
is
obviously
incredibly
invasive.
M
R
I
just
think
that
that
software
also
fails
to
account
for
connection
coalescing,
which
is
already
deployed
and
already
exists
and
is
already
used
so
as
as,
even
if
you
manage
to
kill
ech
you're
not
going
to
achieve
the
effect
you
want.
S
S
I
want
to
point
out
that
I
have
actually
done
maintenance
work
in
school
environments
where
there
are
content,
filtering
and
malware
and
ransomware
concerns,
and
yes,
it
is
a
burden,
and
the
right
way
to
do
that
is
to
do
it
on
the
endpoint
you're
not
going
to
block
all
malware
you're,
not
going
to
block
all
ransomware
with
sni
detection.
This
is
the
wrong
way
to
solve
that
problem
and
we
should
not
be
breaking
the
other
security
goals
that
end
users
do
have
in
order
to
try
to
half
solve
one
of
the
other
problems.
M
Thanks
daniel,
I
think
it's
fair
to
say,
you're,
probably
not
typical,
of
the
level
of
expertise
in
in
many
schools,
sadly,
and
also
from
a
security
point
of
view.
Removing
a
layer
of
security
doesn't
feel
like
a
good
sort
of
solution
in
in
that
regard.
M
L
Okay,
hey
hey
andrew!
I
was
saying
that
one
of
the
major
challenges
with
malware
today
is,
if
you
see
they
they're
continuously
updating
their
the
way.
They
use
censorship
technologies
to
avoid
detection
by
passive
network
security
services
and
one
of
the
challenges
that
I
have
seen
is
they
always
there?
Many
of
the
malware
families
have
started
lying
on
the
sni.
L
So,
for
example,
this-
and
I
would
say
that
hey,
I'm
just
visiting
youtube.com,
but
in
fact
it
would
be
visiting
malware.com
and
that
pretty
much
throws
anyone
who
is
assuming
that
they
have
a
content
filtering
and
they
can
just
look
at
sni
and
say
that
hey
sni
is
going
to
let's
say
youtube.com
and
I'll
just
allow
it,
but
in
fact
it
would
end
up
going
to
a
malware
domain
right.
That's
one
big
problem
that,
even
without
encrypted
smi
by
just
looking
at
smi
you,
you
won't
be
able
to
detect,
malware
and
block
it
successfully.
L
M
Okay,
thanks
terry,
I
think
that's
that's
a
call.
B
Yeah,
I
think
we've
reached
the
end
of
our
queue
here,
just
kind
of
summing
up
from
the
chair
point
of
view.
It
seems,
like
the
feedback
here
was
pretty
clear:
there's
no
action
via
etf
to
take
here
at
the
moment,
so
thanks
for
walking
us
through
it
andrew
and
I
think
we're
on
to
our
next
topic.
B
Which
would
be
trustworthy
and
transparent
digital
supply
chains,
s-c-I-t-t
and
hank?
Will
you
be
presenting.
T
T
Hi
everybody
is
this
fine,
okay,
I'm
hank,
as
indicated
so
yeah,
I'm
talking
about
trustworthy,
digital
supply,
chain,
transparency,
services,
which
is
a
mouthful
so
there's
even
more
a
mouthful
of
people
on
this
slide.
So
I'm
I'm
talking
on
behalf
of
multiple
individuals
and
we
have
a
and
that's
maybe
something
to
highlight
early
on
an
email
list
already,
there's
a
non-working
group
email
list
on
the
itf
space,
it's
skit
itf.org
and
thanks
to
all
of
the
people
that
already
commented
before
we
are
starting
this
presentation
here
because
I
think
that's
very
useful.
T
I
will
be
talking
a
lot
of
context
first,
because
before
I
come
back
to
the
skit
stuff,
and
so
thank
you,
skit
is,
of
course,
sc
it's
supply
chains
and
generic
supply
chain.
Of
course,
it's
obvious.
There
are
entities
in
there
and
they
have
purpose
and
intent.
So
some
of
them
are
designing
things.
They
give
you
a
plan,
an
activity,
and
this
goes
into
production
at
some
point
to
create
a
commodity,
and
this
commodity
is
then
brought
throughout
the
world
because
you
supply
things
to
other
people
and
at
the
end,
there's
a
consumer.
T
So
that's
very
obvious,
I
think
so
so
coming
to
the
ietf
scope,
there
is,
of
course
software
and
software
has
a
supply
chain
management
component
to
it
and
and
one
very
prominent
one
that
everybody
can
look
into.
It's
not
the
only
one
is
by
far,
not
though
the
only
one,
but
it's
very
obvious.
It's
like
github,
you
have
source
and
you
can
look
at
the
source
and
the
source
will
basically
compose
the
things
that
you
will
in
the
end,
compile
and
build-
and
that's
the
second
step
here.
T
So
we
have
developers
creating
stories
and
then
you
go
at
some
point
to
a
release,
also
temporal
artifacts
that
are
going
in
ci,
the
continuous
integration
and
then
you
create
software
artifacts.
So
all
of
this
is
very
common.
Again
you
distribute
them,
you
package
them
and
at
the
end
they
end
up
on
your
computer,
but
also
already
here.
What
you
do
have
is
on
the
ci
and
the
distribution
level,
some
third-party
endorsement
that
program
in
here
and
you
do
some
artifacts
that
will
never
be
published
in
the
end.
T
So
we
have
things
that
you
might
want
to
know
about
because
they
will
affect
the
quality
of
your
product
that
will
end
up
as
your
application
next
slide.
Please
click.
T
It's
remotely,
oh,
it's
not
somewhere,
it's
doing
it.
Thank
you,
sorry
I
didn't
know
so,
and
and
so
why
do
you
want
to
know
about
the
supply
chain?
You
just
care
about
the
thing
that
is
running
on
your
computer
right,
so
so
I'm
starting
with
the
right
here
and
the
right
says,
but
but
sometimes
I
really
want
to
know
right.
T
I
really
want
to
know
why
this
came
to
be
why
this
is
happening
and
later
on
in
the
slide
deck
you'll
find
some
executive
order
thing
you
might
heard
about,
and
so
the
real
question
is:
what's
the
provenance
of
the
things
that
will
end
up
in
my
trusted.
Computing
base
faster
computing
based
means
the
things
that
can
really
believe
and
if
it
tells
me
stuff,
is
happening
so
there's
a
lot
of
red
text
in
this
now
augmented
supply
chain
example.
T
So
you
want
maybe
some
have
some
insight
on
the
tool
chain
and
you
want
to
have
some
insight
about
the
versioning
that
is
in
the
end
done
so,
if
you're
just
fake
at
the
end
of
versioning,
it
might
look
like
the
same
thing,
so
it's
healthy
still,
but
it
isn't,
and
so
so
all
these
things
are
now
not
only
about
the
binary
that
you
create
it's
not
about.
Only
the
the
artifacts
are
created,
but
it's
about
the
metadata
around
the
supply
chain
and
the
contact.
T
And
all
of
this
is
not
old.
Sorry,
it's
new!
No!
This
has
been
very
old,
so
in
2016
I
think
that's
the
oldest
quote
here
all
this
happened
before
right.
So
this
is
not
a
new
problem.
Everybody
knows
about
these
problems.
Everybody
has
seen
these
problems
before
and
and
still
they're
happening.
So
that's
why
there's
this
famous
executive
order,
because
they're
still
happening
today
and
basically
that's
what
all
the
site
is
about.
T
T
Because
this
is
a
problem,
that's
everywhere
and
it's
not
solved
in
a
generic
way.
So
what
I'm
going
here
is
a
fish.
That's
at
the
top
and
chips.
That's
at
the
bottom.
T
The
cold
chain
of
seafood
is
a
supply
chain,
as
well
as
the
chips
that
you
put
into
computers.
So
fish
and
chips
are
also
things
you
want
to
talk
about.
This
is
not
only
about
binary
transparency,
which
is
nice
to
talk
about,
but
it's
about
the
endorsements
of
all
of
these
things
has
my
fish
exceed
the
temperature
of
one
degree.
The
celsius,
then
the
cooling
chain
cool
chain
has
been
broken,
has
something
being
and
then
now
picking
again,
some
red
text
out
here
of
the
bottom
has
some.
T
It's
called
insert
trojan
circuitry,
that's
a
very
hot
topic.
I
think
so.
You
want
some
transparency
into
that.
What
there
may
be
a
falsification
of
test
results,
so
this
is
actually
bad,
but
hey,
I'm
telling
you
it's
good
and
what's
very
invoked
right
now
is
like
on
the
very
right
there.
We
are
in
a
circular
economy
today,
yeah
other
thing
is
circular,
so
is
my
recycling
cigarette
recycling
really
really
or
is
fixtures
right,
there's
so
many
attacks
on
these
things-
and
this
is
just
microchips
again-
there
might
be
attacks
on
fish.
T
You
might
see
the
result
the
next
day
if
you
eat
the
wrong
fish,
but
but
it's
not
always
as
obvious
when
you
have
a
malfunctioning
microchip
in
your
computer.
So
next
slide,
please
so
coming
back
to
the
very
first
slide.
All
of
this
is
about
the
auditing
in
the
end,
so
you
want.
The
transparency,
of
course
serves
a
purpose
and
the
purpose
is
auditing
and
now
there's
this
eo.
T
I
have
to
reduce
1402
14028,
which
is
about
the
increasing
the
nation's
cyber
security
from
buying
in
the
u.s
and-
and
there
are
a
lot
of
lot
of
things
about
artifacts
here,
which
are
then
described.
We
are
the
softer
bills
of
materials
and
that's
fine,
so
describing
artifacts
statements
about
the
supply
chain.
Artifact,
that's
cool,
but
this
is
not
what
this
is
about.
So
this
is
a
very
good
use
case.
Now
we
really
want
to
address
that
use
case.
T
There's
a
lot
of
sense
to
address
that
use
case,
but
we
also
do
the
fish
and
chips
and
all
the
other
things
right.
So
so
the
transparency
that
this
work
is
about
is
not
just
about
software,
which
is
like
chemistry
with
sweat
and
spd-x
and
salsa
and
the
cyclone
the
x
was
the
vulnerabilities,
and
then
you
have
to
measure
all
that
you
have
to
understand.
The
statements
that
are
now
have
made
been
transparent
by
the
transparency
service,
but
that's
nice,
but
we're
not
about
that
statement
level.
T
T
So
that's
basically
the
core
intuition.
The
transparency
ledger
basically
makes
you
that
ensures
that
a
malicious
actor
actually
cannot
contradict
other
people
that
will
be
seen
a
lie
will
be
made
non-repudiational.
T
It's
very
obvious,
I
think
as
a
goal,
and
so
the
different
actors
on
the
supply
chain
can
react
on
this
on
inconsistency
actually,
and
also
it's
about
that,
you
provide
the
service
and
that
you
control.
Basically,
it's
a
transparent
confidentiality,
so
you
control,
what
is
confidential.
Word
is
transparent.
T
The
the
thing
what
we
provide
here
is
that
it's
interoperable.
However,
you
do
it
if
you
just
have
one
contextual
partner,
fine,
if
you
want
to
show
it
to
the
world
fine,
but
the
thing
is
what
the
itf
building
blocks
are
used
here
are
for
is
transparency
about
the
statement
about
the
artifacts
so
that
all
the
consumers
of
the
claims
can
basically
say
I
can
vouch
that
they
made
this
transparent.
T
I
can
give
you
now
a
tiny
thing
and
we'll
come
to
that.
Of
course.
It's
some
itf
technology
that
can't
anything
back.
That
tells
that,
and
there
are
examples
that
transparency
systems
actually
work.
I'm
not
going
into
the
details
here
right
now,
but
this
is
the
this
previous
work
that
shows
okay,
that
that
makes
sense,
and
some
of
that
is
actually
the
certificate
transparency,
and
some
of
it
is
the
binary
transparency
which
are
all
very
specific
use
cases
all
over
this.
T
We
again
we
are
uplifting
this
to
a
to
a
global
level,
then
higher
layer,
so
to
speak
next
slide.
Please.
T
So
we
have
two
things:
if
talking
about
the
service,
the
service
maintains,
this
append
only
ledger.
That's
basically
the
thing
that
contains
the
thing
you
can't
take
back,
if
you
say
it
out
loud,
so
to
speak,
and
then,
if
you
say
it
out
loud,
if
you
put
it
to
the
service,
you
will
get
back
a
counter
signing
thing.
That's
the
receipt,
and
it's
cryptographic
proof
that
some
identity
has
said
this
at
a
given
point
of
time
and
you
don't
have
to
actually
understand
what
the
statement
means.
T
It's
really
important
that
you
can't
re-verify
that
it
has
been
made
and
it
was
available
at
that
time
that
somebody
did
this,
and
that
is
the
issues
responsibility
effectively
and
the
the
identities
we
involve
here.
You
could
think
sure
you're
going
with
pkix
first,
but
we
want
to
abstract
that
a
little
bit
with
the
webdid
from
w3c,
which
basically
is
a
uri,
pointing
or
identifying
sorry
to
a
specific
identity
document.
So
we
want
to
have
a
little
bit
of
flexibility
here.
What
kind
of
identity
system
you
want
to
use?
T
That's
why
the
current
proposal
is
to
use
dead,
and
so
the
very
important
thing
is
the
first
statement,
and
maybe
we
go
to
the
next
slide.
I
guess
there's
a
there's,
a
architecture
picture
yeah
exactly
so
you
you
have
this
artifact,
it's
a
fish,
it's
a
very
top.
They
have
the
flow
now
from
the
from
the
top
to
the
bottom
and
the
artifact
is
the
thing
you
want
to
talk
about.
T
You
create
a
statement
about
the
artifact
and
then
you
wrap
it
in
an
envelope,
and
now
you
can
basically
all
kind
of
see
this
is
cozy.
So
we
are
talking
to
cozy
and
itf
building
blocks
here
to
sign
by
an
issue
of
the
statement,
and
there
might
be
a
little
bit
of
unfortunate
terminology,
but
this
for
now.
We
call
this
a
claim-
and
this
already
includes
the
identity
of
the
issuer.
T
But
the
really
important
thing
now
is
that
you
sent
this
already
signed
thing
that
you're
responsible
for
having
managing
the
key
material
to
this
transparency
service.
That
has
a
ledger
and
back
you
get
a
counter
signature
about
a
ledger
based
thing
that
is
now
again
available
to
you
and
now
you
can
validate
the
signature
of
that
receipt,
and
the
important
thing
here
is
air
gap.
T
You
can
validate
this
fact
here
to
have
exposed
this
to
the
transparency
service
globally
by
a
receipt
that
you
can
validate
offline
and
that's
very
useful,
and
sometimes
you
don't
believe
that,
and
then
you
go
back
to
the
transparency
service
at
the
right
edge
here
and
go
to
the
ledger
and
can
do
all
the
other
trails
you
can
find
out.
Does
it
really
make
sense
to
me
so
the
auditors,
in
the
end,
have
now
two
things
to
do.
T
They
can
replay
letter
servers
in
turn
and
they
can
just
look
at
the
receipt
that
they
collected,
so
both
is
viable
in
most
cases.
Sometimes
you
do
one
sometimes
with
the
other,
sometimes
if
you're,
both
and
so
next
type
please.
So
this
is
about
the
cozy
world.
So
this
is
the
first
step.
You
issue
your
statement
and
there
are
some
things
in
here
like
they
did
at
the
top
there's
something
you
know
like
elk
and
key
id.
That
might
make
a
lot
of
sense.
T
Then
there's
something
called
the
feed
and
this
might
be
new
work.
We
want
to
talk
about
so
this
is
like
the
subject.
You're
talking
about
the
feed
is,
and
now
we
come
back
to
the
example
of
the
s
bomb,
my
version
updates.
So
it's
still
the
same
thing.
It's
thunderbird,
sorry,
I'm
not
saying
any
names,
but
it's
it's
a
software
edit.
My
editor,
my
text
editor
right
so
and
now
it
gets
a
new
version.
So
in
these
versions
I
have
a
provenance
and
a
history.
That's
a
feed!
T
I
mean
it's
the
issue
of
using
the
same
key.
To
add
on
to
that.
So
there's
history
and
at
some
point
say
this
is
discontinued
and
I
put
an
end
to
this
feat,
but
sometimes
I
just
die
as
a
company,
and
I
don't
have
the
time
for
that
and
that
doesn't
ever
happen.
So
now
you
can
really
check
by
the
transparency
service.
Okay.
There
was
a
continuous
update
of
this
feat,
but
suddenly
that
stopped-
maybe
that's
a
red
flag
for
me.
Maybe
I
shouldn't
use
that
anymore.
T
So
feeds
are
the
subjects
we
are
talking
about
and
the
rest
of
like
a
cti.
You
might
be
very,
very
afraid
of
yeah.
Let's,
let's
go
to
the
next
slide.
I
think
I
think
that's
enough
on
this
topic
and
the
append
thing
is
now.
We
have
a
ledger.
That's
a
hash
tree!
It's
a
merkle
tree,
I
think
that's
very
obvious.
It
could
be
done
distributed
in
the
blockchain.
We
are
doing
this
as
a
decentralized
history,
replica
thing
and
and
the
important
thing
to
make
to
ensure
some
scalability
here.
T
You
cannot
just
only
assert
one
statement,
but
a
bundle
of
statements
and
that
creates
a
new
hash
route.
So,
if
you're
familiar
with
the
concept
of
merkel
trees,
you
can
see
there's
already
some
automation
down
here.
The
important
thing
is
at
the
bottom
again,
I
think,
which
is
a
new
counter,
signing
specification
for
cosy.
That
would
include
a
counter
signing
proof
that
an
operation
has
happened
with
a
bunch
of
statements
potentially
on
the
h3
and
there's
a
step,
but
you
get
back
so
you
get
your
send
in
the
signed
envelope.
T
T
So
you're
not
to
don't
have
to
you,
don't
have
to
do
this
alone,
so
we
are
not
expecting
that
you
are
adhering
to
one
global
ledger
owned
by.
I
don't
know
acme
arc,
but
you
could
do
that.
You
can
also
have
your
own
with
your
own
contextual
partner
and
now
there's
a
spectrum
between
those
extremes.
Okay
and
the
spectrum
is,
I
think,
addressed
by
federation.
T
So
everything
we
built
here-
and
this
might
be
up
to
for
the
discussion-
is
something
we
want
to
do
in
a
federated
system
of
transparency
services,
so
the
identities
might
have
trust
relationships,
so
the
web
debt
comes
in
again
and
how
you
correlate
this
and
I
think
yeah.
This
is
an
open,
open
topic.
I
think
it's
it's
a
goal,
it's
on
the
roadmap,
but
that's
it's
certainly
something
we
have
to
take
into
account,
because
this
should
not
be
ships
in
the
night.
T
This
should
be
again
that's
why
we're
doing
this
in
an
interoperable
level,
with
the
transparency
with
cosy
and
such
and
the
receipt
mechanism
here
in
the
itf
next
slide.
Please.
T
T
So
we
made
some
running
code
that
basically
has
the
through
the
the
green
bubbles
here
like
the
primary.
That's
the
primary
ledger
we
have
replicas
of
it
and
between
them
is
running
a
consensus
protocol.
So
one
of
these
things
doesn't
work
is
differing
from
the
others.
You
get
even
more
guarantees,
and
that
is
where
rats
kicks
ends,
for
example
right.
T
So
if
every
of
these
nodes
operate
as
they
should
be,
and
they
don't,
they
shouldn't
be
able
to
provide
you
with
attestation
results
that
they
do
the
things
they
are
supposed
to
do
and
nothing
else
because
well
they
didn't
so
we
want
to
add
guarantees
on
on
the
central
level
first
and
because
we
know
that
people
who
create
the
an
original
statement
might
not
be
in
the
position
today
to
create
rats
viable
evidence.
I
don't
know
when
they
catch
a
fish
on
a
boat.
T
I
want
to
say
this
is
the
cooling
chain
now,
maybe
that
is
not
red
supported,
so
that
is
nothing
we
require
today,
but
it's
foreseeable
feature,
but
what
we
can
the
most
definitely
require
today
is
that
the
central
service,
that
is
the
cluster
of
transparency
services,
could
be
supported
by
or
is
effectively
supported
by
remote
association
technology,
as
done
by
the
itf,
and
we
have
some
examples
here
that
the
scx
protected
items
are
running
in
the
ledger
stories.
Sdx
is
an
example
because
of
this
running
code,
that's
not
restricted
to
it.
T
It's
just
a
first
proof
of
concept.
Let's
think
about
this
as
more
broader
than
this
next
slide,
please
so
yeah
the
takeaway
is.
This
is
basically
only
itf
technology,
but
I'm
talking
about
right
now
we're
signing
things
with
cozy.
The
payload
is
opaque.
Everybody
can
talk
about
interoperability
of
payload
effectively,
but
that's
not
our
concern
here.
With
this
work,
it's
one
layer
above
the
transparency,
has
to
be
interoperable.
Otherwise,
how
should
you
know
you
cannot
agree
on
everything?
Fish
temperature
could
be
a
picture
of
a
spoiled
fish.
Okay,
fine!
T
You
can't
standardize
that
you
may
be
able
to
standardize
most
of
the
s-bomb
stuff,
but
that's
also
really
really
hard.
If
you
follow
the
discussion
out
there,
like
the,
I
don't
know:
cyclone
x
s,
pdx
and
why
you
have
to
do
a
sweat
thing
right.
So
that's
already
a
problem
by
itself
and
that's
only
software.
So
if
you
look
at
the
whole
supply
chain,
it
might
be
better
just
to
focus
on
the
transparency
of
that
thing,
and
I
think
cozy
is
an
excellent
building
block
and
I'm
not
the
only
one.
T
There
was
a
list
of
names
at
the
beginning
here
and
and
so
to
add
on
to
this
cozy
issuer
authenticity,
I
want
to
say
the
reds
output.
I
think,
as
attestation
results
defined
today
would
help
there
and
again
transparency
services
with
certificate
transparency
and
the
ambiguous
thing
that
is
called
binary
transparency.
There's
a
lot
of
meanings
has
rep,
has
a
precedence,
so
there's
one
rfc.
We
are
borrowing
a
lot
of
terms
from
that,
but
it's
not
that.
Okay,
it's
it's
it's
transparency,
but
on
a
higher
level.
T
So
that's
my
take-home
message
for
this
sac
dispatch
thing
and
I
hope
it
is
of
interest
to
the
itaf,
because
that's
I'm
here.
We
want
to
have
some
guidance
on
how
to
proceed
on
this
work
and
so
that's,
hopefully
less
than
20
minutes.
I
actually
don't
know.
T
Oh
yeah,
oh
I'm
sorry.
I
have
a
last
light,
so
yeah
this
is
last
edition.
So,
if
you're
free
after
this
session,
you
can
gather
outside
and
just
around
the
corner,
there's
a
conference
room,
and
we
can.
We
continue
discussion
about
this.
We
have
a
regular
meeting
on
tuesdays.
It's
by
chance,
5
p.m.
On
tuesday,
so
we
made
this
above
like
a
pre-buff,
it's
not
an
actual
buff.
It's
a
barb
off
and-
and-
and
I
don't
know
I
heard-
sometimes
people
find
beer
at
barbos.
Maybe
we
do?
Maybe
we
don't.
T
I
can't
tell
about
this,
but
it's
around
the
corner.
If
you
want
to
meet
it's
5
p.m
like
at
the
coffee
table
and
if
anybody's
interested
in
joining
in
that
and
doesn't
have
lunch
plans
before
6
p.m.
Today,
maybe
just
join
the
discussion.
There's
a
link
here,
it's
in
the
slides.
Maybe
someone
is
so
nice
to
copy
that
link
into
the
meet
echo
chat.
Then
you
can
just
join
wherever
you
are,
even
if
you're
at
dinner.
T
So
I
almost
forgot
about
that
and
yeah.
So
that's
basically
it
that's.
That's
our
proposal
here
and
I
hope
we
find
a
place.
T
And
we
can
do
a
queue.
If,
if
you
agree,
I
don't
know
yep.
U
Yes,
so
I
just
want
to
make
some
difference
based
on
comments
that
were
made
in
the
chat
during
the
presentation.
So
I
think
there
were
several
comments
about
this
having
been
discussed
before,
and
why
should
itf
want
to
try
to
standardize
this?
No,
so
I
think
I
should
be
quite
clear
that
the
main
application
from
itf
point
of
view
is
transparency
for
binaries
and
software
supply
chain.
U
So
at
this
point
there
are
many
actual
deployed
implementation
of
binary
transparency
systems
made
by
firefox
made
by
google
made
by
microsoft,
and
it's
a
bit
concerning
that.
There
is
currently
no
interoperability
at
all
between
these
systems
and
one
of
the
reasons
that
we
think
that
the
kind
of
demand
for
implementations
is
going
to
increase
very
quickly
is
confidential
computing,
which
is
a
use
case
where
you
have
hardware
that
can
provide
a
remote
measurement
of
binary.
U
That
is
running
somewhere
else,
and
you
want
to
interpret
the
security
of
this
binary
and
essentially,
the
only
way
that
you
can
make
this
useful
is
through
transparency
and
that's
one
of
the
big
driving
factors
that
justify
having
more
operability
for
a
large-scale
transparency
system
system.
That
would
work
for
complex
software
or
even
web
service
environments.
B
Thanks
antoine
I'll,
I'm
next
in
the
queue
so
taking
off,
chair
hat
moving
to
participant
hat,
so
this
seems
like
clearly
a
big
piece
of
work
that
I
think
I
agree
with
the
discussion
in
the
chat
that,
if
anything,
is,
if
there's
an
ietf
problem
here,
we
need
to
have
a
buff
to
kind
of
validate
that
there's
broad
agreement
on
this
and
there's
a
community
to
solve
it.
B
I
think,
there's
I
would
probably
suggest
two
broad
areas
of
preparation
for
that:
buff
one
is
kind
of
validating
or
kind
of
focusing
in
on
a
fairly
specific
problem
where
people
can
kind
of
understand
a
specific
architecture,
specific
interoperability
problem
in
particular-
and
you
know
kind
of
focusing
this
up
a
bit
from
what
is
currently
designed
as
a
very,
very
broad
problem
statement.
B
The
second
thing
I
would
suggest
focusing
on
is
kind
of
building
up
the
community
aspect
of
validating.
There
are
other
folks
who
are
shipping
real
systems
out
there
who
want
to
who
want
to
solve
this
interoperability
problem.
So
I
think
antoine
is
correct
that
we
have
a
bunch
of
systems
out
there
these
days,
that
are
not
currently
interoperable,
but
it's
also
not
clear
to
me.
B
That's
a
problem,
because
a
lot
of
these
things
are
intravender
firefox's,
binary,
transparency
is
done
by
is
verified
by
firefox,
and
so
there's
not
a
bunch
of
need
for
interoperability
so
validating
that
there
are
people
who
are
going
to
ship
whatever
product
the
itf
might
come
up
with.
You
know
what
is
kind
of
the
other
suggestion
I
would
make
in
terms
of
what
we
need,
what
we
need
to
solve
and
above
and
then
I'll
pass
to
eric.
T
So
yeah
the
the
the
the
point
is
actually
really
do.
People
need
that
interoperability
or
is
it?
Is
it
not
necessary
right?
So
that
is.
I
think,
I
think
that
we
really
have
to
come
to
a
conclusion
with
because
if,
if
nobody
needs
an
interoperable
way
to
find
out,
if
the
supply
chain
statements
are
true,
then
then
then
this
is
not
not
necessary
right.
So
yeah,
sorry,
you
got
it
no.
J
No,
please
so
yeah.
I
think
first
like
I
think
that
not
very
lead
like
yeah.
This
is
gonna
need
a
buff
if
anything,
so
the
higher
the
question
for
me
is
like
you
know
what
the
relevant
community
is
and
how
much
we're
seeing
so
antoine
mentioned
that
there's,
like
you,
know,
open
a
lot
of
different
bts
efforts,
and
you
know
I'm
I'm
flattered
that
people
are
acting
as
if
the
firefox
one
is
perhaps
a
little
more
alive
than
it
really
is,
but
on
you
know,
and
they
aren't
interoperable.
J
But
you
know
it's
not
creating
me
making
and
another
one
is
going
to
solve
that
problem.
So
I
guess
my
question
is:
are
those
people
going
to
come
and
they
want
to
standardize
and
make
their
own
purple
standard?
I
know
there's
similar
work.
You
know
what's
often
called
web3,
and
so
are
those
people
comment
coming
and
want
to
work
on
this.
So
I
think,
like
you
know,
the
you
know
you
know
before
we
for
itf
is
an
effort
right.
J
We
should
make
sure
that,
like
we're
getting
enough
of
the
relevant
community
that
we're
actually
creating
a
converged
standard
rather
than
which
creating
earth's
there,
the
people
that
those
people
will
then
endure.
So
I
think
that's
that
would
be
the
thing
that
I
think
is
absolutely
most
critical
for
the
buff
to
get
into
I.
J
The
second
would
be
what
is
the
minimal
viable
like
thing
that
can
be
done
here
around
the
sort
of
maximum
maximal
division,
you're
proposing
the
maximum
visions
are
good,
but
but
in
terms
of
making
progress,
making
minimum
viable
is
valuable,
and
so
you
know
dkg
hand
with
a
little
bit
of
direction.
I
think
that's
valuable
for
my
hand
waving.
I
guess
I
would
say
that
I
think
that
the
that
the
ledger
aspect
of
this
has
perhaps
been
oversold.
In
many
cases.
J
You
know
we
got
pretty
far
with
ct
with
basically
no
meaningful,
like
third-party
verifiability,
and
so
you
know
descent
to
which
that
is
like
not
that
big
a
deal,
then
okay,
but
that's
a
big
part
of
the
big
part
of
the
value
prop.
You
know
counter.
Centers
will
get
you
pretty
far
so
and
certainly
for
most
the
cases
like
we're
looking
for
bt
like
if
you
just
had
counter
signatures,
you'd
actually
be
like
getting
emotionally
there.
So
I
think
you
know
anything
we
can
just
film.
T
O
Masks
yeah
steven
pearl
so
yeah,
I
I
think
richard
and
ecker
said
mostly.
What
I
wanted
to
say
is
that
you
know
above
seems,
like
the
right
dispatch.
If
there's
you
know,
if
you
can
get
a
bunch
of
people
interested
in
the
topic,
I
think
it's
a
it's
a
good
topic,
in
addition
to
kind
of
trying
to
come
up
with
a
minimal
piece
of
work
that
focuses
on
interoperability
for
the
ietf
part,
it's
also
a
giant
topic,
so
I'd
say,
try
and
also
find
a
small
bit
box.
T
O
Yeah
and
yeah,
so
I
think
there
could
be
a
possible
buff
here
if
you,
if
you
get
more
people
involved-
and
there
is
such
a
small
chunk,
because
otherwise
I
think
the
buff
would
be
just
kind
of
likely
to
waste
a
whole
bunch
of
time
only
discussing
scoping
and
maybe
never
coming
to
conclusion.
Yeah.
T
V
V
So
I'll
be
real
short
because
I
had
a
number
of
points
to
make
and
richard
made
all
of
them,
but
since
he
asked
those
who
are
arguing
for
a
buff
to
say
what
the
boss
should
accomplish,
I
just
wanted
to
weigh
in.
That
said,
I
agree.
V
I
think
some
of
the
main
points
is
to
make
sure
that
that
there
is
a
need
for
interoperability,
that
there
would
actually
be
multiple
implementations
that
are
actually
interested
in
implementing
the
same
thing
as
approach
to
price
terry
stuff,
and
also
that
the
sets
of
people
that
represent
implementations
of
those
I
would
actually
be
coming
to
ietf,
in
other
words,
are
the
right
set
of
people
in
the
room,
and
would
they
actually
want
implement
stuff,
because
we've
had
other
cases
of
interesting
problems
to
be
solved,
and
I
can
think
of
cases
where
there
wasn't
agreement
that
we
needed
interoperability.
V
W
W
W
W
At
the
other
end,
if
you
want
to
do
work
on
the
development
part
of
the
cycle,
you
need
git
now
I
know
that
you
have
a
microsoft
research
person,
so
github
would
be
you
know
I
I
would.
If
you're
going
to
have
a
buff,
I
would
say,
get
github
to
bring
the
get
people
into
the
room
because
they
have
technology
that
is
very
close
to
being
where
we
need
it
to
be.
W
The
problem
is
signing
your
commit,
doesn't
do
quite
enough
and
finally-
and
I'm
absolutely
serious
here,
if
you
want
to
get
any
anywhere,
do
not
mention
web3
do
not
mention
blockchain
and
absolutely
you
have
not
mentioned
proof
of
work.
W
T
Yeah,
I
think
this
has
to
be
carefully
worded.
Also
what
you
just
said
was:
it
would
be
the
initial
box
that
we
were
talking
about.
It
would
be
a
little
bit
bigger
when
we
run
when
we
talk
about
the
running
codes.
Signing
but
well
that's
delving
into
the.
I
don't
know,
for
example,
confidential
computing
space,
but
we
have
a
strong
overlap.
That's
not
bad,
but
maybe
that's
the
second
step,
so
maybe
we
have
to
really
find
out
what
the
initial
box
is
and
then
go
from
there
to
what
you
just
said.
T
So
I
think
that
the
path
is
right
so,
but
I
think
we
have
to
carefully
compartmize
the
problem
so
that
people
don't
are
scared
away
like
you're
trying
again
to
boil
this
here
right.
This
will
never
break.
This
is
like
the
code
signing
over
again
so
yeah.
S
Hi
there,
daniel
kahn
gilmore,
so
I
find
this
kind
of
work
interesting,
but
I
think
a
boss
is
the
right
place
to
go,
and
I
would
specifically
ask
for
the
both
to
think
about
what
actionable
outcomes
there
are
for
whatever
systems
you're
trying
to
design
right.
If
all
of
this
is
yeah,
I
just
want
to
know
where
my
code
comes
from.
I
just
want
to
see
this
transparency
stuff,
but
there's
no
there's
no
concrete
actions
that
can
result.
S
Then
we've
built
a
lot
of
mechanism
that
doesn't
actually
do
anything
right,
and
I
worry
about
this
in
a
lot
of
different
contexts,
not
just
technical
ones,
but
transparency
without
accountability
doesn't
actually
get
you
as
far
as
you'd
like
it
to
be
right.
We
think
of
transparency
so
as
you're
thinking
about
what
are
the
interoperable
goals
here.
Think
about
the
interoperable
actions
that
can
be
taken,
not
just
in
the
positive
case
where,
okay,
everything
is
on
the
chain,
we're
fine.
S
But
what
are?
What
are
the
actions
where
you
don't
want
to
run
something
because
it
didn't
match
this,
and
how
can?
How
can
you
actually
get
to
that
point?
I
think
that's
often
missing
the
folks
who
you
want
in
the
room
here
are
going
to
include
people
from
the
reproducible
builds
community.
I
mentioned
that
in
the
chat.
S
That's
reproduced,
pool,
dashbuilds.org
they've
been
doing
this
kind
of
work,
but
from
the
inside
out,
whereas
I
think
what
you're
trying
to
design
here
is
something
from
the
outside
in
the
folks
who
have
been
doing
that
in
different
contexts
will
have
a
lot
of
insight
about
what
the
stuff
actually
on
you
know,
close
to
the
machinery
looks
like
and
and
what
you.
Q
David's
kanaz,
google,
sorry
I
didn't
get
up
dkg
was
in
the
queue
before
me,
but
he
seemed
to
have
disappeared
so
first
off
thanks
for
this
presentation,
this
is
the
first
time
I'm
thinking
about
software
signatures
and
then
wanting
fish
and
chips
for
dinner.
Q
This
was
great,
but
then,
as
the
presentation
went
on,
you
did
gave
me
like
a
pretty
serious
spike
in
anxiety.
This
problem
is
very
big
to
the
point
where
it
makes
my
head
spin
and
so
kind
of
coming.
Coming
back
to
like
the
dispatch
questions
and
where
we
go
from
here,
I
think
the
first
dispatch
step
is
a
bar
buff,
which
is
really
great
that
you're
doing
that,
because
a
lot
of
good
itf
work
starts
that
way,
and
so
this
you
know
is
early,
that's
where
I
would
start
so.
Q
Absolutely
that's
great,
and
you
know
if
you
have
beer
even
better
and
then
next
steps.
So
I
think
you
definitely
need
to
figure
out
a
way
that
you
can
present
this
without
my
head,
spinning.
I'm
sure.
F
Q
The
only
one
and
so
teasing
out
like
from
what
other
folks
have
said,
which
part
do
you
really
belong
in
the
itf
and
which
part
don't
so.
I
think,
there's
value
in
explaining
kind
of
the
overall
ecosystem
and
then
so
people
know
the
context,
but
really
focusing
on
like
what
parts
we
need.
I
wouldn't
spend
any
time
on
like
the
solution
yet
like
jose
or
whatever
like
things
you
have
like
that
will
come
later,
but
really
saying.
Okay,
these
are
the
bits
that
we
need
to
do
here
and
what
I
would
so.
Q
What
I
would
suggest
for
you
is
to
spend
the
barb
off
meeting
the
people
who
are
interested
and
figuring
what
those
bits
are
with
them
and
then
kind
of
bringing
that
back
at
a
future
meeting
or
on
the
list
to
perhaps
hope,
probe
off.
I
think
this
is
a
good
direction
to
go
in,
but
the
scope
is
really
really
big
right
now
and
I've
never
seen
a
itf
effort
with
such
a
huge
scope
succeed.
But
if
you
manage
to
scope
it
down
to
something,
you
can
actually
make
progress.
T
So,
thank
you
david,
so
the
the
two
two
pieces
that
that
we
currently
think
are
in
the
box
are
just
the
the
issue
thing
and
the
receipting
all
of
the
framing.
How
is
this
useful?
Who
doesn't
really
need
that?
I
think
yes,
that
should
be
a
growing
topic
and
I
hope
to
have
some
discussion
today.
Basically
soon
and
yes,
we
will
definitely
make
this
happen
so
that
we
can
have,
in
a
four
month
interval
an
actual
buff,
maybe
and
and
and
we'll
discuss
the
results
of
this.
This
intermediate
discussion,
cooler.
F
F
So
we
don't
wind
up
with
a
solution
that
is
just
really
not
manageable
for
organizations
and
requires
just
tons
of
resources
and
the
architectural
patterns
for
management
that
we've
created
all
along.
So
that's
something
that
I
will
be
looking
out
for,
and
so
consensus
seems
to
be
the
recommendation
for
this
to
go
to
above.
If
the
ads
agree,
there's
a
lot
of
interest-
and
I
think
the
eyes
the
ietf
could
put
on
it-
would
be
really
helpful.
F
T
F
T
T
So
the
eyes
of
the
ietf
should
help
us
shape
that
box,
as
david
just
said,
and
I
think
we
have
two
pieces
and-
and
they
might
already
be
very
specific,
but
I
think
we
are
the
viable,
but
still
again
this
will
be
a
process.
Thank
you.
I
think
that
is
a
nice
response
from
the
group
here
and
yeah
again
at
5
p.m.
T
E
F
B
Okay,
thank
you
yeah.
I
could
talk
about
a
review.
Our
findings
here,
so
just
going
through
the
topics
we
have
covered
today
talked
about
updating
parameters
for
syslog
that
got
dispatched
to
uta.
B
Second
thing
was
updating
the
iana
ssh
parameters.
Registries
feedback
was
to
move
that
to
80
sponsorship
and
roman
agreed
to
sponsor
that
or
work
work
with
the
psycads
to
figure
out
who
to
sponsor
it.
B
Third
thing
was
andrew's
talk
about
ech
deployment
considerations
resolved
to
take
no
action
on
that
and,
finally,
on
the
trustworthy
supply
chain
thing,
the
feedback
was
to
take
that
to
a
buff,
and
I
think
there
was
some
good
feedback
in
the
discussion
for
how
the
the
proponents
should
kind
of
work
to
refine
this
and
kind
of
set
themselves
up
for
a
successful
ball
from
that.