## WG Reports

[mostly already sent via email, and some sessions had yet to occur]
[no noteworthy updates from the IAB Model-T program]

## AD reports 

Ben Kaduk - AD-sponsored drafts are in progress, albeit slowly.
draft-gont-numeric-ids-sec-considerations is about ready for IETF LC;
draft-foutil-securitytxt had an IETF LC but needs me to review the outcome.
OPENPGP is in the re-chartering process.
With Jim's passing, ACE has a co-chair vacancy.
Roman Danyliw - and not just for ACE; in general, if you have interest in being a WG
chair, please let us know.  Other highlights: vulnerability disclosure
guidelines for the IETF LLC and the IETF (protocols) in progress; we have a
last-resort alias that goes to Ben and me.
I also want to plug our list of "common DISCUSS topics"
I'll also highlight that our "publication requested" queues are both empty, a
good change from recent times.  We tend to operate first-come-first-served but
are happy to reorder on request.

Ira McDonald - Is there a second WG chair for CBOR to replace Jim Schaad.
BK - CBOR is not in SEC area, but believe something is in the works

DKG - On the vulnerability disclosure topic;  I know there is a PGP key
published to send disclosure to, but its not published in common PGP key
servers or in WKD.  Are there plans to do either/both of those.
RD - absolutely coming; doc not yet published, still in GitHub, but that is on the list of things as the document progresses
DKG - if any help is needed, reach out

RD - Thank you to the secdir reviewers -- they make a big different and we ant
to publicly acknowledge them.
BK - yes, huge thank you.  We tried hard to make this list complete, but if we
missed you it is our mistake.


## MITM/on-path terminology

BK - link to Michael Richardson's thread about what the "man in the middle"
terminology actually means, including his summary.  "On path" also may have
trouble, and there may not even be a single path.  Distinctions between
multiple classes of attack can be useful, and it would be useful to have clear
terminology to talk about them.  [Sets the stage a bit more, but ...] help?

Paul Hoffman - some similar conversations happening in DPRIVE right now;
willing to edit document, but not full decider; would be useful to have within
the next 9-12 months for a few WGs

Jonathan Hoyland - we should look to academia, sure there are some papers on
this; maybe limiting to 3 attacker types isn't sufficient; can get much more
complicated w/ relays
BK - can you or someone look through the literature?
JH - I can look through the literature

Joe Salowey - Is this something that would go along with the model-T work?
BK - right now not that's not clear to us; it's something model-T could or
should be thinking about but we may want something before model-T is done.

Jim Fenton - I'm confused about the problem to be solved: is this a question
of inclusive terminology, or possibly a finer grained definition of what a
MITM attack is?  If it is in terms of inclusive terminology - then there is
also work in the IETF terminology GitHub repo.  I don't know who's managing
that.
BK - the primary problem is that when you say "MITM", not everyone is thinking
the same thing; want everyone to understand the term.  Any inclusivity topics
would be a separate effort.

JH - If we're doing terminology should we be looking at RFC4949 (relayed for Mohit from Jabber)
BK - let's take that to the list, I'm not prepared for that right now.

Hannes Tschofenig - we ue a lot of terms, I would like them aligned or at
least mappable to academic literature and what is used for formal analysis
BK - yes, that would be good

Paul Hoffman - to answer Jim Fenton - the other reason why it's important to
have good terminology is not only so that we have useable terms, but also so
that people can read our materials and find term definitions; I recently wrote
a paper recently and used MITM and got some interesting responses from
security novices but people who understand the internet.  One is, if there's
something in the middle, that is a machine and it's there all the time, not
necessarily a person; another is, coming from Doh, that the MITM are rarely
really in the middle, they're close to an edge; e.g. security admins putting
in proxies on their users.

Robert Moskowitz - do we need to differentiate between peer wise, multi-user,
broadcast, different communication types.  Is that a factor?
BK - we're just brain storming this, so reasonable to consider
RD - Two other things we heard: we should check things we've published already
in the IETF, and we should check for consistency and not publish something in
conflict.
BK - should this get split off into another mailing list outside of the SAAG
list?  **ADs will check in a few weeks on SAAG**
[The jabber log at https://www.ietf.org/jabber/logs/saag/2020-11-19.html has a
robust discussion of this topic]

## Requirements for Building a PKI

BK - Thanks for this talk.  Lots of good discussion in the jabber, and I think
we may have extracted a promise from Phill to give his sense of the history
here.  The second half of the talk is still useful.

PHB - Many details of the talk were wrong; Netscape didn't have a chain check
because it took a non-trivial # of seconds to connect to a website at the time
(stated vaugely); the crypto we use here is from the 90s, or really even has
its origins in Loren Kohnfelder's thesis from the 70's which was the blueprint
for PKIX.  For some things blockchains may be useful, let's use the right
tools for the topic.

David Schinazi - thanks Ryan for this talk; we should have some more
historical talks at IETF.  I learned a huge amount today.

Fraser Tweedale - Can you briefly talk about the topic of GREASE
Ryan - GREASE is hard because you need the cooperation of the CA as well as
the presenter and recipient of the CA; so you need a 3-party communication
problem; likely easier for something like S/MIME, but for TLS you have
1-cetificate and 1 shot to get it right; so it's risky to accept GREASE
certificates - who might break the world first; what CA will issue a GREASE
certificate.

## Open Mic

Kirsty P - could we use this time to talk about the vulnerability disclosure
policy: in particular timescale for publication?  How to harness
skills/knowledge in IETF to improve it. This is a v1, missing some things -
what will happen when for v2?
RD - this really documents the "as is" in the IETF; it doesn't try to change
anything other than adding an email address;  it doesn't really get IETF to
best practice, there could be a lot more work to be done to get IETF to
best-practice and that would involve consensus building;  IETF should probably
its own dog food, for example about to publish "security.txt" if the  IETF
should publish that.  We also can think about how much we want to reach out to
the implementation community and let them know about updates.
BK - are these evolutions that you (Roman) will be driving
RD - We need a community-based approach.  Something that came out of the
conversation of current work is whether we have a place for that conversation
to occur; I want to drive that consensus and get a mailing list for that
conversation.
Kirsty P - thanks, that sounds like a good plan

Dave Waltermire - I work on CVE outside of IETF as a CVE board member; want
other organizations to become a CVE numbering authority for creating CVE's;
has the IESG considered being a CVE numbering authority, issuing CVE's for
RFCs
RD - that's a good idea, we haven't talked about it, but it's come back as
feeback to the IESG.  What we're doing right now is not so bold as that, but
it's good fodder for IESG being better at vuln mgmt in general
DW - willing to help that if IESG is interested

PHB - blockchain is a hot topic in crypto; but I would urge people to start
looking at the threshold crypto world; next US administration will be looking
at consequences from Snowden, insider threats, etc.; I made a set of training
videos covering how threshold crypto works and will put up slides soo
BK - sounds good, post note to saag when slides are ready.

Chris Lemmons - I would second having CVE's for RFC's;  Where a tool gets made and defines RFC's that it relies on and then can get notifications of CVE's
RD - Yes, if IESG goes that way, it makes sense to have that machine readable and distributed for automated consumption
CL - it's not simple, but there have definitely been vuln's in RFCs

DKG - I'm more wary about assigning CVE's to RFC's; more likely to be assigned
to certain sections of an RFC, which may not be implemented in a tool; or
about how a tool is used in the world, or might be between intersection of
different RFCs.  I don't see how we can represent that for machine consumption
CL - this is a common problem w/ CVE's and not unique to RFCs; CVE's on
independent libraries often declare a vuln on a particular usage which might
not apply for everyone; (a) this may not be solveable for this problem and (b)
that might be okay that it isn't solveable, it shouldn't stop us from
producing easily digestable mechanisms.
RD - CVE's can refer to vulns across RFC's; RFC's vary a bit, this is why we
need conversation on the list.
DW - The CVE program is working on CVE v5 which includes a lot more metadata
in the vulnerability record and open to having more robust metadata to work
through these challenges; please work with us on CVE definition and don't
define your own record format; I will post to list
BK - good to have a forum for people to engage with you
RD - does CVE board have other SDO's on board?
DW - no, there is no SDO w/ issuing authority; it goes to entity of last
resort, currently MITRE
Joe Salowey - CVE format current is not perfect now and not entirely
automatible; but its encouraging that its still getting improved; it would be
good if IETF worked to improve that and get CVE better.  What kinds of things
do we want to be able to say, what protocols had problems, why, etc.
BK - looking to Dave W. to post more information on how to engage.
DW - will do
Hannes - OAUTH looked at security incidents related to OAUTH and they were
fairly complicated; first problem is to learn about the incidents at the
necessary level of detail; requires a lot of time to understand how the
vulnerability happened; some incidents took months to analyze, especially if
it involves custom variants of the protocol; who will do this?  this is really
tough.
RD - Yes, this can be really challenging; for people who come to IETF and
finding CVE's related to RFCs; also Hannes is being modest -- OAUTH is the
only WG with a defined vuln handling method in its charter.
BK - yes, its likely that WG's will have to get involved in handling this.
Confidential disclosure may not be a thing.
CL - inevitably there will be disclosures against closed WG's; need to plan
for that occurance too.
Sean Turner - reminds me of errata -- it's hard to get errata fixed against
closed WG's; vuln's will be really hard to deal with; as former chair of WG
wanted to stop getting notices on vulns because had to keep confidentiality,
etc.
DW - we're trying to dispell that all vulnerabilities need a fix; sometimes it
may be okay to publish a vulnerability even though there won't be a fix; maybe
that could be motivation to move to a newer protocol that doesn't have
vulnerabilities.
Hannes - As an example, OAUTH relied on JWT's but many implementations didn't
have policy checks on the JWT's (e.g., having the NULL ciphers); is that an RFC
vulnerability (maybe NULL cipher shouldn't be included); but then IETF needed
to try to reach out to MANY implementators of these systems and that was a
problem; it's a huge ecosystem and the long tail is really hard to solve; but
the fundamental protcol was fine and still in use.
DW - agree, and that's a classic problem in the space; another reason to
publish a CVE is to be able to publish guidelines around compensating controls
and implementation guidance; can generate an awareness campaign.
BK - thanks to Chris Inacio for taking minutes.

### meeting end