Secdispatch - IETF106 Tuesday Nov 19 2019, (17:10-18:40) Chairs: Francesca Palombini, Richard Barnes, Kathleen Moriarty (remote), Nancy Cam-Winget (stand-in) Minute takers: Rich Salz, Giridhar Mandyam Recordings: https://www.youtube.com/watch?v=CYBhLQ0-fwE Session's material: https://datatracker.ietf.org/meeting/106/session/secdispatch 1. Logistics and introduction (chairs) --------------------------------------- Intro and Note Well; welcome Francesca as new co-chair 2. Problem statement for post-quantum multi-algorithm PKI (Max Pala) --------------------------------------------------------------------- draft: https://datatracker.ietf.org/doc/draft-pq-pkix-problem-statement/ https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/ Intro: will RSA/ECC fail? Are Lattice schemes sufficiently strong? Can PKI's be secure in 20, 30 years? Different solutions: multi-chain, ISARA Catalys, Composite Crypto Multi-chain/Multiple Certs: Pro's: Suitable for negotiated protocols Con's: Require protocol changes for multiple signature validation, how would it work with non-negotiated protocols Hybrid Certs: ITU-T added new extensions/rules for alternative sigs/keys. Pro's: backwards-compatible Cons: backwards-compatible (i.e. false sense of security) Composite crypto: new public key algm. Data structures defined to hold keys/sigs use sequences of keys/sigs. Pro's: "Drop-in" for existing OID-based crypto protocols, can be extended to combine algm.'s, can be used in all PKIX lifecycle stages Con's: backwards-compatiblity requires support of new algm. ID's, large keys/sigs are sent every time even if they are not used Discussion on secdispatch mailing list to problem statement I.-D. and composite crypto solution have been mixed. Different approaches have been proposed (e.g. MathMesh). TLS community has not chimed in yet. Discussion Perhaps not applicable to TLS, contrasted with signatures/off-line where it seems more applicable. Skepticism as to value in Web PKI. Browsers either accept an algorithm or they don't; hybrid algorithms that could include deprecated algorithms won't be possible for real-time applications. Max Pala: this is useful for protection of high-value keys such as Root CA's. There was additional skepticism expressed on use of hybrid crypto in a TLS context, as TLS has tried to simplify signatures, and complexity may have to be pushed into the crypto libraries. Chair suggest LAMPS; LAMPS sent it here. Seems scoped to signatures, so Secdispatch recommends to go back to LAMPS. Conclusion: Chairs recommendation (to be confirmed on list): dispatch to LAMPS. 3. OCSPv2 - Improving OCSP Responses (Max Pala) ------------------------------------------------ LAMPS & PKIX discussions: Ml discussion: https://mailarchive.ietf.org/arch/msg/pkix/eGE53uJIYKSzu7pObiUGWNXDH3M https://mailarchive.ietf.org/arch/msg/spasm/Ug_HtJz5FQvLbiXIdGXH---q7N8 Problem statement: revocation infrastructure is costly. OCSP does not scale well for large PKI. OCSP not optimized for the common case - "no revocation information", i.e. cert is valid. In addition, the revocation information or multiple certs in a chain can be simplified without multiple round trips. CRL's and OCSP are the most common methods for cert revocation. CRL size is unpredictable, unless statically partitioned. The proposal is to allow for range queries to the PKI. It allows for limited cert revocation information requests from the client. Discussion: Much of the discussion was supportive. There was discussion on whether CRL compression could be leveraged. If so, maybe LAMPS could be of interest; maybe not change OCSP, but address narrowing responses client needs to "hear". The ATSC example was mentioned, where specific OCSP responses are stapled to the broadcast emission so that the client can selectively download revocation information by tuning to the associated channels. There was a question on how range requests could be used when stapling is in effect. Another comment was it would be good to see data on the "cost" of data currently have to send. Conclusion: Chairs recommendation (to be confirmed on list): create a new focused working group. 4. Privacy Pass Protocol (Nick Sullivan) ----------------------------------------- draft: https://datatracker.ietf.org/doc/draft-privacy-pass/ Privacy Pass is a zero-knowledge protocol suitable for use in large-scale internet applications. The CAPTCHA example was cited, where a single CAPTCHA provider may leak information if multiple websites are using it. Privacy Pass provides a blind token from the CAPTCHA provider, and the client can unblind it accordingly for future verifications. Blinded RSA was cited as an example. VOPRF is what is currently used, where the token is verified by the issuer. Privacy Pass has FF and Chrome extensions over all Cloudlare sites. A proposed Working Group charter was provided where a protocol would be defined such that an auth token can be issued and verified in such a way as to blind the identity of the user from the verifier, and use of the protocol in HTTPS. ID Federation is out-of-scope. Discussion: The offline authentication use case was suggested. There was a question as to whether crypto work needed to be done as part of any standardization effort. All discussion was supportive. Will collaborate, see other uses. Want off-line added. Does CFRG need to review? Maybe. Suggest CFRG review the crypto regardless. Reconsider "interop out of scope". Yes, maybe too broad just federation out of scope. It was mentioned that cache/intermediary interactions may require coordination with HTTPbis. Conclusion: Chairs Recommendation: continue to work on possible charter text on the mailing list. A BoF could be next. 5. HTTP Request signing (Justin Richer) ---------------------------------------- draft: https://tools.ietf.org/html/draft-cavage-http-signatures Some driving use cases: proof-of-possession, authentication, request message integrity beyond TLS, non-repudiation, audit. HTTP message encapsulation breaks layering, which is why it isn't done today. HTTP messages are transformed, or parsed by different entities and re-serialized. TLS message integrity/signing does not work when traversing proxies or message relaying. S/HTTP encapsulates HTTP in signed container, but it is not widely-used. JOSE wrapping could be used to sign HTTP messages, but this looks like SOAP ("with curly braces"). Several standards were surveyed that propose some level of signing of HTTP requests - Cavage, OAuth DPoP, OAuth PoP, XYZ project, and AWS v4. Cavage has been published and used in several implementations, but it is not an IETF standard. Proposal: combine drafts, find a WG to take on this work, or start a new WG. Discussion: It was suggested to bring this to HTTPbis. mnot commented that the time may be ripe to start the work, and could consider a call for adoption. However, there would need to be the appropriate crypto/security experts participating. Integration with endpoints and intermediaries is tricky; may even be harder than the crypto part. The speaker clarified that the Cavage authors are in favor of IETF adoption Conclusion: Chairs Recommendation: dispatched to HTTPBIS WG. 6. Communication Network Perspective on Malware Lifecycle (Joachim Fabini) --------------------------------------------------------------------------- draft: https://datatracker.ietf.org/doc/draft-fabini-smart-malware-lifecycle/ Discussion: Chair - not clear how this fits into IETF, maybe the measurement stuff? How does lifecycle model fit? Ans. maybe making RFC 3552 more resilient not-yet-started IAB program on threat modelling might be a place for this. Conclusion: Chairs Recommendation: check the IAB program (talk to Ted) 7. Securing protocols between proxies and backend (HTTP?) servers (Brian Campbell) ----------------------------------------------------------------------------------- draft: Looking for support/contributors, no draft yet --> needs draft Conclusion: Chairs Recommendation: write up draft (can then re-submit to secdispatch) 8. 5m Wrap up, review of conclusions ------------------------------------ Summarized chairs recommendations.