From mailman-bounces@ietf.org Wed Dec 1 06:14:34 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 GAA14287 for ; Wed, 1 Dec 2004 06:14:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZSWj-0005hz-CQ for tls-archive@ietf.org; Wed, 01 Dec 2004 06:20:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZRoW-0002IQ-6b for tls-archive@ietf.org; Wed, 01 Dec 2004 05:34:24 -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: Wed, 01 Dec 2004 05:26:45 -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 Thu Dec 2 00:05:14 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 AAA17266; Thu, 2 Dec 2004 00:05:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZjEp-0007HS-II; Thu, 02 Dec 2004 00:10:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZiX2-0003Ko-CP; Wed, 01 Dec 2004 23:25:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZdi7-0000Pu-DP for tls@megatron.ietf.org; Wed, 01 Dec 2004 18:16:36 -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 SAA08549 for ; Wed, 1 Dec 2004 18:16:32 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 5EE6810150; Wed, 1 Dec 2004 18:16:04 -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 1C1D61016A for ; Wed, 1 Dec 2004 18:16:04 -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 13038-48 for ; Wed, 1 Dec 2004 18:15:36 -0500 (EST) Received: from sierra.rtfm.com (unknown [198.144.203.251]) by mail.ca.certicom.com (Postfix) with ESMTP id 1C4FF10150 for ; Wed, 1 Dec 2004 18:15:34 -0500 (EST) Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id A0E2E7538; Wed, 1 Dec 2004 15:34:32 -0800 (PST) Received: by romeo.rtfm.com (Postfix, from userid 556) id DBB1044ACF; Wed, 1 Dec 2004 15:14:53 -0800 (PST) To: Pasi.Eronen@nokia.com Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-psk-03.txt References: <125EA890549C8641A72F3809CB80DCCD16FE0D@esebe056.ntc.nokia.com> From: Eric Rescorla Date: Wed, 01 Dec 2004 15:14:53 -0800 In-Reply-To: <125EA890549C8641A72F3809CB80DCCD16FE0D@esebe056.ntc.nokia.com> (Pasi Eronen's message of "Tue, 30 Nov 2004 18:40:46 +0200") 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-Mailman-Approved-At: Wed, 01 Dec 2004 23:25:12 -0500 Cc: ietf-tls@lists.certicom.com 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: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Peter, CAn you live with this? -Ekr Pasi.Eronen@nokia.com writes: > 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" > 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 >> >> 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 > -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Dec 3 01:53:14 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 BAA18696; Fri, 3 Dec 2004 01:53:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca7PG-0003lQ-6m; Fri, 03 Dec 2004 01:59:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca56K-000053-7Z; Thu, 02 Dec 2004 23:31:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZtT0-0001XI-AL for tls@megatron.ietf.org; Thu, 02 Dec 2004 11:06:02 -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 LAA03031 for ; Thu, 2 Dec 2004 11:05:59 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 4EF5410284; Thu, 2 Dec 2004 11:05:31 -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 1AF7F102E9 for ; Thu, 2 Dec 2004 11:05:31 -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 24974-12 for ; Thu, 2 Dec 2004 11:05:20 -0500 (EST) Received: from falcon.verisign.com (falcon.verisign.com [216.168.239.71]) by mail.ca.certicom.com (Postfix) with ESMTP id D60D210284 for ; Thu, 2 Dec 2004 11:05:19 -0500 (EST) Received: from vsvapostalgw3.vcorp.ad.vrsn.com (vsvapostalgw3.vcorp.ad.vrsn.com [10.170.12.61]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id iB2G1Top018242 for ; Thu, 2 Dec 2004 11:01:29 -0500 (EST) Received: by vsvapostalgw3.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 2 Dec 2004 11:05:19 -0500 Message-ID: <7468147AEE316B41B3B55152959CE21848F59F@dul1wnexm05.vcorp.ad.vrsn.com> From: "Hollenbeck, Scott" To: "'ietf-tls@lists.certicom.com'" Date: Thu, 2 Dec 2004 11:05:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Mailman-Approved-At: Thu, 02 Dec 2004 23:31:20 -0500 Subject: [TLS] Implementations of RFC 3749 (TLS Compression)? 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: 7d33c50f3756db14428398e2bdedd581 RFC 3749 has existed as a Proposed Standard since May 2004. Now that it's December we've met the six month requirement for progression described in section 6.2 of RFC 2026: "A specification shall remain at the Proposed Standard level for at least six (6) months." OK, so the TLS spec itself isn't there yet, but that doesn't mean that we can't document implementation experience if any exists. Progression to Draft Standard status requires "at least two independent and interoperable implementations from different code bases" (RFC 2026, section 4.1.2). I'm willing to write the implementation report(s) if there are implementers out there who are willing to contribute information. Are there any implementations? -Scott- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Dec 3 13:53:03 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 NAA19977; Fri, 3 Dec 2004 13:53:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaIdz-0008B5-58; Fri, 03 Dec 2004 13:59:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaGZd-0002Yb-6N; Fri, 03 Dec 2004 11:46:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca7Un-0000Te-7M for tls@megatron.ietf.org; Fri, 03 Dec 2004 02:04:49 -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 CAA24403 for ; Fri, 3 Dec 2004 02:04:47 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 7AE0710345; Fri, 3 Dec 2004 02:04:17 -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 3EF3510344 for ; Fri, 3 Dec 2004 02:04:17 -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 30051-100 for ; Fri, 3 Dec 2004 02:04:06 -0500 (EST) Received: from smtpc.itss.auckland.ac.nz (harpo.itss.auckland.ac.nz [130.216.190.13]) by mail.ca.certicom.com (Postfix) with ESMTP id D1C8B10345 for ; Fri, 3 Dec 2004 02:04:05 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 6C99333EF4; Fri, 3 Dec 2004 20:04:03 +1300 (NZDT) Received: from smtpc.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10428-03; Fri, 3 Dec 2004 20:04:03 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 8779933EF0; Fri, 3 Dec 2004 20:04:00 +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 0151E37748; Fri, 3 Dec 2004 20:04:00 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Ca7U6-0005vv-00; Fri, 03 Dec 2004 20:04:06 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ekr@rtfm.com Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-psk-03.txt In-Reply-To: Message-Id: Date: Fri, 03 Dec 2004 20:04:06 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Mailman-Approved-At: Fri, 03 Dec 2004 11:46:23 -0500 Cc: ietf-tls@lists.certicom.com 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: d6b246023072368de71562c0ab503126 EKR writes: >CAn you live with this? It seems to be leaving it as Someone Else's Problem. I agree that for any normal/usual scenario the ID is going to be a (text-form) user name, but requiring that anything that isn't a user name be subject to a non-injective transformation seems to be asking for trouble. I could live with having the handling of user names clearly defined and everything else left open (to be resolved in future updates if it ever becomes necessary, which I think is unlikely), but requiring a surjective transformation as the current text does doesn't seem like a good move. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Dec 3 13:53:45 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 NAA20058; Fri, 3 Dec 2004 13:53:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaIed-0008CS-Vy; Fri, 03 Dec 2004 13:59:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaGZd-0002Yh-O1; Fri, 03 Dec 2004 11:46:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca7h7-0003cR-0z for tls@megatron.ietf.org; Fri, 03 Dec 2004 02:17:33 -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 CAA04399 for ; Fri, 3 Dec 2004 02:17:31 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 50BB0100E1; Fri, 3 Dec 2004 02:16:46 -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 C3E8510344 for ; Fri, 3 Dec 2004 02:16:45 -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 02415-04 for ; Fri, 3 Dec 2004 02:16:34 -0500 (EST) Received: from stdin (unknown [61.74.133.10]) by mail.ca.certicom.com (Postfix) with ESMTP id CB696100E1 for ; Fri, 3 Dec 2004 02:16:32 -0500 (EST) Received: from [210.113.9.2] (helo=[192.168.100.94]) by stdin with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.35 #1 (Debian)) id 1Ca7g4-00065f-00; Fri, 03 Dec 2004 16:16:28 +0900 Message-ID: <41B012AD.8010600@initech.com> Date: Fri, 03 Dec 2004 16:15:57 +0900 From: Joo-Won Jung User-Agent: Mozilla Thunderbird 0.8 (X11/20040926) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hollenbeck, Scott" Subject: Re: [TLS] Implementations of RFC 3749 (TLS Compression)? References: <7468147AEE316B41B3B55152959CE21848F59F@dul1wnexm05.vcorp.ad.vrsn.com> In-Reply-To: <7468147AEE316B41B3B55152959CE21848F59F@dul1wnexm05.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 03 Dec 2004 11:46:23 -0500 Cc: "'ietf-tls@lists.certicom.com'" 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: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Hollenbeck, Scott wrote: >Are there any implementations? > > As far as I know, there are two implementations, GNUTLS and OpenSSL-CVS, which may be interoperable. (I tested the connect, send and receive operations, but I did not test all the cases) Moreover, GNUTLS implements LZO compression based on RFC-3749 framework. Hope this helps... - Joo-Won Jung _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Dec 3 13:54: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 NAA20168; Fri, 3 Dec 2004 13:54:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaIfK-0008EB-0O; Fri, 03 Dec 2004 14:00:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaGZe-0002Ym-Bi; Fri, 03 Dec 2004 11:46:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaD7h-0007PU-Is for tls@megatron.ietf.org; Fri, 03 Dec 2004 08:05:21 -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 IAA01341 for ; Fri, 3 Dec 2004 08:05:20 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id B22831030E; Fri, 3 Dec 2004 08:04:49 -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 825FB10323 for ; Fri, 3 Dec 2004 08:04:49 -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 02859-53 for ; Fri, 3 Dec 2004 08:04:38 -0500 (EST) Received: from falcon.verisign.com (falcon.verisign.com [216.168.239.71]) by mail.ca.certicom.com (Postfix) with ESMTP id D206B1030E for ; Fri, 3 Dec 2004 08:04:37 -0500 (EST) Received: from VSVAPOSTALGW1.vcorp.ad.vrsn.com (vsvapostalgw1.vcorp.ad.vrsn.com [10.170.12.38]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id iB3D0Dop008823; Fri, 3 Dec 2004 08:00:14 -0500 (EST) Received: by vsvapostalgw1.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 3 Dec 2004 08:04:04 -0500 Message-ID: <7468147AEE316B41B3B55152959CE21848F5FA@dul1wnexm05.vcorp.ad.vrsn.com> From: "Hollenbeck, Scott" To: "'Joo-Won Jung'" Subject: RE: [TLS] Implementations of RFC 3749 (TLS Compression)? Date: Fri, 3 Dec 2004 08:03:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Mailman-Approved-At: Fri, 03 Dec 2004 11:46:23 -0500 Cc: "'ietf-tls@lists.certicom.com'" 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 > -----Original Message----- > From: Joo-Won Jung [mailto:jwjung@initech.com] > Sent: Friday, December 03, 2004 2:16 AM > To: Hollenbeck, Scott > Cc: ietf-tls@lists.certicom.com > Subject: Re: [TLS] Implementations of RFC 3749 (TLS Compression)? > > > Hollenbeck, Scott wrote: > > >Are there any implementations? > > > > > > As far as I know, there are two implementations, GNUTLS and > OpenSSL-CVS, > which may be interoperable. (I tested the connect, send and receive > operations, but I did not test all the cases) > > Moreover, GNUTLS implements LZO compression based on RFC-3749 > framework. > > Hope this helps... Greatly, thanks. Could I ask anyone else that's familiar with those implementations to contact me off-list? Thanks, -Scott- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Dec 3 17:21:38 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 RAA11141; Fri, 3 Dec 2004 17:21:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaLtp-0006YZ-M7; Fri, 03 Dec 2004 17:27:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaLim-00084q-Lt; Fri, 03 Dec 2004 17:16:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaKyr-0003C3-SE for tls@megatron.ietf.org; Fri, 03 Dec 2004 16:28:45 -0500 Received: from win.lh.vix.com (win.lh.vix.com [204.152.188.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08318 for ; Fri, 3 Dec 2004 16:28:43 -0500 (EST) Received: from snoopy.treese.org (h0040100cc755.ne.client2.attbi.com [24.91.127.132]) (authenticated) by win.lh.vix.com (8.11.6/8.11.6) with ESMTP id iB3NwXt04040 for ; Fri, 3 Dec 2004 18:58:33 -0500 Received: from deimos.treese.org (unknown [192.168.168.6]) by snoopy.treese.org (Postfix) with ESMTP id E1B3E77AC1 for ; Fri, 3 Dec 2004 16:28:12 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by deimos.treese.org (Postfix) with ESMTP id 94EF01D4302 for ; Fri, 3 Dec 2004 16:28:05 -0500 (EST) To: tls@ietf.org From: Win Treese X-Mailer: MH-E 7.4.4; nmh 1.1; GNU Emacs 21.3.1 Date: Fri, 03 Dec 2004 16:28:05 -0500 Message-Id: <20041203212805.94EF01D4302@deimos.treese.org> Subject: [TLS] please use the new list address 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Please use the new TLS mailing list address, tls@lists.ietf.org. The old one @lists.certicom.com is forwarding now, but it won't be for long. Thanks, Win Treese _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Dec 6 08:03: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 IAA10293; Mon, 6 Dec 2004 08:03:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbIcl-0004Jz-LR; Mon, 06 Dec 2004 08:09:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbIFL-00053B-L7; Mon, 06 Dec 2004 07:45:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbI5s-0004Wt-N6 for tls@megatron.ietf.org; Mon, 06 Dec 2004 07:35:56 -0500 Received: from falcon.verisign.com (falcon.verisign.com [216.168.239.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04917 for ; Mon, 6 Dec 2004 07:35:55 -0500 (EST) Received: from VSVAPOSTALGW1.vcorp.ad.vrsn.com (vsvapostalgw1.vcorp.ad.vrsn.com [10.170.12.38]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id iB6CVVop016802 for ; Mon, 6 Dec 2004 07:31:31 -0500 (EST) Received: by vsvapostalgw1.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 6 Dec 2004 07:35:25 -0500 Message-ID: <7468147AEE316B41B3B55152959CE21848F663@dul1wnexm05.vcorp.ad.vrsn.com> From: "Hollenbeck, Scott" To: "'tls@lists.ietf.org'" Subject: RE: [TLS] please use the new list address Date: Mon, 6 Dec 2004 07:35:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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: b19722fc8d3865b147c75ae2495625f2 Win, You might want to ask the Secretariat to update the working group charter web page. It still lists the "ietf-tls@lists.certicom.com" address. -Scott- > -----Original Message----- > From: tls-bounces@lists.ietf.org [mailto:tls-bounces@lists.ietf.org] > Sent: Friday, December 03, 2004 4:28 PM > To: tls@ietf.org > Subject: [TLS] please use the new list address > > > > Please use the new TLS mailing list address, > tls@lists.ietf.org. The old > one @lists.certicom.com is forwarding now, but it won't be for long. > > Thanks, > > Win Treese > > _______________________________________________ > 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 Wed Dec 8 03:59:55 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 DAA03712; Wed, 8 Dec 2004 03:59:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbxmh-0008IJ-1w; Wed, 08 Dec 2004 04:06:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbxdv-0001Nc-MA; Wed, 08 Dec 2004 03:57:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbxaU-0000dY-RG for tls@megatron.ietf.org; Wed, 08 Dec 2004 03:54:19 -0500 Received: from smtpc.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03051 for ; Wed, 8 Dec 2004 03:54:15 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 117493462E for ; Wed, 8 Dec 2004 21:53:45 +1300 (NZDT) Received: from smtpc.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10753-03 for ; Wed, 8 Dec 2004 21:53:44 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id EE3153459F for ; Wed, 8 Dec 2004 21:53:44 +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 7B90637745 for ; Wed, 8 Dec 2004 21:53:44 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Cbxa3-0002oK-00 for ; Wed, 08 Dec 2004 21:53:51 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: tls@ietf.org Message-Id: Date: Wed, 08 Dec 2004 21:53:51 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Subject: [TLS] PSK question 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: 7d33c50f3756db14428398e2bdedd581 I was reading through the draft again an noticed: To help the client in selecting which identity to use, the server can provide a "PSK identity hint" in the ServerKeyExchange message (note that if no hint is provided, a ServerKeyExchange message is still sent) I have no idea what an "identity hint" could possibly be (the spec says it's optional, but I'd have no idea what to put in there in any case). If the field is used for something, what's it supposed to be used for? If not, perhaps it should be dropped. (Hmm, and I'll repeat my earlier gripe that apart from its use to convey this unknown quantity, there's no need to send the server keyex at all. In other words in 99.99% of cases it's just going to be code and message bloat). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Dec 8 05:24:24 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 FAA09996; Wed, 8 Dec 2004 05:24:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbz6Q-0001Uz-BN; Wed, 08 Dec 2004 05:31:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbyyL-0001OD-FE; Wed, 08 Dec 2004 05:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbyuY-0000ms-Tm for tls@megatron.ietf.org; Wed, 08 Dec 2004 05:19:14 -0500 Received: from smtpd.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09728 for ; Wed, 8 Dec 2004 05:19:03 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 41DB534853 for ; Wed, 8 Dec 2004 23:18:34 +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 15404-05 for ; Wed, 8 Dec 2004 23:18:34 +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 2B0573483B for ; Wed, 8 Dec 2004 23:18:33 +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 C279137745 for ; Wed, 8 Dec 2004 23:18:33 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Cbyu9-0002qz-00 for ; Wed, 08 Dec 2004 23:18:41 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: tls@ietf.org Message-Id: Date: Wed, 08 Dec 2004 23:18:41 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Subject: [TLS] Re: PSK question 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: 7d33c50f3756db14428398e2bdedd581 Another thing I just noticed: 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. What's the point of the N zero octets? If other_secret is empty (which it is for the simplest case where there's no DH, RSA, or other keying material present) then shouldn't the: opaque other_secret<0..2^16-1>; just be a 16-bit length of zero and no data octets? Why the unnecessary zero octets? Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Dec 8 12:45: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 MAA17761; Wed, 8 Dec 2004 12:45:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc5zM-0003FJ-Jc; Wed, 08 Dec 2004 12:52:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc5lZ-0005Sv-Ms; Wed, 08 Dec 2004 12:38:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc5c0-0003Fb-7W for tls@megatron.ietf.org; Wed, 08 Dec 2004 12:28: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 MAA16355 for ; Wed, 8 Dec 2004 12:28:21 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc5io-0002ot-JU for tls@ietf.org; Wed, 08 Dec 2004 12:35:27 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iB8HSFF12497; Wed, 8 Dec 2004 19:28:16 +0200 (EET) X-Scanned: Wed, 8 Dec 2004 19:27:52 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iB8HRqsD028766; Wed, 8 Dec 2004 19:27:52 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00HQsLmw; Wed, 08 Dec 2004 19:27:52 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 iB8HRpa02559; Wed, 8 Dec 2004 19:27:51 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 8 Dec 2004 19:27:39 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 8 Dec 2004 19:27:39 +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] PSK question Date: Wed, 8 Dec 2004 19:27:38 +0200 Message-ID: <125EA890549C8641A72F3809CB80DCCD16FE1A@esebe056.ntc.nokia.com> Thread-Topic: [TLS] PSK question Thread-Index: AcTdBRuB08QUet1OSGenE8V7WAUAXQAQfVpg To: , X-OriginalArrivalTime: 08 Dec 2004 17:27:39.0345 (UTC) FILETIME=[374F5C10:01C4DD4B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Peter Gutmann wrote: >=20 > I was reading through the draft again an noticed: >=20 > To help the client in selecting which identity to use,=20 > the server can provide a "PSK identity hint" in the=20 > ServerKeyExchange message (note that if no hint is=20 > provided, a ServerKeyExchange message is still sent) >=20 > I have no idea what an "identity hint" could possibly be (the=20 > spec says it's optional, but I'd have no idea what to put in=20 > there in any case). If the field is used for something, what's=20 > it supposed to be used for? If not, perhaps it should be dropped. This depends on how you manage the keys for TLS and what you're using TLS for (the application). But the basic idea is the same one as in listing certificate authorities in the CertificateRequest=20 message, giving the client something more to work on in the (probably rare) case that it has some choice. (E.g., in the 3GPP GAA/GBA system, the hint tells the client which "bootstrapping function" it should use to bootstrap a shared key between the client and the server, if it hasn't done that already.) > (Hmm, and I'll repeat my earlier gripe that apart from its use > to convey this unknown quantity, there's no need to send the > server keyex at all. In other words in 99.99% of cases it's > just going to be code and message bloat). I agree that in many cases it's 6 bytes of message bloat, but I'm not so sure about the code bloat; it might even be simpler not to have any special code paths for zero-length identity hint. (And DH ciphersuites work this way, too; the ClientKeyExchange message is sent even if it's empty.) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Dec 8 12:50:34 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 MAA18222; Wed, 8 Dec 2004 12:50:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc64I-0003OI-Oy; Wed, 08 Dec 2004 12:57:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc5nE-0006Cg-4H; Wed, 08 Dec 2004 12:40:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc5gC-0004Du-88 for tls@megatron.ietf.org; Wed, 08 Dec 2004 12:32: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 MAA16709 for ; Wed, 8 Dec 2004 12:32:41 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc5mz-0002vA-Nk for tls@ietf.org; Wed, 08 Dec 2004 12:39:47 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iB8HWTF18714; Wed, 8 Dec 2004 19:32:30 +0200 (EET) X-Scanned: Wed, 8 Dec 2004 19:31:18 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iB8HVIJX006827; Wed, 8 Dec 2004 19:31:18 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00evW8Fa; Wed, 08 Dec 2004 19:31:16 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iB8HVAa05590; Wed, 8 Dec 2004 19:31:10 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 8 Dec 2004 19:31:10 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 8 Dec 2004 19:31:10 +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] Re: PSK question Date: Wed, 8 Dec 2004 19:31:10 +0200 Message-ID: <125EA890549C8641A72F3809CB80DCCD16FE1B@esebe056.ntc.nokia.com> Thread-Topic: [TLS] Re: PSK question Thread-Index: AcTdEQ6zGIeIkaCxRhqkDnORo1AuVgAOjuOg To: , X-OriginalArrivalTime: 08 Dec 2004 17:31:10.0399 (UTC) FILETIME=[B51BA4F0:01C4DD4B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Peter Gutmann wrote: >=20 > Another thing I just noticed: >=20 > The premaster secret is formed as follows: if the PSK=20 > is N octets long, concatenate an uint16 with the value N,=20 > N zero octets, a second uint16 with the value N, and the=20 > PSK itself. >=20 > What's the point of the N zero octets? If other_secret is=20 > empty (which it is for the simplest case where there's no DH,=20 > RSA, or other keying material present) then shouldn't the: >=20 > opaque other_secret<0..2^16-1>; >=20 > just be a 16-bit length of zero and no data octets? Why the=20 > unnecessary zero octets? This was already discussed earlier, see e.g. issue #5 in=20 http://www.imc.org/ietf-tls/mail-archive/msg04389.html and http://www.imc.org/ietf-tls/mail-archive/msg04098.html.=20 BR, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Dec 8 21:44:03 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 VAA12074; Wed, 8 Dec 2004 21:44:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcEOf-0001EE-EO; Wed, 08 Dec 2004 21:51:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcEG8-0000jf-Dm; Wed, 08 Dec 2004 21:42:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcE3O-0006SF-1k for tls@megatron.ietf.org; Wed, 08 Dec 2004 21:29: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 VAA11008 for ; Wed, 8 Dec 2004 21:29:11 -0500 (EST) Received: from zeppo.itss.auckland.ac.nz ([130.216.190.14] helo=smtpd.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcEAG-0000su-N5 for tls@ietf.org; Wed, 08 Dec 2004 21:36:21 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 4C0CF34BE2; Thu, 9 Dec 2004 15:29:04 +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 03283-02; Thu, 9 Dec 2004 15:29:04 +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 0AE9434AF0; Thu, 9 Dec 2004 15:29:04 +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 0714537747; Thu, 9 Dec 2004 15:29:04 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1CcE3I-0003aW-00; Thu, 09 Dec 2004 15:29:08 +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] PSK question In-Reply-To: <125EA890549C8641A72F3809CB80DCCD16FE1A@esebe056.ntc.nokia.com> Message-Id: Date: Thu, 09 Dec 2004 15:29:08 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.9 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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: 2409bba43e9c8d580670fda8b695204a writes: >(E.g., in the 3GPP GAA/GBA system, the hint tells the client >which "bootstrapping function" it should use to bootstrap a >shared key between the client and the server, if it hasn't >done that already.) Having something like this in the text for guidance would be useful. At the moment I know of no authentication protocol that needs or uses an "identity hint", which makes it rather hard to see the utility of this field. >I agree that in many cases it's 6 bytes of message bloat, but >I'm not so sure about the code bloat; it might even be simpler >not to have any special code paths for zero-length identity >hint. I can't speak for anyone else, but in my case there's extra code needed on both the server (to memcpy() in a fixed zero-contents message) and client (to skip the same). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Dec 8 21:53:58 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 VAA13538; Wed, 8 Dec 2004 21:53:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcEYE-0001WR-Qf; Wed, 08 Dec 2004 22:01:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcEGy-0003mH-SW; Wed, 08 Dec 2004 21:43:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcECP-0007mY-Ng for tls@megatron.ietf.org; Wed, 08 Dec 2004 21:38:33 -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 VAA11575 for ; Wed, 8 Dec 2004 21:38:31 -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 1CcEJI-00013b-5M for tls@ietf.org; Wed, 08 Dec 2004 21:45:41 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 8C1C23437E; Thu, 9 Dec 2004 15:34:35 +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 17984-17; Thu, 9 Dec 2004 15:34:35 +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 6E95534180; Thu, 9 Dec 2004 15:34:35 +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 633B837746; Thu, 9 Dec 2004 15:37:57 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1CcEBt-0003an-00; Thu, 09 Dec 2004 15:38:01 +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] Re: PSK question In-Reply-To: <125EA890549C8641A72F3809CB80DCCD16FE1B@esebe056.ntc.nokia.com> Message-Id: Date: Thu, 09 Dec 2004 15:38:01 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.9 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: 7d33c50f3756db14428398e2bdedd581 writes: >This was already discussed earlier, see e.g. issue #5 in >http://www.imc.org/ietf-tls/mail-archive/msg04389.html and >http://www.imc.org/ietf-tls/mail-archive/msg04098.html. That was a somewhat different discussion, my concern there was that the MD5 half was being fed all zeroes. Whether you feed it explicit all-zeroes (required by the current "zeroes || PSK" construct) or implicit all-zeroes (from "PSK" with the LHS set to zeroes) shouldn't make any difference... hmm, OK maybe the explicit-zeroes is more explicit, there just seemed to be a lot of unnecessary extra messing with the input required to format the data this way, whereas simply feeding the PSK straight to the PRF without extra processing seemed cleaner. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Dec 8 23:37:25 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 XAA01699; Wed, 8 Dec 2004 23:37:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcGAM-0003PR-4U; Wed, 08 Dec 2004 23:44:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcFwm-0007zj-GO; Wed, 08 Dec 2004 23:30:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbmTn-0006sr-R6 for tls@megatron.ietf.org; Tue, 07 Dec 2004 16:02:39 -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 SMTP id QAA20489 for ; Tue, 7 Dec 2004 16:02:35 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id C0F2A105DE; Tue, 7 Dec 2004 16:02:00 -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 8991B105DA for ; Tue, 7 Dec 2004 16:02:00 -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 30661-80 for ; Tue, 7 Dec 2004 16:01:49 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.ca.certicom.com (Postfix) with ESMTP id 0E974105DE for ; Tue, 7 Dec 2004 16:01:44 -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 QAA20428; Tue, 7 Dec 2004 16:01:37 -0500 (EST) Message-Id: <200412072101.QAA20428@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, 07 Dec 2004 16:01:37 -0500 X-Mailman-Approved-At: Wed, 08 Dec 2004 23:30:30 -0500 Cc: ietf-tls@lists.certicom.com Subject: [TLS] I-D ACTION:draft-ietf-tls-ecc-07.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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --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 : ECC Cipher Suites For TLS Author(s) : V. Gupta, et al. Filename : draft-ietf-tls-ecc-07.txt Pages : 33 Date : 2004-12-7 This document describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the TLS (Transport Layer Security) protocol. In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-07.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-ecc-07.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-ecc-07.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-12-7154057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-ecc-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-ecc-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-7154057.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 Dec 8 23:38: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 XAA01774; Wed, 8 Dec 2004 23:38:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcGBc-0003RS-Hn; Wed, 08 Dec 2004 23:45:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcFwo-0007zt-7O; Wed, 08 Dec 2004 23:30:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc9Fp-0008V2-Gm for tls@megatron.ietf.org; Wed, 08 Dec 2004 16:21:45 -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 SMTP id QAA04447 for ; Wed, 8 Dec 2004 16:21:41 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 16246100C3; Wed, 8 Dec 2004 16:21:11 -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 D5FD310363 for ; Wed, 8 Dec 2004 16:21:10 -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 11235-57 for ; Wed, 8 Dec 2004 16:20:59 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.ca.certicom.com (Postfix) with ESMTP id DE059100C3 for ; Wed, 8 Dec 2004 16:20:54 -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 QAA04428; Wed, 8 Dec 2004 16:20:47 -0500 (EST) Message-Id: <200412082120.QAA04428@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 08 Dec 2004 16:20:47 -0500 X-Mailman-Approved-At: Wed, 08 Dec 2004 23:30:30 -0500 Cc: ietf-tls@lists.certicom.com Subject: [TLS] I-D ACTION:draft-ietf-tls-rfc2246-bis-09.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: 8de5f93cb2b4e3bee75302e9eacc33db --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 : The TLS Protocol Version 1.1 Author(s) : T. Dierks, E. Rescorla Filename : draft-ietf-tls-rfc2246-bis-09.txt Pages : 89 Date : 2004-12-8 This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc2246-bis-09.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-rfc2246-bis-09.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-rfc2246-bis-09.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-12-8164831.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-rfc2246-bis-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-rfc2246-bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-8164832.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 Fri Dec 10 09:14:50 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 JAA16518; Fri, 10 Dec 2004 09:14:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cclf0-0005kv-QX; Fri, 10 Dec 2004 09:22:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CclQ8-0006B7-0y; Fri, 10 Dec 2004 09:06:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CclKQ-0004NH-3o for tls@megatron.ietf.org; Fri, 10 Dec 2004 09:01:02 -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 JAA15568 for ; Fri, 10 Dec 2004 09:01:00 -0500 (EST) Received: from bacchus.pvv.ntnu.no ([129.241.210.178]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CclRb-0005Qn-Hi for tls@ietf.org; Fri, 10 Dec 2004 09:08:29 -0500 Received: (qmail 63006 invoked by uid 32454); 10 Dec 2004 14:00:59 -0000 To: tls@ietf.org Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-rfc2246-bis-09.txt References: <200412082120.QAA04428@ietf.org> From: Jostein Tveit Organization: Norwegian University of Science and Technology Date: Fri, 10 Dec 2004 15:00:59 +0100 In-Reply-To: <200412082120.QAA04428@ietf.org> (Internet-Drafts@ietf.org's message of "Wed, 08 Dec 2004 16:20:47 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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: cab78e1e39c4b328567edb48482b6a69 [ This announcement was cc'ed to ietf-tls@lists.certicom.com. Someone should probably change this to tls@ietf.org ] I looked at some of the changes in draft-ietf-tls-rfc2246-bis-09.txt, and my comments are below. Section 6.2.1: > Note: Data of different TLS Record layer content types MAY be > interleaved. Application data is generally of higher precedence > for transmission than other content types and therefore handshake I thought application data had _lower_ precedencs than other content types. SSL 3.0, TLS 1.0 and draft 8 says so. Is this a change to TLS in draft 9? Section 6.3: > Implementation note: > The currently defined which requires the most material is > AES_256_CBC_SHA, defined in [TLSAES]. It requires 2 x 32 byte I think "cipher spec" is missing from this sentence. Section A.5: > CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26 > }; > CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27 > }; > CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28 > }; > CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29 > }; > CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A > }; > CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B > }; Strange formatting here. -- Jostein Tveit _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Dec 14 17:33:45 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 RAA29750; Tue, 14 Dec 2004 17:33:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeLMu-00018P-MN; Tue, 14 Dec 2004 17:42:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeL6p-0000NO-Iu; Tue, 14 Dec 2004 17:25:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeL2k-00083k-A1 for tls@megatron.ietf.org; Tue, 14 Dec 2004 17:21:18 -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 RAA28619 for ; Tue, 14 Dec 2004 17:21:16 -0500 (EST) Received: from sierra.rtfm.com ([198.144.203.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeLAn-0000nH-77 for tls@ietf.org; Tue, 14 Dec 2004 17:29:40 -0500 Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id C07DB7244; Tue, 14 Dec 2004 14:42:45 -0800 (PST) Received: by romeo.rtfm.com (Postfix, from userid 556) id 85FB444ACF; Tue, 14 Dec 2004 14:20:36 -0800 (PST) To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Subject: Re: [TLS] Re: PSK question References: From: Eric Rescorla Date: Tue, 14 Dec 2004 14:20:36 -0800 In-Reply-To: (Peter Gutmann's message of "Thu, 09 Dec 2004 15:38:01 +1300") 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: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea 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: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Peter, do you have a strong objection to this proceeding as-is or do you just find it mildly unaesthetic? If the second, I'd like to call it soup. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Dec 15 00:47: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 AAA01497; Wed, 15 Dec 2004 00:47:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeS92-0002pp-Uw; Wed, 15 Dec 2004 00:56:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeRzL-0003G9-5c; Wed, 15 Dec 2004 00:46:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeRxS-0002r3-8H for tls@megatron.ietf.org; Wed, 15 Dec 2004 00:44:18 -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 AAA01326 for ; Wed, 15 Dec 2004 00:44:14 -0500 (EST) Received: from zeppo.itss.auckland.ac.nz ([130.216.190.14] helo=smtpd.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeS5X-0002kr-P2 for tls@ietf.org; Wed, 15 Dec 2004 00:52:44 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 3AF903452F; Wed, 15 Dec 2004 18:44:06 +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 29760-04; Wed, 15 Dec 2004 18:44:06 +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 92A57340C8; Wed, 15 Dec 2004 18:44:05 +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 6A9B037749; Wed, 15 Dec 2004 18:44:05 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1CeRxL-0000i2-00; Wed, 15 Dec 2004 18:44:11 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ekr@rtfm.com Subject: Re: [TLS] Re: PSK question In-Reply-To: Message-Id: Date: Wed, 15 Dec 2004 18:44:11 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.9 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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.9 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 EKR writes: >Peter, do you have a strong objection to this proceeding as-is or do you just >find it mildly unaesthetic? I'm not keen on the PSK kludging when it's fed into the PRF but I guess I can live with that, however I'd really like to have the server keyex/identity hint made optional. Except for one extremely obscure situation (the 3GPP thing that Pasi mentioned), implementors won't even know what they're supposed to do with this facility, let alone be able to use it. All it's doing is unnecessarily complicating the code on both the client and server, and bloating up the handshake message size. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Dec 15 04:54:33 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 EAA16805; Wed, 15 Dec 2004 04:54:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeVzs-0000Vb-Ub; Wed, 15 Dec 2004 05:03:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeVlV-0007PZ-Jj; Wed, 15 Dec 2004 04:48:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeVg1-00069c-1V for tls@megatron.ietf.org; Wed, 15 Dec 2004 04:42: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 EAA16011 for ; Wed, 15 Dec 2004 04:42:30 -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 1CeVoC-0000BT-5l for tls@ietf.org; Wed, 15 Dec 2004 04:51:01 -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 iBF9gHF08579; Wed, 15 Dec 2004 11:42:18 +0200 (EET) X-Scanned: Wed, 15 Dec 2004 11:40:34 +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 iBF9eYMq016839; Wed, 15 Dec 2004 11:40:34 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 0019HkVs; Wed, 15 Dec 2004 11:40:33 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 iBF9eKD21625; Wed, 15 Dec 2004 11:40: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); Wed, 15 Dec 2004 11:40:20 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 15 Dec 2004 11:40:19 +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] Re: PSK question Date: Wed, 15 Dec 2004 11:40:19 +0200 Message-ID: <125EA890549C8641A72F3809CB80DCCD16FE28@esebe056.ntc.nokia.com> Thread-Topic: [TLS] Re: PSK question Thread-Index: AcTiaV5qMw+jq7VOSzOgxtC41fIUcwAHIrcA To: , , X-OriginalArrivalTime: 15 Dec 2004 09:40:19.0224 (UTC) FILETIME=[16FCB180:01C4E28A] X-Spam-Score: 1.3 (+) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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: 1.3 (+) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable pgut001@cs.auckland.ac.nz writes: > EKR writes: >=20 > > Peter, do you have a strong objection to this proceeding=20 > > as-is or do you just find it mildly unaesthetic? >=20 > I'm not keen on the PSK kludging when it's fed into the PRF > but I guess I can live with that, however I'd really like to > have the server keyex/identity hint made optional. Except for > one extremely obscure situation (the 3GPP thing that Pasi > mentioned), implementors won't even know what they're supposed > to do with this facility, let alone be able to use it. All > it's doing is unnecessarily complicating the code on both the > client and server, and bloating up the handshake message size. It should not complicate the client code at all, since even if the client does not use the hint for anything, it has to be able to skip it. And the "bloat" we're talking on server side is maybe=20 one line of code. So IMHO it really does not matter either way (reducing message bloat by 6 bytes increases specification bloat by a couple of sentences), so if this is keeping the draft from going forward, let's change it. In Section 2, change "To help the client in selecting which identity to use, the server can provide a "PSK identity hint" in the ServerKeyExchange message (note that if no hint is=20 provided, a ServerKeyExchange message is still sent)." to "To help the client in selecting which identity to use, the server can provide a "PSK identity hint" in the ServerKeyExchange message. If no hint is provided,=20 the ServerKeyExchange message is omitted." In Section 2, change "The elements in parenthesis are not included when PSK=20 key exchange algorithm is used." to "The elements in parenthesis are not included when PSK key exchange algorithm is used, and "*" indicates a situation-dependent message that is not always sent." In the figure in Section 2, change=20 "ServerKeyExchange" to =20 "ServerKeyExchange*" In Section 3, change "When these ciphersuites are used, the ServerKeyExchange and ClientKeyExchange also include the Diffie-Hellman parameters. The PSK identity and identity hint fields have the same meaning as in the previous section." to "When these ciphersuites are used, the ServerKeyExchange and ClientKeyExchange messages also include the Diffie-Hellman parameters. The PSK identity and identity hint fields have the same meaning as in the previous section (note that the ServerKeyExchange message is always sent even if no PSK identity hint is provided)." In Section 4, change "As in normal RSA ciphersuites, the server must send a Certificate message. The format of the ServerKeyExchange and ClientKeyExchange messages is shown below." to "As in normal RSA ciphersuites, the server must send a Certificate message. The format of the ServerKeyExchange=20 and ClientKeyExchange messages is shown below. If no PSK=20 identity hint is provided, the ServerKeyExchange message=20 is omitted." Would this be better? Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Dec 15 14:29:01 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 OAA00636; Wed, 15 Dec 2004 14:29:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ceexs-0007RU-0T; Wed, 15 Dec 2004 14:37:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ceeeh-0005Wd-Uj; Wed, 15 Dec 2004 14:17:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeeUz-0003da-Aw for tls@megatron.ietf.org; Wed, 15 Dec 2004 14:07:45 -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 OAA28895 for ; Wed, 15 Dec 2004 14:07:43 -0500 (EST) Received: from sierra.rtfm.com ([198.144.203.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeedF-0006qm-1t for tls@ietf.org; Wed, 15 Dec 2004 14:16:18 -0500 Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id DFB2F720E; Wed, 15 Dec 2004 11:29:16 -0800 (PST) Received: by romeo.rtfm.com (Postfix, from userid 556) id 5898144ACF; Wed, 15 Dec 2004 11:07:06 -0800 (PST) To: Subject: Re: [TLS] Re: PSK question References: <125EA890549C8641A72F3809CB80DCCD16FE28@esebe056.ntc.nokia.com> From: Eric Rescorla Date: Wed, 15 Dec 2004 11:07:06 -0800 In-Reply-To: <125EA890549C8641A72F3809CB80DCCD16FE28@esebe056.ntc.nokia.com> (Pasi Eronen's message of "Wed, 15 Dec 2004 11:40:19 +0200") 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: 1.1 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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: 1.1 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 writes: > pgut001@cs.auckland.ac.nz writes: >> EKR writes: >> >> > Peter, do you have a strong objection to this proceeding >> > as-is or do you just find it mildly unaesthetic? >> >> I'm not keen on the PSK kludging when it's fed into the PRF >> but I guess I can live with that, however I'd really like to >> have the server keyex/identity hint made optional. Except for >> one extremely obscure situation (the 3GPP thing that Pasi >> mentioned), implementors won't even know what they're supposed >> to do with this facility, let alone be able to use it. All >> it's doing is unnecessarily complicating the code on both the >> client and server, and bloating up the handshake message size. > > It should not complicate the client code at all, since even if > the client does not use the hint for anything, it has to be able > to skip it. And the "bloat" we're talking on server side is maybe > one line of code. > > So IMHO it really does not matter either way (reducing message > bloat by 6 bytes increases specification bloat by a couple of > sentences), so if this is keeping the draft from going forward, > let's change it. This looks good to me. Peter, can we call this soup? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Dec 15 14:34:51 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 OAA01375; Wed, 15 Dec 2004 14:34:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cef3X-0007cM-9l; Wed, 15 Dec 2004 14:43:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ceegu-0006Nx-9R; Wed, 15 Dec 2004 14:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeeY5-00048T-Tq for tls@megatron.ietf.org; Wed, 15 Dec 2004 14:10: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 OAA29116 for ; Wed, 15 Dec 2004 14:10:56 -0500 (EST) Received: from sierra.rtfm.com ([198.144.203.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeegL-0006vm-VS for tls@ietf.org; Wed, 15 Dec 2004 14:19:31 -0500 Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id 04C9571AC; Wed, 15 Dec 2004 11:32:11 -0800 (PST) Received: by romeo.rtfm.com (Postfix, from userid 556) id 83ED644ACF; Wed, 15 Dec 2004 11:10:00 -0800 (PST) To: Jostein Tveit Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-rfc2246-bis-09.txt References: <200412082120.QAA04428@ietf.org> From: Eric Rescorla Date: Wed, 15 Dec 2004 11:10:00 -0800 In-Reply-To: (Jostein Tveit's message of "Fri, 10 Dec 2004 15:00:59 +0100") 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: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Jostein Tveit writes: > [ This announcement was cc'ed to ietf-tls@lists.certicom.com. > Someone should probably change this to tls@ietf.org ] > > I looked at some of the changes in draft-ietf-tls-rfc2246-bis-09.txt, > and my comments are below. > > Section 6.2.1: >> Note: Data of different TLS Record layer content types MAY be >> interleaved. Application data is generally of higher precedence >> for transmission than other content types and therefore handshake > > I thought application data had _lower_ precedencs than other > content types. SSL 3.0, TLS 1.0 and draft 8 says so. > Is this a change to TLS in draft 9? It's a thinko. I propose: Note: Data of different TLS Record layer content types MAY be interleaved. Application data is generally of lower precedence for transmission than other content types and therefore pending application data may be pre-empted by handshake traffic. However, records MUST be delivered to the network in the same order as they are protected by the record layer. Recipients MUST receive and process interleaved application layer traffic during handshakes subsequent to the first one on a connection. > Section 6.3: >> Implementation note: >> The currently defined which requires the most material is >> AES_256_CBC_SHA, defined in [TLSAES]. It requires 2 x 32 byte > > I think "cipher spec" is missing from this sentence. Thanks. > Section A.5: >> CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26 >> }; >> CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27 >> }; >> CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28 >> }; >> CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29 >> }; >> CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A >> }; >> CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B >> }; Fixed. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Dec 17 23:48:10 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 XAA02100; Fri, 17 Dec 2004 23:48:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfWeZ-0006NC-LK; Fri, 17 Dec 2004 23:57:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfWS9-0005jL-81; Fri, 17 Dec 2004 23:44:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfOm0-00061e-Cn for tls@megatron.ietf.org; Fri, 17 Dec 2004 15:32:24 -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 SMTP id PAA00895 for ; Fri, 17 Dec 2004 15:32:22 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 2C0F110119; Fri, 17 Dec 2004 15:31:53 -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 F07101020E for ; Fri, 17 Dec 2004 15:31: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 16094-13 for ; Fri, 17 Dec 2004 15:31:42 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.ca.certicom.com (Postfix) with ESMTP id 7360810119 for ; Fri, 17 Dec 2004 15:31:41 -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 PAA00837; Fri, 17 Dec 2004 15:31:38 -0500 (EST) Message-Id: <200412172031.PAA00837@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 17 Dec 2004 15:31:38 -0500 X-Mailman-Approved-At: Fri, 17 Dec 2004 23:44:23 -0500 Cc: ietf-tls@lists.certicom.com Subject: [TLS] I-D ACTION:draft-ietf-tls-psk-05.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-05.txt Pages : 16 Date : 2004-12-17 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-05.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-05.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-05.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-12-17153836.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-psk-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-psk-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-17153836.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 Dec 21 10:53: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 KAA21731; Tue, 21 Dec 2004 10:53:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgmTl-00079V-36; Tue, 21 Dec 2004 11:03:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgmIo-00062j-Bv; Tue, 21 Dec 2004 10:51:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgmHv-0005fm-Cg for tls@megatron.ietf.org; Tue, 21 Dec 2004 10:51:03 -0500 Received: from falcon.verisign.com (falcon.verisign.com [216.168.239.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21618 for ; Tue, 21 Dec 2004 10:50:59 -0500 (EST) Received: from VSVAPOSTALGW1.vcorp.ad.vrsn.com (vsvapostalgw1.vcorp.ad.vrsn.com [10.170.12.38]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id iBLFkKop028464 for ; Tue, 21 Dec 2004 10:46:20 -0500 (EST) Received: by vsvapostalgw1.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 21 Dec 2004 10:50:30 -0500 Message-ID: <046F43A8D79C794FA4733814869CDF07057718@dul1wnexmb01.vcorp.ad.vrsn.com> From: "Hollenbeck, Scott" To: "'tls@lists.ietf.org'" Date: Tue, 21 Dec 2004 10:50:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [TLS] Implementation Report for RFC 3749 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: 856eb5f76e7a34990d1d457d8e8e5b7f I have completed an implementation report for RFC 3749 (TLS Compression Methods) in cooperation with Steve Henson, Simon Josefsson, and Nikos Mavrogiannopoulos. I just sent a copy off to the Secretariat. When they get around to it the report should be available on the IETF web site: http://www.ietf.org/IESG/implementation.html So, the time and implementation hurdles to move 3749 from proposed to draft have been met. Now all we have to do is deal with moving the normative references to draft! For what it's worth, -Scott- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Dec 28 10:35:09 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 KAA05211; Tue, 28 Dec 2004 10:35:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjJYL-0005Ou-GS; Tue, 28 Dec 2004 10:46:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjJHp-0007wy-RE; Tue, 28 Dec 2004 10:29:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ciy0m-0008EU-Fp for tls@megatron.ietf.org; Mon, 27 Dec 2004 11:46:24 -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 SMTP id LAA27145 for ; Mon, 27 Dec 2004 11:46:22 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 7998710111; Mon, 27 Dec 2004 11:45:53 -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 499121016C for ; Mon, 27 Dec 2004 11:45:53 -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 08734-96 for ; Mon, 27 Dec 2004 11:45:42 -0500 (EST) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mail.ca.certicom.com (Postfix) with ESMTP id 2E34410111 for ; Mon, 27 Dec 2004 11:45:42 -0500 (EST) Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1Cixu8-0006W3-Vn; Mon, 27 Dec 2004 11:39:32 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 27 Dec 2004 11:39:32 -0500 X-Mailman-Approved-At: Tue, 28 Dec 2004 10:29:24 -0500 Cc: ietf-tls@lists.certicom.com Subject: [TLS] Last Call: 'Addition of Camellia Ciphersuites to Transport Layer Security (TLS)' to Proposed Standard X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org 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: 856eb5f76e7a34990d1d457d8e8e5b7f The IESG has received a request from the Transport Layer Security WG to consider the following document: - 'Addition of Camellia Ciphersuites to Transport Layer Security (TLS) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-01-10. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-camellia-06.txt _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Dec 28 10:35:24 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 KAA05250; Tue, 28 Dec 2004 10:35:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjJYa-0005PC-50; Tue, 28 Dec 2004 10:46:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjJHq-0007x3-5q; Tue, 28 Dec 2004 10:29:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjIje-00038R-CV for tls@megatron.ietf.org; Tue, 28 Dec 2004 09:54:06 -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 SMTP id JAA00811 for ; Tue, 28 Dec 2004 09:54:01 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id D7C0810143; Tue, 28 Dec 2004 09:53:30 -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 A61CC1010A for ; Tue, 28 Dec 2004 09:53:30 -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 20133-60 for ; Tue, 28 Dec 2004 09:53:17 -0500 (EST) Received: from mulder.f5.com (mulder.f5.com [205.229.151.150]) by mail.ca.certicom.com (Postfix) with ESMTP id 46AF71017D for ; Tue, 28 Dec 2004 09:53:15 -0500 (EST) Received: from exchfour.olympus.f5net.com ([192.168.11.152]) by mulder.f5.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Dec 2004 06:53:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 28 Dec 2004 06:53:08 -0800 Message-ID: <3D8E54E3CAA3864295233C618F53F2ADC819C6@exchfour.olympus.f5net.com> Thread-Topic: Re: [Tsvwg] Looking for feedback on DTLS Thread-Index: AcTs7PHxUEvxtQPwTtWFnlENO3x+Qw== From: "Amit Jain" To: X-OriginalArrivalTime: 28 Dec 2004 14:53:10.0873 (UTC) FILETIME=[F321C490:01C4ECEC] X-Mailman-Approved-At: Tue, 28 Dec 2004 10:29:24 -0500 Cc: nagendra@cs.standford.edu.cnri.reston.va.us, ietf-tls@lists.certicom.com Subject: [TLS] Re: [Tsvwg] Looking for feedback on DTLS 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="===============1374802541==" Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 210770d71723b650f9c8e3db4e95b596 This is a multi-part message in MIME format. --===============1374802541== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4ECEC.F2DF6217" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4ECEC.F2DF6217 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to submit following inputs as the feedback: =20 Current draft proposes to add fragmentation, reliability and in-order delivery to handshake layer while keeping the record layer mostly unchanged.=20 =20 Draft seems to imply that the handshake layer sends a collection of handshake messages (referred as flight) and then waits for the other end to respond. The timeout causes all the messages in flight to be retransmitted.=20 =20 Here the reliability is being tracked for a complete flight of messages as a single unit. Given that a flight can have considerable amount of data, the probability of packet loss seems to be high. And since each packet loss causes complete flight to be retransmitted, this may be a large retransmission again. And this may again suffer a packet loss. I think tracking reliability on per flight and retransmitting complete flight as a response to packet loss may not be an efficient approach. =20 Also building the reliability and in-order delivery into handshake layer makes handshake state machine complicated. =20 =20 I think another approach worth considering may be to introduce a thin layer inside record layer which takes care of fragmentation, reliability, in-order delivery to record layer. In this approach: =20 1: A Handshake message can never span multiple records. A record can contain multiple handshake messages though. =20 This will eliminate the need of handshake message re-assembly. Assembling a record will always result in at least one complete handshake message or multiple complete handshake messages. =20 This is different from the current specification where the handshake can span multiple records. And will need the change in length field of record layer (it'll have to be extended to 3 bytes) =20 =20 2: Records are fragmented and is converted to UDP datagram.=20 =20 These UDP data-grams are then transmitted reliably to other end in the handshake phase using a very thin layer (built into record layer). It may be analogous to a simple reliable variant of UDP (something like TFTP). Here the reliability is tracked for each UDP datagram and only the missing UDP datagram is re-transmitted. =20 =20 This may provide following advantages: =20 1: Handshake layer will be similar to the TLS. There won't be any change needed in the implementation of state machine and the specification of handshake messages. =20 2: A Record can span multiple UDP packets; this will free DTLS from strict need of having a correct path MTU. =20 2: Record layer will consist of a thin reliability layer; this layer will be active during handshake phase and will make sure the reliable ordered delivery of the handshake messages. During application data transfer the reliability part of the record layer is switched off. (Actually this'll mostly depend on the application, and if application wants to use reliability mode of record layer, that should be possible too.) =20 3: Having a thin reliability layer in Record layer will allow greater flexibility and extensibility. Reliability layer can be replaced with other reliability mechanism like DCCP in future for providing reliability/congestion control. =20 =20 Thanks, -amit =20 > Eric Rescorla wrote: =20 > As we all know, TLS is popular but is only compatible with reliable > transports. Unfortunately, a number of important protocols (SIP in > particular) run over datagram transport and therefore cannot use TLS. In > response, Nagendra Modadugu and I have designed a variant of TLS which > we call Datagram TLS (DTLS). DTLS consists of only the minimal changes > required to TLS to make it operate on datagram transport. =20 > We've submitted DTLS as an I-D which you can find at: > draft-rescorla-dtls-01.txt =20 > You can also read our paper on DTLS from ISOC NDSS at: > http://crypto.stanford.edu/~nagendra/papers/dtls.pdf =20 > We've already gotten some useful comments from PMTUD people about > handling PMTU but any comments TSV people have on the protocol would be > appreciated. =20 > Best, >-Ekr =20 _______________________________________________ tsvwg mailing list tsvwg at ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg =20 =20 =20 =20 _______________________________________________ tsvwg mailing list tsvwg at ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg =20 =20 ------_=_NextPart_001_01C4ECEC.F2DF6217 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
I would like to submit following inputs as =
the feedback:
 
Current =
draft proposes to add fragmentation, reliability and in-order delivery =
to handshake layer while keeping the record layer mostly unchanged. =

 
Draft =
seems to imply that the handshake layer sends a collection of handshake =
messages (referred as flight) and then waits for the other end to =
respond. The timeout causes all the messages in flight to be =
retransmitted. 
 
Here the =
reliability is being tracked for a complete flight of messages as a =
single unit. Given that a flight can have considerable amount of data, =
the probability of packet loss seems to be high. And since each packet =
loss causes complete flight to be retransmitted, this may be a large =
retransmission again. And this may again suffer a packet loss. I think =
tracking reliability on per flight and retransmitting complete flight as =
a response to packet loss may not be an efficient =
approach.
 
Also =
building the reliability and in-order delivery into handshake layer =
makes handshake state machine =
complicated.
 
 
I think =
another approach worth considering may be to introduce a thin layer =
inside record layer which takes care of fragmentation, reliability, =
in-order delivery to record layer. In this =
approach:
 
1: A =
Handshake message can never span multiple records. A record can contain =
multiple handshake messages =
though.
 
This will =
eliminate the need of handshake message re-assembly. Assembling a record =
will always result in at least one complete handshake message or =
multiple complete handshake =
messages.
 
This is =
different from the current specification where the handshake can span =
multiple records. And will need the change in length field of record =
layer (it’ll have to be extended to 3 =
bytes)
 
 
2: =
Records are fragmented and is converted to UDP datagram. =

 
These UDP =
data-grams are then transmitted reliably to other end in the handshake =
phase using a very thin layer (built into record layer). It may be =
analogous to a simple reliable variant of UDP (something like TFTP). =
Here the reliability is tracked for each UDP datagram and only the =
missing UDP datagram is =
re-transmitted.
 
 
This may =
provide following advantages:
 
1: =
Handshake layer will be similar to the TLS. There won’t be any =
change needed in the implementation of state machine and the =
specification of handshake =
messages.
 
2: A =
Record can span multiple UDP packets; this will free DTLS from strict =
need of having a correct path =
MTU.
 
2: Record =
layer will consist of a thin reliability layer; this layer will be =
active during handshake phase and will make sure the reliable ordered =
delivery of the handshake messages. During application data transfer the =
reliability part of the record layer is switched off. (Actually =
this’ll mostly depend on the application, and if application wants =
to use reliability mode of record layer, that should be possible =
too.)
 
3: Having =
a thin reliability layer in Record layer will allow greater flexibility =
and extensibility. Reliability layer can be replaced with other =
reliability mechanism like DCCP in future for providing =
reliability/congestion control.
 
 
Thanks,
-amit
 
> Eric =
Rescorla wrote:

 

> As we all know, TLS is popular but is =
only compatible with reliable
> =
transports. Unfortunately, a number of important protocols (SIP =
in
> =
particular) run over datagram transport and therefore cannot use TLS. =
In
> =
response, Nagendra Modadugu and I have designed a variant of TLS =
which
> we =
call Datagram TLS (DTLS).  DTLS consists of only the minimal =
changes
> =
required to TLS to make it operate on datagram =
transport.

 

> We've submitted DTLS as an I-D which you =
can find at:
> =
draft-rescorla-dtls-01.txt

 

> You can also read our paper on DTLS from =
ISOC NDSS at:
> http://cryp=
to.stanford.edu/~nagendra/papers/dtls.pdf


 



> We've already gotten some useful =
comments from PMTUD people =
about
> =
handling PMTU but any comments TSV people have on the protocol would =
be
> =
appreciated.



 



> =
Best,
 =
>-Ekr
















 
______________________________________________=
_
tsvwg =
mailing list
tsvwg at =
ietf.org
https://www1.ietf.o=
rg/mailman/listinfo/tsvwg



 



 



 








 
______________________________________________=
_
tsvwg =
mailing list
tsvwg at =
ietf.org
https://www1.ietf.o=
rg/mailman/listinfo/tsvwg



 



 
------_=_NextPart_001_01C4ECEC.F2DF6217-- --===============1374802541== 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 --===============1374802541==-- From tls-bounces@ietf.org Tue Dec 28 13:55:45 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 NAA16958; Tue, 28 Dec 2004 13:55:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjMgT-0001vD-0u; Tue, 28 Dec 2004 14:07:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjMNe-0006M9-B1; Tue, 28 Dec 2004 13:47:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjLCH-0000BS-3b for tls@megatron.ietf.org; Tue, 28 Dec 2004 12:31:49 -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 SMTP id MAA11780 for ; Tue, 28 Dec 2004 12:31:45 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 4DA9510110; Tue, 28 Dec 2004 12:31:18 -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 2085A1017D for ; Tue, 28 Dec 2004 12:31:18 -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 19663-93 for ; Tue, 28 Dec 2004 12:31:05 -0500 (EST) Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by mail.ca.certicom.com (Postfix) with ESMTP id AD45310110 for ; Tue, 28 Dec 2004 12:31:03 -0500 (EST) Received: by romeo.rtfm.com (Postfix, from userid 1001) id CC1F81702B; Tue, 28 Dec 2004 09:31:12 -0800 (PST) To: "Amit Jain" References: <3D8E54E3CAA3864295233C618F53F2ADC819C6@exchfour.olympus.f5net.com> From: EKR Date: Tue, 28 Dec 2004 09:31:12 -0800 In-Reply-To: <3D8E54E3CAA3864295233C618F53F2ADC819C6@exchfour.olympus.f5net.com> (Amit Jain's message of "Tue, 28 Dec 2004 06:53:08 -0800") Message-ID: <86d5wugwin.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 28 Dec 2004 13:47:36 -0500 Cc: nagendra@cs.standford.edu.cnri.reston.va.us, ietf-tls@lists.certicom.com, tsvwg@ietf.org Subject: [TLS] Re: [Tsvwg] Looking for feedback on DTLS 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: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 "Amit Jain" writes: > I would like to submit following inputs as the feedback: Amit, Thanks for your comments. Responses below. > Current draft proposes to add fragmentation, reliability and in-order > delivery to handshake layer while keeping the record layer mostly > unchanged. That's a fair summary, yes. > Draft seems to imply that the handshake layer sends a collection of > handshake messages (referred as flight) and then waits for the other end > to respond. The timeout causes all the messages in flight to be > retransmitted. Yes, that's correct. We considered a cumulative ACK as in TCP (see Section 4.4 of the DTLS paper) but we ultimately decided that it wouldn't add that much efficiency improvement and it of course makes life more complicated. Our initial measurements seem to support that, but it would of course be very easy to add ACKs later. > Here the reliability is being tracked for a complete flight of messages > as a single unit. Given that a flight can have considerable amount of > data, the probability of packet loss seems to be high. And since each > packet loss causes complete flight to be retransmitted, this may be a > large retransmission again. And this may again suffer a packet loss. Yes, that's correct, but it's fairly unlikely to be the SAME packet. You keep going until you've received all the bytes at least once, not until a given flight comes through intact. > Also building the reliability and in-order delivery into handshake layer > makes handshake state machine complicated. Yes, that's correct. However, the complexity is relatively minimal, at least in our implementation. > I think another approach worth considering may be to introduce a thin > layer inside record layer which takes care of fragmentation, > reliability, in-order delivery to record layer. In this approach: Yes. We considered this approach. However, we were concerned about designing a generic reliability layer. Designing reliable transport protocols is difficult, as evidenced by the fact that we're still working on TCP after 20+ years. Our feeling was that as the only real requirement was to make the handshake reliable it was best to tie the reliability into the handshake process and thus avoid the complexity and rathole potential of trying to design something more general. Moreover, there is experience with this kind of state machine from IKE and other similar protocols. > 1: A Handshake message can never span multiple records. A record can > contain multiple handshake messages though. > > This will eliminate the need of handshake message re-assembly. > Assembling a record will always result in at least one complete > handshake message or multiple complete handshake messages. Of course. But it will replace it with record reassembly, which is basically the same problem. > This is different from the current specification where the handshake can > span multiple records. And will need the change in length field of > record layer (it'll have to be extended to 3 bytes) Just a clarification: you mean "the current TLS specification" here, correct? TLS currently has this feature. > 2: Records are fragmented and is converted to UDP datagram. > > These UDP data-grams are then transmitted reliably to other end in the > handshake phase using a very thin layer (built into record layer). It > may be analogous to a simple reliable variant of UDP (something like > TFTP). Here the reliability is tracked for each UDP datagram and only > the missing UDP datagram is re-transmitted. > > This may provide following advantages: > > 1: Handshake layer will be similar to the TLS. There won't be any change > needed in the implementation of state machine and the specification of > handshake messages. That's sort of correct, except that the handshake state machine will need to do signalling to the record layer about when it wants reliability. It's also important to note that the DTLS handshake reliability layer lives mostly at the level of the DTLS handshake wrapper. The handshake payloads themselves don't change. > 2: A Record can span multiple UDP packets; this will free DTLS from > strict need of having a correct path MTU. Not really. The DTLS handshake doesn't need an exact PMTU. It just needs an approximate PMTU estimate to make sure that its own messages get through. Typically it's the applications which need a PMTU estimate because they actually want to send data in a single UDP datagram. That's what their non-DTLS behavior is, after all. Actually, the approach you suggest makes the PTMU problem worse in some ways. In the current design, the DTLS implementation can mostly punt the process of PMTU discovery off to the application. Because the HS is fairly short, it can use a safe PMTU for its own traffic and then let the application send large messages until it becomes clear that it can't. This lets the app use PMTU discovery mechanisms that are better than those described in RFC 1191. (Note that this isn't exactly what the DTLS draft says because I just worked it out recently, but it's a fairly minor change that doesn't affect interop). By contrast, if DTLS is in the business of fragmenting data records, then it has to do so efficiently, which means that it really needs to know the PMTU. Otherwise, it's at risk of making fragments that are way too small. I suppose you could say you'll only fragment handshake records, but that's kind of a layer violation inside TLS. > 2: Record layer will consist of a thin reliability layer; this layer > will be active during handshake phase and will make sure the reliable > ordered delivery of the handshake messages. During application data > transfer the reliability part of the record layer is switched off. This is actually fairly problematic. Remember that in TLS the handshake and application data can be interlaced during the rehandshake process. So, it's not a simple matter of reliability being "on" or "off". You certainly don't want to suddenly turn applications that expect unreliable semantics into reliable ones just because they're rehandshaking. (This is a special problem if the reliability layer provides in-order delivery as well, which is what's required if you want to not change the handshake layer at all). > (Actually this'll mostly depend on the application, and if application > wants to use reliability mode of record layer, that should be possible > too.) I think this illustrates the point I made above about genericity. The transport requirements for the handshake phase of TLS, which is short and doesn't move a lot of data, are very different from the requirements for a generic data transport protocol such as is provided by the DTLS/TLS record layer. If you're going to use your reliability layer for data, you're going to want much better efficiency and congestion control guarantees and suddenly you're reinventing TCP and SCTP. > 3: Having a thin reliability layer in Record layer will allow greater > flexibility and extensibility. Reliability layer can be replaced with > other reliability mechanism like DCCP in future for providing > reliability/congestion control. Well, DCCP wouldn't do the job here since it ONLY provides congestion control and not reliability. DTLS will of course run fine over DCCP. It just doesn't make the problem any easier. Michael Tuexen and I are currently talking about the interaction of DTLS and SCTP, but I don't think that's a universal solution. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Dec 29 09:40:04 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 JAA12393; Wed, 29 Dec 2004 09:40:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjfAl-0000EB-Jg; Wed, 29 Dec 2004 09:51:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjewX-0007VR-Iv; Wed, 29 Dec 2004 09:36:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjPpZ-0003gH-0C for tls@megatron.ietf.org; Tue, 28 Dec 2004 17:28: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 SMTP id RAA08953 for ; Tue, 28 Dec 2004 17:28:37 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 2701F102B9; Tue, 28 Dec 2004 17:28:10 -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 EBDAB102E2 for ; Tue, 28 Dec 2004 17:28:09 -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 25665-38 for ; Tue, 28 Dec 2004 17:27:58 -0500 (EST) Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by mail.ca.certicom.com (Postfix) with ESMTP id D0BA1102B9 for ; Tue, 28 Dec 2004 17:27:52 -0500 (EST) Received: by romeo.rtfm.com (Postfix, from userid 1001) id C7D6917025; Tue, 28 Dec 2004 14:27:35 -0800 (PST) To: Murali Bashyam References: <3D8E54E3CAA3864295233C618F53F2ADC819C6@exchfour.olympus.f5net.com> <86d5wugwin.fsf@romeo.rtfm.com> <41D1C7DE.6020208@cisco.com> From: EKR Date: Tue, 28 Dec 2004 14:27:35 -0800 In-Reply-To: <41D1C7DE.6020208@cisco.com> (Murali Bashyam's message of "Tue, 28 Dec 2004 12:53:50 -0800") Message-ID: <86k6r2f488.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Wed, 29 Dec 2004 09:36:51 -0500 Cc: nagendra@cs.standford.edu.cnri.reston.va.us, ietf-tls@lists.certicom.com, tsvwg@ietf.org, Amit Jain Subject: [TLS] Re: [Tsvwg] Looking for feedback on DTLS 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: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Murali Bashyam writes: > I had a question on the congestion control aspect of the handshake > protocol in DTLS. The draft doesn't seem to address the congestion > control requirements of the handshake protocol such as how soon is it > okay to send an entire flight of packets into the network without > overloading it. We suggest a retransmit timer on the order of 500-1000 ms. > I think there's also a problem in retransmitting the > entire flight when 1 packet in that flight from the original > transmission got dropped because it starts burdening an already > congested network. And it's clear from simulation and experience that > it's more efficient to use TCP mechanisms such as SACK/NewReno/Reno > to recover from scenarios where multiple packets/single packet drop > occurs in that flight of packets. Of course, but we're talking extremely small amounts of data here. It's important to remember that in your average SSL handshake the total number of bytes exchanged is generally less than 3k and that the largest single flight (ServerHello ... ServerHelloDone) is typically less than 2k [1]. In most cases it will fit in 1-2 MTUs. Obviously, one could optimize this interaction some, but if you're in a situation where DTLS handshakes represent a significant fraction of your network congestion, you've got some really serious problems that marginally better retransmission response is not going to fix. > Are we really convinced that the amount of code in terms of > development effort, testing, risk etc to add to handshake protocol to > bring in in-order delivery, reliability, congestion control etc is > less than simply addressing the issues that arise as a result of doing > split channel? It wasn't clear to me that the draft compared the > details involved in the two approaches. It's not addressed in the draft, however we do discuss this point in S 2.2 of our ISOC NDSS paper[2]. The implementation cost of adding the timeout and retransmission is relatively small and there are a number of significant difficulties with using multiple channels, in particular wrt. during-connection rehandshake. -Ekr [1] D. Boneh, H. Shacham, E. Rescorla, "Client Side Caching for TLS", to appear in ACM TISSEC. http://crypto.stanford.edu/~dabo/papers/fasttrack.pdf [2] N. Modadugu and E. Rescorla, "The Design and Implementation of Datagram TLS", Proc ISOC NDSS 2004. http://crypto.stanford.edu/~nagendra/papers/dtls.pdf _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Dec 29 09:42:26 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 JAA12712; Wed, 29 Dec 2004 09:42:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjfD3-0000Iw-9P; Wed, 29 Dec 2004 09:53:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjewX-0007VW-Tn; Wed, 29 Dec 2004 09:36:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjVwj-0004SE-FN for tls@megatron.ietf.org; Wed, 29 Dec 2004 00:00:29 -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 SMTP id AAA03903 for ; Wed, 29 Dec 2004 00:00:26 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 892A410261; Tue, 28 Dec 2004 23:59:58 -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 5C0B7102E1 for ; Tue, 28 Dec 2004 23:59:58 -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 26100-76 for ; Tue, 28 Dec 2004 23:59:45 -0500 (EST) Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by mail.ca.certicom.com (Postfix) with ESMTP id 35D5510261 for ; Tue, 28 Dec 2004 23:59:44 -0500 (EST) Received: by romeo.rtfm.com (Postfix, from userid 1001) id 2FA0A17025; Tue, 28 Dec 2004 20:59:54 -0800 (PST) To: Murali Bashyam References: <3D8E54E3CAA3864295233C618F53F2ADC819C6@exchfour.olympus.f5net.com> <86d5wugwin.fsf@romeo.rtfm.com> <41D1C7DE.6020208@cisco.com> <86k6r2f488.fsf@romeo.rtfm.com> <41D1E445.1000805@cisco.com> From: EKR Date: Tue, 28 Dec 2004 20:59:54 -0800 In-Reply-To: <41D1E445.1000805@cisco.com> (Murali Bashyam's message of "Tue, 28 Dec 2004 14:55:01 -0800") Message-ID: <868y7hg0mt.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Wed, 29 Dec 2004 09:36:51 -0500 Cc: nagendra@cs.standford.edu.cnri.reston.va.us, ietf-tls@lists.certicom.com, tsvwg@ietf.org, Amit Jain Subject: [TLS] Re: [Tsvwg] Looking for feedback on DTLS 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: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Murali Bashyam writes: > EKR wrote: > >>Murali Bashyam writes: >> >>>I had a question on the congestion control aspect of the handshake >>>protocol in DTLS. The draft doesn't seem to address the congestion >>>control requirements of the handshake protocol such as how soon is it >>>okay to send an entire flight of packets into the network without >>>overloading it. >>> >>We suggest a retransmit timer on the order of 500-1000 ms. >> > I was referring more to the TCP capability of slow-start, where TCP > tries to probe the network > and expands its flight of packets gradually as opposed to sending the > entire flight in 1 shot. That's true, but note that the current TCP initial window as specified in RFC 3390 is 3 packets with a 1460-byte MSS and 4 packets with a 512-byte MSS. This looks pretty similar to what you would see out of a DTLS implementation initially (though the TCP implementation would back off faster). > Of course the point which u bring up that the > flight typically fits in 1-2 packets is true for 1500 MSS probably but > when MSS is 512 (the common MSS value on the Internet), this > immediately becomes 6 packets. Well, since we're talking about 2k-sized flights here, it's 4 packets, not 6 for a 512-byte MSS. 512 bytes is actually fairly conservative in the modern network. According to CAIDA's measurements [1], over half the TCP traffic by volume uses a 1500-byte packet size: The primary features of this distribution originate in the way common TCP implementations divide a data stream into packets. Approximately 85% of the traffic in these traces is TCP, and a large proportion of this TCP traffic is generated by bulk transfer applications such as HTTP and FTP. Consequently, the majority of the packets seen are one of three sizes: 40 byte packets (the minimum packet size for TCP) which carry TCP acknowledgments but no payload; 1500 byte packets (the maximum Ethernet payload size) from TCP implementations that use path MTU discovery; and 552 byte and 576 byte packets from TCP implementations that do not use path MTU discovery. > I just want to highlight that by > avoiding TCP for handshaking and implementing retransmissions and > timers solves only the reliability problem but doesn't address > congestion control including efficient retransmission possibilities > too. I don't agree that we're not addressing congestion control. We recommend an initial timer value of 500 ms with a typical doubling exponential backoff with each retransmit. (I know this isn't exactly what I said earlier, but I had to look it up to refresh my memory). Given the small amounts of data involved here, I think that's fairly congestion friendly. As for efficient retransmission, it's true that DTLS could be smarter (though with 1500 byte packets and medium-sized (order 1k) server cert payloads, there's not really much room for improvement) but the overall improvement would be fairly modest and would introduce substantial additional complexity. >>Of course, but we're talking extremely small amounts of data here. >>It's important to remember that in your average SSL handshake the >>total number of bytes exchanged is generally less than 3k and that >>the largest single flight (ServerHello ... ServerHelloDone) is >>typically less than 2k [1]. In most cases it will fit in 1-2 MTUs. >> > True when the MSS is 1500, not when the MSS is negotiated to be > 512. What about large certificates being sent by the server, that > would increase the number of messages? 1k is a fairly large certificate. It's quite uncommon to see a certificate chain larger than two certificates. That's where I got 2k from. -Ekr [1] http://www.caida.org/outreach/papers/2000/AIX0005/AIX0005.html#plen_hist _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Dec 29 09:42:52 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 JAA12772; Wed, 29 Dec 2004 09:42:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjfDT-0000Ja-Vu; Wed, 29 Dec 2004 09:54:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjewY-0007Vb-Bs; Wed, 29 Dec 2004 09:36:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjYRO-0006UO-3G for tls@megatron.ietf.org; Wed, 29 Dec 2004 02:40:18 -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 SMTP id CAA16050 for ; Wed, 29 Dec 2004 02:40:16 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 065C9101FA; Wed, 29 Dec 2004 02:39:47 -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 D05D910211 for ; Wed, 29 Dec 2004 02:39:46 -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 30704-03 for ; Wed, 29 Dec 2004 02:39:35 -0500 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by mail.ca.certicom.com (Postfix) with ESMTP id 16C2F101FA for ; Wed, 29 Dec 2004 02:39:35 -0500 (EST) Received: from jurassic.eng.sun.com ([129.146.17.57]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iBT7dVpv014427; Tue, 28 Dec 2004 23:39:31 -0800 (PST) Received: from [129.158.218.230] (dhcp-cbjs05-218-1.PRC.Sun.COM [129.158.218.230]) by jurassic.eng.sun.com (8.13.2+Sun/8.13.2) with ESMTP id iBT7dTO2169044; Tue, 28 Dec 2004 23:39:30 -0800 (PST) Message-ID: <41D25F20.6070503@Sun.COM> Date: Wed, 29 Dec 2004 15:39:12 +0800 From: Kais Belgaied User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: iesg@ietf.org Subject: Re: [TLS] Last Call: 'Addition of Camellia Ciphersuites to Transport Layer Security (TLS)' to Proposed Standard References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 29 Dec 2004 09:36:51 -0500 Cc: ietf-tls@lists.certicom.com, IETF-Announce X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kais.Belgaied@Sun.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: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit (sorry for the nit-picking) the ({0x00,0x47}-{0x00,0x4D}) range seems available. Any reason for not choosing the *_CAMELLIA_256_* numbers contiguously after the *_CAMELLIA_128_* ones? Kais. The IESG wrote: > The IESG has received a request from the Transport Layer Security WG to > consider the following document: > > - 'Addition of Camellia Ciphersuites to Transport Layer Security (TLS) ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2005-01-10. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-tls-camellia-06.txt > > > _______________________________________________ > 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 Wed Dec 29 09:46: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 JAA13352; Wed, 29 Dec 2004 09:46:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjfH4-0000Qo-Rb; Wed, 29 Dec 2004 09:58:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cjewp-0007XK-E9; Wed, 29 Dec 2004 09:37:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjPRk-0006sg-2D for tls@megatron.ietf.org; Tue, 28 Dec 2004 17:04: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 SMTP id RAA06499 for ; Tue, 28 Dec 2004 17:04:00 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 15F02102B9; Tue, 28 Dec 2004 17:03: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 DA51D102F0 for ; Tue, 28 Dec 2004 17:03:32 -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 24920-52 for ; Tue, 28 Dec 2004 17:03:19 -0500 (EST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.ca.certicom.com (Postfix) with ESMTP id 13F89102B9 for ; Tue, 28 Dec 2004 17:03:19 -0500 (EST) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 28 Dec 2004 14:03:40 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBSM3B05026971; Tue, 28 Dec 2004 14:03:13 -0800 (PST) Received: from cisco.com ([171.69.42.231]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BAD56290; Tue, 28 Dec 2004 13:05:40 -0800 (PST) Message-ID: <41D1C7DE.6020208@cisco.com> Date: Tue, 28 Dec 2004 12:53:50 -0800 From: Murali Bashyam User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: EKR References: <3D8E54E3CAA3864295233C618F53F2ADC819C6@exchfour.olympus.f5net.com> <86d5wugwin.fsf@romeo.rtfm.com> X-Mailman-Approved-At: Wed, 29 Dec 2004 09:37:10 -0500 Cc: nagendra@cs.standford.edu.cnri.reston.va.us, ietf-tls@lists.certicom.com, tsvwg@ietf.org, Amit Jain Subject: [TLS] Re: [Tsvwg] Looking for feedback on DTLS 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="===============0849381921==" Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 2ed9477f79f24ff120e9894ad9dc9cb5 --===============0849381921== Content-Type: multipart/alternative; boundary="------------080407050208020609030607" --------------080407050208020609030607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi I had a question on the congestion control aspect of the handshake protocol in DTLS. The draft doesn't seem to address the congestion control requirements of the handshake protocol such as how soon is it okay to send an entire flight of packets into the network without overloading it. I think there's also a problem in retransmitting the entire flight when 1 packet in that flight from the original transmission got dropped because it starts burdening an already congested network. And it's clear from simulation and experience that it's more efficient to use TCP mechanisms such as SACK/NewReno/Reno to recover from scenarios where multiple packets/single packet drop occurs in that flight of packets. Are we really convinced that the amount of code in terms of development effort, testing, risk etc to add to handshake protocol to bring in in-order delivery, reliability, congestion control etc is less than simply addressing the issues that arise as a result of doing split channel? It wasn't clear to me that the draft compared the details involved in the two approaches. Murali EKR wrote: >"Amit Jain" writes: > > >>I would like to submit following inputs as the feedback: >> >> >Amit, > >Thanks for your comments. Responses below. > > > >>Current draft proposes to add fragmentation, reliability and in-order >>delivery to handshake layer while keeping the record layer mostly >>unchanged. >> >> >That's a fair summary, yes. > > > >>Draft seems to imply that the handshake layer sends a collection of >>handshake messages (referred as flight) and then waits for the other end >>to respond. The timeout causes all the messages in flight to be >>retransmitted. >> >> > >Yes, that's correct. We considered a cumulative ACK as in TCP >(see Section 4.4 of the DTLS paper) but we ultimately decided that >it wouldn't add that much efficiency improvement and it of >course makes life more complicated. Our initial measurements >seem to support that, but it would of course be very easy to >add ACKs later. > > > >>Here the reliability is being tracked for a complete flight of messages >>as a single unit. Given that a flight can have considerable amount of >>data, the probability of packet loss seems to be high. And since each >>packet loss causes complete flight to be retransmitted, this may be a >>large retransmission again. And this may again suffer a packet loss. >> >> > >Yes, that's correct, but it's fairly unlikely to be the SAME packet. >You keep going until you've received all the bytes at least once, >not until a given flight comes through intact. > > > >>Also building the reliability and in-order delivery into handshake layer >>makes handshake state machine complicated. >> >> >Yes, that's correct. However, the complexity is relatively minimal, >at least in our implementation. > > > > >>I think another approach worth considering may be to introduce a thin >>layer inside record layer which takes care of fragmentation, >>reliability, in-order delivery to record layer. In this approach: >> >> >Yes. We considered this approach. However, we were concerned about >designing a generic reliability layer. Designing reliable transport >protocols is difficult, as evidenced by the fact that we're still >working on TCP after 20+ years. Our feeling was that as the only real >requirement was to make the handshake reliable it was best to tie the >reliability into the handshake process and thus avoid the complexity >and rathole potential of trying to design something more >general. Moreover, there is experience with this kind of state machine >from IKE and other similar protocols. > > > >>1: A Handshake message can never span multiple records. A record can >>contain multiple handshake messages though. >> >>This will eliminate the need of handshake message re-assembly. >>Assembling a record will always result in at least one complete >>handshake message or multiple complete handshake messages. >> >> > >Of course. But it will replace it with record reassembly, which >is basically the same problem. > > > > >>This is different from the current specification where the handshake can >>span multiple records. And will need the change in length field of >>record layer (it'll have to be extended to 3 bytes) >> >> > >Just a clarification: you mean "the current TLS specification" here, >correct? TLS currently has this feature. > > > > >>2: Records are fragmented and is converted to UDP datagram. >> >>These UDP data-grams are then transmitted reliably to other end in the >>handshake phase using a very thin layer (built into record layer). It >>may be analogous to a simple reliable variant of UDP (something like >>TFTP). Here the reliability is tracked for each UDP datagram and only >>the missing UDP datagram is re-transmitted. >> >>This may provide following advantages: >> >>1: Handshake layer will be similar to the TLS. There won't be any change >>needed in the implementation of state machine and the specification of >>handshake messages. >> >> >That's sort of correct, except that the handshake state machine >will need to do signalling to the record layer about when it wants >reliability. It's also important to note that the DTLS handshake >reliability layer lives mostly at the level of the DTLS handshake >wrapper. The handshake payloads themselves don't change. > > > >>2: A Record can span multiple UDP packets; this will free DTLS from >>strict need of having a correct path MTU. >> >> >Not really. The DTLS handshake doesn't need an exact PMTU. It >just needs an approximate PMTU estimate to make sure that its own >messages get through. Typically it's the applications which need >a PMTU estimate because they actually want to send data in >a single UDP datagram. That's what their non-DTLS behavior >is, after all. > >Actually, the approach you suggest makes the PTMU problem >worse in some ways. In the current design, the DTLS implementation >can mostly punt the process of PMTU discovery off to the application. >Because the HS is fairly short, it can use a safe PMTU for its >own traffic and then let the application send large messages until >it becomes clear that it can't. This lets the app use PMTU >discovery mechanisms that are better than those described in >RFC 1191. (Note that this isn't exactly what the DTLS draft >says because I just worked it out recently, but it's a fairly >minor change that doesn't affect interop). > >By contrast, if DTLS is in the business of fragmenting data >records, then it has to do so efficiently, which means that >it really needs to know the PMTU. Otherwise, it's at risk >of making fragments that are way too small. I suppose you >could say you'll only fragment handshake records, but that's >kind of a layer violation inside TLS. > > > > >>2: Record layer will consist of a thin reliability layer; this layer >>will be active during handshake phase and will make sure the reliable >>ordered delivery of the handshake messages. During application data >>transfer the reliability part of the record layer is switched off. >> >> >This is actually fairly problematic. Remember that in TLS the >handshake and application data can be interlaced during the >rehandshake process. So, it's not a simple matter of reliability >being "on" or "off". You certainly don't want to suddenly >turn applications that expect unreliable semantics into reliable >ones just because they're rehandshaking. (This is a special >problem if the reliability layer provides in-order delivery as >well, which is what's required if you want to not change the >handshake layer at all). > > > >>(Actually this'll mostly depend on the application, and if application >>wants to use reliability mode of record layer, that should be possible >>too.) >> >> >I think this illustrates the point I made above about genericity. >The transport requirements for the handshake phase of TLS, which >is short and doesn't move a lot of data, are very different from >the requirements for a generic data transport protocol such as >is provided by the DTLS/TLS record layer. If you're going to >use your reliability layer for data, you're going to want much >better efficiency and congestion control guarantees and suddenly >you're reinventing TCP and SCTP. > > > >>3: Having a thin reliability layer in Record layer will allow greater >>flexibility and extensibility. Reliability layer can be replaced with >>other reliability mechanism like DCCP in future for providing >>reliability/congestion control. >> >> > >Well, DCCP wouldn't do the job here since it ONLY provides congestion >control and not reliability. DTLS will of course run fine over DCCP. >It just doesn't make the problem any easier. Michael Tuexen and I >are currently talking about the interaction of DTLS and SCTP, but >I don't think that's a universal solution. > >-Ekr > > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg > > --------------080407050208020609030607 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi

I had a question on the congestion control aspect of the handshake protocol in DTLS. The draft doesn't seem to address the congestion control requirements of the handshake protocol such as how soon is it okay to send an entire flight of packets into the network without overloading it. I think there's also a problem in retransmitting the entire flight when 1 packet in that flight from the original transmission got dropped because it starts burdening an already congested network. And it's clear from simulation and experience that it's more efficient to use TCP mechanisms such  as SACK/NewReno/Reno  to recover from scenarios where multiple packets/single packet drop occurs in that flight of packets.

Are we really convinced that the amount of code in terms of development effort, testing, risk etc to add to handshake protocol to bring in in-order delivery, reliability, congestion control etc is less than simply addressing the issues that arise as a result of doing split channel? It wasn't clear to me that the draft compared the details involved in the two approaches.

Murali

EKR wrote:
"Amit Jain" <a.jain@f5.com> writes:
  
I would like to submit following inputs as the feedback:
    
Amit,

Thanks for your comments. Responses below.

  
Current draft proposes to add fragmentation, reliability and in-order
delivery to handshake layer while keeping the record layer mostly
unchanged. 
    
That's a fair summary, yes.

  
Draft seems to imply that the handshake layer sends a collection of
handshake messages (referred as flight) and then waits for the other end
to respond. The timeout causes all the messages in flight to be
retransmitted. 
    

Yes, that's correct. We considered a cumulative ACK as in TCP
(see Section 4.4 of the DTLS paper) but we ultimately decided that
it wouldn't add that much efficiency improvement and it of
course makes life more complicated. Our initial measurements
seem to support that, but it would of course be very easy to
add ACKs later.

  
Here the reliability is being tracked for a complete flight of messages
as a single unit. Given that a flight can have considerable amount of
data, the probability of packet loss seems to be high. And since each
packet loss causes complete flight to be retransmitted, this may be a
large retransmission again. And this may again suffer a packet loss.
    

Yes, that's correct, but it's fairly unlikely to be the SAME packet.
You keep going until you've received all the bytes at least once,
not until a given flight comes through intact.

  
Also building the reliability and in-order delivery into handshake layer
makes handshake state machine complicated.
    
Yes, that's correct. However, the complexity is relatively minimal,
at least in our implementation. 


  
I think another approach worth considering may be to introduce a thin
layer inside record layer which takes care of fragmentation,
reliability, in-order delivery to record layer. In this approach:
    
Yes. We considered this approach.  However, we were concerned about
designing a generic reliability layer. Designing reliable transport
protocols is difficult, as evidenced by the fact that we're still
working on TCP after 20+ years. Our feeling was that as the only real
requirement was to make the handshake reliable it was best to tie the
reliability into the handshake process and thus avoid the complexity
and rathole potential of trying to design something more
general. Moreover, there is experience with this kind of state machine
from IKE and other similar protocols.

  
1: A Handshake message can never span multiple records. A record can
contain multiple handshake messages though.
 
This will eliminate the need of handshake message re-assembly.
Assembling a record will always result in at least one complete
handshake message or multiple complete handshake messages.
    

Of course. But it will replace it with record reassembly, which
is basically the same problem.


  
This is different from the current specification where the handshake can
span multiple records. And will need the change in length field of
record layer (it'll have to be extended to 3 bytes)
    

Just a clarification: you mean "the current TLS specification" here,
correct? TLS currently has this feature. 


  
2: Records are fragmented and is converted to UDP datagram. 
 
These UDP data-grams are then transmitted reliably to other end in the
handshake phase using a very thin layer (built into record layer). It
may be analogous to a simple reliable variant of UDP (something like
TFTP). Here the reliability is tracked for each UDP datagram and only
the missing UDP datagram is re-transmitted.

This may provide following advantages:
 
1: Handshake layer will be similar to the TLS. There won't be any change
needed in the implementation of state machine and the specification of
handshake messages.
    
That's sort of correct, except that the handshake state machine
will need to do signalling to the record layer about when it wants
reliability. It's also important to note that the DTLS handshake
reliability layer lives mostly at the level of the DTLS handshake
wrapper. The handshake payloads themselves don't change.

  
2: A Record can span multiple UDP packets; this will free DTLS from
strict need of having a correct path MTU.
    
Not really. The DTLS handshake doesn't need an exact PMTU. It
just needs an approximate PMTU estimate to make sure that its own
messages get through. Typically it's the applications which need
a PMTU estimate because they actually want to send data in
a single UDP datagram. That's what their non-DTLS behavior
is, after all.

Actually, the approach you suggest makes the PTMU problem
worse in some ways. In the current design, the DTLS implementation
can mostly punt the process of PMTU discovery off to the application.
Because the HS is fairly short, it can use a safe PMTU for its
own traffic and then let the application send large messages until
it becomes clear that it can't. This lets the app use PMTU
discovery mechanisms that are better than those described in
RFC 1191. (Note that this isn't exactly what the DTLS draft
says because I just worked it out recently, but it's a fairly
minor change that doesn't affect interop).

By contrast, if DTLS is in the business of fragmenting data
records, then it has to do so efficiently, which means that
it really needs to know the PMTU. Otherwise, it's at risk
of making fragments that are way too small. I suppose you
could say you'll only fragment handshake records, but that's
kind of a layer violation inside TLS.


  
2: Record layer will consist of a thin reliability layer; this layer
will be active during handshake phase and will make sure the reliable
ordered delivery of the handshake messages. During application data
transfer the reliability part of the record layer is switched off.
    
This is actually fairly problematic. Remember that in TLS the
handshake and application data can be interlaced during the
rehandshake process. So, it's not a simple matter of reliability
being "on" or "off". You certainly don't want to suddenly
turn applications that expect unreliable semantics into reliable
ones just because they're rehandshaking. (This is a special
problem if the reliability layer provides in-order delivery as
well, which is what's required if you want to not change the
handshake layer at all).

  
(Actually this'll mostly depend on the application, and if application
wants to use reliability mode of record layer, that should be possible
too.)
    
I think this illustrates the point I made above about genericity.
The transport requirements for the handshake phase of TLS, which
is short and doesn't move a lot of data, are very different from
the requirements for a generic data transport protocol such as
is provided by the DTLS/TLS record layer. If you're going to
use your reliability layer for data, you're going to want much
better efficiency and congestion control guarantees and suddenly
you're reinventing TCP and SCTP.

  
3: Having a thin reliability layer in Record layer will allow greater
flexibility and extensibility. Reliability layer can be replaced with
other reliability mechanism like DCCP in future for providing
reliability/congestion control.
    

Well, DCCP wouldn't do the job here since it ONLY provides congestion
control and not reliability. DTLS will of course run fine over DCCP.
It just doesn't make the problem any easier. Michael Tuexen and I
are currently talking about the interaction of DTLS and SCTP, but
I don't think that's a universal solution.
   
-Ekr


_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg

--------------080407050208020609030607-- --===============0849381921== 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 --===============0849381921==-- From tls-bounces@ietf.org Wed Dec 29 09:48:50 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 JAA13581; Wed, 29 Dec 2004 09:48:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjfJH-0000XY-1c; Wed, 29 Dec 2004 10:00:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cjewp-0007XP-SA; Wed, 29 Dec 2004 09:37:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjQFo-0000vM-Vx for tls@megatron.ietf.org; Tue, 28 Dec 2004 17:55:49 -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 SMTP id RAA10560 for ; Tue, 28 Dec 2004 17:55:45 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 36B9710104; Tue, 28 Dec 2004 17:55:18 -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 06E49102E2 for ; Tue, 28 Dec 2004 17:55:18 -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 25665-41 for ; Tue, 28 Dec 2004 17:55:06 -0500 (EST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.ca.certicom.com (Postfix) with ESMTP id AFAE710104 for ; Tue, 28 Dec 2004 17:55:05 -0500 (EST) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 28 Dec 2004 14:55:50 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iBSMt1e6023059; Tue, 28 Dec 2004 14:55:02 -0800 (PST) Received: from cisco.com ([171.69.42.231]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BAD64374; Tue, 28 Dec 2004 15:06:52 -0800 (PST) Message-ID: <41D1E445.1000805@cisco.com> Date: Tue, 28 Dec 2004 14:55:01 -0800 From: Murali Bashyam User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: EKR References: <3D8E54E3CAA3864295233C618F53F2ADC819C6@exchfour.olympus.f5net.com> <86d5wugwin.fsf@romeo.rtfm.com> <41D1C7DE.6020208@cisco.com> <86k6r2f488.fsf@romeo.rtfm.com> X-Mailman-Approved-At: Wed, 29 Dec 2004 09:37:10 -0500 Cc: nagendra@cs.standford.edu.cnri.reston.va.us, ietf-tls@lists.certicom.com, tsvwg@ietf.org, Amit Jain Subject: [TLS] Re: [Tsvwg] Looking for feedback on DTLS 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="===============1215153446==" Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b --===============1215153446== Content-Type: multipart/alternative; boundary="------------010006020508060300010608" --------------010006020508060300010608 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit EKR wrote: >Murali Bashyam writes: > > >>I had a question on the congestion control aspect of the handshake >>protocol in DTLS. The draft doesn't seem to address the congestion >>control requirements of the handshake protocol such as how soon is it >>okay to send an entire flight of packets into the network without >>overloading it. >> >> >We suggest a retransmit timer on the order of 500-1000 ms. > I was referring more to the TCP capability of slow-start, where TCP tries to probe the network and expands its flight of packets gradually as opposed to sending the entire flight in 1 shot. Of course the point which u bring up that the flight typically fits in 1-2 packets is true for 1500 MSS probably but when MSS is 512 (the common MSS value on the Internet), this immediately becomes 6 packets. I just want to highlight that by avoiding TCP for handshaking and implementing retransmissions and timers solves only the reliability problem but doesn't address congestion control including efficient retransmission possibilities too. > > > >>I think there's also a problem in retransmitting the >>entire flight when 1 packet in that flight from the original >>transmission got dropped because it starts burdening an already >>congested network. And it's clear from simulation and experience that >>it's more efficient to use TCP mechanisms such as SACK/NewReno/Reno >>to recover from scenarios where multiple packets/single packet drop >>occurs in that flight of packets. >> >> > >Of course, but we're talking extremely small amounts of data here. >It's important to remember that in your average SSL handshake the >total number of bytes exchanged is generally less than 3k and that >the largest single flight (ServerHello ... ServerHelloDone) is >typically less than 2k [1]. In most cases it will fit in 1-2 MTUs. > True when the MSS is 1500, not when the MSS is negotiated to be 512. What about large certificates being sent by the server, that would increase the number of messages? Murali > >Obviously, one could optimize this interaction some, but if you're >in a situation where DTLS handshakes represent a significant fraction >of your network congestion, you've got some really serious problems >that marginally better retransmission response is not going to fix. > > > >>Are we really convinced that the amount of code in terms of >>development effort, testing, risk etc to add to handshake protocol to >>bring in in-order delivery, reliability, congestion control etc is >>less than simply addressing the issues that arise as a result of doing >>split channel? It wasn't clear to me that the draft compared the >>details involved in the two approaches. >> >> > >It's not addressed in the draft, however we do discuss this point in >S 2.2 of our ISOC NDSS paper[2]. The implementation cost of >adding the timeout and retransmission is relatively small and there >are a number of significant difficulties with using multiple channels, >in particular wrt. during-connection rehandshake. > >-Ekr > > >[1] D. Boneh, H. Shacham, E. Rescorla, "Client Side Caching for TLS", >to appear in ACM TISSEC. >http://crypto.stanford.edu/~dabo/papers/fasttrack.pdf > >[2] N. Modadugu and E. Rescorla, "The Design and Implementation of >Datagram TLS", Proc ISOC NDSS 2004. >http://crypto.stanford.edu/~nagendra/papers/dtls.pdf > > --------------010006020508060300010608 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

EKR wrote:
Murali Bashyam <mbashyam@cisco.com> writes:
  
I had a question on the congestion control aspect of the handshake
protocol in DTLS. The draft doesn't seem to address the congestion
control requirements of the handshake protocol such as how soon is it
okay to send an entire flight of packets into the network without
overloading it.
    
We suggest a retransmit timer on the order of 500-1000 ms.
I was referring more to the TCP capability of slow-start, where TCP tries to probe the network
and expands its flight of packets gradually as opposed to sending the entire flight in 1 shot. Of course the point which u bring up that the flight typically fits in 1-2 packets is true for 1500 MSS probably but when MSS is 512 (the common MSS value on the Internet), this immediately becomes 6 packets.  I just want to highlight that by avoiding TCP for handshaking and implementing retransmissions and timers solves only the reliability problem but doesn't address congestion control including efficient retransmission possibilities too.

  
I think there's also a problem in retransmitting the
entire flight when 1 packet in that flight from the original
transmission got dropped because it starts burdening an already
congested network. And it's clear from simulation and experience that
it's more efficient to use TCP mechanisms such  as SACK/NewReno/Reno
to recover from scenarios where multiple packets/single packet drop
occurs in that flight of packets.
    

Of course, but we're talking extremely small amounts of data here.
It's important to remember that in your average SSL handshake the
total number of bytes exchanged is generally less than 3k and that
the largest single flight (ServerHello ... ServerHelloDone) is
typically less than 2k [1]. In most cases it will fit in 1-2 MTUs.
True when the MSS is 1500, not when the MSS is negotiated to be 512. What about large certificates being sent by the server, that would increase the number of messages?

Murali

Obviously, one could optimize this interaction some, but if you're
in a situation where DTLS handshakes represent a significant fraction
of your network congestion, you've got some really serious problems
that marginally better retransmission response is not going to fix.

  
Are we really convinced that the amount of code in terms of
development effort, testing, risk etc to add to handshake protocol to
bring in in-order delivery, reliability, congestion control etc is
less than simply addressing the issues that arise as a result of doing
split channel? It wasn't clear to me that the draft compared the
details involved in the two approaches.
    

It's not addressed in the draft, however we do discuss this point in
S 2.2 of our ISOC NDSS paper[2]. The implementation cost of
adding the timeout and retransmission is relatively small and there
are a number of significant difficulties with using multiple channels,
in particular wrt. during-connection rehandshake.

-Ekr


[1] D. Boneh, H. Shacham, E. Rescorla, "Client Side Caching for TLS",
to appear in ACM TISSEC. 
http://crypto.stanford.edu/~dabo/papers/fasttrack.pdf

[2] N. Modadugu and E. Rescorla, "The Design and Implementation of
Datagram TLS", Proc ISOC NDSS 2004.
http://crypto.stanford.edu/~nagendra/papers/dtls.pdf

--------------010006020508060300010608-- --===============1215153446== 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 --===============1215153446==-- From tls-bounces@ietf.org Wed Dec 29 22:49:36 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 WAA16582; Wed, 29 Dec 2004 22:49:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjrUx-0003Xa-Qb; Wed, 29 Dec 2004 23:01:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjrDF-000790-55; Wed, 29 Dec 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 1Cjkfg-0003Ul-Jo for tls@megatron.ietf.org; Wed, 29 Dec 2004 15:43:52 -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 SMTP id PAA09576 for ; Wed, 29 Dec 2004 15:43:50 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id C7576103EC; Wed, 29 Dec 2004 15:43:21 -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 8ED91103EE for ; Wed, 29 Dec 2004 15:43:21 -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 31349-94 for ; Wed, 29 Dec 2004 15:43:10 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.ca.certicom.com (Postfix) with ESMTP id D301E103EC for ; Wed, 29 Dec 2004 15:43:09 -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 PAA09543; Wed, 29 Dec 2004 15:43:07 -0500 (EST) Message-Id: <200412292043.PAA09543@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 29 Dec 2004 15:43:07 -0500 X-Mailman-Approved-At: Wed, 29 Dec 2004 22:42:53 -0500 Cc: ietf-tls@lists.certicom.com Subject: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.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: 14582b0692e7f70ce7111d04db3781c8 --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 : Transport Layer Security (TLS) Extensions Author(s) : S. Blake-Wilson, et al. Filename : draft-ietf-tls-rfc3546bis-00.txt Pages : 29 Date : 2004-12-29 This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc3546bis-00.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-rfc3546bis-00.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-rfc3546bis-00.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-12-29154122.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-rfc3546bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-rfc3546bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-29154122.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 Thu Dec 30 10:40:09 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 KAA21901; Thu, 30 Dec 2004 10:40:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ck2ah-00036f-ME; Thu, 30 Dec 2004 10:51:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ck2NY-0001NS-Bu; Thu, 30 Dec 2004 10:38:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ck2Jn-0000jg-6p for tls@megatron.ietf.org; Thu, 30 Dec 2004 10:34:27 -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 KAA21622 for ; Thu, 30 Dec 2004 10:34:25 -0500 (EST) Received: from tomts16.bellnexxia.net ([209.226.175.4] helo=tomts16-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ck2V9-0002zS-0t for tls@ietf.org; Thu, 30 Dec 2004 10:46:11 -0500 Received: from simon ([64.231.75.133]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20041230153421.EULC1836.tomts16-srv.bellnexxia.net@simon> for ; Thu, 30 Dec 2004 10:34:21 -0500 From: "Simon Blake-Wilson" To: Subject: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt Date: Thu, 30 Dec 2004 10:34:06 -0500 Message-ID: <005f01c4ee85$03058150$c500a8c0@simon> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 2.2 (++) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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: 2.2 (++) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Hi folks, We just posted an internet-draft updating the extensions RFC to deal = with the issue of which documents can define new extensions - the current RFC allows only standards track RFCs while this draft allows any RFC based = on IETF consensus (which basically means IESG review). I've summarized the detailed list of changes below. Eric/Win ... How do you want to handle this? Given the minor nature of = the updates, can we proceed with working group last call on this (and the = ECC in TLS draft)? Best regards. Simon=20 Here's a summary of the changes: - Assignment of ExtensionType values handed over to IANA. New values can = be assigned only via the IETF Consensus process. (This means that an RFC is required and the RFC must have undergone IESG review.) This affects = Section 2.3, Section 5, and Section 8. - The text concerning handling of extensions during session resumption requests has been clarified since the previous text was ambiguous, and = it would be bad to have to update the RFC again to deal with any RFCs that = come along and need clarity on this. This affects the last paragraph of = Section 2.3 and the third paragraph of Section 3. There are also a few minor editorial changes - updating references, = author addresses and the like. > -----Original Message----- > From: tls-bounces@lists.ietf.org=20 > [mailto:tls-bounces@lists.ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: Wednesday, December 29, 2004 3:43 PM > To: i-d-announce@ietf.org > Cc: ietf-tls@lists.certicom.com > Subject: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. This draft is a work item of the=20 > Transport Layer Security Working Group of the IETF. >=20 > Title : Transport Layer Security (TLS) Extensions > Author(s) : S. Blake-Wilson, et al. > Filename : draft-ietf-tls-rfc3546bis-00.txt > Pages : 29 > Date : 2004-12-29 > =09 > This document describes extensions that may be used to add > functionality to Transport Layer Security (TLS). It provides both > generic extension mechanisms for the TLS handshake client=20 > and server > hellos, and specific extensions using these generic mechanisms. >=20 > A URL for this Internet-Draft is:=20 > http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc3546bis-00.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of the message. =20 > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-tls-rfc3546bis-00.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-tls-rfc3546bis-00.txt". > =09 > 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=20 > 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. > =09 > =09 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Dec 30 11:02:44 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 LAA23304; Thu, 30 Dec 2004 11:02:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ck2wZ-0003dU-2e; Thu, 30 Dec 2004 11:14:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ck2hC-0005nb-Gs; Thu, 30 Dec 2004 10:58:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ck2dQ-000555-Up for tls@megatron.ietf.org; Thu, 30 Dec 2004 10:54: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 KAA22687 for ; Thu, 30 Dec 2004 10:54:42 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ck2om-0003Qe-Os for tls@ietf.org; Thu, 30 Dec 2004 11:06:29 -0500 Received: by romeo.rtfm.com (Postfix, from userid 1001) id AB80817029; Thu, 30 Dec 2004 07:54:22 -0800 (PST) To: "Simon Blake-Wilson" Subject: Re: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt References: <005f01c4ee85$03058150$c500a8c0@simon> From: EKR Date: Thu, 30 Dec 2004 07:54:22 -0800 In-Reply-To: <005f01c4ee85$03058150$c500a8c0@simon> (Simon Blake-Wilson's message of "Thu, 30 Dec 2004 10:34:06 -0500") Message-ID: <861xd7g4sx.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) 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: 08170828343bcf1325e4a0fb4584481c 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: 79899194edc4f33a41f49410777972f8 "Simon Blake-Wilson" writes: > We just posted an internet-draft updating the extensions RFC to deal with > the issue of which documents can define new extensions - the current RFC > allows only standards track RFCs while this draft allows any RFC based on > IETF consensus (which basically means IESG review). > > I've summarized the detailed list of changes below. > > Eric/Win ... How do you want to handle this? Given the minor nature of the > updates, can we proceed with working group last call on this (and the ECC in > TLS draft)? Given the holidays, etc. let's see what people have to say over the next few weeks. If there are no substantive comments I'll initiate WGLC. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Dec 30 18:41:58 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 SAA28703; Thu, 30 Dec 2004 18:41:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkA72-0007aS-Vx; Thu, 30 Dec 2004 18:53:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ck9rY-0004uM-R9; Thu, 30 Dec 2004 18:37:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ck8uB-0001wn-I2 for tls@megatron.ietf.org; Thu, 30 Dec 2004 17:36:27 -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 SMTP id RAA23668 for ; Thu, 30 Dec 2004 17:36:24 -0500 (EST) Received: by mail.ca.certicom.com (Postfix) id 68AAA10120; Thu, 30 Dec 2004 17:35:56 -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 37A961041F for ; Thu, 30 Dec 2004 17:35:56 -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 09692-91 for ; Thu, 30 Dec 2004 17:35:45 -0500 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by mail.ca.certicom.com (Postfix) with ESMTP id 1769C10120 for ; Thu, 30 Dec 2004 17:35:45 -0500 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1Ck8tU-000JQR-C3 for ietf-tls@lists.certicom.com; Thu, 30 Dec 2004 17:35:44 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iBUMZhc24743 for ; Thu, 30 Dec 2004 14:35:43 -0800 Date: Thu, 30 Dec 2004 14:35:43 -0800 (PST) From: Bernard Aboba To: ietf-tls@lists.certicom.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Mailman-Approved-At: Thu, 30 Dec 2004 18:37:48 -0500 Subject: [TLS] Re: PSK question 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: 769a46790fb42fbb0b0cc700c82f7081 I am also concerned about the interoperability of the client/server identity exchange specified in draft-ietf-tls-psk-05.txt. In reading the posts by Peter Gutmann, I find the arguments persuasive: http://www.imc.org/ietf-tls/mail-archive/msg04402.html http://www.imc.org/ietf-tls/mail-archive/msg04418.html I'd suggest that this issue needs to be addressed before this specification can progress. The following potential problems come to mind: a. Generality. On reading the discussion, it would appear that this facility was designed for use within 3GPP, where the "hint" refers to the "bootstrapping" function used to bootstrap the shared key between client and server. However, I believe that IETF specifications should also be able to interoperate widely so that they can be used on the Internet. I'm not clear that the current specification will interoperate. For example, if the spec is going to support multiple ID formats, then support for various formats should be negotiated. b. Compatibility with existing specifications. One of the major uses of this specification is in WLAN authentication. However, mandating at least one form for the client identifier, it is not clear how wecan guarantee conformance to RFC 2486, which standardizes the format of the Network Access Identifier (NAI). c. Difficulties in operation with AAA. Without mandating at least one form for the server identifier, it is not clear to me how a client can unambiguously identify what server it is talking to. It is quite possible that AAA servers will not be synchronized with respect to their session caches, or even the pre-shared keys to be utilized (e.g. LDAP directory synchronization can lag behind), so that this could be a problem. d. IPR disclosure. IPR has been filed relating to "hint" mechanisms: http://www.ietf.org/ietf/IPR/telecom-italia-ipr-wlan-access.txt I am therefore concerned that making "hints" an integral part of this specification will create problems with encumbrance. This problem can be avoided by clearly mandating support for certain client and serverid formats. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Dec 31 11:29: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 LAA09360; Fri, 31 Dec 2004 11:29:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkPqB-00047a-8M; Fri, 31 Dec 2004 11:41:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkPRd-0005kK-BI; Fri, 31 Dec 2004 11:16:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkMaP-000888-1v for tls@megatron.ietf.org; Fri, 31 Dec 2004 08:12:57 -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 SMTP id IAA25994 for ; Fri, 31 Dec 2004 08:12:55 -0500 (EST) From: Pasi.Eronen@nokia.com Received: by mail.ca.certicom.com (Postfix) id 517F9101A6; Fri, 31 Dec 2004 08:12:25 -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 2243510087 for ; Fri, 31 Dec 2004 08:12:25 -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 20492-18 for ; Fri, 31 Dec 2004 08:12:14 -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 48843101A6 for ; Fri, 31 Dec 2004 08:12:13 -0500 (EST) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iBVDC3q22590; Fri, 31 Dec 2004 15:12:04 +0200 (EET) X-Scanned: Fri, 31 Dec 2004 15:11:23 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iBVDBNGS016181; Fri, 31 Dec 2004 15:11:23 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00mxBbCg; Fri, 31 Dec 2004 15:11:23 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 iBVDBNx29526; Fri, 31 Dec 2004 15:11:23 +0200 (EET) Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 31 Dec 2004 15:11:17 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 31 Dec 2004 15:11:16 +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] Re: PSK question Date: Fri, 31 Dec 2004 15:11:17 +0200 Message-ID: <125EA890549C8641A72F3809CB80DCCD1783F1@esebe056.ntc.nokia.com> Thread-Topic: [TLS] Re: PSK question Thread-Index: AcTuyUn/sP4PiEHASveOguxY5y5YBwAbI97Q To: , X-OriginalArrivalTime: 31 Dec 2004 13:11:16.0969 (UTC) FILETIME=[36334D90:01C4EF3A] Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 31 Dec 2004 11:16:02 -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 Bernard Aboba wrote: >=20 > I am also concerned about the interoperability of the > client/server identity exchange specified in=20 > draft-ietf-tls-psk-05.txt. Thanks for your comments, Bernard! > In reading the posts by Peter Gutmann, I find the arguments=20 > persuasive: >=20 > http://www.imc.org/ietf-tls/mail-archive/msg04402.html > http://www.imc.org/ietf-tls/mail-archive/msg04418.html >=20 > I'd suggest that this issue needs to be addressed before this > specification can progress. >=20 > The following potential problems come to mind: >=20 > a. Generality. On reading the discussion, it would appear > that this facility was designed for use within 3GPP, where the > "hint" refers to the "bootstrapping" function used to > bootstrap the shared key between client and server. However, > I believe that IETF specifications should also be able to > interoperate widely so that they can be used on the Internet. > I'm not clear that the current specification will > interoperate. For example, if the spec is going to support > multiple ID formats, then support for various formats should > be negotiated. TLS-PSK alone does not do anything useful, and cannot be used by itself: it's always a component in a larger system. It is these systems that either interoperate or don't. So if e.g. 3GPP runs protocol FOO over TLS (using PSK ciphersuites), there's no need (or possibility) to interoperate with someone running a different protocol BAR over TLS.=20 The approach so far has been to put only the common parts in=20 TLS specs (RFC 2246, 2712, etc.) and application-specific parts=20 elsewhere. For some uses of TLS, we have separate documents=20 (like RFC 2595 for IMAP/POP-over-TLS, RFC 2818 for HTTP-over-TLS); others specify TLS details together with the rest of the protocol=20 (e.g. RFC 2716 for EAP-TLS, RFC 3788 for SIGTRAN). These TLS=20 details include, among other things, what ciphersuites and what=20 kind of identifiers (e.g. dNSName SubjectAltName) should be be=20 used (and we don't have negotiation for these either). I think this approach has worked so far with other TLS=20 ciphersuites, and I don't see any special reason why it would=20 fail especially with PSK ciphersuites...? > b. Compatibility with existing specifications. One of the > major uses of this specification is in WLAN authentication. > However, mandating at least one form for the client > identifier, it is not clear how we can guarantee conformance to > RFC 2486, which standardizes the format of the Network Access > Identifier (NAI). Agreed; I just think the right place to mandate this is in the "upper layer protocol" using TLS (in this case, EAP-TLS), not the TLS specs. > c. Difficulties in operation with AAA. Without mandating at > least one form for the server identifier, it is not clear to > me how a client can unambiguously identify what server it is > talking to. It is quite possible that AAA servers will not be > synchronized with respect to their session caches, or even the > pre-shared keys to be utilized (e.g. LDAP directory > synchronization can lag behind), so that this could be a > problem. This problem also seems related to one specific application (EAP-TLS) that uses TLS, not TLS itself. > d. IPR disclosure. IPR has been filed relating to "hint" > mechanisms: > http://www.ietf.org/ietf/IPR/telecom-italia-ipr-wlan-access.txt > I am therefore concerned that making "hints" an integral part > of this specification will create problems with encumbrance. > This problem can be avoided by clearly mandating support for > certain client and serverid formats. The IPR disclosure is related to network discovery and selection, and does not mention the word "hint" anywhere. Best regards & Happy New Year, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls