Minutes interim-2020-edm-01: Tue 06:30
minutes-interim-2020-edm-01-202009010630-00

EDM kick-off meeting - September 1, 2020

Welcome by Tommy (program lead)
- This is not a wg or rg. Goal is to have a focused discussion and get input by
interested people in the community so we can write document, have workshops, or
provide recommendations. - Tommy is moderator; use +q to join the queue! - How
flexibility of protocol is impacted by mechanisms and our process, e.g. interop
testing, greasing. But not done consistently and a lot of effort to organise.
There is a trend so maybe we can put some general tools in place to help. -
Issues on GitHub on evolvability and deployability (30 minutes each)

Issue #3 What extension mechanisms are successful?
- Tommy: draft started by Martin Thomson: Good set to start with. What is
missing? What has changed? - Martin: list is complete as I was aware of at that
time. But since thought more about evolvement of other parties. Main thing that
is needed is review and feedback. - Tommy: document can take it up? - Martin:
Yes, people can pitch in and turn it into something usable - Tommy: how do we
make active use happen in the way we design our extension mechanism? E.g how to
design IANA Considerations. Could that be added? - Martin: mechanism that
people care about are the ones that work. So one of the points is to have very
few extensions points. Often people want every possible option and multiple
IANA registries but that haven’t work well in the past - Tommy: notice the
same. Flag e.g. might be hard to extend as you don’t plan to use. You should
active use or make it an invariant. - Brian: how do you create invariant
without actively using it. Active use if 4.1. if you want to have an extension
mechanise that works, you need one that works. Rest is about if you can’t get
active use then you should simulate it. Invariant is a document a threat to
simulate it - Martin: crypto is narrowing who you expose to. - Tommy: you can
still ossified on the other end - Brian: or on the encryption. - Tommy: Broader
context: are there other examples and it is true that active use are the used
that work? - Brian: Like to heart examples of active use failing - Tommy:
what’s the additional we might need to add - Watson: NTPv4 extension field was
used by implementation but RFC came later, so squatting happened and also DoS
application: So aggressively policed NTP and no we have all kind of network
problems. So real challenge to negotiate v5 now. - Tommy: it wasn’t used well
until later - Watson: widely deployed implementation but not widely deployed
protocol extension. It works somewhat but depends on your ISP. There is a
certain range that is bad. - Chris: TLS had mixed success for new extensions.
ESNI recent debacle to be blocked by china. What’s the threat model. Is it just
a buggy middlebox or actively preventing a certain extension. - Tommy: maybe
something to add. Even if you have active use but if people don’t like it, you
probably need crypto. - Chris: Moree guidance about which extension mechanism
to use. - Martin: Bootstrapping problem for crypto. So you have to be exposed
at some point. - Chris: TLS vs. QUIC? - Martin: QUIC is probably much like TLS
in that sense. - Chris: QUIC obfuscated - Martin: not sure how successful in
the long run - Tommy: helps against dump middle boxes but not against active
attackers - TLS is interesting because we need to treat security special. You
can have crypto context before you have crypto context. There is also different
models of non-functioning of extension mechanism. SNI changes the channel.
Other protocols use this to upgrade as a nice to have. In some cases it chances
the channel in an unexpectable ways. Do we need to treat them different?
Different semantics? Different terminology. Not not saying “security is hard”
but consequences are different. For security a failure of connectivity might be
preferable. It’s different than just interference. Same wire effect but
different semantics and so these are two - Tommy: different layers. On higher
layer your website just looks like garbage - Brain: be more carful about things
that impact end user directly. - Colin: Are there other cases where we want to
fail rather can continue without extension. That seems to be the distinction -
Tommy: Can always design fallbacks. Usually applicator does not rely on newer
semantics. - Brain: problem with SNI is that is does work. Are other other case
where it is better to fail. Only if you want to test the extension. It might
just be that security is special. - Tommy: temporal aspect. Every downgrade has
explicit engineering effort. Only do it to something that I know works well on
the Internet. Don’t go back to SSL. So it’s only so far we fall back. Maybe
something to document - Martin: Watson made comment on chat: if you can’t trust
the other to implement feature properly, sometimes it’s not worths to continue,
so you know that something has failed and you escalate. Robustness princple
doesn’t always give you reliable results. Carsten says “fail fast”, I’d say
“fail noisy”. - Tommy: fail fast and let everybody know. - Tommy: look at notes
and ask people to review

Issue #1: Approaches to tracking implementation interop and deployment
- Tommy: discussed on wg chairs list. We have examples on quic and tls; use of
GitHub or wiki. What have people done and what works well? - Charles:
increasing deployability also needs code to help people to implement correctly
or understand, e.g. like test clients. We have this in the hackathon but those
are not findable easily. People in the hacakthon know but if you only have the
RFC how do you know? Is that a separate issue? - Tommy: could open a separate
issue. But it on topic. Tracking implementation to the point that is helped
deployability. Where are people putting this? - Charles: Usually in the
hackathon wiki for that IETF meeting. Like to GitHub repos or other wikis that
have links to repos. Also in the presentation of hackathon with are also in
another github repo. But are those link still useful after the hackathon. Info
at multiple different place. Sometimes in wg wiki but that’s not universal
either. Let’s discuss and agree to a small set of ways to do that - Colin: For
RTP spec we had a separate draft to write down interop points and
implementation. Was never intended to be published but slides are in
proceedings and draft is still there. Examples of Interop record which life in
the IETF process - Martin: protocols work the best of you have a developer
community around them that communicate to each other. In those communities
there have not been any problems to figure out where to find things. - Tommy:
healthy communities. Wiki in GitHub for QUIC as all links and that’s better for
implementor community. Should we have a template or an easy way too bootstrap?
- Roman: We don’t need all interop report in the same format but the
datatracker should have a standardised pointer. Consistent way to find things -
Mirja. Other people need to be able to join - Tommy: don’t have too many silos
of communities. Communities involved in the IETF that’s great. But how to enter
and how to make clear to invite implementor who are otherwise not involved in
the protocol spec work - Colin: pointers to external resources are great but
those external resources might not be stable. It hard to add resources beside
wiki. E.g. markdown to upload. Make it easier to put content on ietf side. -
Tommy: datatracker? - Colin: Somewhere on ietf.org - Martin on chat: TLS wiki
rotted pretty fast - Tommy: datatracker: proposed slides works better than just
relying on chairs. Implementor should propose content - Brian: Publicly
available endpoints makes sense in QUIC because of virtual interops and time
zone problem. Probably there are other testing endpoints. Collect those and
make them publicly available. Might be behind version but if you use it
yourself it’s not rotting - Tommy: also calendars for interops - Zhenbin: In
RGT area we have a draft to record interop/implementation status. But when wg
is closed this draft will not be updated. Can we simulate IPR mechanism? Tool
for user to disclose implementation or interop test results. Update at any
time. - Tommy: in RGT there is already practice to have a section in draft
about implementation status. Move this to a different place or amend RFC to
have a way to update that even after the RFC is published. - Watson: Is the
question about tracking interop testing or deployments? Concerns about
long-term is not a problem if it’s only for draft development. I only know NTP
and new versions will be in release note. But a lot implementations are only
there to test if spec works. - Tommy: different groups find different value in
documenting development or deployment implementations - Mirja: Important is to
make information easy to find. If people are aware a common format might arise.
- Charles: for next hackathon let’s get this information for all project in
wiki or datatracker and make it easy to find. - Tommy: have already hackathon
infrastructure to try things out. Virtual interop testing is just individual
hackathon that we can make look the same. - Tommy: look at existing tools and
what’s done at the hackathon and recommendation we can give. - Tommy: Action
items - (1) work on updating and reviewing use-it-or-lose-it document, (2) work
with tools team and hackathon to start tracking Interop testing.