1) administrivia/wg reports (10 mins)
Reports provided in email can be found on the SAAG list.  The reports mentioned during the meeting (included below) were for working groups or BoFs that had not sent a summary to the list yet.
DANE --  very interested in email security impacts dane
OATH -- meets next; wrapping up charter, discussing new work
HTTPBIS -- will request security review; http2 mandates tls, discussion of ciphers and proxies ongoing
UTA -- likely to focus on email security as next steps; much interest in TLS overhead
SIDR -- controversy about cert validation
CFRG -- much of the session time was spent discussing ECC. Asked by TLS WG to recommend new curves; have a process, will take weeks. Also asked by W3C for WebCrypto to write doc about attacks on crypto, likely to take that on.
Mattheson; secure conferencing in cloud, will send to SAAG list.
IRTF open session -- good paper on BGP security
Others, see their minutes (most are posted)

2) Opportunistic Security - Viktor Dukhovni (via Farrell) (5 mins)
New draft, in LC ending August 5.
Crocker: paper good, but it's not a definition (similarly to perpass).  Same comment from gen-art review
Martin Thompson: amplified this concern (he was the reviewer); uncomfortable publishing as it stands, just needs editorial work
Wes: yes, needs more time. Viktor would probably take another author.
Michael Richardson: Good enough, it's a marketing term, ship it and don't get bogged down in per-protocol details.
Wendy Seltzer: perhaps its too long to be just a definition, too short to describe all places we want to use the term?
Chairs: Last call can be extended to address issues if needed. Send comments to list.


3) TLS WG asking for curvacious guidance - TLS chair (20 mins) Sean Turner
Moving ECC to standards track. Trying to figure out which curves?  Asked CFRG for advice since they got the people who created the curves to come here. Not deleting NIST curves, adding new ones. For signature and key exchange, at 256 and 512 bits; 192 optional. If CFRG comes back with a large set, TLS will punt decision to SAAG to decide since not appropriate for TLS to decide.
PHB: By saying TLS, need to also work for certificates and PKIX, would not like a "niche" curve for limited uses.
Stephen et al: CFRG understands this. Get them your input.
Tim Polk: NIST review completed; docs are available NIST website and link posted to saag; much constructive feedback to ingest. Will hold a call for comments on the NIST curves including not specifying curves just curve families and methods. Likely to have protocol impact.
Michael Richardson, et al: Pick fewer curves.
Rene Struik: embedded devices care more about consumption and less about efficiency (and common time?)
Hoffman: consider re-evaluating signature mechanisms such as Schnorr (fits into PKIX easily because it's just an OID); some of that is SAAG work
Stephen: where would we do this?
Hoffman: PKIX if it were alive.  So SAAG should find a home.
Steve Kent: note evaluation impact on crypto hardware certification programs.


4.1) Email security - Dave Crocker (20 mins)
Not a proposal to do work, rather to start a discussion
Seen a list of 100+ messaging, VOIP, etc., projects; seen list of 35+ just for email. Nobody doing IETF yet, but eventually some will. We should start discussions in anticipation.
Components: email envelope (hard to deliver if not in clear); headers; content (body and attachments)
Adding privacy and key management (discovery, etc.) to classic Internet mail architecture
A new object, more than a key, perhaps identity and other attributes, but no trust info (no CA chain) and therefore perhaps not an x509 cert.
Key management, revocation, etc.: similar to DNS.
Many projects use "always connected" model which is problematic, also multi-platform.
Selective disclosure of attachments to different recipients in one message. Likely to be seen as overkill by many IETF'ers
Can we limit what's in the clear?  Perhaps expose only some of envelope to have only FQDN's, not mailboxes

4.2) Email security - Phillip Hallam-Baker (20 mins)
http://prismproof.org/
Standards stalemate: S/mime in 5 billion clients and vendor support; PGP mindshare. Neither are widely used (2Bn/day, not 100K geeks/week).
Need new system to do both. Success criteria: no harder than current email; rotate keys weekly as a way to prevent stupidity and be frictionless
Integration with SMTP and distribution is common. Do this first.
Research areas: trust model and TA-resistant transport. Do this later.
Why not encrypt always: Sender doesn't know which key, format (s/mime, pgp), cipher suites, wrapped messages, if recipient can handle or wants it.
PRISM is a great marketing tool; QR codes (email with key info)


4.3) Discussion (20 mins)
Mike Jones. Look at WebFinger rfc7033 as a way to query for email keys.
Chris Newman. Mail UA doc for UTA, including key-pinning. Would appreciate input and applicability for MTA relay.
Steve Kent. Enterprise examining email for spam, malware, etc. And also scan outgoing email before signing to make sure it doesn't say anything embarrassing or illegal.
Doug Otis: *Not recorded in minutes or jabber.
Rescorla: web mail is dominant, not email clients and is different.
Crocker: it's not different.
Rescorla: yes, if you don't trust your provider.
Phill: I have a solution, yes it is a problem and violates E2E, don't let it mean we give up on E2E model directly.
?: LDAP key discovery, etc., in walled gardens/enterprise. Much prior art. Key discovery the biggest problem. We should focus on incremental approach.
Phill: I have running code that addresses my requirements.
Chris Newman: As an engineer this is interesting, as a company person, I am not interested. Because of encrypted spam.


5) IEEE 802 Privacy Work - Juan-Carlos Zuniga (10 mins)
New IEEE 802 Privacy WG. Includes Ethernet, wifi, Bluetooth.
After STRINT workshop realized IEEE doesn't know these issues. Had a tutorial this month for them; focus RFC 6973.
ExecComm created study group until Nov 2014 with extension until March 2015. Report at plenary in November.
Will soon issue call for contributions: link layer privacy issues, any proposal on how measure privacy, and how to improve privacy at the link layer
Will propose to an opt-in trial at IEEE and IETF meetings to address impact of MAC address randomization on IP issues.
Starting, don't want to drag on forever, contact j.c.zuniga@ieee.org to contribute.


6) open-mic (30 mins)
Paul Hoffman: Is this privacy for the person, or for the device?
Juan-Carlos: Person, for individual devices, not something to do on a switch, for example.
Bob Moskowitz: Big data (such as SSID queries at Stadiums). Working with Juan-Carlos, MAC address is closest tie to device (more then IP address). How does changing MAC mess up WiFi association, DHCP leases, etc.
Michael Richardson: Are we on a witch-hunt about MAC addresses? There might be stuff that would never be private, have perspective.
Juan-Carlos: Study group makes recommendations, not proposals which is in individual WG's
?: We need a threat model.
Kathleen: avoid loaded terms like "witch hunt" but drawing out topics is good.
Robert Moskowitz:
Phill-Hallam Baker: why need MAC and not go all-IP?
Yoav Nir: Thundernet(??) has a draft about PEM format, will be an individual submission. PKIX text assignments and encodings.