Transport Layer Security (TLS) Working Group Minutes Meeting : IETF69, Tuesday 24 July 2007 Location: Chicago, Palmer House Hilton, Adams room, 13:00-15:00 Chairs : Eric Rescorla & Pasi Eronen Minutes : Bob Morgan Version : 1 (2007-07-26) ============================================================== WG summary (by Eric & Pasi) TLS met in the first session on Tuesday Jul 24. Eric Rescorla gave a report on the current state of TLS 1.2. There are no really contentious issues here. The biggest issues are the precise rules for when alerts must be sent, and the formats for carrying signatures. The signature issue is small but detailed and important, so we'll take it to the list. Then there's a new section on implementation pitfalls and then we expect a fairly polished revision in fairly short order. Joe Salowey presented on TLS RSA-AES-GCM, which is AES-GCM for TLS. Nothing controversial here, but it became clear that some generic text on how to handle CTR mode needs to be moved to TLS 1.2 and EKR took the action item for that. Tim Polk gave a presentation about what he called making TLS more useful for applications. His theme was that applications wanted to [0]: 1. Contribute randomness to the TLS PRF (draft-rescorla-tls-opaque-prf-input) 2. Extract keying material out of the TLS handshake (draft-rescorla-tls-extractor) There was quite a bit of pushback on (1) but modest levels of agreement on (2). Pasi and I are discussing how to move forward on (2). Tim agreed to go back and see if he can produce a better rationale for (1). Larry Zhu presented the use cases for a GSS-API integration with TLS. This was very contentious. While this may turn out to be worthwhile there doesn't seem to be consensus to move forward at this time. We've talked to Larry a bit about what it would take to build such a consensus. [0] Note: the present author (Eric) is the author of both drafts. ============================================================== agenda: several presentations document status: -srp IESG eval 4346-bis updated 4366-bis new ecc-new-mac WG item rsa-aes-gcm WG item tls-interop expired TLS 1.2 status, ekr issue: TLS uses arbitrary DH groups what if server chooses unsafe group? solution: client should verify group correctness and modulus size reference needed on how to do this, please help objections? none issue: use DigestInfo with RSA signatures how is Parameters in AlgorithmIdentifier encoded? solution: MUST be NULL, MUST be accepted as empty issue: cert hash types generalized to signature hash types added a preference order issue: handling alerts used to be optional solution: error alerts sent before closure MUST be fatal alerts but alerts don't have to be sent paul h: don't understand the last bit about not sending alert ekr: to thwart some side-channel attacks paul h: but if this has no info in it? (discussion of fatal alerts) sam: may be useful in DTLS for signaling premature closure so, support proposed solution issue: signature hash agility 1 need a hash indicator, also needs to be indicated in cert solution: proposed new structure indicating digest in SignatureAlgorithm Pasi suggests digest_algorithm be an AlgorithmIdentifier allows carrying params, basically pack params into signature ekr thinks ... tim polk: have to crack it ekr takes item to write this one up RSA-AES-GCM TLS Joe Salowey working towards alignment with ecc-new-mac draft nonce text aligned some may need to move to TLS 1.2 need to add key exchange methods? DSA? ekr: guidance from ADs? dave mcgrew: if there's a nonce on the wire doesn't that have to be in 1.2? ekr: there is ... but not in doc yet ... tim p: is there something needed in core here? ekr: TLS has known how to handle stream and block ciphers but these are different, they're counter mode chose to handle like ipsec tim p: OK, does sound like needs to be in base spec nico: ekr: GCM has 96 bit per record nonce, only 64 on wire a human race condition, expected 1.2 to finish earlier so, OK to slightly destabilize 1.2 to add this? people seem OK with this dave m: specify split between TLS and cipher suite? ekr: dave's new draft makes clean separation, but TLS isn't that clean pasi: only half page of text, so we'll add to 1.2 DSA? tim p: NIST 186-3 isn't out yet, which would add DSA lengths ... so will follow up ... interest in anonymous DH? ekr: sure, anything someone would use should be in someone: maybe SRP will reduce interest jaltman: I care about anonymous DH nico: would be nice if cipher suites were more modular ie, don't have to have separate doc for each combo joe: we'll add DH RFC 4057 bis, Joe S 4507 has encoding error that affects interop with prior 4507bis corrects this, should be published pronto Tim: will go straight to IETF LC extending TLS to meet protocol developers' requirements, Tim Polk Tim would like WG to consider ... protocol devs turning to TLS for security provisioning, this is good paul h: and DTLS too TLS security services focus on TLS endpoints, not calling protocols apps don't contribute context to TLS KDF apps don't get to use results of TLS KDF, have to do another one channel bindings are a good thing ie use of TLS finished msgs binds key material need method for app/protocol to contribute to KDF ekr: what security properties does that provide? tim p: helps two ends agree on app/protocol-level context nico: has to do with resumption? everyone: no ekr: suppose client/server just add strings to messages, not PRF does that do the same thing? tim p: apps may want to have input into keying material ... using extractors draft ekr: shades of 800-56 ... more philosophical than technical pasi: ekr has draft on srtp and mixing dave m: is there an example app that wants to do this? tim p: some instances of confusion between client and server ... nico: I have an example ... sam: speaking as AD, NIST has to explain why it wants to do this as individual, if PRF is good, then mixing is harmless bernard: don't understand why tls needs to change ekr: two different things, taking out and putting in tom wu: ... nico: don't see how this helps sam: seems to be a lot of pushback on this proposal ... tim p: propose that opaque objects and extractors drafts be WG docs belt'n'suspenders approach sam: as indiv, very strongly if extractor is required to be used with an extension, will be little used, worked around ... ekr: app would have to define usage of its extension to do extraction ekr: NIST really needs to make a case for this TLS and GSS, Larry Zhu GSS and SASL variants for several protocols want to use TLS rather than SASL as framework ekr: proposing to stop using SASL in these protocols? SMTP etc jeff h: SASL and TLS are not congruent, have small intersection pasi: SASL has elements that are not in TLS ... non-standard protocols use TLS for security no SASL variants firewalls and NAT traversal RFC 4559 deficiencies only supports single-round-trip GSS mechs lack of channel bindings to TLS makes unsuitable for proxy scenarios no session-based reauthentication ekr: second bullet? if proxies are TLS endpoints how does this help? sam: 4559 requires both PKI and Kerb infras, since no channel bindings nico: can't have channel bindings in a half-round-trip first bullet should say "half-round-trip" sam: some protocols just want to use TLS, added SASL under pressure adds complexity nico: how about new protocol that says: do TLS, then SASL GS2 with CB? larry: inefficient ekr: is end-game to throw away SASL? others: yes leif: want "sktunnel" for non-standard protocols jeff h: is non-standard protocol IETF work? SASL is mostly protocol design pattern use of TLS is also pattern is proposal to provide more well-defined toolkit for designers? leif: still want solution for non-standard protocols ekr: if SASL still has to be used sometimes, this seems like only adding complexity sam: this would be very useful for non-IETF protocols ekr: is this TLS WG work? sam: mission of IETF is to make a better Internet charlie kaufman: dual-port problem? jeff h: didn't IESG say no dual ports for TLS? sam: not any more pasi: seems to be a diversity of opinions, what to do? tim p: certainly a desire to rely on TLS, but doesn't do everything ... (end)