Transport Layer Security (TLS) Working Group Minutes Meeting : IETF68, Tuesday 20 March 2007 Location: Prague Hilton, room Karlin I, 09:00-11:30 Chairs : Eric Rescorla & Pasi Eronen Minutes : Paul Hoffman & Joe Salowey, edited by Pasi Eronen Version : 1 (2007-03-30) ============================================================== WG summary (by Pasi & Eric) Transport Layer Security (TLS) working group met on Tuesday morning. The main topic was TLS 1.2, which is progressing (although missing some milestones). We discussed how to best handle algorithm agility for signatures (in certificates and certain TLS messages), what to say about algorithm identifier parameters, and alert messages. Eric and Joe Salowey presented drafts that add AES-GCM cipher suites to TLS 1.2, one document containing RSA key exchange and the other "Suite B" compliant ECC suites. There was consensus to adopt both as WG documents (subject to confirmation on the list). There was also some desire to have clear rules when to adopt algorithm and/or profile documents as WG items, so that similar documents backed by other national governments would be treated fairly. The chairs promised to make a first proposal for rules. Yaron Sheffer gave a presentation on adding EAP authentication TLS. This is not consistent with current EAP applicability statement, and changing it needs more discussion with EAP community. There was some interest from e.g. SSL VPN community. GSS-API authentication for TLS was not presented, but it was observed that there are similarities to EAP work. WG seemed to have interest in this work, and discussion will continue on the list. Eric gave a presentation on using TLS to derive keys for other uses than TLS record layer (such as SRTP and SCTP). This seems desirable, but needs to consider other parts of security association than just the key. As few people had read the draft, this will continue as an individual draft for now. ============================================================== Eric Rescorla: Agenda and document status Not much since last IETF TLS PSK NULL was published authz withdrawn Eric Rescorla: TLS 1.2 20-50 issues, mostly editorial There is a tracker from Pasi Bunch of major changes, see slides Open issues: DigestInfo parameters Lots of weird history with PKCS #2.1 NULL parameter in encodings or omitted? Proposal: MUST be NULL but must accept NULL or no parameters Sam: If you ignore the option parameters can there be problems? Ekr: Don't think so. Tim: This has been confusing for other algorithms, field is optional, never heard of any attacks based on accepting both. Don't think there is a security risk. Ekr: we Will move forward. Open issues: Hash agility for signatures TLS 1.0 and 1.1 mixed MD5 and SHA1 in RSA Current draft allows client to specify allowable hashes Current requirements: SHA-1 with DSA, must use same alg as in your cert Proposal: Either side can sign with any hash offered by the peer Maybe offer the list in preference order DSA/ECDSA MUST be used with an acceptable variant of SHA defined by NIST Tim: ECDSA/DSA are not defined for other SHAs. Sam: Having things in preference order makes debugging easier. Pasi: For algorithm agility hash must be specified. Ekr: Not all implementations working in signature recovery mode. Russ: Not allowing truncated 384? Ekr: No unless NIST does Paul: waiting on NIST issue, NIST has changed its mind. If we say do it the way NIST does they may change. We should define it definitively in our documents. Tim: Things don't really change that often. We are blocked on FIPS 186-3. Notice should come out soon. Russ: public comment? Tim: yes so we are little ways away. No problem with duplicating in IETF Ekr: Wait a while and beat on Tim if it is not ready. Pasi: We want alg agility feature done so we don't have to revisit it. Ekr: This is a separate issue. Russ: can't accommodate hashes with different sizes? Ekr: unless NIST defines Russ: hash contest coming up Ekr: will post proposed fix on line, make signature part of ciphersuite - ie RSA-PKCS1, RSA-PSS Pasi: Doesn't complete solve problem, signature is not tied to ciphersuite Ekr: we will put it in the certificate request, problem is in the certificates. If you sign with PSS your certificate must be signed PSS Russ: it is just RSA encrypt in both, in both it is key alg RSA-ENC. Ekr: replicate ciphersuite for PSS Sam: problematic to replicate ciphersuites for certificate signing algorithms Ekr: Put this off for now so we don't have to do TLS 1.3 Ekr: Symmetry of request for is wrong, not going to do it. Open issues: Alert processing Nelson wants all alerts to be mandatory Agree which alerts must be fatal; these must be sent NIST proposal for new fatal alerts on certificates Ekr says some implementations always abort on any alert Tim: If you don't care don't evaluate them. If you process them if you care send a alert of fatal. Seems good for NIST. If you plan to abort the connection, send it Warn about older implementations tearing down Will add wording about SHOULD not tear down for non-fatal Eric Rescorla: draft-rescorla-tls-suiteb NSA profile for COTS security algorithms Adds some cipher suites to TLS-ECC Adds ECC+GCM Profile the specific curves for Suite B What to do with the document? Comments from Pasi -- will be incorporated Should this be a WG doc? What about specifying longer hashes for non-ECC cipher suites? Sam: What is the criteria for accepting documents from government requirements. Pasi: working group consensus Sam: probably not good enough, needs to be fair from objective viewer Ekr: Policy accepting profile versus algorithm. uncomfortable with accepting all national standards as WG items. Paul: In SMIME has this issues. GOST had insufficient spec. Look at the algorithms first. Profile is easy. Pasi: we had a quite low bar for accepting. When in working group we deal with working group consensus. Sam: adequate review from CFRG is a good possible criteria. Pasi: algorithms must be publicly available. Tim: These meet all these criteria. Jeff: all for having lots of algorithms available. However standards need not make every thing available. Simon (jabber): Patent concerns with ECC is it relevant? What about SHA-2? Pasi will come up with rules. Joe Salowey: draft-salowey-tls-rsa-aes-gcm-00 Basically similar to Suite B but has the suites for RSA and RSA-DHE Should probably be separate document from Suite B doc Wants to make it as similar to Suite B as possible Needs to fix up the counter/nonce construction No objections heard Yaron Sheffer: draft-nir-tee-pm Protocol-level auth for TLS EAP is heavily used for auth in many places, can be reused Draft is a protocol model, not a full protocol Has identity protection for the client Binds EAP material into TLS Finished message Finished sent by the server first Sam: Inconsistent with EAP applicability statement, need EAP community and security discussion of whether this is a good idea. Yaron: TLS used for full network connectivity, SSL VPNs Paul: Even though IETF has no standards for TLS tunneling. Basically, for secure network access, SSL VPNs are rapidly growing. Greg Liebowitz: NEA uses EAP. For network access control, and for groups for applications (anti-virus, etc) Sam: that is not a topic for this working group. Pasi: SSL VPNs are being used, but they are proprietary. No need to standardized. You could easily do EAP authentication. Sam: I would like to see capability where the TLS endpoint and EAP endpoint are different. Eric Rescorla: draft-rescorla-tls-extractor People are using TLS as a key management framework for other protocols DTLS-SRTP and EAP-TLS do this Purpose of draft: do it one way even if multiple things use Should this be signalled by TLS extension? Thoughts about IANA registries Debate about "IETF consensus" or "specification required" We don't want to encourage this without being careful Proposal allows multiple parties to the use the key without knowing about each other Question about experimental protocols and naming Discussion: Extending the TLS state machine for auth protocols GSS-API presentation didn't happen because presenter didn't come Similarities between GSS-API and EAP Discussion happening on the list of of how to do this Suggestion to obsolete RFC 2712 What about SASL? This kind of thing is going to get more common Many people thought it was a good idea to use GSSAPI as an auth under TLS Many people thought it was a good idea to use EAP as an auth under TLS ==============================================================