SAAG (1300-1500) Thanks to Peter Yee for note-taking. As usual WGs posted meeting summaries to the saag list. The PKIX WG has been closed. DANE didn’t have an official meeting, but there was an informal get together. There are a lot of things that people want to do in DANE based on operational experience and testing. There was a PERPASS BoF. Concrete proposals from that BoF are under consideration, but none of them include creating a perpass WG. Other security related WGs KARP: lacking in reviews; more volunteers desired. PRECIS: Discussed framework document. Heading towards WGLC. Many comments received from KITTEN WG. SIDR: They have some drafts in need of review. MPTCP: Steve Kent: Apple uses MPTCP in iOS7 for Siri with TLS on top of it. So security such as tcpcrypt may not be needed for this. TSV area: Discussed Quic which has features similar to TLS 1.3. CFRG: gave a recommendation to TLS WG that ChaCha20 and Poly1305 seem all right. Invited Presentations: Tim Polk: NIST Cryptographic Standards Process Review ===================================================== NIST announced on November 1st that it will do a review of its cryptographic standardization process. History: NIST’s first crypto spec was DES (FIPS 46). Most expertise in crypto was in government intel agencies. Nonetheless, DES was developed in a fairly open fashion considering the time, including acceptance of public comment. Since then, the crypto FIPS catalog has expanded to cover the needs of NIST’s stakeholders. The community of users as well as the community giving input have both grown over the years. NIST’s covers US government non-national-security systems, although NIST standards are adopted by organizations beyond the USG. NIST recognizes that its standards are used beyond its statutory authority by organizations such as other SDOs and the financial industry. The reasons for such wide adoption are increased interoperability, wide availability of products, and reduced cost. NIST Goals, Objectives, and Roles: Develop crypto specs that are strong yet practical. What’s strong and what’s practical is reviewed over time. The process is supposed to open and transparent, with NIST balancing everyone’s needs with technical competence and impartiality. NIST’s Process: not one-size-fits-all. Sometimes there are international competitions. Other times, externally specified standards are adopted, or new algorithms are developed. Inclusiveness and transparency are aided by public workshops, solicitation of public feedback, and direct engagement with the crypto community (at crypto conferences, standards meetings). Anyone who wants to submit comments is welcome to. Recent Events: based on Snowden’s revelations, NIST has reopened SP 800-90A (RNGs) and two related drafts. Dual EC DRBG is now deprecated. Comments are welcome on the gamut of RNGs/DRBGs specified in the SP. The IAB submitted a comment against SP 800-90A that really made suggestions about the NIST process in general. Process Review & Update: covers more than the one DRBG of concern. Trust in the process is crucial to crypto algorithms and their standards. The process will be updated to: maximize openness and transparency (even more so than previously done), support the development of the best guidance practicable, and maintain the confidence of stakeholders. The revised process will be posted for public comment. Additionally, an independent review panel will be convened to provide an expert opinion on how to move forward. Review of Existing Work: NIST will go back to all of its current crypto standards with an eye to asking for additional public input or withdrawal as necessary. Floor comments: Ben from DigiCert: concerns expressed over Suite B EC curves. There seems to be FUD over what curves to use. Polk: we will review all of the documents, including the ECC documents. Dan Harkins: NIST should also consider the impact outside of the USG. NIST won’t standardize cipher modes that aren’t standardized elsewhere, and outside SDOs prefer to use NIST modes. Somebody: Despite NIST’s good work, regardless of what you do to the process, why should the community continue to work with NIST (as part of the USG) rather than seek another avenue for this work. Polk: you have to trust in the process. NIST also does have significant technical expertise. But it’s the participation of the community that really makes the processes work. With that participation, NIST remains a good place to do those standards. Try not to “throw the baby out with the bath water”. Even if someone else ran the process, it would still matter that the process was being run. Somebody: NIST is subject to backchannel pressure from other parts of the USG and is therefore untrustworthy. Polk: I’m not aware of any such backchannel pressure or susceptibility to the same. Addressing SP 800-90A, that document had a tortured development. It has 4 RNGs, one of which is the Dual EC DRBG. The hash and block cipher DRBGs are significantly faster than the Dual EC DRBG. Diversity suggested that the Dual EC DRBG was useful to some communities including the intel agencies. NIST reviewed the specification and noted that points are specified without attribution. So NIST suggested that others generate their own curve points. They learned that the Dual EC DRBG user community was building hardware that embodied the selected curve points. NIST did not, therefore, force generation of new points. But the Dual EC DRBG was retained for the use of those communities that cared. Robert Wilson: it would be a mistake to go forward on the basis that NIST only needs to address a process problem. Your explanation of the Dual EC DRBG points to an expertise problem as well. Those who can’t do their own crypto analysis rely on NIST’s review of crypto specifications. Thus it is paramount that NIST be able to review any draft thoroughly before approval. Polk: that’s fair. We are looking to expand our review team of experts. Russ Housley: NIST already has the most open and transparent process, but the IAB listed ways it thinks they process can be improved. Also, eliminating concern over the origin of curves would really help. Ben somebody on Jabber: any chance of a stream cipher competition in the near future? Polk: NIST is definitely looking at stream ciphers. The process to be used is not clear: competitions are a major strain on NIST resources over the 5-year period of the competition. Stream ciphers are the short list to be addressed. Brian Smith: by next year, some Web browsers will be using new ciphers and elliptic curves that have not been reviewed by NIST. Is there any opportunity for NIST to review the things that the browser community has chosen to use? Polk: I can’t commit NIST to that, but we might express input if we had it. In terms of elliptic curves, less is more. Originally, 15 curves were specified. FIPS 201 reduced the number of curves to 6 and but didn’t get uptake on that. Not until the number of curves was reduced to two did uptake commence. On the other hand, if there’s concern over specific curves and others are being implemented, that tells NIST something. What you really want is a review from NIST plus the broader cryptographic community. Bob Moskowitz – SessIon layEr SecuriTy Approach (SIESTA) ======================================================== Problem: application security context is tightly couple to the underlying communication context. This is not flexible, has a high overhead, and attacks on the communication context affect the application context. SIESTA wants to provide security context and message formats for an application without tie to the communication layer. Session layer security rides one layer above the transport layer. Although the IETF doesn’t recognize such a layer, there are many session layer protocols in the IETF. Decoupling from the communications context allows security to be resilient in the face of TCP resets, for example. No new KMP or algorithms are envisioned for this effort. Audience: Software-defined Networks, machine-to-machine (M2M), and others. Security state survivability: the threat is loss of state from events such as reboot. Loss of state prevents successful communication, which may cause loss of service, time, or energy due to the need to recover from the loss of state. SIESTA has a state machine that supports Start, Key refresh, Secure, Reveal (the opposite of Secure), and Teardown functions. It also needs to handle setup and state loss recovery. The application protection provided is in the form a Session Security Envelope (SSE). Think of pushing ESP up the stack to the session layer. It would only use modern cipher suites/modes, although it’s not a hardwired single format. Moskowitz thinks this is simple and could be done in 3 months without a working group. Two volunteers for the main document are already identified. It has already been implemented on NETBSD. There will be a siesta@ietf.org mailing list. Moskowitz is currently working on Verizon products that use an SSE. There will be IPR filed and revealed to the IETF. SSE formats: one compact format for constrained networks, one for fast networks that in maintaining synchronization, and one for extremely high speed networks that would overwhelm a 32-bit sequence number. Moskowitz is asking for IETF review and participation. Are there any thoughts on mid-box awareness? Is the state machine complete? The initial draft is expected within the month. Somebody: You are sending SMS and using ESP to protect it. How do use IKE to set up the association? Over SMS? Moskowitz: A chain of SMS messages would work, but also a compressed form of HIP-DEX could do it as well. Vijay Gurbani: have you used this in a VoIP context? I’d like to discuss it with you. Moskowitz: not yet, but I have heard from vendors with a similar interest. Dino Farinacci – Data-Plane Security for the LISP Protocol ========================================================== This is the LISP WG asking for SAAG’s expertise. LISP is in the routing area and needs security help early on. There’s no I-D yet. Problem Statement: Want to have confidentiality of the LISP data plane without PKI. The LISP Mapping Database could be used in place of the PKI. Doing everything in 1 round trip is a strong requirement. The need is to secure communications between xTRs (routers???) Sam Hartman: this sounds easy. I’d be happy to have a teleconference on this topic. Obvious Solution (from a routing perspective): put key material in the LISP mapping database system. Keys are exchanged with a LISP Map-Request/Response. There’s a Security Type LCAF (LISP Canonical Address Format) for key type, cipher-type, and key material. LISP is an overlay technology, so the core network, LISP site, or mapping system needs to change for this solution. Changes are made in the xTR data-plane (for encrypt/decrypt), and the xTR control-plane. Michael Richardson: assume there are multiple hosts behind one xTR sending to a host behind to another xTR. Should the Security Association be the same between the xTRs? Farinacci: Yes. Richardson: what about host-to-host security or host to xTR security? Farinacci: not my problem. Sam Hartman: this is simple. Is there integrity for the mapping system? Farinacci: there is integrity on the map replies using a one-time key. Hartman: substantial PERPASS benefits can be obtained encrypting the link between xTRs. Hoffman: if IPsec is too heavy because of round trips for the xTR link, use CMS. Farinacci/Farrell: don’t solve the problem right now. We don’t even have an Internet-Draft. Kent: you don’t want a PKI, but you seem to have built one anyhow. Farinacci: true. Kent: characterize the security you get from your system. Also, don’t assume the use of the RSA algorithm. And use fresh pseudo-random data from each end. Which admittedly triggers additional round trip. You’ll want to see if the desire for fresh pseudo-random data and not to have additional round trips can be dealt with. PHB: you said PKI is complex. Three reasons: 1) incompetent architecture; 2) ASN.1; 3) the problems are hard and the world is hard. PKIX ended up where it was after having to meet all of the use cases. Starting from scratch will probably end up leading you down the PKIX route with great complexity and incompatibility with everything else. If you can simplify what services you really need, you may find that existing PKI services are close to what you want. Harkins: this reminds me of the key management wars. SKIP from the ‘90’s signed Diffie-Hellman keys. This would work in the static case for a single encryption key between xTRs. Tero Kivinen: Authentication and integrity checking strike me as important services; encryption only misses out. Authenticated encryption can be added relatively cheaply with certain modes. And don’t leave out IKE just by forcing only 1 round trip. IKE would do what you want in 2 round trips. Paul Wouters – Opportunistic Encryption revisited ================================================= Wouters’ definition two endpoints using encryption without prior set up. Suggestion: public an OpenPGP key in DNSSEC to allow mail clients, MUAs, and MTAs to encrypt. See draft-wouters-dane-openpgp-01. Trying to speed up DNSSEC, especially on phones. See draft-wouters-edns-tcp-chain-query and draft-wouters-edns-tcp-keepalive. Old FreeS/WAN opportunistic encryption was slow and might time out the application that wasn’t aware of the OE taking place. There were lots of other reasons why this scheme didn’t work: hard for end user to publish IPSECKEY, key distribution via reverse DNS(SEC), a hope for NATs to go away with IPv6 (which hasn’t happened, yet), fallback to no OE took too long, etc. In the era of pervasive monitoring, deployed DNSSEC, and more powerful devices, it seems like the time to revisit OE. Users still can’t be expected to publish IPSECKEYs in DNS, IPv6 still isn’t there, and reverse DNS isn’t viable. Current solution: On DNS A record lookup by an application, have the DNS server have an IKE daemon set up an IPsec link if the lookup target has an IPSECKEY record, then send the A record response back to the application. The application transparently and obliviously sends data over the IPsec tunnel. Comparison to BTNS: seems too complicated for a variety of reasons. An implementation will appear in Libreswan 3.7 in Fedora 21. Please contact Wouters for more information. Hoffman: since you are doing a client-server model, why not just TLS? Wouters: that seems to require every protocol being combined with TLS. IPsec is more transparent in usage. Andrea Bittau: what layer is the sweet spot for OE? Wouters: at the outermost layer or multiple layers. Kivinen: I like that the application doesn’t have to know anything about the OE, whereas with TLS, the application has to know that TLS is being used. We get encryption everywhere without application mangling. And it could be optimized to allow the initial packets through in the clear since they are probably just TCP setup, then switch over to the encrypted tunnel for actual application data. Open Mic: ======== Hartman: we could have made the same mistakes that NIST did; that said, it’s important for the IETF to ask: what’s our process for interacting for NIST. In some cases, it’s a no-brainer. We couldn’t replicate AES and SHA. In some cases, though we do have the expertise to discuss alternatives to NIST standards. We should question why we don’t look at some standards more at arms length. Perhaps we treat them like other SDOs such as ISO where they need to sell us on the merit of the specification. We need to question whether standards that are offered to us are any good. Farrell: it’s a fair point, but we shouldn’t necessarily treat NIST and ISO the same. NIST does participate in our processes. Vendors do like adopting NIST stuff because it makes it easier for them to sell to the government. Dan (Cisco): how do we engage the security expertise in the IETF earlier. Do we have a scalable means to do so? Turner: the security folks will often show up elsewhere because another AD has asked for help. But that’s a reactive model which is sometimes the only way to do it due to the limited number of volunteers. We’re open to other ways of doing things. Dan: we don’t necessarily know how to engage early and then security issues are surfaced until late in the review process. It would be good to have a POC to reach out to for early input and direction. Kivinen: there is a SECDIR review process that can be engaged for early reviews. That’s typically done at WGLC or later. But earlier engagement is possible. Wes Hardaker: we have traditionally used building blocks from a lot of other organization. He would argue that there are two metrics to determine suitability of building blocks. Most importantly, was the process open? Were comments accepted and openly replied to? Farrell: this is basically what the IAB told NIST. Hartman: SP 800-63 says how the USG want authentication to work, which pervades their standards. I’m not sure their goals are aligned with ours. Polk: was written explicitly for government needs (based on an OMB memorandum). We didn’t like doing it and hoped no one would use it outside of government. That was a case that no one else would do something as silly, hence ours gets cited because it’s nearly the only one out there. The IETF needs to consider suitability of documents like that. We hope that the IETF or someone else will do something better. Michael Richardson: I wrote RFC 4322, which I’m glad Paul if going to fix and get working. It took 3 years to get it through the IETF. I was “helped” by lots of helpful people who gave endless suggestions on what was a personal draft. Better became the enemy of good enough. Housley/Turner: there are processes that simplify getting these things through without all of nitpicking.