Minutes IETF108: saag
minutes-108-saag-00

SAAG @ IETF 108

WG Reports
----------
Yaron Sheffer: We were going to shutdown [SECEVENT], but discovered a lot of
interest in the subject identifiers draft, so we'll keep going with that. Paul
Wouters: TRANS is working on one document and has one document left; three ADs
have DISCUSS points so we have to track them down. Karen O’Donoghue: I sent
late report on NTP for its security related items.

AD sponsored drafts progressing:
--------------------------------
- draft-foudil-securitytxt
Ben Kaduk: working through the many last call comments; discussion on saag@
- draft-gont-numberic-ids-sec-considerations
[covered in a later section]

Thank you to the secdir reviewers from both Ben and Roman!

DOTS Overview
-------------
no questions

PKI vs. Pinning Applicability vs. Manual Configuration
------------------------------------------------------
- https://mailarchive.ietf.org/arch/msg/nfsv4/SLTNqWbjE-H8JshLk0HwlwxArrI/
[Ben sets the stage, including an informal taxonomy for what we could be
talking about today, and some of the pros/cons of the various options]
Ben: If we think RFC 7469 is no longer recommended, someone could write
a document to explain why and move it to Historic.
Wes Hardacker: Yes, I'm always in favor of having people able to configure their
crypto.  But to clarify on the questions, we're not defining who is doing the
less trusting. Clueful users want the control, but clueless users are letting
someone else make the decisions -- browsers and OSes do so for them.  But
there's other potential parties as well -- CAs don’t trust each other, and cert
owners want to only trust (pin) their CA and reject all the others ... but what
if they have to move to a different CA.  If you ask different parties, you get
different answers.

Richard Barnes: (echoing what he said on the list already) This is almost not a
protocol issue. In various protocols (TLS, MLS, etc.) the authenticationn stack
is loosely coupled to the protocol stack.  So the question becomes limited to
protocols that try to constrain themself to only one or few of these options.
We probably don't need an absolute prohibition, but we do need some kind of
justification of why a protocol contrains itself to manual provisioning, or
whichever mechanism it uses.  How will you deal with the
trust-establishment/provisioning problems, and how will you deal with
revocation? Ben: right.  It becomes more plausible scoped to an enterprise, but
is harder to justify in broader settings.  That said, you still have to justify
it. Richard: To be clear, my preference is that all protocols go the TLS/MLS
path and have it be entirely separate.

ekr: A few points.  First, to Richard, it's true that comsec protocols are
agnostic for the authentication mechanism but the upper layer protocols tend
to not be as agnostic, HTTP specifies cert authentication, etc.  If you need
any client to be able to talk to any server, you're essentially forced to a
PKI or some sort of public thing like DNS, and from that baseline,
pinning is just an attempt to narrow this public namespace. this has fallen
out of favor in the “community”.  In an enterprise or private setting, then as
your provisioning grows to handle more systems it ends up becoming automatic,
which is in essence becoming a PKI.  And I think the number of systems for
that threshold is very small.

dkg: Two points 1- IETF continues to skate around the question of we do APIs,
as this starts to look like an API.  To be clear, I want to support it -- I
think we should think clearly about what API for authentication should be
for any certificate stack, and that helps shape good implementation.
2- In terms of terminology, there is a history of multiple uses of “pinning”
and what it means here. Both "I want to constrain" and "I want to add
additional things", and we should be careful.  We could try to claim that we
own the term and will use it only one way, but there's history using other
ways.

yoav nir: We did HPKP a while ago, and initially had all sorts of options for
what to pin, and eventually came to the conclusion that pinning the end-entity
is the wrong thing because eventually it will need an update. pinning to the CA
is where you want to pin something. Granted, when Google says something
"doesn't scale" that can mean something different than for the rest of us, but
it still sounds like you don't want to pin the end-entity certificate.

Phillip Hallam-Baker (in jabber): most users don't want to configure this
stuff but they pay AV companies to manage it for them.  One point for us to
make is that the decisions about what (e.g., CAs) to trust should be
controllable by the user, not just defaulting to Google because they control
Chrome.  Also, we have better crypto than old PKIs now -- we could go to
threshold crypto.

Potential BCP 72 Updates
------------------------
- IAB Model-T program
- draft-gont-numeric-ids-sec-considerations
please chime in on the email thread for the threat model -- questions about
requiring coverage of specific topics in security considerations vs. just
adding to the list of potential topics, and about how much detail to include
in this document vs. others.

IAB Model-T Program
-------------------
Jari: We've had great success, so this is about possibly extending the set
of threats to consider, with the emergence of new types of issues.
Open mailing list: model-t@iab.org

Open Mic
--------
'()