# SAAG@IETF 103 Time: Thursday 13:50-15:50 Chairs: Eric Rescorla (ekr) and Ben Kaduk ## WG Reports Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-saag-chair-slides-00 See the mailling list repo for reports: https://mailarchive.ietf.org/arch/browse/saag/ * NTP - has sent the NTP security draft to IESG and they would love a review. * DNSSD is meet at the same time, but the last part of their agenda is privacy-related. * UTA - has a proposal to drop old versions of TLS for applications. * DPRIVE - intention to have virtual interim for ADoT. Working on use cases. * SMART (a research group) - Planning meeting in Pagoda Tonight. First 40 get a drink. ## IoT Benchmarking Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-saag-iot-benchmarking-00 Sean Turner: It would be helpful to add what class of IoT device is with the scores; not sure if you can do that. Hannes: You have to provide those details (processor, ram, flash, etc.) when you submit a score, so you could create a script. Alex: Is the focus more on power or performance Hannes: both Alex: would expect that some would lean toward power. Hannes: Cheating is a thing so they're working on verifying the results. Alex: They are just two profiles - creates a muddled score. Hannes: Running on higher clock speed it runs faster, slower sometimes mean longer so more battery drain. Hannes: One thing that confuses people sometimes is whether the score indicates it how secure the device is. IT IS NOT THAT! ## Calls for Assistance ### International Civil Aviation Planning to use Internet to create an ARKO newtork for network. Need to authenticate ground-ground, ground-air, and air-air. Need trust model that does not rely on certificates issued by RKTO. Had two ideas - 1) bridge CA or 2) DNSSEC + TLSA. BenK: We can probably find some help for you. ## Open Mic ### Publish Nation State Profiles through ISE Paul W: Recently moved a bunch of Suite B RFCs to historic. But, we shouldn't really do any more Nation state RFCs. THey're going through the ISE. yoav: IETF publishes April Fool's RFCs, we may not like it, but we publish a bunch of different RFC's; including publishing brainpool which is a nation developed algorithm. Paul W: More specifically, I'm opposed to the IETF publishing RFC's which make recommendations of using specific algorithms for specific purposes; we want IETF recommendations, not nation/state recommendations. ekr: On what ground would the 5742 conflict review block publication for these profiles. Sean Turner: We could try publish an RFC that says doesn't publish those type of RFCs, but the RFC++ BOF outcome was that the IETF can't really tell the ISE what to do. It would be hard to get that draft published. Dmitry Belyavsky: Need a place to get a stable place to put code points. Kathleen: I agree with ekr + sean. And I don't think it would help to add additional process. Paul W: Not talking about defining ciphers - it's about recommendations of ciphers. Kathleen: What published RFCs are there where this is recommended? Mike: CSNA - outlines a set of algorithms RSA 3k, ecdsa 384, aes256 -- all algorithms that are alreay used and specificied when used in IETF protocols. Dan Harkins: It's already specified. It's not defining anything new; it's actually generally recommended algorithms/parameters Stephen F: We can't tell him what to do. THere was some utility in the earlier Suite B documents -- I'm not sure we need it anymore. We don't want to be in the business of national specific stuff. Wes Hardaker: Two issues 1) The instant you say you can't publish something we're doing censorship, 2) some people will need code points - we need to support that. There is confusion with RFC #s and whether they indicate IETF consensus. Two things we can do 1) we can publish an RFC that says don't do this or that, 2) we need to fix perception problem. Vasily Dolmatov: Wes stole my show. Real world decides which standardsa are implemented - and this is a good thing. I would like to give them to present some solution. BenK: NSA has multiple publication venues: ISE and their own. But that's really up to them and the publisher. Adrian (the ISE): Paul and I didn't synch up, but that was maybe a good thing. I'm not paid to do ISE work, thus not seeking more drafts to publish ;) I would prefer that everything that came to me could back to the IETF and get published as a WG document. For cipher suites, I know that there's a research group that could make a statement that this is "not known to be broken", and I would even prefer "known to be good". Code points are somewhere in the middle, if that registry says you can only get throug the IETF that's easy - if it's FCFS then it's already been applied. This one is a profile - if this is of benefit for the Internet as a whole or part of it - it should be published. Publishing supports vendors that sell there and an understanding of what a good profile is (i.e., it gives them a template). Can you tell me what to do? The exent to which I listen is based on your arguement. I factor in the reviews I get, and I do require external reviews before I publish anything. ### GET WELL CARD FOR BOB Rich: There's a card for Bob Moskowitz - sign the card please. ### Root KSK Signing Paul Hoffman: DNSSEC KSK was rolled - not much bustage. Looking for more input about how often to do it, as this affects (perceptions of) the security provided by DNSSEC. Tomorrow at 9 - on the side meeting schedule. ### I2NSF Yoav: we need help with a draft for configuring ipsec gateways using an SDN controller, and the YANG model for this draft is probably just straight from a linux header and has every algorithm ever. The list needs pruning; please help! Understanding IPSEC is a plus, but any crypto understanding will do, to get us to just things we want in 2018, not things we want in 1998. Thank you, Paul!