IEEE P1363 Meeting Minutes ========================== November 18 -- 20, Albuquerque, NM Sierra Vista room, 19th floor, Hyatt Regency Hotel November 18, 1997 Meeting started at 8:30 am. Attendees: Ian Blake *Lily Chen *Don Johnson (by phone) *Burt Kaliski, Chair *David Kravitz *Michael Markowitz, Treasurer *Roger Schlafly, Secretary *Jerry Solinas *Yiqun Lisa Yin, Editor *Robert Zuccherato Kaliski reviewed the meeting agenda and laid out the work plan for the meeting: -- first category: "finalize" the main body as a draft; agree on conformance; revise naming (if necessary) -- Second category: annex work - conformance - security considerations - key management - "others" -- Work plan for completion of the document Kaliski reviewed the status of the two PARs. Kaliski said that he'll make one more round of patent solicitations, based on the draft approved at this meeting, and prepare a summary of patent issues for the working group before the March meeting. Yin reviewed the changes to the draft since the last meeting. Definition section was added. A question about whether mathematical definitions should be included in that section or elsewhere. KDF and MGF sections completed. Do we still want KDF-HMAC? Kaliski said he had some reservations since the last meeting, because it's not clear how to prove that KDF-HMAC is secure (although no attacks are known). Since the other KDF, KDF-X9.42, is better established, perhaps we should not include KDF-HMAC now and instead work on something for the addendum. Kaliski suggests we consider removing it, and should discuss further with Johnson when he calls. Public keys are no longer considered part of the input to the schemes, but instead are obtained as a first step. Yin reviewed the approaches to key validation in DLKAS-DH1/ECKAS-DH1 and also the approach in DLSSA/ECSSA. We agreed to move the "encoding parameters" from the setup of the signature scheme to the signature generation and verification functions. We also agreed to remove the phrase "associated with the signer" in step 2 of signature verification. We may have security considerations for each of the schemes (to be discussed tomorrow), and the setup sections of the schemes could point to the corresponding security considerations. We will add a sentence to the setup sections saying that the parameters and so on may be the same for any number of operations, or may be changed at some frequency, may be shared among a number of users, etc. Security considerations can give the tradeoffs. A question on whether the polynomial-to-octet string conversion in Section 5.5.4 is still necessary (it was originally included to support ASN.1 syntax, which will now be in an annex). Other notes: ECSVDP-DH has optional cofactor multiplication. DLSVDP-DH does not. This was agreed at the August meeting. SHA-1 and RIPEMD versions of encoding techniques have been combined, e.g., into ETSA-hash, ETE-OAEP-hash. The note about the Girault-Misarksy result in Section 11.1.2.2 is not relevant to the techniques currently in the document so will be removed. Kravitz pointed out, commenting on the definitions section, that authentication is often achieved without digital signatures (e.g., via an interactive protocol). Also a comment on forward secrecy: "a long-term private key" should be reworded to say "any long-term private key." Need to include "with respect to one party" in definition. An exercise we need to do is to review the definitions in light of how terms are used in the standard. We dove into the conformance issue after a break. Johnson called in to join the discussion at this point. Kaliski started by reviewing the issue of conforming with primitives, in particular, how a primitive should operate on "invalid" inputs. At one extreme, the primitive could check nothing about the input ("doesn't matter"), and at the other extreme, the primitive could reject any illegal input ("reject"). Kaliski said that we should agree on something in between the two extremes, and we should balance between robustness and simplicity. In order to handle both valid and invalid inputs, Kaliski suggested that we define primitives over a more general set of inputs. For example, a signature primitive would work on public keys rather than "valid" public keys. Johnson said that we should specify key and parameter validation in the document. Kaliski pointed out there are currently no key and parameter validation as primitives, but we put it as a 'required' step in all the schemes, as Yin presented earlier. The question is what happens to the primitive if such validation steps fail in the scheme. Johnson said that a primitive should be "well-defined" on ALL inputs. Kaliski said that we should require primitives to be "well-behaved" -- i.e., compute according to the correct formula on valid inputs and behave in a reasonable way on invalid inputs. Johnson said that a primitive implementor should that what an implementation does on invalid inputs or state that "it is unpredictable on invalid inputs." In other words, it should specify the behavior clearly. We resumed the meeting at 1:00pm. After some discussion, it seemed that we were back to the early proposal of "doesn't matter." Kaliski then pointed out that it would still be nice to have some robustness guildlines. In sum, -- the primitives stay as they are (i.e., work correctly on valid inputs) -- conformance is only on valid inputs for primitives -- write implementation consideration on robustness in the annex (e.g., general guildlines on how to behave on invalid inputs). We might want to isolate a few things that are primitive-specific. We moved on the issue of conformance with schemes. Kravitz pointed out it seemed to him that the first time one executes a scheme may be different from the second time one executes it. For example, one may not need to fetch the public key, but just get it from its local database. Yin suggested that adding this to Note 3 in Section 8.1.3. Kaliski summarized the primitive conformance issue. Johnson argued against having time-consuming checks in a primitive. We discussed different kinds of bad behavior. What if a bad key causes an infinite loop? What if it causes future bad outputs? Kravitz says the first is ok, but not the second. Some other questions were: Should an implementation accept all valid inputs in the allowed range? Can a dead chip claim conformance? Solinas argued that we are getting into quality control with some of these questions. Kravitz said that if a primitive accepts valid input, it should give the right answer even if previous bad inputs put the device in a funny state. We discovered that we meant different things by "valid input". Kaliski drew a Venn diagram, with big circles for the "mathematically valid inputs" and the "accepted inputs". The region of conformance is a subset of the intersection. Schlafly proposed a definition of "valid" input to be numbers satisfying the definitions in the draft. Also defined "accepted" as taken by the device. Kaliski said the discussion was repetitious, and we should postpone until tomorrow when we could focus on specific proposals. Kaliski changed the subject to "naming", and proposed some new name for the various acronyms we have. The current names are: Primitives Schemes DLSVDP-DH DLKAS-DH1 -MQV -DH2 DLSP-NR -MQV -DSA DLSSA DLVP-NR -DSA RSAEP IFES RSADP IFSSA RSASP1 IFSSR RSASP2 RSAVP1 RSAVP2 RWSP RWVP Solinas suggested that for more consistency we follow the pattern: family - function - S/P - inventors. Eg, IFEP-RSA. Markowitz raised the issue of RSADSI's defense of its trademark "RSA." According to a decade-old consent agreement, Markowitz and Schlafly are prohibited from using the acronym. This makes it impossible for them, and they say, dangerous for others, to claim conformance in advertising literature with a primitive or scheme whose name contains that acronym. Kaliski agreed to contact RSADSI, as P1363 chair, seeking permission for users of the standard to identify techniques according to the names specified in the standard. He also noted that a consent decree is different than a trademark violation. The other names are: Encoding techniques ETSA-hash -X9.31-hash ETSR-ISO-9796 ETE-OAEP-hash Key derivation KDF-X9.42 KDF-HMAC Auxiliary functions SHA-1 RIPEMD-160 MGF-hash We discussed ordering of letters, "technique" v. "method". We changed "T" to "M" since P1363a uses "additional techniques" Kravitz told us that "signature with appendix" means that the message is the appendix. Some of us thought the signature was the appendix to the message. We decided to continue using the term because it is commonly used. Motion 1. (Yin, Kravitz) Change all the IF primitives and schemes to start with "IF" and have a descriptor after a hyphen, change "T" to "M" in encoding techniques, and leave other names as is. Passed, 7-0-1. Yin outlined the annex. Currently, it is: Rationale Mathematical background DL background EC background Test vectors Number-theoretic algorithms Crypto random number generation Conformance Security Notes ASN.1 Syntax References The suggested new order is: A. Number theoretic background B. Conformance (Implementation notes?) C. Rationale D. Test vectors E. Security notes Random number generation Key management F. ASN.1 syntax We decided to merge the sections on Mathematical background and EC background into the section on Number-theoretic algorithms since there are currently some redundant mateirals in these sections. We also decided to merge the sections on DL background and RNG into Security notes. Markowitz discussed ASN.1 definitions. Kaliski said we should use our own OIDs, as we have some differences with ANSI. Kaliski suggested: E. Security considerations - random number generation - key management - key size We adjourned at 5pm. November 19, 1997 Present: Ian Blake, Jerry Solinas, David Kravitz, Rob Zuccherato, Lily Chen, Mike Markowitz, Lisa Yin, Burt Kaliski, Roger Schlafly, Don Johnson (by phone) We began at 8:30. We reviewed the minutes from the August meeting. The version Kaliski distributed was the one Schlafly posted to the stds-p1363 list in September. Yin had made some editorial changes since then which were included in the version posted on the Web. Kaliski did not distribute these but mentioned them during the review. Motion 2. (Yin, Markowitz). Accept August minutes as revised on Web with additional editorial changes as discussed at meeting. Passed, 5-0-2. Kaliski reviewed the plans for Wednesday and Thursday: Wednesday: Approval of minutes (done) Conformance presentations & decision Security considerations I: scheme review Thursday: Security considerations II: outline & plan Test vectors New contributions (Biely encoding method) Approval of draft Review of plans Meeting schedule Two issues will be discussed at some point: KDF-HMAC and MQV alignment with X9.63. Markowitz collected the meeting fee, which was $60, all for the IEEE international participation fee since Certco covered the meeting expenses. Yin & Solinas presented a handout on conformance. Yin defined "primitive", "implementation", "valid input", and "operational input". A supported input was then a subset of { valid inputs } and { operational inputs }. On a non-supported input, an implementation may - output an error condition - perform same sequence of steps - fail in some manner, e.g., infinite loop, crash. Operation on a non-supported input should not interfere with the later operation on a supported input. Johnson & Schlafly criticized primitive conformance under this definition. Schlafly argued that just about any implementation would conform, no matter how buggy. Kaliski suggested defining "operational mode", and changing "should" to "shall", as long it is in operational mode. Schlafly proposed that we tighten the conformance requirements by saying that the set of supported inputs is the intersection of the valid inputs and the operational inputs, and that an implementation must not crash on operational inputs. Kaliski proposed a "compromise" in which no one is allowed to claim conformance to a primitive, but we define what it means for an implementation to support a primitive over some set of inputs. Schlafly moved that we require conforming implementations of primitives to produce correct answers on operational inputs which are also valid inputs. It died for lack of a second. Everyone else thought it was perfectly acceptable for a conforming implementation to accept a valid input, and output the private key or any other wrong answer. Schlafly argued that under Yin's proposal a conforming implementation could define the supported inputs to be just the ones producible by a black box, or just the ones which work, or just 1 number. An implementation could also go into another mode without notice to user in which it gives wrong answers on supported inputs. As a result, the user has no guarantee of anything. (The group also pointed out that no one would likely buy such an implementation; in practice, claims of conformance would have to be backed up with more robust guarantees of behavior on non-supported inputs.) Kaliski said he wants to allow implementation to claim conformance even if the supported inputs are defined by some condition which is completely mysterious to the user. For example might use a a classified set of inputs with, e.g., secret DH parameters. Solinas said we were not telling implementors what to do, and we are just giving them guidance on what to tell each other. Markowitz said that all of our discussions have been such that we are careful to allow just about anything. Johnson raised several objections. He said we don't want a stamp of approval on primitives meeting such weak requirements. He just wanted scheme conformance, and pointed out that a scheme implementation might rather not include a component that conforms to the primitives. That is, it is possible to conform to a scheme without conforming to a primitive, and, therefore, primitives are in some sense optional. Motion 3. (Solinas, Markowitz) Adopt Yin's proposals, as amended below. Passed, 5-2-2. The edited version of Yin's handout is: Term Definition Example ---- ---------- ------- Primitive A mathematically defined IFEP-RSA sequence of steps Implementation A software or hardware module RSA library routine, RSA chip Valid input An input of the form defined (n,e),f where (n,e) is an by a primitive RSA public key, f is an integer in [0,n-1] Operational mode A condition in which an library is loaded, chip is implementation accepts input powered, etc. and during which the implementation claims conformance for certain valid inputs Operational input An input accepted in the n,e,f at most 2048 bits long operational mode Supported input An input accepted in the A valid input where n is at operational mode for which most 1024 bits long the implementation claims conformance with the primitive The implementation shall operate in accordance with the primitive on all supported inputs. The operation of a primitive on operational inputs that are not supported inputs ("non-supported inputs") is implementation- dependent. For instance, on a non-supported input, the implementation may: * output an error condition; or * perform the same sequence of steps as for a supported input and output the result; or * fail in some manner, for instance by entering an infinite loop, or by "crashing." The operation of an implementation on a non-supported input shall not interfere with the later operation of the implementation on a supported input. The set of supported inputs and the operational mode shall be clearly specified in documentation associated with the implementation. In the interests of interoperability, the set of supported inputs should be explicitly specified and sufficiently broad to support a range of possible applications. --- end of Yin handout --- After lunch, Johnson called in again. Kaliski began a systematic discussion of the "Security Considerations" annex. Topics are: RN gen key management key size specific considerations Kaliski addressed schemes. We had a general discussion in which we listed an assortment of security considerations. Some of them are listed below. DLKAS-DH1 (also EC) in 8.1.1 Setup - DL params - secret value derivation primitive (DH) - cofactor or not - key derivation - properties or attributes of keys (ephemeral? authenticated?) Kravitz mentioned the Vaudenay attack in which someone takes a public key and tricks another user into using it as the generator. Solinas questioned why a cofactor is not allowed in DL-DH case, and required in EC MQV. Motion 4. (Solinas Yin) We want cofactor multiplication/exponentiation to be an option in DH1, in each part of DH2, in MQV, both in DL and EC key agreement schemes. Passed, 6-1-2. Schlafly opposed, as it adds 8 new cases, with needless complexity. We discussed security matters, including ephemeral keys, forward secrecy, parameter sizes (q & r in DL, r in EC). DH2 has a backward compatibility feature in which it can fall back to DH1 if two particular values are equal. This was copied from ANSI so we may have a compatibility problem if we change it. Kravitz wanted an option, so a DH2 user doesn't have to test for DH1. MQV has similar security considerations. DLSSA/ECSSA - DL params - sig/verif primitives (NR,DSA) - message encoding method (EMSA) hash -- hash function -- length of message rep Schlafly raised the problem that r must be near 160 bits, or we have a situation with no clear security recommendation on how to expand the hash. DSA users should be cautioned not to leak the random number, and not to use it twice. We have no security notes on primitives for the reason that the security of a primitive is meaningless. At 5pm we adjourned. November 20, 1997 On Thursday we had the same group, except for Blake. We continued to discuss security considerations. IFSSA Johnson said we might want to recommend a larger exponent for possible greater security. Others thought that the arguments for that are speculative. (Some additional discussion was not recorded.) Kaliski handed out an outline, and proposed a revision. D.1 General considerations - rng - setup negotiation - environmental attacks (timing, hardware) - security of primitives (not promised) D.2 Family considerations - DL params - DL keys - EC params - EC keys - IF keys D.3 Scheme considerations Johnson said an attack is only an attack if it threatens some promised feature of a system. Kaliski added intro material on "What is security?" Resistance to some class of attacker. This annex describes security considerations of techniques in the standard, and there may be additional ways to resist some attack. RNG - seeds, pseudorand gen parameters - integrity, associating with keys (risks of certs which don't have parameters), auditability of param gen, validation of params. keys - seed entropy, integrity for public integrity for private keys, association with params, public with private, certificates setup negotiation - integrity, conformance testing, environmental attack (timing, fault analysis), security of primitives Family considerations - DL params field size, NFS, subgroup size pointer to gen & validation methods Chen will list known attacks and complexity ref to time/space estimates possibility of better algorithms - DL keys - EC params some curves have structure - EC keys - IF keys D.3 Scheme considerations Identify underlying problems, and consider the possibility of a breakthrough there. DL/ECKAS cofactor & key validation key derivation function properties, hash key derivation params DL/ECSSA security of 1-time private encoding method requirements - hash IFES comments on other established methods (PKCS 1) IFSSA/R properties of encoding method ... We resumed after lunch. Kaliski outlined the work remaining in the annexes. - rationale (writing) - security considerations (writing) - conformance (writing) - body (minor edits, definition review, Yin, Reyzin) - test vectors (generating) - number-theoretic background (editing, Solinas) - ASN.1 syntax (writing, Markowitz) - references (editing, Yin) Johnson will do security considerations for EC, except key agreement. Kravitz will do DL & EC key agreement, and possibly SSA. Chen will do other DL schemes. Kaliski (or someone else at RSADSI) will do IF schemes. We decided to leave RNG in its own section. Yin will edit the current RNG material and merge in the algorithms in X9 for pseudorandom number generation. Meeting in March for 3 days to stabilize the annexes. We need substantial work for DL parameter and key management (eg, certs, etc). Johnson mentioned an attack where a good signature is used to masquerade as a signature with a broken hash function. Kaliski suggests test vectors for schemes only, with enough detail so that primitive test vectors will be included. Kaliski volunteered to do IF test vectors, with a range of key sizes, exponents 3 and 2^16+1, OAEP-SHA1. Schlafly will do characteristic 2 DL test vectors for DH, MQV, signature. Johnson may supply EC test vectors. Kaliski will get permissions from patent holders to generate test vectors and test them for standards development purposes. Johnson thought that it would be automatic. Test vectors will be in hex, according to octet conversion rules, and stored in a plain ascii file. We want test vectors by the next meeting Mar. 3-5, 1998. Yin will post some examples of test vectors in ASCII format by mid December so that other people can follow the same format to generate more test vectors. The revised body will be posted in early Dec. She will post the entire revised document by Feb. 19. Kaliski wants to approve draft, contingent on Yin's changes and approval of our PARs at December NesCom meeting. Motion 5. (Yin, Kravitz) Approve the (modified) body as a draft. Passed, 7-0-2. Kaliski will try to get a conformance draft out before the RSADSI conference in Jan. 13-16, 1998. We scheduled a teleconference for Tues, Jan. 6, 10am PST. Maybe another one will be scheduled in Feb. Kaliski is not so hot about KDF-HMAC anymore. There may be a key derivation function with provable properties, but this may not be it. Johnson co-authored (with Menezes & Simon) a paper on provable security for the unified model. Motion 6. (Johnson, Schlafly) Remove KDF-HMAC from the main body of the document. Passed 5-0-3. Kaliski read a contribution from Helmut Biely. Biely suggested that we have signature restrictions that a European group is adopting for legal purposes. We expressed concern about whether the restrictions were useful to P1363. Kaliski will respond to him. We will need to schedule an Addendum meeting soon after P1363a is approved. Miles Smid recently announced NIST is planning an AES meeting just before Crypto '98. So we could have a meeting after Crypto '98 in Santa Barbara in August, as usual. We talked about having another meeting in May. Solinas raised an MQV issue. Apparently ANSI did not reconcile its version with ours. Johnson will look into the matter, and try to get ANSI to conform to us. When asked what Certicom is trying to claim in its MQV patent application, Johnson said that no information would be available until the patent issues. Motion 7. (Solinas, Markowitz) Adjourn (at 4pm).