From mailman-bounces@ietf.org Mon Nov 1 05:30:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12695 for ; Mon, 1 Nov 2004 05:30:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COZhF-0003jB-9Y for tls-archive@ietf.org; Mon, 01 Nov 2004 05:45:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZ66-0007Tw-QX for tls-archive@ietf.org; Mon, 01 Nov 2004 05:07:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: lists.ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: tls-archive@ietf.org X-No-Archive: yes Message-ID: Date: Mon, 01 Nov 2004 05:02:49 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your lists.ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@lists.ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@lists.ietf.org. Thanks! Passwords for tls-archive@ietf.org: List Password // URL ---- -------- tls@lists.ietf.org akviiw https://www1.ietf.org/mailman/options/tls/tls-archive%40ietf.org From tls-bounces@ietf.org Tue Nov 2 20:03:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09572; Tue, 2 Nov 2004 20:03:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP9nd-0004Fz-AY; Tue, 02 Nov 2004 20:18:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP9Ow-0005rZ-Hf; Tue, 02 Nov 2004 19:53:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP97U-0004Gm-Hh for tls@megatron.ietf.org; Tue, 02 Nov 2004 19:35:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06845 for ; Tue, 2 Nov 2004 19:35:21 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP9Mf-0003ck-RC for tls@ietf.org; Tue, 02 Nov 2004 19:51:06 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iA30ZLui001255 for ; Tue, 2 Nov 2004 17:35:21 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6K00EX3UYWSP@edgemail1.Central.Sun.COM> for tls@ietf.org; Tue, 02 Nov 2004 17:35:21 -0700 (MST) Received: from [129.146.72.213] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I6K00L5KUYVVC@mail.sun.net> for tls@ietf.org; Tue, 02 Nov 2004 17:35:20 -0700 (MST) Date: Tue, 02 Nov 2004 16:36:18 -0800 From: Vipul Gupta Subject: Re: [TLS] Next steps for draft-ietf-tls-ecc-XX.txt In-reply-to: <200410270758.20372.nmav@gnutls.org> To: Eric Rescorla Message-id: <603AF135-2D30-11D9-B118-000A95C4D60E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20041023055852.90063718B@sierra.rtfm.com> <200410270758.20372.nmav@gnutls.org> X-Spam-Score: 2.0 (++) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7BIT Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7BIT Hi Eric, I agree with Nikos that - Removing the extensions in the ECC in TLS draft may harm interoperability (especially with constrained devices), and - There doesn't appear to be an important reason for dropping them except for the wording in RFC 3546. In fact, at least one of the authors of that draft didn't realize that the sentence would preclude Informational/Experimental RFCs from defining new TLS extensions. So I'd also favor changing the wording in RFC 3546. Who needs to approve such a change and if they do would you want us to remove the extensions in the ECC draft until the change is made or could it proceed to last call in parallel with the change to RFC 3546? thanks, vipul On Oct 26, 2004, at 10:58 PM, Nikos Mavrogiannopoulos wrote: > On Saturday 23 October 2004 07:40, Eric Rescorla wrote: > > (in my previous posting I used a different e-mail address and > it did not appear, so I resend it) > >> The results are below: >> A (Proposed Standard): 12 >> B (Informational w/o extensions): 7 (including both chairs) >> C (Informational w/ extensions): 1 > >> Win and I have consulted with the ADs and we believe that this does >> not >> represent a WG consensus to progress the document at Proposed >> Standard. Accordingly, we will be progressing the document at >> Informational. > > I don't really find it usefull to have this as an informational RFC > without > the extensions. Especially the removal of "the Supported Elliptic > Curves" > extension may harm interoperation. > > Other than that, by not allowing this informational rfc to define > extensions, > this will prohibit any other proposed additions to TLS, that do not > end up as > proposed standard, from using TLS extensions. For example the SRP > draft and > the openpgp-keys, if end up as informational, they will be completely > useless. They heavily depend on the TLS extensions. > > Given that there is no important reason for removing them except for > the > wording of the extensions rfc, I'd suggest to change the wording > instead. > > > > PS. I disagree with the choice of the extension numbers in the ecc > draft > though, since they overlap with other extensions in the above drafts. > > -- > Nikos Mavrogiannopoulos > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Nov 2 20:08:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10210; Tue, 2 Nov 2004 20:08:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP9sH-0004OV-Nk; Tue, 02 Nov 2004 20:23:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP9U6-0008FH-OZ; Tue, 02 Nov 2004 19:58:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP9KG-0003yU-Jt for tls@megatron.ietf.org; Tue, 02 Nov 2004 19:48:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08342 for ; Tue, 2 Nov 2004 19:48:33 -0500 (EST) Received: from sierra.rtfm.com ([198.144.203.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP9ZT-0003vJ-K5 for tls@ietf.org; Tue, 02 Nov 2004 20:04:20 -0500 Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id 1B1F073D4; Tue, 2 Nov 2004 17:06:57 -0800 (PST) Received: by romeo.rtfm.com (Postfix, from userid 556) id 3378C44AB0; Tue, 2 Nov 2004 16:48:02 -0800 (PST) To: Vipul Gupta Subject: Re: [TLS] Next steps for draft-ietf-tls-ecc-XX.txt References: <20041023055852.90063718B@sierra.rtfm.com> <200410270758.20372.nmav@gnutls.org> <603AF135-2D30-11D9-B118-000A95C4D60E@sun.com> From: Eric Rescorla Date: Tue, 02 Nov 2004 16:48:02 -0800 In-Reply-To: <603AF135-2D30-11D9-B118-000A95C4D60E@sun.com> (Vipul Gupta's message of "Tue, 02 Nov 2004 16:36:18 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 2.0 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Vipul Gupta writes: > I agree with Nikos that > > - Removing the extensions in the ECC in TLS draft may harm > interoperability (especially with constrained devices), and > > - There doesn't appear to be an important reason for dropping them > except for the wording in RFC 3546. > > In fact, at least one of the authors of that draft didn't realize that > the sentence would preclude Informational/Experimental > RFCs from defining new TLS extensions. So I'd also favor changing > the wording in RFC 3546. > > Who needs to approve such a change and if they do would you want > us to remove the extensions in the ECC draft until the change is made > or could it proceed to last call in parallel with the change to RFC > 3546? You'd need to create a new document to revise 3546 and get WG consensus behind it. The documents should proceed in parallel. WG members: I'd like to get opinions on this proposed change to RFC 3546. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Nov 4 11:22:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06286; Thu, 4 Nov 2004 11:22:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPkcv-0008I5-NX; Thu, 04 Nov 2004 11:38:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPkIi-00010N-FI; Thu, 04 Nov 2004 11:17:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPkEA-0008DE-L1 for tls@megatron.ietf.org; Thu, 04 Nov 2004 11:12:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05329 for ; Thu, 4 Nov 2004 11:12:44 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPkTi-00083K-Vw for tls@ietf.org; Thu, 04 Nov 2004 11:28:51 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA4GCiE24889 for ; Thu, 4 Nov 2004 18:12:44 +0200 (EET) X-Scanned: Thu, 4 Nov 2004 18:12:27 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iA4GCR9H021582 for ; Thu, 4 Nov 2004 18:12:27 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00U3hilf; Thu, 04 Nov 2004 18:12:25 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA4GCKa19366 for ; Thu, 4 Nov 2004 18:12:20 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Nov 2004 18:11:22 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Nov 2004 18:11:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Nov 2004 18:11:22 +0200 Message-ID: <125EA890549C8641A72F3809CB80DCCD16FDA0@esebe056.ntc.nokia.com> Thread-Topic: TLS-PSK WGLC comments Thread-Index: AcTCiOztIU4BPqEvSqKcuOKcjiPN8g== To: X-OriginalArrivalTime: 04 Nov 2004 16:11:23.0125 (UTC) FILETIME=[EDA01A50:01C4C288] X-Spam-Score: 0.3 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Content-Transfer-Encoding: quoted-printable Subject: [TLS] TLS-PSK WGLC comments X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Content-Transfer-Encoding: quoted-printable Hi everyone, Here's a summary of the comments received during WGLC (thanks especially to Nikos and Peter for going through the document quite thoroughly!), together with my proposals on how to=20 address them. I hope to update the document soon after IETF61, so I'd appreciate comments (even saying that the proposals are acceptable to you, so we'll know if we have rough consensus=20 on this) during the next week or so... Technical issues: 1. Removing RC4-based ciphersuites? Peter Gutmann asked whether the RC4 ciphersuites are necessary. Pasi commented that practically all TLS implementations have RC4 anyway, and in some implementations RC4 is considerably faster. My proposal: No harm in including them, so keep them in. 2. Removing RSA_PSK ciphersuites Nikos asked if the RSA_PSK ciphersuites are actually needed for anything, but at least Peter thought they would be quite useful. My proposal: keep them. 3. Adding other combinations like DHE_RSA_PSK and DHE_DSS_PSK Nikos also asked by other combinations, like DHE_RSA_PSK or DHE_DSS_PSK (or even DH_DSS_PSK, DH_RSA_PSK, ECDH_ECDSA_PSK, ECDHE_ECDSA_PSK, ECDH_RSA_PSK, ECDHE_RSA_PSK, and ECDHE_PSK) were not included. At least Pasi and Eric thought that there is no real need for them, and if a need arises, they can be defined in a separate document later (and we should avoid unnecessary number space explosion). My proposal: Do not include other combinations at this time. This does not, of course, prevent us from defining them in a separate document later. 4. Empty identity hint Currently the draft says that the identity hint can be an empty string, but the ServerKeyExchange message is always sent even in that case. Peter asked if it would be better to omit the whole message in this case. Pasi thought sending the message anyway might be simpler, but there's no big difference either way. My proposal: Keep it as it is (that is, no special case for zero-length identity hint). 5. MD5/SHA1 PRF stuff Currently the premaster secret for plain PSK ciphersuites is "0 || PSK", meaning that only zeroes are fed to the MD5 part of the PRF. Peter Gutmann commented that "Argh, no, this is just wrong! Even if using half the PRF is considered secure, it's just bad engineering practice to take a security mechanism with fail-safe redundancy built in and throw away the redundancy (this was exactly what my draft initially did, and it was flagged as a flaw by people commenting on it). The MD5 calculation is being performed anyway, so you're not saving anything by doing this. The calculation should use both parts of the PRF, to match its usage everywhere else in TLS." Hugo Krawczyk commented that from "From a purely analytical point of view using 0||PSK is better than PSK||PSK (as explained in my January's message referenced below). Heuristically, your guess is as good as mine." Dan Simon replied that "I believe I'm the guy who originally suggested the current parallel construction of the PRF. At the time, I explicitly stated that the whole business of using two fixed hash functions (instead of a single function specified in the ciphersuite) was a stupid idea, and that I was only proposing the parallel construction because certain people were absolutely dead-set on the idea of using both MD5 and SHA1 in the PRF. So naturally I'm all in favor of Hugo's proposal." My interpretation of these comments is that none of the proposed alternatives has any real vulnerabilities (so choosing any of them would work just fine in practice), and the difference is mainly which design principle is considered more important (keeping the fail-safe redundancy or analytical "elegance"). I have no strong opinions either way here, but my proposal would be to keep it as "0||PSK" as suggested by Hugo and Dan. 6. DHE premaster secret=20 Currently the premaster secret is the DH value and PSK concatenated. Peter suggested that it might be better to include some length field to remove the possibility for key equivalents. I tend to agree here, and I propose changing this: =20 "The premaster secret is formed as follows: concatenate the value produced by the Diffie-Hellman exchange (with leading zero bytes stripped as in other Diffie-Hellman based ciphersuites) and the PSK, in this order." To this: "The premaster secret is formed as follows. Let Z be the value produced by the Diffie-Hellman exchange (with leading zero bytes stripped as in other Diffie-Hellman based ciphersuites). Concatenate an uint16 containing the length of Z (in octets), Z itself, and the PSK, in this order." 7. Identity format Nikos commented that the draft should be more specific about what the identity field contains to improve chances for interoperability, and suggested using UTF-8. Pasi agreed that it's important to avoid the situations where both ends are using e.g. Distinguished Names, but encode them in a different way, or an implementation does not allow an administrator to enter the identifier the other end is expecting.=20 My proposal (from http://www.imc.org/ietf-tls/mail-archive/ msg04374.html): Change this "This document does not specify the format of the PSK identity or PSK identity hint; neither is specified how exactly the client uses the hint (if it uses it at all). The parties have to agree on the identities when the shared secret is configured (however, see Section 6 for related security considerations). In situations where the identity is entered by a person, it is RECOMMENDED that the input is processed using an appropriate stringprep [9] profile and encoded in octets using UTF-8 encoding [14]. One possible stringprep profile is described in [8]." To this: "It is expected that different types of identities are useful for different applications running over TLS. This document does not therefore mandate the use of any particular type of identity (such as IPv4 address or FQDN) or identity hint; neither is specified how exactly the client uses the hint (if it uses it at all). To increase the chances for succesful interoperation between applications that do agree on what type of identity is used, the identity MUST be first converted to a character string, and then encoded to octets using UTF-8 [UTF8]. For instance, o IPv4 addresses are sent as dotted-decimal strings (e.g., "192.0.1.2"), not as 32-bit integers in=20 network byte order. o Domain names are sent in their usual text form (e.g., "www.example.com" or "embedded\.dot.example.net"), not in DNS protocol wire format. o X.500 Distinguished Names are sent in their string representation [draft-ietf-ldapbis-dn-14], not as BER-encoded ASN.1. In situations where the identity is entered by a person, processing the character string with an appropriate stringprep [9] profile is RECOMMENDED." =20 8. Ciphersuite and other numbers are TBD Nikos and Peter commented that we can't have any implementations before we assign the required numbers. =20 Eric suggested that numbers should be picked after WGLC, =20 being very careful to avoid collisions. My proposal (from http://www.imc.org/ietf-tls/mail-archive/ msg04373.html): Use ciphersuite numbers starting from 0x8A=20 and alert number 115. Editorial comments: 9. Ciphersuite names Nikos commented about the ciphersuite names, but I think the conclusion of the discussion was that they are reasonably in line with other TLS ciphersuites. Thus, I propose keeping the current names. 10. Wording about "Dictionary attacks" Nikos commented that "I don't think that here "dictionary attacks" is appropriate. PSK is not supposed to be a password based authentication (as also stated in section 1.1), so dictionary attacks do not apply." Pasi replied that in some cases, PSKs might be selected by humans (instead of generated randomly), and the term "dictionary attack" could be used without being too inaccurate. My proposal is to change this: "Use of a fixed shared secret of limited entropy (such as a password) may allow an attacker to perform a brute-force or dictionary attack to recover the secret. (...) " To this: "Use of a fixed shared secret of limited entropy (for example, a PSK that is relatively short, or was chosen by a human and thus may contain less entropy than its length would imply) may allow an attacker to perform a brute-force or dictionary attack to recover the secret. (...)" 11. Possible ambiguity in RSA_PSK premaster description I got an off-list question about the RSA_PSK ciphersuites: does the client RSA-encrypt only the 48-byte random value, or also the PSK? It's only the 48-byte random value, of course, but perhaps the text could be reworded a bit. My proposal is to change this: "The premaster secret is formed as follows: concatenate the 48-byte value generated by the client (and sent to the server in ClientKeyExchange message) and the PSK, in this order." =20 To this: =20 "The EncryptedPreMasterSecret field sent from the client to the server contains a 2-byte version number and a 46-byte random value, encrypted using the server's RSA public key as described in Section 7.4.7.1 of [3]. The actual premaster secret is formed by both parties as follows: concatenate the 2-byte version number, the 46-byte random value, and the PSK, in this order." =20 Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Nov 4 12:00:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09855; Thu, 4 Nov 2004 12:00:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPlDl-0000oM-8i; Thu, 04 Nov 2004 12:16:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPkhC-00022w-GX; Thu, 04 Nov 2004 11:42:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPka9-0007hB-PD for tls@megatron.ietf.org; Thu, 04 Nov 2004 11:35:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07509 for ; Thu, 4 Nov 2004 11:35:27 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPkph-00008x-9R for tls@ietf.org; Thu, 04 Nov 2004 11:51:34 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA4GZME23230; Thu, 4 Nov 2004 18:35:22 +0200 (EET) X-Scanned: Thu, 4 Nov 2004 18:35:48 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iA4GZmEx003995; Thu, 4 Nov 2004 18:35:48 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00zIBDrY; Thu, 04 Nov 2004 18:35:47 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA4GZ6S28896; Thu, 4 Nov 2004 18:35:06 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Nov 2004 18:34:54 +0200 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Nov 2004 18:34:54 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Nov 2004 18:34:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Next steps for draft-ietf-tls-ecc-XX.txt Date: Thu, 4 Nov 2004 18:34:53 +0200 Message-ID: <125EA890549C8641A72F3809CB80DCCD1783AA@esebe056.ntc.nokia.com> Thread-Topic: [TLS] Next steps for draft-ietf-tls-ecc-XX.txt Thread-Index: AcTBQdTX9jkaju6dQkSGuEVIoQxrywBSEcXQ To: X-OriginalArrivalTime: 04 Nov 2004 16:34:54.0223 (UTC) FILETIME=[36B491F0:01C4C28C] X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Eric Rescorla wrote:=20 >=20 > WG members: > I'd like to get opinions on this proposed change to RFC 3546. I think there are good security and interoperability reasons to=20 avoid proliferation of TLS extensions, so I am opposed to changing=20 the policy to "First Come First Served" or anything similar. However, if the document has been thoroughly reviewed and there=20 is rough consensus on it (which seems to be the case with ECC),=20 I don't think being an Informational RFC should prevent it from=20 defining extensions. So something like "IETF Consensus" policy=20 would IMHO be appropriate. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Nov 4 19:41:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27933; Thu, 4 Nov 2004 19:41:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPsQF-00046S-AS; Thu, 04 Nov 2004 19:57:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPs7t-0002u0-2O; Thu, 04 Nov 2004 19:38:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPs6q-0002b7-EF for tls@megatron.ietf.org; Thu, 04 Nov 2004 19:37:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27781 for ; Thu, 4 Nov 2004 19:37:41 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPsMT-00042i-F6 for tls@ietf.org; Thu, 04 Nov 2004 19:53:53 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iA50bgNH029614 for ; Thu, 4 Nov 2004 17:37:43 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6O003J4KEU1U@edgemail1.Central.Sun.COM> for tls@ietf.org; Thu, 04 Nov 2004 17:37:42 -0700 (MST) Received: from [129.146.72.213] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I6O003N3KET76@mail.sun.net> for tls@ietf.org; Thu, 04 Nov 2004 17:37:42 -0700 (MST) Date: Thu, 04 Nov 2004 16:38:42 -0800 From: Vipul Gupta Subject: Re: [TLS] Next steps for draft-ietf-tls-ecc-XX.txt In-reply-to: <125EA890549C8641A72F3809CB80DCCD1783AA@esebe056.ntc.nokia.com> To: tls@ietf.org Message-id: <418ACB92.4000105@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040913) References: <125EA890549C8641A72F3809CB80DCCD1783AA@esebe056.ntc.nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7BIT X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7BIT Setting aside a range of ExtensionTypes for private/experimental use in closed environments would also help address Pasi's concerns and avoid proliferation of TLS extensions. This, again, is a fairly small change to RFC 3546. vipul Pasi.Eronen@nokia.com wrote: > Eric Rescorla wrote: > >>WG members: >>I'd like to get opinions on this proposed change to RFC 3546. > > > I think there are good security and interoperability reasons to > avoid proliferation of TLS extensions, so I am opposed to changing > the policy to "First Come First Served" or anything similar. > > However, if the document has been thoroughly reviewed and there > is rough consensus on it (which seems to be the case with ECC), > I don't think being an Informational RFC should prevent it from > defining extensions. So something like "IETF Consensus" policy > would IMHO be appropriate. > > Best regards, > Pasi > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Sat Nov 6 09:45:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11472; Sat, 6 Nov 2004 09:45:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQRpE-0008BQ-1S; Sat, 06 Nov 2004 09:45:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQRhK-00026S-EU; Sat, 06 Nov 2004 09:37:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQRa2-00017S-RV for tls@megatron.ietf.org; Sat, 06 Nov 2004 09:30:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10575 for ; Sat, 6 Nov 2004 09:30:12 -0500 (EST) Received: from vulcan.rsasecurity.com ([204.167.114.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQRaA-0007uF-GJ for tls@ietf.org; Sat, 06 Nov 2004 09:30:23 -0500 Received: from ebola.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Sat, 6 Nov 2004 09:30:12 -0500 Received: from sdtihq24.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.12.10/NULL) with ESMTP id iA6ESlUA000147 for ; Sat, 6 Nov 2004 09:28:47 -0500 (EST) Received: from rsana-ex-hq0.NA.RSA.NET (fluke_1touch36.securitydynamics.com [10.100.8.49]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id iA6EUBc3018119 for ; Sat, 6 Nov 2004 09:30:11 -0500 (EST) Received: from rsana-ex-sm1.NA.RSA.NET ([10.80.211.17]) by rsana-ex-hq0.NA.RSA.NET with Microsoft SMTPSVC(6.0.3790.211); Sat, 6 Nov 2004 09:30:10 -0500 Received: from mnystrom-lap ([10.133.240.14]) by rsana-ex-sm1.NA.RSA.NET with Microsoft SMTPSVC(6.0.3790.0); Sat, 6 Nov 2004 06:30:09 -0800 Date: Sat, 6 Nov 2004 15:30:25 +0100 (W. Europe Standard Time) From: Magnus Nystrom To: tls@ietf.org Subject: RE: [TLS] Next steps for draft-ietf-tls-ecc-XX.txt In-Reply-To: <125EA890549C8641A72F3809CB80DCCD1783AA@esebe056.ntc.nokia.com> Message-ID: References: <125EA890549C8641A72F3809CB80DCCD1783AA@esebe056.ntc.nokia.com> X-X-Sender: mnystrom@[10.80.211.17] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 06 Nov 2004 14:30:09.0536 (UTC) FILETIME=[1E4F7800:01C4C40D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: magnus@rsasecurity.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb I tend to agree with Pasi's view here. I cannot speak for any of my co-authors but at least it was not my intent that the wording in 3546 would stop well-reviewed I-Ds with WG consensus from defining extensions. Looking at this again, it seems to me that the creation of an IANA registry for the extensions, with the requirements of "IETF Consensus" and "Specification Required", as defined in BCP 26, before assignments are made, would make sense. -- Magnus On Thu, 4 Nov 2004 Pasi.Eronen@nokia.com wrote: > Eric Rescorla wrote: > > > > WG members: > > I'd like to get opinions on this proposed change to RFC 3546. > > I think there are good security and interoperability reasons to > avoid proliferation of TLS extensions, so I am opposed to changing > the policy to "First Come First Served" or anything similar. > > However, if the document has been thoroughly reviewed and there > is rough consensus on it (which seems to be the case with ECC), > I don't think being an Informational RFC should prevent it from > defining extensions. So something like "IETF Consensus" policy > would IMHO be appropriate. > > Best regards, > Pasi > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Sun Nov 7 21:22:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23710; Sun, 7 Nov 2004 21:22:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQzB4-0002sv-KE; Sun, 07 Nov 2004 21:22:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQz9N-0000DK-Sk; Sun, 07 Nov 2004 21:20:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQz48-0007oY-Nh for tls@megatron.ietf.org; Sun, 07 Nov 2004 21:15:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23348 for ; Sun, 7 Nov 2004 21:15:30 -0500 (EST) Received: from mailhost.auckland.ac.nz ([130.216.190.12] helo=smtpb.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQz4Z-0002kM-Jy for tls@ietf.org; Sun, 07 Nov 2004 21:16:01 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 41A9834194; Mon, 8 Nov 2004 15:13:16 +1300 (NZDT) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00907-02; Mon, 8 Nov 2004 15:13:16 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 0752033F63; Mon, 8 Nov 2004 15:13:16 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 68B5D37744; Mon, 8 Nov 2004 15:14:58 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1CQz3e-00006U-00; Mon, 08 Nov 2004 15:15:02 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Pasi.Eronen@nokia.com, tls@ietf.org Subject: Re: [TLS] TLS-PSK WGLC comments In-Reply-To: <125EA890549C8641A72F3809CB80DCCD16FDA0@esebe056.ntc.nokia.com> Message-Id: Date: Mon, 08 Nov 2004 15:15:02 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.9 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Pasi.Eronen@nokia.com writes: >Currently the premaster secret is the DH value and PSK concatenated. Peter >suggested that it might be better to include some length field to remove the >possibility for key equivalents. What I was really hoping for was a general-purpose: opaque premaster<0..2^16-1>; opaque psk<0..2^16-1>; (in my original post I said 'dhValue' rather than 'premaster', which was a bit misleading). What I was proposing was a general-purpose mechanism that works for all algorithm types (straight shared-key, PSK with RSA, PSK with DH, PSK with quantum tunnelling of key bits...), rather than a special-case one only for DH. This is both consistent (it works the same for all algorithms rather than having special-case handling for different ones, which makes implementation a lot easier) and capable of handling future algorithm choices that may require this. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Nov 15 06:22:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17108; Mon, 15 Nov 2004 06:22:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTeyi-0004pk-8L; Mon, 15 Nov 2004 06:25:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTeus-0004pp-0p; Mon, 15 Nov 2004 06:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTeuS-0004mr-Tb for tls@megatron.ietf.org; Mon, 15 Nov 2004 06:20:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16925 for ; Mon, 15 Nov 2004 06:20:34 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTewR-0004nT-F1 for tls@ietf.org; Mon, 15 Nov 2004 06:22:40 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAFBKNW08006; Mon, 15 Nov 2004 13:20:26 +0200 (EET) X-Scanned: Mon, 15 Nov 2004 13:21:27 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iAFBLRZD020188; Mon, 15 Nov 2004 13:21:27 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00LJaUF1; Mon, 15 Nov 2004 13:21:25 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAFBJUa05053; Mon, 15 Nov 2004 13:19:30 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 15 Nov 2004 13:19:26 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 15 Nov 2004 13:19:26 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 15 Nov 2004 13:19:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] TLS-PSK WGLC comments Date: Mon, 15 Nov 2004 13:19:25 +0200 Message-ID: <125EA890549C8641A72F3809CB80DCCD16FDB8@esebe056.ntc.nokia.com> Thread-Topic: [TLS] TLS-PSK WGLC comments Thread-Index: AcTFON0liNgSK/V5Sx6773HBtbKYywFyjalw To: , X-OriginalArrivalTime: 15 Nov 2004 11:19:26.0969 (UTC) FILETIME=[F7BA0E90:01C4CB04] X-Spam-Score: 0.3 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Peter Gutmann wrote: > Pasi.Eronen@nokia.com writes: >=20 >> Currently the premaster secret is the DH value and PSK=20 >> concatenated. Peter suggested that it might be better to=20 >> include some length field to remove the possibility for=20 >> key equivalents. >=20 > What I was really hoping for was a general-purpose: >=20 > opaque premaster<0..2^16-1>; > opaque psk<0..2^16-1>; >=20 > (in my original post I said 'dhValue' rather than 'premaster', > which was a bit misleading). What I was proposing was a > general-purpose mechanism that works for all algorithm types > (straight shared-key, PSK with RSA, PSK with DH, PSK with > quantum tunnelling of key bits...), rather than a special-case > one only for DH. This is both consistent (it works the same > for all algorithms rather than having special-case handling > for different ones, which makes implementation a lot easier) > and capable of handling future algorithm choices that may > require this. I'm not sure if we should call it a "general-purpose" mechanism, but I don't have any problem doing it the same way for all the ciphersuites in this document. Would something like this be better than the current text? Section 2 (plain PSK case): =20 The premaster secret is formed as follows: if the PSK is N octets long, concatenate an uint16 with the value N, N zero octets, a second uint16 with the value N, and the PSK itself. Note 1: All the ciphersuites in this document share the same general structure for the premaster secret, namely "opaque other_secret<0..2^16-1>; opaque psk<0..2^16-1>;". Here "other_secret" is either zeroes (plain PSK case), or comes from the Diffie-Hellman or RSA exchange (DHE_PSK and RSA_PSK, respectively). See Sections 3 and 4 for a more detailed description. Note 2: Using zeroes for "other_secret" effectively means that only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF is used when constructing the master secret. See [7] for a more detailed rationale. Section 3 (DHE_PSK case) The premaster secret is formed as follows. Let Z be the value produced by the Diffie-Hellman exchange (with leading zero bytes stripped as in other Diffie-Hellman based ciphersuites). =20 Concatenate an uint16 containing the length of Z (in octets), Z itself, an uint16 containing the lengh of the PSK (in octets), and the PSK itself. Section 4 (RSA_PSK case) The EncryptedPreMasterSecret field sent from the client to the server contains a 2-byte version number and a 46-byte random value, encrypted using the server's RSA public key as described in Section 7.4.7.1 of [3]. The actual premaster secret is formed by both parties as follows: concatenate an uint16 with the value 48, the 2-byte version number and the 46-byte random value, an uint16 containing the length of the PSK (in octets), and the PSK itself. (Comments from everyone else are also appreciated!) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Nov 15 07:04:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19460; Mon, 15 Nov 2004 07:04:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTfcw-0005T2-Fo; Mon, 15 Nov 2004 07:06:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTfZP-0007iR-R5; Mon, 15 Nov 2004 07:02:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTfXr-0007Zr-KD for tls@megatron.ietf.org; Mon, 15 Nov 2004 07:01:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19325 for ; Mon, 15 Nov 2004 07:01:16 -0500 (EST) Received: from mailhost.auckland.ac.nz ([130.216.190.11] helo=smtpa.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTfZo-0005PV-GX for tls@ietf.org; Mon, 15 Nov 2004 07:03:22 -0500 Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id CA0B2345EA; Tue, 16 Nov 2004 01:00:38 +1300 (NZDT) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20231-26; Tue, 16 Nov 2004 01:00:38 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 8AACF341B3; Tue, 16 Nov 2004 01:00:38 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 6261837746; Tue, 16 Nov 2004 01:00:38 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1CTfXK-0000T7-00; Tue, 16 Nov 2004 01:00:46 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Pasi.Eronen@nokia.com, pgut001@cs.auckland.ac.nz, tls@ietf.org Subject: RE: [TLS] TLS-PSK WGLC comments In-Reply-To: <125EA890549C8641A72F3809CB80DCCD16FDB8@esebe056.ntc.nokia.com> Message-Id: Date: Tue, 16 Nov 2004 01:00:46 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.9 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 writes: >Would something like this be better than the current text? Yup, that looks fine. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Nov 15 13:55:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20234; Mon, 15 Nov 2004 13:55:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTm2v-0005C7-Do; Mon, 15 Nov 2004 13:57:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTlvg-0002y5-0K; Mon, 15 Nov 2004 13:50:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTlsN-0002NF-6D for tls@megatron.ietf.org; Mon, 15 Nov 2004 13:46:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19306 for ; Mon, 15 Nov 2004 13:46:54 -0500 (EST) Received: from reloaded.enst.fr ([137.194.2.14] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTluM-0004zr-If for tls@ietf.org; Mon, 15 Nov 2004 13:49:02 -0500 Received: from revolutions.enst.fr (revolutions.enst.fr [137.194.2.12]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "smtp2.enst.fr", Issuer "ENST CA" (verified OK)) by smtp2.enst.fr (Postfix) with ESMTP id C08B951D; Mon, 15 Nov 2004 19:46:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by revolutions.enst.fr (Postfix) with ESMTP id E8C0011AC96; Mon, 15 Nov 2004 19:46:35 +0100 (CET) Received: from revolutions.enst.fr ([127.0.0.1]) by localhost (revolutions.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32321-15; Mon, 15 Nov 2004 19:46:35 +0100 (CET) Received: from email.enst.fr (muse.enst.fr [137.194.2.33]) by revolutions.enst.fr (Postfix) with ESMTP id 7FBFE11AC35; Mon, 15 Nov 2004 19:46:35 +0100 (CET) Received: from enst.fr (akkar.enst.fr [137.194.164.28]) by email.enst.fr (8.9.3/8.9.3) with ESMTP id TAA20367; Mon, 15 Nov 2004 19:46:34 +0100 (CET) Message-ID: <4198F98E.4020103@enst.fr> Date: Mon, 15 Nov 2004 19:46:38 +0100 From: Mohamad Badra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax; PROMO) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] TLS-PSK WGLC comments References: <125EA890549C8641A72F3809CB80DCCD16FDB8@esebe056.ntc.nokia.com> In-Reply-To: <125EA890549C8641A72F3809CB80DCCD16FDB8@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at enst.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Hi list, IMHO, the draft is well commented and it is actually more clarified. Public and private comments were token into account by the authors. Big thanks for your comments to the draft and special thanks to Pasi :) Best regards, -Bdr Pasi.Eronen@nokia.com wrote: >Peter Gutmann wrote: > > >>Pasi.Eronen@nokia.com writes: >> >> >> >>>Currently the premaster secret is the DH value and PSK >>>concatenated. Peter suggested that it might be better to >>>include some length field to remove the possibility for >>>key equivalents. >>> >>> >>What I was really hoping for was a general-purpose: >> >> _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Nov 15 15:14:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27775; Mon, 15 Nov 2004 15:14:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTnHM-00072n-5F; Mon, 15 Nov 2004 15:16:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTnDa-0007NP-CC; Mon, 15 Nov 2004 15:12:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTmzH-00068K-EY for tls@megatron.ietf.org; Mon, 15 Nov 2004 14:58:07 -0500 Received: from amsfep12-int.chello.nl (amsfep12-int.chello.nl [213.46.243.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25839 for ; Mon, 15 Nov 2004 14:57:56 -0500 (EST) Received: from [192.168.0.190] (really [212.83.87.36]) by amsfep12-int.chello.nl (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041115195724.MPFE1265.amsfep12-int.chello.nl@[192.168.0.190]> for ; Mon, 15 Nov 2004 20:57:24 +0100 From: Nikos Mavrogiannopoulos To: tls@ietf.org Subject: Re: [TLS] TLS-PSK WGLC comments User-Agent: KMail/1.7 References: <125EA890549C8641A72F3809CB80DCCD16FDB8@esebe056.ntc.nokia.com> In-Reply-To: <125EA890549C8641A72F3809CB80DCCD16FDB8@esebe056.ntc.nokia.com> MIME-Version: 1.0 Content-Disposition: inline Date: Mon, 15 Nov 2004 20:57:10 +0100 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Message-Id: <200411152057.10972.nmav@gnutls.org> Content-Transfer-Encoding: 7bit X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit On Monday 15 November 2004 12:19, Pasi.Eronen@nokia.com wrote: > (Comments from everyone else are also appreciated!) No more comments from me. The current draft is ok with me. > Best regards, > Pasi -- Nikos Mavrogiannopoulos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Nov 16 08:58:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29901; Tue, 16 Nov 2004 08:58:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU3tC-000610-5O; Tue, 16 Nov 2004 09:00:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU3pV-000791-Fw; Tue, 16 Nov 2004 08:57:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU3kQ-0006Jm-Dr for tls@megatron.ietf.org; Tue, 16 Nov 2004 08:51:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28963 for ; Tue, 16 Nov 2004 08:51:53 -0500 (EST) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU3md-0005pZ-4X for tls@ietf.org; Tue, 16 Nov 2004 08:54:11 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id iAGDpo9N013921; Tue, 16 Nov 2004 14:51:50 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iAGDpobK019877; Tue, 16 Nov 2004 14:51:50 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Nov 2004 14:51:50 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0531A7DC@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Pasi.Eronen@nokia.com, tls@ietf.org Subject: RE: [TLS] TLS-PSK WGLC comments Date: Tue, 16 Nov 2004 14:51:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 hi pasi, thanks for summarizing all issues raised during wglc. the proposed resolution for each of them is fine with me. thanks for the great work! ciao hannes > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Donnerstag, 04. November 2004 17:11 > To: tls@ietf.org > Subject: [TLS] TLS-PSK WGLC comments > > > Hi everyone, > > Here's a summary of the comments received during WGLC (thanks > especially to Nikos and Peter for going through the document > quite thoroughly!), together with my proposals on how to address them. > > I hope to update the document soon after IETF61, so I'd > appreciate comments (even saying that the proposals are > acceptable to you, so we'll know if we have rough consensus > on this) during the next week or so... > > Technical issues: > > 1. Removing RC4-based ciphersuites? > > Peter Gutmann asked whether the RC4 ciphersuites are > necessary. Pasi commented that practically all TLS > implementations have RC4 anyway, and in some implementations > RC4 is considerably faster. > > My proposal: No harm in including them, so keep them in. > > 2. Removing RSA_PSK ciphersuites > > Nikos asked if the RSA_PSK ciphersuites are actually needed > for anything, but at least Peter thought they would be quite > useful. > > My proposal: keep them. > > 3. Adding other combinations like DHE_RSA_PSK and DHE_DSS_PSK > > Nikos also asked by other combinations, like DHE_RSA_PSK or > DHE_DSS_PSK (or even DH_DSS_PSK, DH_RSA_PSK, ECDH_ECDSA_PSK, > ECDHE_ECDSA_PSK, ECDH_RSA_PSK, ECDHE_RSA_PSK, and ECDHE_PSK) > were not included. At least Pasi and Eric thought that there > is no real need for them, and if a need arises, they can be > defined in a separate document later (and we should avoid > unnecessary number space explosion). > > My proposal: Do not include other combinations at this time. > This does not, of course, prevent us from defining them in a > separate document later. > > 4. Empty identity hint > > Currently the draft says that the identity hint can be an > empty string, but the ServerKeyExchange message is always > sent even in that case. Peter asked if it would be better to > omit the whole message in this case. Pasi thought sending the > message anyway might be simpler, but there's no big > difference either way. > > My proposal: Keep it as it is (that is, no special case for > zero-length identity hint). > > 5. MD5/SHA1 PRF stuff > > Currently the premaster secret for plain PSK ciphersuites is > "0 || PSK", meaning that only zeroes are fed to the MD5 part > of the PRF. > > Peter Gutmann commented that "Argh, no, this is just wrong! > Even if using half the PRF is considered secure, it's just > bad engineering practice to take a security mechanism with > fail-safe redundancy built in and throw away the redundancy > (this was exactly what my draft initially did, and it was > flagged as a flaw by people commenting on it). The MD5 > calculation is being performed anyway, so you're not saving > anything by doing this. The calculation should use both > parts of the PRF, to match its usage everywhere else in TLS." > > Hugo Krawczyk commented that from "From a purely analytical > point of view using 0||PSK is better than PSK||PSK (as > explained in my January's message referenced below). > Heuristically, your guess is as good as mine." > > Dan Simon replied that "I believe I'm the guy who originally > suggested the current parallel construction of the PRF. At > the time, I explicitly stated that the whole business of > using two fixed hash functions (instead of a single function > specified in the ciphersuite) was a stupid idea, and that I > was only proposing the parallel construction because certain > people were absolutely dead-set on the idea of using both MD5 > and SHA1 in the PRF. So naturally I'm all in favor of Hugo's > proposal." > > My interpretation of these comments is that none of the > proposed alternatives has any real vulnerabilities (so > choosing any of them would work just fine in practice), and > the difference is mainly which design principle is considered > more important (keeping the fail-safe redundancy or > analytical "elegance"). > > I have no strong opinions either way here, but my proposal > would be to keep it as "0||PSK" as suggested by Hugo and Dan. > > 6. DHE premaster secret > > Currently the premaster secret is the DH value and PSK > concatenated. Peter suggested that it might be better to > include some length field to remove the possibility for key > equivalents. > > I tend to agree here, and I propose changing this: > > "The premaster secret is formed as follows: concatenate the > value produced by the Diffie-Hellman exchange (with > leading zero bytes stripped as in other Diffie-Hellman > based ciphersuites) and the PSK, in this order." > > To this: > > "The premaster secret is formed as follows. Let Z be the > value produced by the Diffie-Hellman exchange (with > leading zero bytes stripped as in other Diffie-Hellman > based ciphersuites). Concatenate an uint16 containing the > length of Z (in octets), Z itself, and the PSK, in this > order." > > 7. Identity format > > Nikos commented that the draft should be more specific about > what the identity field contains to improve chances for > interoperability, and suggested using UTF-8. Pasi agreed > that it's important to avoid the situations where both ends > are using e.g. Distinguished Names, but encode them in a > different way, or an implementation does not allow an > administrator to enter the identifier the other end is > expecting. > > My proposal (from http://www.imc.org/ietf-tls/mail-archive/ > msg04374.html): Change this > > "This document does not specify the format of the PSK > identity or PSK identity hint; neither is specified how > exactly the client uses the hint (if it uses it at all). > The parties have to agree on the identities when the > shared secret is configured (however, see Section 6 for > related security considerations). In situations where the > identity is entered by a person, it is RECOMMENDED that > the input is processed using an appropriate stringprep [9] > profile and encoded in octets using UTF-8 encoding [14]. > One possible stringprep profile is described in [8]." > > To this: > > "It is expected that different types of identities are > useful for different applications running over TLS. This > document does not therefore mandate the use of any > particular type of identity (such as IPv4 address or FQDN) > or identity hint; neither is specified how exactly the > client uses the hint (if it uses it at all). > > To increase the chances for succesful interoperation > between applications that do agree on what type of > identity is used, the identity MUST be first converted to > a character string, and then encoded to octets using UTF-8 > [UTF8]. For instance, > > o IPv4 addresses are sent as dotted-decimal strings > (e.g., "192.0.1.2"), not as 32-bit integers in > network byte order. > > o Domain names are sent in their usual text form (e.g., > "www.example.com" or "embedded\.dot.example.net"), > not in DNS protocol wire format. > > o X.500 Distinguished Names are sent in their string > representation [draft-ietf-ldapbis-dn-14], not as > BER-encoded ASN.1. > > In situations where the identity is entered by a person, > processing the character string with an appropriate > stringprep [9] profile is RECOMMENDED." > > 8. Ciphersuite and other numbers are TBD > > Nikos and Peter commented that we can't have any > implementations before we assign the required numbers. > Eric suggested that numbers should be picked after WGLC, > being very careful to avoid collisions. > > My proposal (from http://www.imc.org/ietf-tls/mail-archive/ > msg04373.html): Use ciphersuite numbers starting from 0x8A > and alert number 115. > > Editorial comments: > > 9. Ciphersuite names > > Nikos commented about the ciphersuite names, but I think the > conclusion of the discussion was that they are reasonably in > line with other TLS ciphersuites. Thus, I propose keeping the > current names. > > 10. Wording about "Dictionary attacks" > > Nikos commented that "I don't think that here "dictionary > attacks" is appropriate. PSK is not supposed to be a password > based authentication (as also stated in section 1.1), so > dictionary attacks do not apply." > > Pasi replied that in some cases, PSKs might be selected by > humans (instead of generated randomly), and the term > "dictionary attack" could be used without being too > inaccurate. > > My proposal is to change this: > > "Use of a fixed shared secret of limited entropy (such as > a password) may allow an attacker to perform a brute-force > or dictionary attack to recover the secret. (...) " > > To this: > > "Use of a fixed shared secret of limited entropy (for > example, a PSK that is relatively short, or was chosen by > a human and thus may contain less entropy than its length > would imply) may allow an attacker to perform a > brute-force or dictionary attack to recover the > secret. (...)" > > 11. Possible ambiguity in RSA_PSK premaster description > > I got an off-list question about the RSA_PSK ciphersuites: > does the client RSA-encrypt only the 48-byte random value, or > also the PSK? It's only the 48-byte random value, of course, > but perhaps the text could be reworded a bit. > > My proposal is to change this: > > "The premaster secret is formed as follows: concatenate > the 48-byte value generated by the client (and sent to the > server in ClientKeyExchange message) and the PSK, in this > order." > > To this: > > "The EncryptedPreMasterSecret field sent from the client > to the server contains a 2-byte version number and a > 46-byte random value, encrypted using the server's RSA > public key as described in Section 7.4.7.1 of [3]. The > actual premaster secret is formed by both parties as > follows: concatenate the 2-byte version number, the > 46-byte random value, and the PSK, in this order." > > Best regards, > Pasi > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Nov 16 23:21:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05769; Tue, 16 Nov 2004 23:21:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUHMI-0005Q4-SQ; Tue, 16 Nov 2004 23:23:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUHHa-0003rs-Ay; Tue, 16 Nov 2004 23:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUAev-00085a-Qi for tls@megatron.ietf.org; Tue, 16 Nov 2004 16:14:41 -0500 Received: from mail.ca.certicom.com (ns.ca.certicom.com [66.48.18.197]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14926 for ; Tue, 16 Nov 2004 16:14:38 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 5565110134; Tue, 16 Nov 2004 16:14:09 -0500 (EST) Delivered-To: ietf-tls@lists.certicom.com Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id E4A931016D for ; Tue, 16 Nov 2004 16:14:08 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05898-43 for ; Tue, 16 Nov 2004 16:13:57 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.ca.certicom.com (Postfix) with ESMTP id 7A32510134 for ; Tue, 16 Nov 2004 16:13:55 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14760; Tue, 16 Nov 2004 16:13:53 -0500 (EST) Message-Id: <200411162113.QAA14760@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 16 Nov 2004 16:13:53 -0500 X-Mailman-Approved-At: Tue, 16 Nov 2004 23:18:59 -0500 Cc: ietf-tls@lists.certicom.com Subject: [TLS] I-D ACTION:draft-ietf-tls-psk-03.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) Author(s) : P. Eronen, H. Tschofenig Filename : draft-ietf-tls-psk-03.txt Pages : 16 Date : 2004-11-16 This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys. These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key; and the third set combines public key authentication of the server with pre-shared key authentication of the client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-psk-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-psk-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-16113128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-psk-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-psk-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-16113128.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@ietf.org Wed Nov 24 14:13:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21026; Wed, 24 Nov 2004 14:13:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX2eQ-0003hg-JC; Wed, 24 Nov 2004 14:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX2Wy-0002RI-DS; Wed, 24 Nov 2004 14:10:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX2Vk-00027Y-R1 for tls@megatron.ietf.org; Wed, 24 Nov 2004 14:09:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20765 for ; Wed, 24 Nov 2004 14:09:03 -0500 (EST) Received: from sierra.rtfm.com ([198.144.203.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX2Ze-0003a1-Pn for tls@ietf.org; Wed, 24 Nov 2004 14:13:08 -0500 Received: from rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id DA1C2743A for ; Wed, 24 Nov 2004 11:27:55 -0800 (PST) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Wed, 24 Nov 2004 11:08:28 -0800 From: Eric Rescorla Message-Id: <20041124192755.DA1C2743A@sierra.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [TLS] Export cipher suites and TLS 1.1 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad In Last Call comments Peter Gutmann suggested removing the export cipher suites from TLS 1.1 entirely (I'd leave a note and reserve the numbers). Seems like a good idea to me. Any objections? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Nov 26 22:12:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23663; Fri, 26 Nov 2004 22:12:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXt5O-0004pS-6P; Fri, 26 Nov 2004 22:17:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXsw7-0001RH-2E; Fri, 26 Nov 2004 22:07:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhMM-0002aF-Q7 for tls@megatron.ietf.org; Fri, 26 Nov 2004 09:46:07 -0500 Received: from mail.ca.certicom.com (ns.ca.certicom.com [66.48.18.197]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28492 for ; Fri, 26 Nov 2004 06:19:02 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id B4BAD10388; Fri, 26 Nov 2004 06:16:52 -0500 (EST) Delivered-To: ietf-tls@lists.certicom.com Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 83497103B8 for ; Fri, 26 Nov 2004 06:16:52 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32673-36 for ; Fri, 26 Nov 2004 06:16:38 -0500 (EST) Received: from smtpd.itss.auckland.ac.nz (zeppo.itss.auckland.ac.nz [130.216.190.14]) by mail.ca.certicom.com (Postfix) with ESMTP id 73BEE10388 for ; Fri, 26 Nov 2004 06:16:33 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id A31E03478F for ; Sat, 27 Nov 2004 00:16:31 +1300 (NZDT) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04274-11 for ; Sat, 27 Nov 2004 00:16:31 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 878E93463F for ; Sat, 27 Nov 2004 00:16:31 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2CF5E37746 for ; Sat, 27 Nov 2004 00:16:31 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1CXe5f-0005D1-00 for ; Sat, 27 Nov 2004 00:16:39 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-tls@lists.certicom.com Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-psk-03.txt Message-Id: Date: Sat, 27 Nov 2004 00:16:39 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Mailman-Approved-At: Fri, 26 Nov 2004 22:07:44 -0500 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 I've just been going through the -03 draft and I'm not sure whether the new requirements for encoding the identity are such a good idea. The older -02 had "UTF-8 everything" which admittedly was a bit ambiguous, but I think the current requirement to convert things that aren't normally UTF-8 into UTF-8 will cause more interop problems than it solves, because some of the IDs that could potentially be used have ambiguous encodings in text form. The obvious example is X.500 DNs, not only because (even in a perfect world) there are a pile of sematically equivalent forms that can't be easily compared with a strcmp(), but also because we're in an imperfect world where people put latin-1 into T61Strings that can't be reliably turned into UTF-8 and have multi-AVA RDNs for which some implementations will only see the first AVA and not the others, and a pile of other things. Having to implement X.500 en/decoding and string comparison rules in a TLS implementation is probably asking a bit much. IPv6 has somewhat similar problems, there are several ways to represent an address, so you'd need to add complex en/decode/comparison logic to your code to handle this. To resolve this, I think it's necessary to at least provide information on a couple of common ID types and their encodings, e.g: User names (where the user may be a human or a device, and which usually correspond to account names on the server being connected to) are encoded as a UTF-8 character string, without any terminating null character. IPv4 and IPv6 addresses are encoded as 32-bit and 128-bit integers in network byte order. URIs are encoded as specified in [RFC2616]. Domain names are encoded as specified in [whatever the ref is] X.500 DNs are encoded as DER-encoded ASN.1 as it appears in the certificate or other object from which it's referenced. Having said that, I'm not sure at the moment why you'd need something other than a straight user name. For example, I can't see why I'd be connecting to a server and identifying myself as an IP address (I can certainly dream up an imaginary scenario if given a few minutes, but I can't think of any real-world situation where I'd need the ability to do this). So another option would be to leave everything but the user name unspecified and see if anyone ever needs any of the other options, and if so how they want to handle them. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Nov 29 13:47:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18760; Mon, 29 Nov 2004 13:47:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYqdl-0000AP-27; Mon, 29 Nov 2004 13:52:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYqTF-00063C-QX; Mon, 29 Nov 2004 13:41:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYqOy-0005F7-7C for tls@megatron.ietf.org; Mon, 29 Nov 2004 13:37:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17861 for ; Mon, 29 Nov 2004 13:37:29 -0500 (EST) Received: from web61206.mail.yahoo.com ([216.155.196.130]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CYqTu-0008Nj-IW for tls@ietf.org; Mon, 29 Nov 2004 13:42:39 -0500 Received: (qmail 33427 invoked by uid 60001); 29 Nov 2004 18:36:56 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=ZtsZFbD1EMNT1ggn2P72vq5iSnE4lWcShSt2Wtzytju3rEGeftQfUsG7nRYXyKPCcSHnPgFEUF+fQ7vzez3hlTQnhe5WQNgdlA9XdqA1EZW74LZ/Fmwuh9nCNglwfW/CUaOx3uJV9iAoWOZzxlxQ3wwD7z3Qnvbknave6v3mfMw= ; Message-ID: <20041129183656.33425.qmail@web61206.mail.yahoo.com> Received: from [172.206.166.102] by web61206.mail.yahoo.com via HTTP; Mon, 29 Nov 2004 10:36:55 PST Date: Mon, 29 Nov 2004 10:36:55 -0800 (PST) From: Georges Fdida To: tls@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [TLS] Is the PRF reverversible? X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1808055143==" Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca --===============1808055143== Content-Type: multipart/alternative; boundary="0-86093754-1101753415=:33151" --0-86093754-1101753415=:33151 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA17861 Content-Transfer-Encoding: quoted-printable Hello, I have a question What is the consequence if an attacker who knows the MAC or the encryptio= n key derived from master_secret. In other words, is the PRF-TLS is reversible (if I know the its output, c= an I know its input). =20 georges =09 --------------------------------- Do you Yahoo!? Meet the all-new My Yahoo! =96 Try it today!=20 --0-86093754-1101753415=:33151 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA17861 Content-Transfer-Encoding: quoted-printable
Hello,

I have a question
What is the consequence if an att= acker who knows the MAC or the encryption key derived from master_secret.=
In other words, is the PRF-TLS is reversible (if I know the its outpu= t, can I know its input).
 
georges

Do you Yahoo!?
=20 Meet the all-new My Yahoo! =96 Try it= today!=20 --0-86093754-1101753415=:33151-- --===============1808055143== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1808055143==-- From tls-bounces@ietf.org Mon Nov 29 17:52:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22949; Mon, 29 Nov 2004 17:52:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYuSa-0001kh-Ru; Mon, 29 Nov 2004 17:57:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYuHg-0000bp-E7; Mon, 29 Nov 2004 17:46:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYu8g-0005ml-2Q for tls@megatron.ietf.org; Mon, 29 Nov 2004 17:36:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21679 for ; Mon, 29 Nov 2004 17:36:55 -0500 (EST) Received: from saria.randombit.net ([66.179.181.167] helo=mail.randombit.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYuDe-0001HM-JA for tls@ietf.org; Mon, 29 Nov 2004 17:42:07 -0500 Received: by mail.randombit.net (Postfix, from userid 501) id DFE2C247C327; Mon, 29 Nov 2004 15:36:54 -0700 (MST) Date: Mon, 29 Nov 2004 15:36:54 -0700 From: Jack Lloyd To: tls@ietf.org Message-ID: <20041129223654.GA15214@randombit.net> Mail-Followup-To: tls@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [TLS] RSA signature padding confusion X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 All the SSL/TLS specs (SSLv3 through 1.1) state in one section (4.7, "Cryptographic Attributes" in the 1.1 draft) that RSA signatures are done with PKCS #1 block type 0 or type 1, while a later section (8.1.1 in TLS 1.1) only mentions block type 1 with regards to RSA signatures. Basically, what's up with this? Can a compliant implementation (in any version of SSL/TLS) send a block type 0 (ie, no padding at all) signature to the other side? All I really know for certain is that OpenSSL acts very surprised if it gets a signature that doesn't have normal PKCS padding. I looked through EKR's SSL book for discussion on this last night, and didn't see anything, though maybe I just missed it. Any help appreciated. Thanks, Jack _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Nov 29 18:59:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28174; Mon, 29 Nov 2004 18:59:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYvVn-00030d-LX; Mon, 29 Nov 2004 19:04:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYvNr-0000Sv-0c; Mon, 29 Nov 2004 18:56:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYvMf-0000Cb-G7 for tls@megatron.ietf.org; Mon, 29 Nov 2004 18:55:29 -0500 Received: from amsfep17-int.chello.nl (amsfep17-int.chello.nl [213.46.243.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27977 for ; Mon, 29 Nov 2004 18:55:23 -0500 (EST) Received: from [192.168.0.190] (really [212.83.87.36]) by amsfep17-int.chello.nl (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041129235453.GZEV84.amsfep17-int.chello.nl@[192.168.0.190]> for ; Tue, 30 Nov 2004 00:54:53 +0100 From: Nikos Mavrogiannopoulos To: tls@ietf.org Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-psk-03.txt Date: Tue, 30 Nov 2004 00:54:46 +0100 User-Agent: KMail/1.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200411300054.46572.nmav@gnutls.org> Content-Transfer-Encoding: 7bit X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit On Friday 26 November 2004 12:16, Peter Gutmann wrote: > I've just been going through the -03 draft and I'm not sure whether the new > requirements for encoding the identity are such a good idea. The older -02 > had "UTF-8 everything" which admittedly was a bit ambiguous, but I think > the current requirement to convert things that aren't normally UTF-8 into > UTF-8 will cause more interop problems than it solves, because some of the > IDs that could potentially be used have ambiguous encodings in text form. > The obvious example is X.500 DNs, not only because (even in a perfect > world) there are a pile of sematically equivalent forms that can't be > easily compared with a strcmp(), but also because we're in an imperfect > world where people put latin-1 into T61Strings that can't be reliably > turned into UTF-8 and have multi-AVA RDNs for which some implementations > will only see the first AVA and not the others, and a pile of other things. > Having to implement X.500 en/decoding and string comparison rules in a TLS > implementation is probably asking a bit much. [...] > To resolve this, I think it's necessary to at least provide information on > a couple of common ID types and their encodings, e.g: > User names (where the user may be a human or a device, and which usually > correspond to account names on the server being connected to) are encoded > as a UTF-8 character string, without any terminating null character. > IPv4 and IPv6 addresses are encoded as 32-bit and 128-bit integers in > network byte order. If you do this then you have to include a tag to indicate the type. Otherwise you cannot tell whether the data there are a UTF-8 username or an IP address. > Peter. -- Nikos Mavrogiannopoulos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Nov 29 22:46:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16057; Mon, 29 Nov 2004 22:46:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYz3F-0007sU-QM; Mon, 29 Nov 2004 22:51:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYyun-0004mu-8i; Mon, 29 Nov 2004 22:42:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYryG-00079P-Go for tls@megatron.ietf.org; Mon, 29 Nov 2004 15:18:04 -0500 Received: from mail.ca.certicom.com (ns.ca.certicom.com [66.48.18.197]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27267 for ; Mon, 29 Nov 2004 15:18:02 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id B118C10178; Mon, 29 Nov 2004 15:17:33 -0500 (EST) Delivered-To: ietf-tls@lists.certicom.com Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 7EE7A1008A for ; Mon, 29 Nov 2004 15:17:33 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15384-25 for ; Mon, 29 Nov 2004 15:17:22 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.ca.certicom.com (Postfix) with ESMTP id BE55B10178 for ; Mon, 29 Nov 2004 15:17:21 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27189; Mon, 29 Nov 2004 15:17:18 -0500 (EST) Message-Id: <200411292017.PAA27189@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 29 Nov 2004 15:17:18 -0500 X-Mailman-Approved-At: Mon, 29 Nov 2004 22:42:55 -0500 Cc: ietf-tls@lists.certicom.com Subject: [TLS] I-D ACTION:draft-ietf-tls-psk-04.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) Author(s) : P. Eronen, H. Tschofenig Filename : draft-ietf-tls-psk-04.txt Pages : 16 Date : 2004-11-29 This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys. These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key; and the third set combines public key authentication of the server with pre-shared key authentication of the client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-psk-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-psk-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-29152358.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-psk-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-psk-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-29152358.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@ietf.org Tue Nov 30 05:41:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03222; Tue, 30 Nov 2004 05:41:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ5Wg-0007ur-Mj; Tue, 30 Nov 2004 05:46:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ5Ha-0004Eh-Gx; Tue, 30 Nov 2004 05:30:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ59C-0002Bw-Dx for tls@megatron.ietf.org; Tue, 30 Nov 2004 05:22:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01545 for ; Tue, 30 Nov 2004 05:22:11 -0500 (EST) Received: from chico.itss.auckland.ac.nz ([130.216.190.12] helo=smtpb.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ5EH-0007NV-2E for tls@ietf.org; Tue, 30 Nov 2004 05:27:29 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 398FC3446C; Tue, 30 Nov 2004 23:18:44 +1300 (NZDT) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01748-10; Tue, 30 Nov 2004 23:18:44 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 1896D34450; Tue, 30 Nov 2004 23:18:43 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id ACB3A37746; Tue, 30 Nov 2004 23:21:37 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1CZ58j-00016a-00; Tue, 30 Nov 2004 23:21:45 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: nmav@gnutls.org, tls@ietf.org Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-psk-03.txt In-Reply-To: <200411300054.46572.nmav@gnutls.org> Message-Id: Date: Tue, 30 Nov 2004 23:21:45 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.9 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Nikos Mavrogiannopoulos writes: >If you do this then you have to include a tag to indicate the type. Otherwise >you cannot tell whether the data there are a UTF-8 username or an IP address. Why would it matter? All you're doing is comparing (or looking up) a client- supplied { value, length } against a stored { value, length }. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Nov 30 13:51:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19535; Tue, 30 Nov 2004 13:51:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZDBg-0003if-SN; Tue, 30 Nov 2004 13:57:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZCzG-0005LX-1h; Tue, 30 Nov 2004 13:44:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZBeO-0002ir-U2 for tls@megatron.ietf.org; Tue, 30 Nov 2004 12:18:53 -0500 Received: from mail.ca.certicom.com (ns.ca.certicom.com [66.48.18.197]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08697 for ; Tue, 30 Nov 2004 12:18:49 -0500 (EST) From: Pasi.Eronen@nokia.com Received: by mail.ca.certicom.com (Postfix) id 5BAB010380; Tue, 30 Nov 2004 11:45:44 -0500 (EST) Delivered-To: ietf-tls@lists.certicom.com Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 81CA410475 for ; Tue, 30 Nov 2004 11:45:42 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26578-96 for ; Tue, 30 Nov 2004 11:45:30 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mail.ca.certicom.com (Postfix) with ESMTP id 1A00110380 for ; Tue, 30 Nov 2004 11:45:27 -0500 (EST) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAUGjEF26530; Tue, 30 Nov 2004 18:45:14 +0200 (EET) X-Scanned: Tue, 30 Nov 2004 18:41:18 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iAUGfI8D015633; Tue, 30 Nov 2004 18:41:18 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00vxmadk; Tue, 30 Nov 2004 18:41:16 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAUGf2a12133; Tue, 30 Nov 2004 18:41:02 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 30 Nov 2004 18:40:46 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 30 Nov 2004 18:40:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] I-D ACTION:draft-ietf-tls-psk-03.txt Date: Tue, 30 Nov 2004 18:40:46 +0200 Message-ID: <125EA890549C8641A72F3809CB80DCCD16FE0D@esebe056.ntc.nokia.com> Thread-Topic: [TLS] I-D ACTION:draft-ietf-tls-psk-03.txt Thread-Index: AcTULzVgr+1/dEq5RuW3yPr6O7zKPgCxBR7A To: , X-OriginalArrivalTime: 30 Nov 2004 16:40:47.0092 (UTC) FILETIME=[57C59B40:01C4D6FB] Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 30 Nov 2004 13:44:27 -0500 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Hi, If we assume the typical scenario would be that a person enters the identifier and PSK in the TLS client (and server), then IMHO the current approach (UTF-8 encoding) significantly increases the chances for interoperability. It also simplifies actual implementations, since they don't have to implement encoding/ decoding operations for all the different types of identifiers people might want to use. If, on the other hand, the identifiers and keys on both endpoints come from some key distribution system (or something), and this system actually cares about the type of the identifier then using e.g. DER for X.500 DNs might make sense... but I think the former case will be much more common (and many systems will probably just do strcpy/strcmp for something that a person entered somewhere, so UTF-8 will work fine). This way, we also avoid the need to define what exactly is a user name and what is not (not exactly simple if the "user"=20 not a person but a device or a software component), and all the interoperability issues this would bring up... so IMHO we should keep it as it is. Best regards, Pasi > -----Original Message----- > From: Peter Gutmann > Sent: Friday, November 26, 2004 1:17 PM > To: ietf-tls@lists.certicom.com > Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-psk-03.txt >=20 > I've just been going through the -03 draft and I'm not sure > whether the new requirements for encoding the identity are > such a good idea. The older -02 had "UTF-8 everything" which > admittedly was a bit ambiguous, but I think the current > requirement to convert things that aren't normally UTF-8 into > UTF-8 will cause more interop problems than it solves, because > some of the IDs that could potentially be used have ambiguous > encodings in text form. The obvious example is X.500 DNs, not > only because (even in a perfect world) there are a pile of > sematically equivalent forms that can't be easily compared > with a strcmp(), but also because we're in an imperfect world > where people put latin-1 into T61Strings that can't be > reliably turned into UTF-8 and have multi-AVA RDNs for which > some implementations will only see the first AVA and not the > others, and a pile of other things. Having to implement X.500 > en/decoding and string comparison rules in a TLS > implementation is probably asking a bit much. >=20 > IPv6 has somewhat similar problems, there are several ways to > represent an address, so you'd need to add complex > en/decode/comparison logic to your code to handle this. >=20 > To resolve this, I think it's necessary to at least provide > information on a couple of common ID types and their > encodings, e.g: >=20 > User names (where the user may be a human or a device, and=20 > which usually correspond to account names on the server being=20 > connected to) are encoded as a UTF-8 character string, without=20 > any terminating null character. >=20 > IPv4 and IPv6 addresses are encoded as 32-bit and 128-bit=20 > integers in network byte order. >=20 > URIs are encoded as specified in [RFC2616]. >=20 > Domain names are encoded as specified in [whatever the ref is] >=20 > X.500 DNs are encoded as DER-encoded ASN.1 as it appears in=20 > the certificate or other object from which it's referenced. >=20 > Having said that, I'm not sure at the moment why you'd need > something other than a straight user name. For example, I > can't see why I'd be connecting to a server and identifying > myself as an IP address (I can certainly dream up an imaginary > scenario if given a few minutes, but I can't think of any > real-world situation where I'd need the ability to do this). > So another option would be to leave everything but the user > name unspecified and see if anyone ever needs any of the other > options, and if so how they want to handle them. >=20 > Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls