SAAG 100 https://datatracker.ietf.org/meeting/100/materials/agenda-100-saag/ Open Mic: Yoav Nir: informal discusison tonight re: short-term certificates Jim Fenton: security considerations in recent drafts aren't what I'd like to see. Too much normative content there. Kathleen: there's no strict guidance on how we structure security considerations. Some experiments. If you want to give feedback for a revision of 3552, input welcome. SecDispatch: Nancy: Get well Russ! a. OSCCA Extensions For OpenPGP, Ron Tse (remote) https://datatracker.ietf.org/meeting/100/materials/slides-100-saag-oscca-extensions-for-open-pgp-ronald-tse-et-al/ draft-openpgp-oscca-02 Requesting: AD sponsorship, 3 codepoints in IANA PGP registry; feedback. Tim: Those codepoints would have to be assigned with IETF review. DKG: why are you proposing this now? rather than when there was a WG? Ron: I understood OpenPGP would only do revision Barry Lieba told me that. Sean Turner: IETF review. or update the registry to allow other registration types. Stephen Farrell: adding algorithms would be a mistake. Richard Barnes: clarifiying, you're just asking for a codepoint? Ron: Yes. RLB: then we should fix the registry assignment process Sean Leonard: What's the implementation status? Ron: for OpenPGP to work with these algorithms, need the codepoint. SM2 is already used in cert standards within China Sean L: I don't see it as harmful. more cryptographic diversity is ok. DKG: Do you have OpenPGP implementations? Ron: the algorithms are available if implementers want to use them. github open source project using experimental codepoints. DKG: for elliptic curves, we use OIDs Nancy: couple of paths; 1. do nothing here 2. find an AD to sponsor 3. go through IANA registry. Tim: implicit in AD review is CFRG EKR: As an AD, I'm not going to sponsor a codepoint. Happy to sponsor changing the registrry policy. Tim: should we pursue a change to IANA policy for OpenPGP? @@: could go to CURDLE Tim: 1. do nothing; 2. Revise IANA policy for OpenPGP; 3. go to CURDLE after CFRG review Yoav: No, CURDLE's algorithms are fixed. Tim: would require CURDLE charter change. DKG: registries are one octet; relatively small registry. Hums: 1. (few) 2. moderate 3. moderate+ RLB: fix the registry and go to CURDLE. Not mutually exclusive. Tim: suggest going to CFRG, then to CURDLE. b. TLS Server Identity Pinning with Tickets, Daniel Migault https://datatracker.ietf.org/meeting/100/materials/slides-100-saag-tls-server-identity-pinning-sheffer-migault/ draft-sheffer-tls-pinning-ticket-05 Paul Wouters: isn't this TLS resumption? Daniel: No DKG: This reminds me of TACK Paul: why is this different from HPKP, TACK, etc. Daniel: it's a second factor not a side channel; no impact when you change your key. Tim: decision: is this work something we shoudl be pursuing in IETF? Ben: same work presented at IETF 97? Daniel: yes. DKG: what should the client do if the server doesn't produce new pinning proof? Daniel: hard fail DKG: a difficulty with PKP was no guidance on key rotation schedules. Do you have that? Daniel: we have some Sean Turner: This WG shoudln't become TLS part 2. RLB: we shouldn't do anything. HPKP is being rolled back on the web; this isn't right for IETF. Tim: spec review would get you a codepoint. Probably not interest in a WG. Suggest independent submission. Stephen Farrell: we might suggest this ia bad idea. We should have a way to say No EKR: don't do it here. and this is how you get a codepoint submission. Tim: Hum if you agree we should not pursue it. Louder than "should pursue" c. Randomness Improvements for Security Protocols, Nick Sullivan https://datatracker.ietf.org/meeting/100/materials/slides-100-saag-randomness-improvements-for-security-protocols-nick-sullivan-et-al/ draft-sullivan-randomness-improvements-00 Stephen Farrell: Valuable. Ideally, update 4086, at least be aware of it. @: Nick: this should work with deterministic or non-deterministic signatures. Mix with randomness EKR: ECDSA requires random K. Nick: only issue with predictable K is if you do multiple sigs, so do only one sig per long-term K Leif: have you tested with Linux system to see how much entropy you get? Nick statistically, iif system RNG is random, this will be as well Rich Salz: Give it to CFRG and have them publish it. Tim: CFRG might be the right path. Did you consider that? Nick: possibly RLB: higher up the stack than CFRG usually deals with. You could AD sponsor or spin up a focused WG for one document. Tim: options. 1. send to CFRG; 2. spin up a short-term WG; 3. AD sponsor EKR: do you think this is suitable for AD sponsorship? Tim: CFRG? hum. Focused WG? (silence) Consider AD sponsorship? weaker hum. Tim: Great, go to CFRG. d. OCSP over DNS, Max Pala https://datatracker.ietf.org/meeting/100/materials/slides-100-saag-ocsp-over-dns-max-pala/ draft-pala-odin-03 MT: there's a better caching mechanism. Why not use OCSP stapling. Max: you can. MT: it doesn't reduce the costs of signing, it creates an externality in the DNS. TimW: you can request a DNS RR type. DNSOP will give you the advice to use text records. RLB: DNSSEC... Bjorn: OCSP request payload needs to carry more than the serial number Sean Leonard: support Matt Miller: you're moving caching from CDN to resolvers. Tim: ought we to pursue this? (weak hum) Not: stronger hum. e. EAP usage in 5G, Jari Arkko https://datatracker.ietf.org/meeting/100/materials/slides-100-saag-eap-usage-in-5g-jari-arkko/ draft-arkko-eap-rfc5448bis-00 draft-arkko-eap-aka-pfs-00 jari: this is wrt EAP-AKA’ (RFC 5448) (see slides) Jari would like a place for this work in the IETF km: there's issues with eqp@ mailing list -- also there seems to be renewed interest in this work ?: thinks work should occur ? of 3gpp: would like drafts to progress in ietf Minpeng of China Mobile: if we have more EAP methods the MNO has more options 1. do u think these drafts are impt enough that should be worked on in Sec area? loud hum for, none against