Minutes IETF100: saag
Security Area Open Meeting
||Minutes IETF100: saag
SAAG 100 https://datatracker.ietf.org/meeting/100/materials/agenda-100-saag/
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.
Nancy: Get well Russ!
a. OSCCA Extensions For OpenPGP, Ron Tse (remote)
Requesting: AD sponsorship, 3 codepoints in IANA PGP registry;
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
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
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
Paul Wouters: isn't this TLS resumption?
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?
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
c. Randomness Improvements for Security Protocols, Nick Sullivan
Stephen Farrell: Valuable. Ideally, update 4086, at least be aware of
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
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
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
loud hum for, none against