SAAG Thursday afternoon, 2011-03-31 Minutes taken by Paul Hoffman Text on the slides is not repeated here Tim Polk is leaving Last hurrah Round of applause Steve Farrell is incoming AD Funded by European research money Runthrough of WGs DKIM will have just one chair WEBSEC WG is getting active, had interesting debate on "do not track" OAUTH will meet, wants more security participant People here should read the next draft which will have more security considerations WOES side-meeting Doing CMS in JSON, two complimentary drafts that will probably merge Intro to MIBs, YANG, and why security geeks should care Ron Bonica presented remotely See NETCONF WG Tim Polk: People have wanted us to write these What's in it for us? Ron: Also is an invitation for security folks to review their protocols We should care because of help to operations Wants us to give more security input to the NETCONF and YANG folks Sam Hartman: The two communities are using very different tools Most security protocols are not being managed by network management people They are managed by security people It would be painful to add management to platforms that have many parts We tend to have looser parts Ron: If we started with a protocol that really should have a MIB, we could get a group together to do this Phill Hallam-Baker: Maybe this a reliability problem instead of a security problem Cloud: it is useful to find which of your services have fallen flat on their face Rob Austein: DNS MIBs are an example of what could go wrong Russ Mundy: IPsec MIB was a worked exmaple Paul Hoffman: Disagree Ron: We have a lot of examples where RFCs match what they thought was going to be needed But what was really less than that, so the MIBs were bloated Joe Hildebrand: When you have subagents on one box Their OPs team want them to not use SNMP HTTP-Mutual Authentication Yutaka Oiwa draft-oiwa-http-mutualauth Eric Rescorla: Until we fix the user interface problem, there is no reason to do this work There are other good methods, but we shouldn't bother because users will type their password anywhere Yukata: Users need to have at least a minimal understanding of the UI Even professionals can make this mistakes Jeff Hutzelman: Their university has been tried to train their users into web browsers (?): Several countries require TLS user auth for certificates in banking Laws demand it in some countries, and it works well there Jeff Hutzelman: HTTP itself already has a downgrade attack, so it is no worse than SASL downgrade How do you handle the provisioning problem? How do you know got to the right place first? Yutaka: This is also a social problem Phill: In October, "the patent" expires. This problem is 40% interface and 60% deployment The big pain point for the end user remembering so many passwords, user registration requirements Eric: If the UI problem was actually solved, you could just use salted passwords Completely backward compatible with current databases What would be the advantage of using this more complex crypto? Sam Hartman: Mutual authentication has some advantage Sam: Most important things we should do is to see if there are security services we should be offering We should also look at whether we can help on usability that will bring better security We should ask proponents to get review from our community. Yoav Nir: The baseline is so low we only need to add a small amount to help. The UI problem is 90% of the problem. Yutaka: We also have a proposed browser UI to ensure the security proposed by this protocol [presented at Wednesday Bar-BoF]. In any security mechanisms users need to have at least a minimal understanding of the UI, not only this one. And Phishing is not beginner's only problem: even professionals can make mistakes. The FNV Non-Cryptographic Hash Algorithm - 15 minutes Donald Eastlake draft-eastlake-fnv Stefan Santesson: We considered FNV in PKIX, but we decided that we actually needed security Had code in an old draft FVN-1a design turns out to be most efficient This could have been used in DNSSEC for key tags Eric: compare it to uhash? Don: Not here Joe Salowey: Sometimes it is difficult to define whether or not we want a cryptographic hash Discussion to continue on saag@ietf.org. DNS Certification Authority Authorization (CAA) Resource Record Phillip Hallam-Baker draft-hallambaker-donotissue Jeff: Do the one-year deployment requirements become shorter if everyone deploys Phill: Doesn't know how fast CABrowserForum can work on new rules Wants to see the RRtype Phill: It's in the draft, has policy types Can also tie to a specific CA certificate Can you specify the RA? Phill: No, but you can put an extension for that You are required to have a list of "high value" domains, but the lists are not consistent Steve Hanna: Good idea Michael Richardson: Thinks a good idea, until there was extensions Phill: Hasn't gotten his resource record, is about to tell them which one his going to use Tim Polk: What is the motivation for customers? Phill: Large companies who have a preferred provider but some people buy certs for subdomains Matthew Kaufman: Is this opt-in or opt-out? Phill: Opt-in Sees deployability issue Anton Ivanov(?): Does this apply to subdomains? Do you walk down subdomains? Phill: Uses enclosing domains list and maintain it CAA rules for issue: look to public delegation point Steve Hanna: Sees a strong incentive to put in CAA records Paul Hoffman: This overlaps DANE for CA certs Phill: All protocols create legacy, you have to deal with it. Discussion to continue to saag@ietf.org.