tls@conference.ietf.jabber.com - 2002/11/20

[10:58] %% leg has arrived.
[11:10] %% kmurchison has arrived.
[11:11] <leg> tls working group meeting is starting...
[11:12] <leg> agenda: agenda bashing, TLS v 1.1, SRP for TLS, ciphersuite registration, recent devs in RSA, sigcomp compression
[11:12] %% rjs3 has arrived.
[11:14] <leg> chair: document status overview
[11:15] <leg> chair: any questions on the documents?
[11:15] %% TonyHansen has arrived.
[11:16] <leg> eric r: tls 1.1
[11:16] <leg> er: TLS 1.1 goals
[11:16] %% awa has arrived.
[11:16] <leg> er: fix CBC predictable IV problem, clarify some points from TLS 1.0, change required algorithms to RSA
[11:17] <leg> er: CBC changes
[11:18] %% smb@research.att.com has arrived.
[11:18] <leg> er: generating the IV
[11:19] <leg> er: option 1: random IV (set as IV), option 2: random encrypted IV (encrypt as a dummy cipher block)
[11:20] <leg> er: a less safe option (for IV generation)
[11:21] <leg> er: instead of option 1 or 2, encrypt a known block
[11:22] <leg> er: decryption is easy, just discard the first message block
[11:22] <leg> er: Going forward on the document
[11:23] <leg> er: clean up version, add text about auth then encrypt versus encrypt then auth, get addresses for all contributors
[11:23] <leg> question: where is text about AtE vs EtA going?
[11:23] <leg> er: somewhere in document (security considerations)
[11:25] <leg> next up, tom wu with SRP & TLS
[11:25] <leg> tw: document draft-ietf-tls-srp-03 soon to be -04
[11:27] <leg> tw: 3 ciphersuites, one password auth only, password + server auth (RSA), password + server auth (DSS)
[11:27] %% jhutz has arrived.
[11:27] <leg> tw: next revision will incorporate SRP-6, http://srp.stanford.edu/srp6.ps
[11:28] <leg> tw: two improvements, thwarts two-for-one guessing attack, allows more flexibilty in message ordering
[11:29] <leg> tw: this will let things look more like TLS exchanges do now
[11:29] %% aamelnikov has arrived.
[11:29] <leg> tw: performance will be similiar to ADH and EDH
[11:29] <leg> tw: how to integrate with SRP and non-SRP on the same server?
[11:30] <leg> tw: add TLS alert that indicates missing username?
[11:31] <leg> er: how much analysis has SRP-6 seen outside stanford?
[11:32] <leg> tw: submitted to IEEE WG, open for all to look at
[11:32] <leg> tw: "minor changes" in protocol
[11:32] %% jis has arrived.
[11:33] <leg> er: what's your goal with this document?
[11:33] <leg> er: proposed standard, informational?
[11:33] <leg> tw: like proposed standard
[11:34] <leg> er: not first WG SRP is come up, is it encumbered, etc.
[11:34] <leg> jis: the issue is the patent status, lucent patent.
[11:35] <leg> tw: no, they haven't reviewed it relative to our patent
[11:36] <leg> jis: yes, but lucent hasn't given the go ahead for free use of EKE patent
[11:36] <leg> jis: informational now, maybe proposed standard when the IPR becomes clear
[11:37] <leg> tw: anything that can be done?
[11:38] <leg> jis: not really. patent issues
[11:39] <leg> ted t'so: jablon (spelling?) has patents that cover similiar stuff
[11:40] <leg> tw: jablon is being lucent-like about SRP
[11:40] <leg> ...everyone thinks it's a bummer...
[11:40] <leg> next item: ciphersuite registration. need to add an IANA considerations section.
[11:41] <leg> chair presenting "proposed ciphersuite publication criteria"
[11:42] %% awa has left.
[11:42] <leg> standards track: WG consensus, no IPR limitations, good description, good analysis
[11:43] <leg> informational: reasonable documentation, credible cipher, no "obvious" security problems, no endorsement from WG on security properties
[11:45] <leg> chair: questions or comments?
[11:45] <leg> rich craven: what does "no endorsement" mean?
[11:45] <leg> chair: it's an expectation
[11:46] <leg> ??: so does an RFC have to be published before a ciphersuite number is assigned?
[11:46] <leg> chair: upon publication
[11:47] <leg> er: if the informational meets criteria, will we always publish?
[11:47] %% TonyHansen has left.
[11:47] <leg> chair: this is the first cut.
[11:48] <leg> rough consensus that this is a reasonable approach
[11:49] <leg> new topic: recent devs in RSA
[11:49] <leg> ... technology setup ...
[11:50] <leg> russ housley: ANS X9.44 and IETF TLS
[11:50] <leg> rh: introduction (ANSI, NIST, et al)
[11:52] <leg> rh: reflecting and guiding. X9.44 reflects industry practice
[11:52] <leg> rh: X9.44 also guides toward new techniques
[11:53] <leg> rh: X9.44 focuses on key establishment
[11:54] <leg> rh: TLS Handshake: Crypto Recap
[11:54] <leg> rh: ciphertext = Encrypt(server public, premaster)
[11:54] <leg> rh: master = KDF(premaster, nonces); session = KDF(master, nonces); tag = MAC(master, handshake messages)
[11:55] <leg> rh: TLS handshake today: encrypt = PKCS #1 v1.5 Block Type 02, KDF = TLS PRF, MAC = TLS PRF
[11:55] <leg> rh: Security analysis
[11:57] <leg> rh: analysis has helped support X9F1 acceptance of TLS; SSLv3 somewhat weaker
[11:58] <leg> rh: X9.44-Recommend enhancements
[11:58] <leg> rh: Encrypt = Raw RSA (Premaster as long as RSA modulus)
[11:58] <leg> rh: KDF = IEEE P1363a KDF2
[11:58] <leg> rh: HMAC
[11:58] <leg> rh: err, MAC = HMAC (SHA-1)
[11:59] <leg> rh: Rationale for Enhancements
[11:59] <leg> rh: Raw RSA + KDF2 ~ Shoup's RSA-KEM, only relies on ordinary RSA assumption
[11:59] <leg> rh: KDF2, HMAC more standard, bigger hash sizes
[12:00] %% rjs3 has left.
[12:01] <leg> rh: Client Authentication (missed details)
[12:01] <leg> rh: Next Steps: consider X9.44 direction, hopefully feedback in both directions
[12:02] <leg> question: <unintelligable>
[12:03] <leg> rh: if i had an RSA key I could use it for both (Both what? beats me)
[12:03] <leg> rh: use keys only for one operation: key management keys or signing keys
[12:03] %% tbamonti has arrived.
[12:05] <leg> <more discussion on details>
[12:07] <leg> next up: Using SigComp in TLS, Carsten Bormann
[12:07] <leg> SigComp -- signaling compression
[12:08] <leg> compression desired: developed Universal Decompressor Virtual Machine
[12:09] <leg> UDVM code example
[12:09] <leg> from draft-price-rohc-sigcomp-user-guide-01
[12:10] <leg> UDVM code is small (smaller than a cert)
[12:11] <leg> removed the need for standardizing compressors; anybody can write a new UDVM code
[12:12] <leg> SigComp and TLS: sigcomp runs fine above TLS
[12:13] <leg> idea: allow use of SigComp in TLS, use TLS for parameter negotiation
[12:14] <leg> SigComp and TLS to do: define details of using SigComp in TLS
[12:14] <leg> bar BOF wanted
[12:15] <leg> question: any work done on the security of the downloaded code?
[12:15] <leg> cb: 1/2 the design time was spent on security, we believe it is secure but review is invited
[12:16] <leg> question: SIP was slow. how much time was taken with compression/decompression?
[12:16] <leg> cb: the slowness was the link speed; the decompression is basically free compared to that
[12:17] <leg> er: aren't all compressors about the same? the only issue is IPR?
[12:17] <leg> cb: there are application specific compressors.
[12:17] <jhutz> Is UDVM simplistic enough to prevent an attacker from sending a "decompressor" that uses up arbitrary numbers of cycles?
[12:18] <leg> er: if there are any free algorithms, why don't we just implement them? why do we need to get around it using UDVM?
[12:19] %% john loughney has arrived.
[12:19] <leg> cb: it is a good place to be pluggable.
[12:19] <leg> er: still doesn't understand when this would help.
[12:20] <leg> cb: gets around having to standardize any algorithms.
[12:21] <leg> ... back and forth ...
[12:22] <leg> question: this seems to give an advantage to non-open source implementations.
[12:22] <leg> question: when are the patent expiration dates on good algorithms?
[12:23] %% john loughney has left.
[12:23] <leg> it would be useful to deploy systems soon and enable them to decompress later.
[12:24] <leg> questioner is theorizing about a hypothetical patent
[12:24] <jhutz> Was my question already addressed, or does someone know the answer?
[12:25] <leg> i don't know the answer to your question, haven't read any of the drafts.
[12:25] <leg> presumably, your VM can just put a cycle limit that it's willing to do and maybe the spec can say implementations must support at least X cycles.
[12:26] <leg> chair: open documents
[12:29] <leg> scott a: TLS compression methods
[12:29] <leg> scott a: two methods, zlib, LZS, besides minor question about expansion
[12:30] <leg> scott a: there are some IPR issues
[12:30] <leg> IPR issues mostly with LZS, not zlib
[12:30] <leg> chair: on the standards track?
[12:30] <leg> scott a: yes.
[12:31] %% mrose has arrived.
[12:31] <leg> discussion on upgrading to TLS in HTTP/1.1
[12:33] <leg> moving to draft? can't because TLS is still at proposed.
[12:34] <leg> no one implements it, doesn't work with proxies. move to historic?
[12:34] %% jm has arrived.
[12:34] <leg> meeting done.
[12:37] %% leg has left.
[12:38] %% tbamonti has left.
[12:39] %% jm has left.
[12:40] %% smb@research.att.com has left.
[12:40] %% aamelnikov has left.
[12:43] %% jhutz has left.
[12:46] %% kmurchison has left.
[12:52] %% hartmans has arrived.
[12:57] %% mrose has left.
[13:12] %% hartmans has left.
[13:26] %% jis has left.
[13:26] %% jis has arrived.
[13:26] %% jis has left.
[17:33] %% leg has arrived.
[17:33] %% leg has left.