Note Well *** Working group reports ACE: (Hannes) met monday. lots of different proposals floating around about how to carry different documents around. Many researchers providing input. No much progress on charter items but lots of ideas. I2NSF: (?) Met Thursday. Lots of contribs on data and info models. Make sure they are aligned, lots of good results. OAUTH: (Hannes) Final session is tomorrow. In first session discussed wrapping up working group documents. Documented attacks agains JWD. OpenPGP: (Barry) Remarkable success in getting anything done. It’s been difficult, and we’ve asked EKR to close the working group. Sad that we could not get it done. (DKG) There is continuing work to get that done. If they start submitting drafts, we may revisit it. *** TOKBIND (Lief): Playing around with some documents. Diameter E2E Security: Still looking for a solution for e2e in DIME here. RFC7966 documents the e2e requirements. We have reused a previous draft but there has been no progress. Two new AVPs are defined for protecting other AVPs Are thinking of using CBOR/COSE or other alternatives. Hop-to-hop provided by TLS but no e2e yet. Jean Mahoney: Please help! Been pushed off and we can’t do this by ourselves PHB: I have to generate something similar for mesh work. It’s written up but not separately but not pulled out. Willing to help. *** Related working groups: DMARC: (Barry) Met this morning. Main thing that’s being discussed is whether or not to publish it (ARC spec) as experimental. Crocker pointed out we don’t know if this will work. In our queue to move DMARC to standards track… unsure. NTP: current draft is going to to to WGLC soon, security group was responsive. DPRIVE: bunch of discsussion of DKG’s proposal to do demux over DNS on HTTP. PERC: getting around some of the issues it had with double context encryption for RTP. Could benefit from folks when a new draft is out in a couple weeks. If you like crypto in real-time protocols. RADext: going to close soon. Work on one more draft. UTA: meeting later today. We can sort of start to see the light at the end of the tunnel. Got the core documents that we were chartered to do in RFCs. If SAAG has other TLS application needs, let us know. CURDLE for DKIM: three documents almost done. Deprecating RC4 and SHA1 for ED256. PrivSec: traffic analysis draft. IRTF open: checkoway talk on DUAL-EC-DRBG. TEEP: tutorial on Sunday. Describe how it works, good attendance. Met Wed, to discuss charter. FUD: firmware updates for IoT devices. had side meeting today. two new documents there. Kathleen: we’re hoping to charter these last two soon. W3C (Sam Weiler): WebAuthn making good progress. Trying to get more eyes doing privacy and security reviews on specs. Please get in touch with me if you want to keep our WGs from doing stupid things. *** Post-Quantum (Kenny Patterson) Lifetime of SHA1 Trade-off between SHA1 and SHA2 started in Apr 2016 Progress in Quantum Computing The coming cryptapocalypse RLB: on the ECC point (that ECC will be broken earlier), is there a detailed analysis? A: Look for the name Tim Spiller. Paul Hoffman: paper a few months ago said that ECC is probably stronger for the same strengths. Ways forward - Post-Quantum Crypto But what about Quantum Cryptography? (Kenny rains on our parade) Punch line: we shouldn’t be too worried but we need to think about it. RLB: What can IETF do? KP: comment on NIST process in terms of evaluation and the PQC process. Paul Hoffman: current estimates for key sizes are going to be an order of mag larger… so like 50k-bit key sizes. If you have a protocol like UDP where everything fits in one packet, you’re going to have a bad time. Paul has a draft (c2pq) at CFRG that basically asks what we should do here at IETF/CFRG. We are going to want to know when we should start working on this stuff. PHB: 1) do have a degree in nuclear physics, QKD is probably not going to work given the engineering params. We do have Lamport signatures, and might need to back them in now. 2) CAs started moving to SHA-2 in 2008. The rest of the infrastructure wouldn’t accept them until much later. As a CA, I can’t issue them if they don’t work. Stephen Farrell: Comment: IETF could look at data items that might be sensitive in the future and then engineer to protect them. PK: not just the identifiers, but plaintext. SF: had a nice timeline that said, sit back and relax for 7 years. What’s the IPR situation look like? PK: this is a good question. SHA-3 was a declare and royalty-free license. Will have to look. Nick Sullivan: There are PQC schemes that can trade key sizes and computation to be more performant. PK: Comment about isogenies was that it’s so new. Tobias G: with timelines I feel like I’m in a quantum state… we may only find out when the quantum state has collapsed. Protocols we design have lifetimes of 10 years +. Leads us to crypto-agility+ so that we can update them without breaking things in 5-10 times. Need to consider now. *** Pretty Easy Privacy (Volker Birk) draft-birk-pep-00 from mic: (once it's time for questions): has the pep foundation ever taken a look at the work in UTA (WG) with regard to email security. reporting and UI/security improvements? AFAIK pep is just implementing a kind of overlay for popular clients based on either smime or gpg/pgpUTA meets later on, please join. Paul Wouters: not sure what you are suggesting. A new area in IETF, an effort. VB: there’s no central infrastructure, we don’t manage identities. Mapping identifiers into your own management of identities. MT: read your draft, looked at your website. Neither of those things helped me understand what you are trying to do. Didn’t see an architecture or things that connect principles to your code. This is a massive project. There is a very big difference between implementing code and shipping code where you get interop. PHB: I’ve been following this and I like it. ATM, there are a lot of useable secure messaging systems around. But they’re all single silo models. In order to talk to someone using Signal, I’ve got to get the Signal app. They’re all being sold as ways around government providers. For anything to be secure, you’ll need documented standards or they can just coerce through the single point of failure of the sw. *** Standardize Application-supported list of certificate limitation (Dimitri Belyavskiy) MT: is there a draft? I don’t know what this is. I certainly haven’t read this. You are describing something that has significant overlap with existing things. Why would this be superior? DB: The CRL can be issues by the application. RB: there are application vendors doing this today. Google Chrome does CRLSets and Mozilla does OneCRL for Firefox. What’s the value in standardizing this and having so much more functionality. DB: want to provide a standard syntax. DKG: Check out p11-glue. There is existing work that does this. Rich Salz: OpenSSL hat on. It would be great to have something not just in browsers to do some of this stuff. MT: as someone involved in one of the projects that has some of these things, we’d be willing to participate. RLB: I can see there could be value to this. A soft prereq is going to be some notion of who is trusted to distribute this information. in Vendor/Application space this is clear. Not so true for OpenSSL or Debian. EKR: (no AD hat) there are two problems to solve: 1) the policy problem of which anchors you trust and intermediaries you trust.; 2) distribution is hard and compression is necessary. DB: expect trust anchor being distributed with the application. *** Open mic Stephen Farrell: there was a bit of a fuss in TLS session. TLS would need to re-charter to do the draft-green work. Wondering what you guys think? KM: nothing has been adopted, still discussion, remains to be seen what will happen. Maybe there is an opp. for something data-center specific. SF: if they adopt something like this, do you consider that within their current charter. KM: would need to re-read the charter. We’ll see what the WG ulitmately decide. EKR: speaking not as AD, I don’t believe that draft-green would be within the charter. Yaron: there was a Quantum Random Oracle mentioned in CFRG. Wanted to ask your personal opinion as to whether these models exist, are reliable, and are something that NIST can base their evaluation on. KP: yes, yes, and yes. Still getting around the QRO model.