IETF66 Transport Layer Security (TLS) Working Group Tuesday 2006-07-11, 1520-1720 Chairs: Eric Rescorla and Pasi Eronen Scribes: Joe Salowey (live) and Pasi Eronen (based on MP3 recording) Recording: ietf66-ch2-tue-afnoon.mp3 Eric Rescorla: Agenda and document status ========================================= 0:11:10- (recording timestamp) Eric bashed the agenda and presented status of TLS-related documents. Pasi said IANA is working on fixing RFC 4492 assignments. Eric Rescorla: TLS 1.2 ====================== 0:13:47- (slide 7: How to negotiate new PRF) David McGrew asked if the PRF "API" matches the NIST key derivation function API. Eric replied that changing the API would be difficult, and some kind of "bridge" might be needed. Russ promised to look into the issue. (slide 8: verify_data) Uri and Eric discussed which option, using PRF directly or hashing the messages first, is better. Pasi commented that memory savings are not very big, since much of the data is kept around anyway. Gregorij commented that some future PRFs might not work fast in big inputs. It was decided to continue discussion on the mailing list. (slide 9: SHA-384) Uri and Bill Burr pointed out that NSA "Suite B" includes SHA-384, so it should be included. Nobody objected. (slide 10: Alerts) Pasi said there are two kinds of alerts: most alerts are just for debugging, but some of them change how implementations behave. Humm clearly supported leaving the field as it is. (slide 11: Version Numbers in Records) The solution should break the least number of servers; this needs more research. Pasi said most existing clients send the same version number in both fields; not exactly what the spec says. Yngve said that Opera 9 tries different combinations if the first handshake fails. Discussion will be continued on the list. Eric Rescorla: TLS Counter Mode =============================== 0:36:23- (slide 4: Counter Design) Russ asked if the counter is long enough. Eric said it is. (slide 5: Changes since -00) Pasi: We'll start WGLC soon. Andrea Doherty: OTP Methods for TLS =================================== 0:40:22- (slide 5: From OTP to PSK II) Stefan (?) asked what is hardening is; Andrea replied it injects more entropy to make brute force attacks harder. Eric asked how much entropy there is; Andrea replied the OTP is 6..8 digits. Uri asked how the extra iterations increase entropy; Pasi said "entropy" is not the right word. (slide 7: The OTP_Hardening extension) Eric said the field should be bigger than 16 bits; Andrea agreed. (slide 8: Proposed Use of PSK_Identity) Eric pointed out that server that supports both OTP and PSK has to distinguish them based on PSK identity, e.g. which backend database to use. Discussion about whether defining new ciphersuites would be better approach. (slide 10: Next steps) Comments and discussion: Putting information in PSK identity is potentially difficult, how do you know the structure is there? TLS extension is one possibility, defining new ciphersuite another. Charlie Kaufman asked if the information is sent encrypted? No, since this is before authentication, and the server does not necessarily have a certificate. Charlie asked if asking for second OTP is supported. Andrea replied it is, but not described well in the draft. Eric asked about the underlying entropy in the token? The secret in the token is about 128 bits, much larger than output. Pasi commented that typical OTP alone is 20 bits, and even with maximum hardening, 36 bits, much less than 40-bit export ciphersuites deprecated long time ago. Need DH or RSA. Andrea replied that RSA/DH is recommended in security considerations; Pasi said it should be not allowed at all. Pasi said new ciphersuites would fit TLS style of doing things better. Uri: I do not like hardening, wastes resources of legitimate users, does not add entropy. Does increase work, but not a good defensive mechanism since processors get faster. Layering is conceptually bad, defining new ciphersuites is better. And the algorithm to derive the actual key should be revisited as well. Eric asked what's the primary use case for this? Andrea: mobile device that can't support PKI, network bandwidth limitations, etc. Eric said there isn't enough entropy, 18-20 bits, to prevent brute force attack within the lifetime of the OTP, 30-60 seconds. Andrea said plain PSK could be removed, RSA with server authentication is better. Pasi pointed out that without RSA, we're not really authenticating the server identity, if same OTP token is used with multiple servers. Andrea replied that ephemeral nature of OTP helps, only real-time MitM to worry about. Uri said the some uses cases can't afford RSA operations, but can't see any way to make this secure without some public-key operations. Eric and Pasi concluded this is not ready to be taken as WG item, the concerns raised here need to be addresses. Many of the concerns don't apply to the RSA part. Uri Blumenthal: TLS-PSK with NULL Encryption ============================================ 1:13:30- Yaron Sheffer asked if a middlebox can determine if the traffic is unencrypted. Pasi said yes, since negotiation is in the clear. Eric said you can always distinguish ciphertext and plaintext by entropy measurements. Pasi said this could be a half page document. Someone asked wasn't this suggested years ago? Have to check the archives. Pasi and Joe promised to review the document when it appears. Yngve Pettersen: TLS Interoperability Experiences ================================================= 1:18:25- Yngve mentioned HTTP pipelining and digest authentication as other examples where he has encountered interop problems. Uri asked if the HTTP digest problems were on client or server side? Yngve replied that nobody has implemented server side entity protection right. Stefan Santesson said developers tend to look at syntax specifications first and implement then, and guess behavior without reading the detailed text. Examples help a lot since developers read them. Interop testing is helpful as well. Yngve said reference implementation might help during the spec development. Michael Tuexen asked if there are any TLS interop tests? Pasi replied that ECC folks are doing something, see mails on the list. Michael continued that in transport layer protocols, they've found interops very useful. Pasi said that it's important to get feedback from interops to IETF so the unclear parts get documented. In IPsec, interops were successful since they got implementations working together, but nobody wrote down how the implementors decided to interpret the specs. Joe continued that interops don't often test extensibility, only what's available today. Similar problems have been seen in EAP. Yngve said that the draft suggests testing forward and backward compatibility. Eric convinced Ben Laurie and Stefan Santesson to work with Yngve and provide information about interop problems they've seen. Humm supported making this a WG document. Some others volunteered to review the document. Michael Tuexen: DTLS/SCTP ========================= 1:35:16- Eric: Two ways to suck keys from TLS, either get more bytes from key expansion, or use PRF with some other seed. Both are layering violations of some kind. You need some kind of registry of salts, or extensions, to prevent conflicts. Pasi: This is minor change to implementations, but major change to TLS architecture. Currently TLS talks to transport layer below and application above, neither interface ships keys around..Session keys are internal to TLS. Sam Hartman: Not quite true, EAP-TLS passes keys to a very funny transport layer. IPFIX would have been easier if something like this was already done. I think this is great stuff, and would love to see more usable security solutions like this. Joe and Sam said SASL talked about having access to TLS keys, but this was probably a misunderstanding. Joe asked if you're using DTLS just to exchange the key, why not just TLS? Eric replied it's because of parallel streams, encryption is still done by DTLS, authentication by both DTLS and SCTP layers. Someone asked whether SCTP authentication protects the header; Michael said it protects everything after the authentication chunk, which includes things like acknowledgments. Thomas Phelan said DTLS over DCCP is very simple document, is there something missing there? Eric said probably no, the complexity here is from securing partial reliability. Discussion will be continued on TLS mailing list. 1:48:20 (end of meeting)