Security Dispatch (Secdispatch) WG Minutes IETF 103 TUESDAY, November 6, 2018 1610-1810 Afternoon Session II Room: Meeting 2 Note Taker: Mohit Sethi Jabber Scribe: Yoav Niv Summary ======= The following items were brought to the WG meeting and were dispatched as follows: (1) draft-belyavskiy-certificate-limitation-policy-06 -- clarify use case and motivation (2) draft-vangeest-x509-hash-sigs-01 -- re-charter LAMPS WG to accept this draft (3) draft-vcgtf-crypto-assets-security-considerations-02 -- build a community of interest by requesting an IETF mailing list (4) draft-aura-eap-noob-04 -- discuss with EMU (5) draft-fiebig-acme-esecacme-00 -- AD-sponsored 1. Logistics and introduction ============================= presenter: Roman Danyliw slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-secdispatch-chairs-summary-02 The chairs introduced the Security Dispatch process and the drafts under discussion. 2. Dispatch items ================= (2.1) Certificate Limitation Policy ----------------------------------- draft: draft-belyavskiy-certificate-limitation-policy-06 presenter: Dmitry Belyavsky slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-secdispatch-certificate-limitation-policy-00 Dimitry Belyavsky presented on Certificate Limitation Policy (CLP) as a means to address the binary trust model in PKI and as an approach to mitigate the misbehavior of trusted CAs. Q: (Yoav Niv) The list of certificate trust anchors is signed by who? Is there one that is hard coded? A: (Dmitry Belyavsky): Yes there is a hard coded key but not all check. Q: (Ben Kaduk): What sorts of non-binary limitations do you want to put on the certificate? The potential value I see is in a data model to restrict certificates. Who will use the signing and distribution? A: (Dmitry Belyavsky): A: (Ben Kaduk) Do you think browser vendors would provide this service to the rest of the world? A: (Dmitry Belyavsky): I hope. Model of distribution. I expect source of CLP is browser. Comment: (Martin Thomson): We maintain a similar system. But we have it simpler. It is more boolean. For intermediate CA this is useful. But for lead nodes it adds too many bits. You have to think about the size considerations. Correct trust anchor is difficult to identify. We use a list. Talking about generic system is challenging. (Roman Danyliw): Feedback on the draft is helpful. Does the WG have feedback on where to take this work? A: (Valery): My main problem is that is chicken and egg problem. A: (Dmitry Belyavsky): This is common to all PKI systems. A: (Sean Turner): This seems like a way to manage trust anchors. Browsers do it. IETF protocols do it. We don't need another protocol. Do browser vendors want a universal way to do? A: (Jonathan): Feel a lot things leverage off this. Mirror browser policy. Goal is modeled more formally. NEXT STEP: clarify use case and motivation (2.2) Algorithm Identifiers for HSS and XMSS for Use in the Internet X.509 Public Key Infrastructure ---------------------------------------------------------------------------------------------------- draft: draft-vangeest-x509-hash-sigs-01 presenter: Daniel Van Geest* slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-secdispatch-algorithm-identifiers-for-hss-and-xmss-for-use-in-the-internet-x509-public-key-infrastructure-draft-vangeest-x509-hash-sigs-01-00 Daniel van Geest (remotely) presented about the need for algorithm identifiers for HSSD and XMSS. This work was already presented at the LAMPS WG with a bit of discussion. Comment: (Sean Turner): Ship it to lamps. Looks like ready. Comment: (Russ Housley/co-chair of LAMPS): Will any one implement it? We (LAMPS) need a commitment to implement before re-chartering. (Roman Danyliw): (Asking the WG) Who would be implementing? -- 1x yes; 1x maybe -- Daniel van Geest: We will be implementing it. -- Max: We might implement this. Combine with something else. Not right now. It is going to take a while. Q: (Eric Rescorla): Does it need to go anywhere? A: (Russ Housley): Need parameters description somewhere Q: (Eric Rescorla): What does LAMP think? A: (Daniel Migault): Curdle could adopt if an issue for LAMPS NEXT STEP: re-charter LAMPS WG to accept this draft (2.3) General Security Considerations for Crypto Assets Custodians ------------------------------------------------------------------ draft: draft-vcgtf-crypto-assets-security-considerations-02 presenter: Hirotaka Nakajima slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-secdispatch-general-security-considerations-for-crypto-assets-custodians-draft-vcgtf-crypto-assets-security-considerations-02-01 Hirotaka Nakajima presented on the security considerations for a crypto assets custodian. Nakajima noted that he wasn't sure if it was IETF work -- Is IETF the right place? Where in IETF? If not, where else? Q: (Kathleen Moriarty): Are you talking about creating a common standard broker? A: (Hirotaka Nakajima): No. We are just defining what kind of features/functions could be required. A: (Roman Danyliw): This is an Informational document on operational practices. Q: (Laurence Lundblade): Are you after practice on online server and service? or a end-user device that they might be using to access a server? Comment: (Stanisav): ISO technical committee 307 study group 7 more or less relevant work is going on. Comment: (Paul): Lot of protocols are designed outside the IETF. This is not the right place. Initiative is good. We don't know these protocols. Comment: (Richard): there is probably some work to be done. Where is the boundary between technical and policy. May require more document revisions. IETF as a community is not a fixed thing. It might be good to have a BoF to ensure we have right community involved. Comment: (Kathleen Moriarty): We should not shy away from this work. Blockchain is re-creating our protocols and are not doing a great job. Us having collaboration is a smart thing to do. Comment: (Paul): I think there is value. But IETF is not the right place. If DINRG comes up with a protocol. Difficult to have something very specific. Its the same as voting machine people come and say that we want to have a document on voting machine security. (Roman Danyliw): Feedback of the WG appears to grow a community of interest. Perhaps a BOF? A: (Richard): Somewhere in between ops and sec area. A: (Eric Rescorla): If you need a mailing list, we can create one for you. NEXT STEPS -- build a community of interest around this work (2.4) Nimble out-of-band authentication for EAP (EAP-NOOB) ---------------------------------------------------------- draft: draft-aura-eap-noob-04 presenter: Tuomas Aura slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-secdispatch-nimble-out-of-band-authentication-for-eap-eap-noob-draft-aura-eap-noob-04-01 Tuomas Aura presented on an EAP extension, EAP-NOOB to as a means to primarily connect IoT devices. This approach is different than previous EAP methods. It creates a persistent association between peer and server. Future connections do not require the oob step. Q: (Eric Rescorla): What happens if I take the identifier from another device and display it on my screen. A: (Tuomas Aura): User does need physical control of device. A: (Eric Rescorla): Consider a scenario where Devices are both in imprinting mode. User has remote control. User is getting instructions. User thinks it is configuring. Misconfiguring the honest device. User actually is not. A: (Ben Kaduk): Honest and dishonest device have remote controls in this scenario A: (Martin): Interesting. Thank you for input. We will look it in. (Roman Danyliw) What is the position of the EMU WG on this? A: (Joe Salowey): Maybe. Not explicitly in the charter. Comment: (Mohit Sethi): This is an EAP method that does not depend on other tech. It should be done in EMU -- said as the draft co-author. Lot of other half baked solutions that don't have implementation or formal models. We should not put this in the same basket. Comment: (Richard Barnes): Perhaps EMU is the right place. If this is done in Sec area then EMU seems the right place. Comment: (Daniel Migault): Assumption of QR code (OOB) is quite normal. Comment: (Abhijan): Something like this is needed for developing countries. Need to take care of device cost. NEXT STEP -- discuss with EMU WG; and bring draft to the "IoT Onboarding Mechanisms" side-meeting on 1800 this evening (2.5) Extended Security Considerations for the Automatic Certificate Management Environment (ESecACME) ------------------------------------------------------------------------------------------------------ draft: draft-fiebig-acme-esecacme-00 presenter: Tobias Fiebig slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-secdispatch-extended-security-considerations-for-the-automatic-certificate-management-environment-draft-fiebig-acme-esecacme-00-02 Tobias Fiebig presented on draft to that described additional security considerations for the Automatic Certificate Management Environment (ESecACME). This draft is intended to explicitly document operational practices. Comment: (Yoav Niv): This seems entirely ACME. It should go to us (ACME). Comment: (Richard Barnes): pply to other methods. If we are going to do this, the idea should be that you could read as a general web CA. There could be utility here. Looks like an AD sponsored draft. Comment: (Sean Turner): RFC3647 already describes how to write policies. Is this an update to these practices? A: (Richard Barnes): This would be a "Delicate patient to put on the operating table." A: (Tobias Fiebig): The need for this is moving quite fast. A: (Jonathan): A lot of people depend on RFC3647. We might need a new WG to revise it. Comment: (Eric Rescorla): I think Yoav said that ACME is right place. Comment: (Ben Kaduk): If this is a operational document, and if it was AD sponsored, then it would be the ops ADs? Comment: (Richard Barnes) 3 possible work avenues -- Updating certificate policy document (which would probably be a new group); AD sponsorship; ... A: (Sean Turner): Re-opening PKIX? It will bleed everywhere. Keep it LAMPS. Comment: (Eric Rescorla): One of us will take it or shop it to Warren (Kumari, OPS Area AD). Use Secdispatch list to refine. Perhaps chair could assist us. Focus on problem and less on solution. Fine to say that this is something. NEXT STEPS -- AD-sponsored (3) Summary =========== See above.