Security Dispatch (Secdispatch) WG Minutes IETF 101 Tuesday, March 20, 2018 9:30-12:00, Morning session I Room: Blenheim (-3E) Summary ======= The following items were brought to the WG meeting and were dispatched as follows: ** draft: draft-foudil-securitytxt-03 -- AD-sponsorship ** draft: draft-nir-saag-star-01 -- bring to the LAMPS WG ** draft-housley-cms-mts-hash-sig-08 -- bring to the LAMPS WG ** draft: draft-birk-pep-trustwords-00 -- describe scope/problem statement to SAAG/SECDISPATCH mailing lists ** draft-friel-tls-atls-00 -- requires ART-SEC AD discussion for next steps 1. Logistics and introduction (chairs, 10 min) ============================= presenters: chairs slides: https://datatracker.ietf.org/meeting/101/materials/slides-101-secdispatch-chairs-overview-02 The chairs introduced the Security Dispatch process. Agenda bashing added draft-friel-tls-atls-00. 2. A Method for Web Security Policies (security.txt) ==================================================== draft: draft-foudil-securitytxt-03 presenter: Ed Foudil slides: https://datatracker.ietf.org/meeting/101/materials/slides-101-secdispatch-a-method-for-web-security-policies-securitytxt-01 Foudil presented draft-foudil-securitytxt-03 and asked for a recommendation on how to proceed. Q: (Mark Nottingham) Is this already used? A: (Foudil) Yes -- Google, Facebook, and others A: (Nottingham) Seems reasonable. Good that there’s already adoption. It would not be appropriate for HTTP WG. Q: (Ted) Would this format support multiple languages? A: (Foudil) It does not. Comment: (): Perhaps this should be made machine-readable too Comment: (Daniel Gillmor) Nice and simple, support this. Think about the scope of the security: site vs project Comment: (Phillip Hallam-Baker) I like it a lot. Comment: (Cullen Jennings) I like it and recommend it should be AD sponsored. Don’t add languages; keep it simple. Comment: (Paul W) Bad idea. If web server is compromised, how can I trust this? We have other ways (RDAP/whois) to get this information outside the (compromised) web site. Comment: (Ben Kaduk) Perhaps this should be a small WG. Comment: (Eric Rescorla) I appreciate the possible security problems, but alternatives seem heavyweight. I would not be opposed to small WG Comment: (Yaron Sheffer) You seem undecided about whether the target is machines or humans. I18n matters more for humans; contact information may be different. A: (Martin T) This is machine-readable format that contains URIs, not i18n-able, not needed. A: (Joe H) Agreeing with Martin; it already says UTF-8, and an administrator who cares can always put data in whatever language(s). Comment from chairs: Most feedback appears to be that this is a good idea. [chairs] WG please hum on these options: (1) this draft should be AD sponsored (2) this draft should be a handled by a short-lived new WG (3) do nothing with this draft Consensus Outcome: recommendation for AD sponsorship Dispatch result: recommendation for AD sponsorship 3. Considerations For Using Short Term Certificates =================================================== draft: draft-nir-saag-star-01 presenter: Yoav Nir slides: https://datatracker.ietf.org/meeting/101/materials/slides-101-secdispatch-considerations-for-using-short-term-certificates-00 Nir presented draft-nir-saag-star-01 and asked for a recommendation on how to proceed. The primary motivation for this draft was to discuss how to deal with short-term certificates. Q: (Hannes Tschofenig) Is this specific to ACME? (Intended as Informational); ACME is an example of these types of certificates. Comment: (Tim Hollebeek) Love this, but some of it’s over the top. No reason not to use it on the web, for instance. We should discuss the challenges, rather than dismiss them. Comment: (Volker Birk) We’ve discussed this before and decided against it. If keys expire quickly, you need new keys frequently. Mechanism for distributing keys can also distribute revocation info. Comment: (Phillip Hallam-Baker) Good reasons to use short-term certs on the web. Cloud systems, for example. Key exposures. Comment: (Eric Rescorla) Are you expecting communication from CA to client? Comment: (Stefan S) Should be rescoped to revocationless certificate, not just short-term; might be other reasons Comment: (Melinda Shore) Might rethink the language around key reuse and renewal Q: (Toma G) Is the focus on data centers? A: (Nir) Yes. A: (Toma G) Seems like you’re replacing CRL distribution with certificate distribution. Seems not to be making things better, really. (Reovcation server needs to be up all the time, so it’s different. Comment: (Phillip Hallam-Baker): This draft should not be AD sponsored. Perhaps a WG. Challenge will be interfacing with CT. Comment: (Russ Housley) I support the ability to flag these certificates as non-revokable, but no ad-sponsorship on this draft. Comment: (Eric Rescorla) I'm not sure how publication of this draft changes anything; or helps tell security auditor why we don’t have revocation ability. Dispatch result: bring to the LAMPS WG 4. Use of the Hash-based Merkle Tree Signature (MTS) Algorithm in the Cryptographic Message Syntax (CMS) ======================================================================================================== draft: draft-housley-cms-mts-hash-sig-08 presenter: Russ Housley slides: https://datatracker.ietf.org/meeting/101/materials/slides-101-secdispatch-use-of-the-hash-based-digital-signatures-in-the-cryptographic-message-syntax-draft-housley-cms-mts-hash-sig-08-00 Housley presented draft-housley-cms-mts-hash-sig-08 and asked for a recommendation on how to proceed. Comment: (Stephen F) I like the idea of work being done on this topic. Are you looking at rolling over to next gen key? Q: (Bob V) Are algorithms done? A: (Housley): Yes. Comment: () Prefer that this draft not be scoped to IoT, prefer starting a post-quantum working group Comment: (Phillip Hallam-Baker) I would prefer to see this would in LAMPS WG. It has significant connections to PKI stack. Comment: (Eric Rescorla) I would prefer to see this would in LAMPS WG. This is important work. I don’t think should create a post-quantum WG Comment: (Cullen Jennings) I don’t think SUIT is a good choice Comment: () Recharter or change names of lamps? curdle? Comment: (Eric Rescorla) Would you bring it to COSE? It should be generic so other groups can use beyond CMS. A: (David W.) +1 what EKR is saying Dispatch result: bring to the LAMPS WG 5. pretty Easy privacy (pEp): Trustwords concept ================================================ draft: draft-birk-pep-trustwords-00 presenter: Birk Volker and Bernie Hoeneisen slides: https://datatracker.ietf.org/meeting/101/materials/slides-101-secdispatch-trustwords-00 Volker and Hoeneisen presented draft-birk-pep-trustwords-00 and the broader pEp construct; and asked for a recommendation on how to proceed. Comment: (Phillip Hallam-Baker) I like it and am supportive. Comment: (): I think that this problem is more complex that you think. Language translation is an issue for communications. A: (Volker) We avoid translation. Comment: (Martin T) You can pick many words with different connotations but shouldn’t rely on humans to carry cryptographic dependencies A: (Volker) This work tries to remove human dependencies. Comment: (Jeffery R.) I like idea of standardizing word strings, but wish it wasn’t limited to 65k words Comment: (Dan G.) I agree about human dependencies, 16-bit isn’t sufficient for most languages Comment: (Joe Hildebrand) Representing the XMPP community, we're looking for liaison to XMPP community with this work. Q: (Eric Rescorla) Are you willing to bring all of PEP to IETF? A: (Volker/Hoeneisen) We think so. We see PEP as toolbox, and want to focus on interoperability. A: (Eric Rescorla) This draft doesn’t define trustwords, just the algorithms to determine them, do you plan to define the trustwords? A: (Volker) We do plan to define trustwords in IANA. If at the end it is just a registry of words, may not be too interesting Comment: (Phillip Hallam-Baker) You might want to look at making the registry more general, perhaps supporting images. 65k word dictionary is much more than most humans know Comment: (Cullen Jennings) This should focus on problem we are trying to solve. This work is too complex for AD sponsorship. Someone should write a mini-charter for a proposed WG. A: (David ) +1 on this point Comment: (Eric Rescorla) Maybe this work needs a mailing list for technical discussions, if the entire scope is under consideration. Dispatch result: describe scope/problem statement to SAAG/SECDISPATCH mailing lists 6. Application Layer TLS ======================== draft: draft-friel-tls-atls-00 presenter: Owen Friel slides: https://datatracker.ietf.org/meeting/101/materials/slides-101-secdispatch-atls-00 Friel presented draft-friel-tls-atls-00 and asked for a recommendation on how to proceed. Q: () Will this look like an HTTP tunnel? A: (Owen Friel) This work solves a different problem than HTTP tunneling A: (Daniel Gillmor) +1 for this, perhaps break up into the different things this does into different WGs, too many different use-cases A: (Eric Rescorla) We shouldn’t design in this meeting. Do people thing tunneling crypto info is useful? I want a general end-to-end solution beyond HTTP, that covers all protocols A: (Ben Kaduk) Sounds like this is ripe for BOF to figure out what area this should go Comment: (Richard Barnes) The point of this work is to create a secure way for transporting security information within an application protocol A: (Eric Rescorla) Proponents should get together to create BOF A: (Richard Barnes) We're treating this like mini-WG for scope of work, but still do BOF Comment: (Kathleen Moriarty): It may not need BOF. Dispatch result: requires ART-SEC AD discussion for next steps