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 -------- '()