Minutes IETF99: saag
Security Area Open Meeting
||Minutes IETF99: saag
*** 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
DPRIVE: bunch of discsussion of DKG’s proposal to do demux over DNS on
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
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
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
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
*** Pretty Easy Privacy (Volker Birk)
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
VB: there’s no central infrastructure, we don’t manage
identities. Mapping identifiers into your own management of
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
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
KM: nothing has been adopted, still discussion, remains to be seen
what will happen. Maybe there is an opp. for something data-center
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
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.