From tls-bounces@lists.ietf.org Mon Jan 02 11:44:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtSnd-0004Yr-1R; Mon, 02 Jan 2006 11:44:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtSnY-0004Xv-Av for tls@megatron.ietf.org; Mon, 02 Jan 2006 11:44:42 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18903 for ; Mon, 2 Jan 2006 11:43:26 -0500 (EST) Message-Id: <200601021643.LAA18903@ietf.org> Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EtSnV-000DWS-L9; Mon, 02 Jan 2006 16:44:37 +0000 To: tls@ietf.org Date: Mon, 02 Jan 2006 08:44:37 -0800 From: Allison Mankin Cc: lennox@cs.columbia.edu, hartmans+ietf@mit.edu, mmusic@ietf.org, jon.peterson@neustar.biz Subject: [TLS] Brief Cross-WG review - draft-ietf-mmusic-comedia-tls X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mankin@psg.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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org The Multiparty Multimedia Session Control (MMUSIC) WG has completed IETF Last Call on a document related to TLS called : Connection-Oriented Media Transport over the TLS Protocol in the Session Descriptoin Protocol (SDP) draft-ietf-mmusic-comedia-tls-05.txt comedia stands for connected media We (Sec ADs, TSV ADs) realized we should have the TLS WG give a quick review of the document, since there hasn't been a look by this working group, though there have been reviews by security experts with some TLS expertise. This document is a dependency for three others, and it is being reviewed by the IESG on Thursday. In the busy-ness of the holidays I wrote this message on Dec 26th, but did not notice when an SMTP hiccup caused the email not to go before I went with my family for some email-free holiday (just back). If it's possible for someone give the draft a read this week despite the short notice, that would be appreciated. Allison _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 02 11:54:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtSx3-0001oZ-TC; Mon, 02 Jan 2006 11:54:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtSx1-0001oC-6c; Mon, 02 Jan 2006 11:54:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19817; Mon, 2 Jan 2006 11:53:13 -0500 (EST) Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtT24-0006Ot-Vb; Mon, 02 Jan 2006 11:59:44 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 2B2011E8C4C; Mon, 2 Jan 2006 08:54:14 -0800 (PST) To: mankin@psg.com Subject: Re: [TLS] Brief Cross-WG review - draft-ietf-mmusic-comedia-tls References: <200601021643.LAA18903@ietf.org> From: Eric Rescorla Date: Mon, 02 Jan 2006 08:54:14 -0800 In-Reply-To: <200601021643.LAA18903@ietf.org> (Allison Mankin's message of "Mon, 02 Jan 2006 08:44:37 -0800") Message-ID: <86u0cm8tah.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: lennox@cs.columbia.edu, hartmans+ietf@mit.edu, tls@ietf.org, jon.peterson@neustar.biz, mmusic@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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Allison Mankin writes: > The Multiparty Multimedia Session Control (MMUSIC) WG > has completed IETF Last Call on a document related to TLS > called : > > Connection-Oriented Media Transport over the TLS > Protocol in the Session Descriptoin Protocol (SDP) > draft-ietf-mmusic-comedia-tls-05.txt > > comedia stands for connected media > > We (Sec ADs, TSV ADs) realized we should have the TLS WG > give a quick review of the document, since there hasn't > been a look by this working group, though there > have been reviews by security experts with some TLS > expertise. > > This document is a dependency for three others, and > it is being reviewed by the IESG on Thursday. In the > busy-ness of the holidays I wrote this message on Dec > 26th, but did not notice when an SMTP hiccup caused the > email not to go before I went with my family for some > email-free holiday (just back). If it's possible for > someone give the draft a read this week despite the short > notice, that would be appreciated. I'll take the action item to do this by COB Wed. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 02 14:36:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtVTz-0001Qg-K4; Mon, 02 Jan 2006 14:36:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtVTx-0001Pv-Ix; Mon, 02 Jan 2006 14:36:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06498; Mon, 2 Jan 2006 14:35:24 -0500 (EST) Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtVZ4-0002lI-Ri; Mon, 02 Jan 2006 14:41:56 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 017A61E8C4C; Mon, 2 Jan 2006 11:36:18 -0800 (PST) To: mankin@psg.com Subject: Re: [TLS] Brief Cross-WG review - draft-ietf-mmusic-comedia-tls References: <200601021643.LAA18903@ietf.org> From: Eric Rescorla Date: Mon, 02 Jan 2006 11:36:18 -0800 In-Reply-To: <200601021643.LAA18903@ietf.org> (Allison Mankin's message of "Mon, 02 Jan 2006 08:44:37 -0800") Message-ID: <86psna8lsd.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: lennox@cs.columbia.edu, hartmans+ietf@mit.edu, tls@ietf.org, jon.peterson@neustar.biz, mmusic@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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Review of draft-ietf-mmusic-comedia-tls-05 SUMMARY This draft describes how to use SDP to describe TLS connection-oriented media sessions. The major new thing is putting certificate fingerprints in the SDP m-line so that as long as you have signalling integrity you can prevent MITM attacks without 3rd party certificates. This draft seems like a good idea and the implementation seems basically solid, modulo the comments below. S 5: I agree that it's fine to use the same hash as was used to generate the certificate, but I think you need to explain why it's OK here or in the security considerations section. The key point is that the same security properties are required of the hash here as in the certificate signature. S 6.1: This text seems to imply that you need to have a valid identity in the certificate even if it's self-signed and used with a fingerprint. From a security perspective, that doesn't really add any value, since it's the fingerprint, not the identity, that provides security. S 6.2: certificate does not match the provided fingerprint, or, if there was no fingerprint, the certificate identity is incorrect, the server endpoint MUST either notify the user or terminate the media connection with a bad certificate error. I assume you mean "bad_certificate" here. Also, why are you generating that if no fingerprint is provided? That's not a TLS-level error, it's an error at the upper layer protocol. You shouldn't even be negotiating TLS if there's no fingerprint. Note that when the offer/answer model is being used, it is possible for a media connection to outrace the answer back to the offerer. Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass' role, it MUST (as specified in the Connection-Oriented Media specification [2]) begin listening for an incoming connection as soon as it sends its offer. However, because its peer's media connection may outrace its answer, it MUST NOT definitively accept the peer's certificate until it has received and processed the SDP answer. What does "definitively accept" mean here. What I would assume would be that you would let the TLS handshake complete but then defer some other action till you had the fingrerprint. But what action? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 02 20:22:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtasM-0001UM-Gi; Mon, 02 Jan 2006 20:22:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtasK-0001U3-Ny; Mon, 02 Jan 2006 20:22:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06616; Mon, 2 Jan 2006 20:20:55 -0500 (EST) Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtaxV-0004IT-UD; Mon, 02 Jan 2006 20:27:30 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id BD95A1E8C4C; Mon, 2 Jan 2006 17:21:58 -0800 (PST) To: Jonathan Lennox Subject: Re: [TLS] Brief Cross-WG review - draft-ietf-mmusic-comedia-tls References: <200601021643.LAA18903@ietf.org> <86psna8lsd.fsf@raman.networkresonance.com> <17337.52920.343464.422053@metro-north.cs.columbia.edu> From: Eric Rescorla Date: Mon, 02 Jan 2006 17:21:58 -0800 In-Reply-To: <17337.52920.343464.422053@metro-north.cs.columbia.edu> (Jonathan Lennox's message of "Mon, 2 Jan 2006 20:09:12 -0500") Message-ID: <86lkxy85s9.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: jon.peterson@neustar.biz, hartmans+ietf@mit.edu, tls@ietf.org, mmusic@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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Jonathan Lennox writes: >> S 5: >> I agree that it's fine to use the same hash as was used to >> generate the certificate, but I think you need to explain >> why it's OK here or in the security considerations section. >> The key point is that the same security properties are required >> of the hash here as in the certificate signature. > > Good point. > > The other motivation is that the fingerprint be usable by the recipient so > long as the certificate itself is. Understood. I just think you need to explain this in the ID :) >> S 6.1: >> This text seems to imply that you need to have a valid identity >> in the certificate even if it's self-signed and used with a >> fingerprint. From a security perspective, that doesn't really >> add any value, since it's the fingerprint, not the identity, >> that provides security. > > The motivation here was to allow SSH-style security (per-endpoint credential > cacheing) if the SDP isn't secured, or is only secured hop-by-hop. Perhaps > this isn't useful? Sorry, I still don't understand how this requires having a valid identity. If you're doing ssh doesn't that imply that the cert isn't signed by a valid signer, in which case whatever's in the cert DN or subjectAltName is pretty meaningless, right? >> Note that when the offer/answer model is being used, it is possible >> for a media connection to outrace the answer back to the offerer. >> Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass' >> role, it MUST (as specified in the Connection-Oriented Media >> specification [2]) begin listening for an incoming connection as soon >> as it sends its offer. However, because its peer's media connection >> may outrace its answer, it MUST NOT definitively accept the peer's >> certificate until it has received and processed the SDP answer. >> >> What does "definitively accept" mean here. What I would assume would >> be that you would let the TLS handshake complete but then defer >> some other action till you had the fingrerprint. But what action? > > I'm not sure. Perhaps this should be re-worded as "it MUST NOT > assume the data transmitted over the TLS connection is valid until > it has received a matching fingerprint in the SDP answer. If the > received fingerprint is invalid, the TLS connection SHOULD be torn > down." (Is there an appropriate TLS message for "I just discovered > your certificate is invalid"?) I don't see anywhere in RFC 2246 which restricts you from sending bad_certificate outside the handshake, so I think you would probably use that alert. > One other question -- in the IESG review, the issue was raised that > there's not currently an IANA registry for textual names of hash > functions. I agreed to add an IANA considerations section for this > purpose, but I was wondering if there's interest in having this > registry be more broadly scoped than just for comedia-tls? Well, as far as TLS goes, we only use integer code points, so this wouldn't buy us anything, but speaking personally I think this would be a good idea. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jan 03 12:46:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtqET-00084G-MC; Tue, 03 Jan 2006 12:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtqER-00082t-Lj; Tue, 03 Jan 2006 12:45:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01321; Tue, 3 Jan 2006 12:44:45 -0500 (EST) Message-Id: <200601031744.MAA01321@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtqJj-0004Ge-LZ; Tue, 03 Jan 2006 12:51:29 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EtqEM-0009ee-Vq; Tue, 03 Jan 2006 17:45:54 +0000 To: Eric Rescorla Subject: Re: [TLS] Brief Cross-WG review - draft-ietf-mmusic-comedia-tls Date: Tue, 03 Jan 2006 09:45:54 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Jonathan Lennox , hartmans+ietf@mit.edu, tls@ietf.org, jon.peterson@neustar.biz, mmusic@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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org > > > One other question -- in the IESG review, the issue was raised that > > there's not currently an IANA registry for textual names of hash > > functions. I agreed to add an IANA considerations section for this > > purpose, but I was wondering if there's interest in having this > > registry be more broadly scoped than just for comedia-tls? > > Well, as far as TLS goes, we only use integer code points, so this > wouldn't buy us anything, but speaking personally I think this > would be a good idea. Ekr, I somehow missed Jonathan's original question about this. I'll support making this registry broad-based as long as we don't have to troubleshoot it a lot from the security side. Essentially this is going to be an IANA space for SDP-folk determined names of the algorithms from RFCs 3280 and 4055 (and later, any RFCs which update 4055). The reason I don't want to use the broad registry if it entails debugging is that it's not very likely to be in the consciousness of future security developers, not being integrated into a reference security RFC, and there's not much precedent (if any) for using the same registry for multiple protocols. Allison _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jan 03 14:03:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtrRW-0007H2-VX; Tue, 03 Jan 2006 14:03:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtrRU-0007Gu-Vf; Tue, 03 Jan 2006 14:03:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13063; Tue, 3 Jan 2006 14:02:18 -0500 (EST) Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtrWo-0007MX-Qv; Tue, 03 Jan 2006 14:09:04 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 55EA31E8C4C; Tue, 3 Jan 2006 11:03:20 -0800 (PST) To: Allison Mankin Subject: Re: [TLS] Brief Cross-WG review - draft-ietf-mmusic-comedia-tls References: <20060103174729.5D0CF222418@laser.networkresonance.com> From: Eric Rescorla Date: Tue, 03 Jan 2006 11:03:20 -0800 In-Reply-To: <20060103174729.5D0CF222418@laser.networkresonance.com> (Allison Mankin's message of "Tue, 03 Jan 2006 09:45:54 -0800") Message-ID: <86hd8l877r.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Jonathan Lennox , hartmans+ietf@mit.edu, tls@ietf.org, jon.peterson@neustar.biz, mmusic@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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Allison Mankin writes: >> >> > One other question -- in the IESG review, the issue was raised that >> > there's not currently an IANA registry for textual names of hash >> > functions. I agreed to add an IANA considerations section for this >> > purpose, but I was wondering if there's interest in having this >> > registry be more broadly scoped than just for comedia-tls? >> >> Well, as far as TLS goes, we only use integer code points, so this >> wouldn't buy us anything, but speaking personally I think this >> would be a good idea. > > Ekr, > > I somehow missed Jonathan's original question about this. I'll support > making this registry broad-based as long as we don't have to troubleshoot > it a lot from the security side. Essentially this is going to be > an IANA space for SDP-folk determined names of the algorithms > from RFCs 3280 and 4055 (and later, any RFCs which update 4055). > > The reason I don't want to use the broad registry if it entails > debugging is that it's not very likely to be in the consciousness of > future security developers, not being integrated into a reference > security RFC, and there's not much precedent (if any) for using > the same registry for multiple protocols. OK, well I don't have a strong feeling either way, so this is probably a question for SAAG or the SEC ADs. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 04 15:23:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuFA0-0001iT-Au; Wed, 04 Jan 2006 15:23:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuF9y-0001g4-60; Wed, 04 Jan 2006 15:23:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20832; Wed, 4 Jan 2006 15:21:46 -0500 (EST) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuFFV-0007MA-AJ; Wed, 04 Jan 2006 15:28:46 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 60EF1160059; Wed, 4 Jan 2006 15:22:59 -0500 (EST) To: Jonathan Lennox Subject: Re: [TLS] Brief Cross-WG review - draft-ietf-mmusic-comedia-tls References: <200601021643.LAA18903@ietf.org> <86psna8lsd.fsf@raman.networkresonance.com> <17337.52920.343464.422053@metro-north.cs.columbia.edu> From: Sam Hartman Date: Wed, 04 Jan 2006 15:22:59 -0500 In-Reply-To: <17337.52920.343464.422053@metro-north.cs.columbia.edu> (Jonathan Lennox's message of "Mon, 2 Jan 2006 20:09:12 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tls@ietf.org, mmusic@ietf.org, jon.peterson@neustar.biz 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Especially in the case where a fingerprint is present I think that the requirements for identity matching would introduce usability problems with no security benefit. So I strongly argue for relaxing the identity checking in the case where a fingerprint is available in an integrity protected SDP exchange. In the case where the cert is being matched against a trust anchor through the process described in RFC 3280, the identity constraints given in this document (or similar constraints) are absolutely essential. In the case where you are doing ssh-style leap of faith you do need to decide what identity you are binding the leap of faith entry to in your cache. In that case the identity requirements may be helpful but are not strict security requirements. If you are going to support ssh-style leap of faith you do need to be careful not to make rekeying/changing a cert harder than it needs to be. In particular, the user should not get a warning because there is a leap of faith cache entry with a different certificate in it and a valid fingerprint is presented in an integrity protected SDP session. I'm not sure updating the cache entry would be good in that case, but presenting a warning to the user because the cert changed would definitely be a bad idea because it would discourage rekeying. Now you do need to present the warning in the case where the SDP session is not integrity protected. --Sam P.S. If I was too terse I can expand. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 04 18:02:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuHe8-000724-GQ; Wed, 04 Jan 2006 18:02:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuHe5-00071j-OT; Wed, 04 Jan 2006 18:02:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16116; Wed, 4 Jan 2006 18:01:02 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuHjd-0006xV-Tt; Wed, 04 Jan 2006 18:08:03 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 04 Jan 2006 15:02:07 -0800 X-IronPort-AV: i="3.99,331,1131350400"; d="scan'208"; a="387421112:sNHT33979608" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k04N25jt009631; Wed, 4 Jan 2006 15:02:06 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Jan 2006 15:08:21 -0800 Message-ID: <7210B31550AC934A8637D6619739CE690667A6F6@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: few comments on salowey-tls-ticket-03 Thread-Index: AcYK7X78x3gd+JhbQzWwgXq1gtLLXwGYNX3g From: "Salowey, Joe" To: , "Zhou, Hao" , , , "Igal Ioffe" , "Russ Housley" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, iesg@ietf.org Subject: [TLS] RE: few comments on salowey-tls-ticket-03 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Hi Amir, Thanks for the review and your support. The latest draft is -06 and can be found at http://www.ietf.org/internet-drafts/draft-salowey-tls-ticket-06.txt. I'm forwarding your comments to the TLS list where the this draft has been discussed and to the IESG who are currently evaluating the document for publication as an RFC. Comments are included below. Thanks, Joe > -----Original Message----- > From: Amir Herzberg [mailto:herzbea@macs.biu.ac.il]=20 > Sent: Monday, December 26, 2005 11:50 PM > To: Zhou, Hao; Salowey, Joe; pasi.reronen@nokia.com;=20 > hannes.tshofenig@siemens.com; Igal Ioffe > Subject: few comments on salowey-tls-ticket-03 >=20 > Friends, I am very supportive of the TLS ticket idea, and=20 > cover it in my=20 > network security course as part of the TLS lecture (which you=20 > can find=20 > in my site, btw). A few comments on the draft (-03, July 15)=20 > version; if=20 > there is an appropriate mailing list, please let me know (and forward=20 > the message to it). >=20 > 1. Expiration time. Tickets clearly would (usually) have expiration=20 > time. It makes sense for the server to indicate this, so that=20 > the client=20 > can discard expired tickets. It may make sense to give some=20 > guideline as=20 > to sensible expiration time, in particular so that people=20 > realize that=20 > it makes sense to use substantially longer periods cf. to the TLS=20 > session lifetime. >=20 [Joe] The client does not know the expiry time of the ticket, this is consistent with current operation of TLS session resumption. If the server does not accept the ticket then the conversation falls back to the full handshake. I think adding expiration times would complicate the client implementation. We currently mention longer life tickets in the introduction, but we do not discuss ticket lifetime much outside this. =20 > 2. A missing security consideration: client identification=20 > (exposure to=20 > anonymity). TLS tickets may be cached for substantial=20 > periods. Users may=20 > move during these periods, e.g. from home to cafe. The ticket could=20 > allow identification of the user; this could be a concern in some=20 > scenarios. Notice that the session identified of regular TLS can also=20 > have this property but is short lived and therefore less of=20 > concern. We=20 > can solve this problem if needed, by encrypting the ticket using the=20 > server's public key, or maybe using some shared-key=20 > mechanisms; I'm not=20 > sure if the complexity is worth the benefit, but at least=20 > this should be=20 > mentioned, imho. >=20 [Joe] Yes, it is probably worthwhile to add a section in the security considerations on this. I agree that it probably isn't worth the complexity to try to address this at this point.=20 > Is there a good reason for sending the newticket in the clear i.e.=20 > before CSS? Sending after CSS would have reduced this=20 > exposure, esp. if=20 > the server changed the ticket at every connection. >=20 [Joe] The TLS spec indicates that the Finished message must follow the Change Cipher Spec message so we thought it would be more of a deviation from the existing TLS standard and TLS implementations. It was also in line with what was provided in [CSSC].=20 > 3. I think the `sample ticket` (section 4) should be given as=20 > a standard=20 > `ticket format`: this will facilitate multiple server=20 > implementations to=20 > support same ticket, which is a possible scenario; and why=20 > not? OTOH, I=20 > think the ticket should include a `ticket format identifier` (as an=20 > OID), allowing easy identification of the ticket format, for=20 > versioning=20 > and for supporting different ticket mechanisms. For same=20 > reason, it may=20 > make sense to allow sending multiple tickets. >=20 [Joe] This comment has come up before. The specification is not intended to provide interoperability between different server implementations. This would require a lot more specification and complexity. The sample ticket is included as a reasonable example that implementers can use instead of trying to invent their own. The ticket is issued by the server and understood by the server. Adding more structure to the ticket will tempt clients into interpreting the ticket which will have negative impacts on interoperability. If deployment experience shows that interoperability between different servers is useful and achievable then we can look at this again.=20 [CSSC] Shacham, H., Boneh, D., and E. Rescorla, "Client-side caching for TLS", Transactions on Information and System Security (TISSEC) , Volume 7, Issue 4, November 2004. > --=20 > Best regards, >=20 > Amir Herzberg >=20 > Associate Professor > Department of Computer Science > Bar Ilan University > http://AmirHerzberg.com > Try TrustBar - improved browser security UI:=20 > http://AmirHerzberg.com/TrustBar > Visit my Hall Of Shame of Unprotected Login pages:=20 > http://AmirHerzberg.com/shame >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 05 13:52:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaDc-0004wl-Ch; Thu, 05 Jan 2006 13:52:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaDb-0004wZ-7O for tls@megatron.ietf.org; Thu, 05 Jan 2006 13:52:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25908 for ; Thu, 5 Jan 2006 13:50:55 -0500 (EST) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuaJH-0006LJ-QW for tls@ietf.org; Thu, 05 Jan 2006 13:58:07 -0500 Received: (qmail 833 invoked by uid 0); 5 Jan 2006 18:51:59 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (192.55.60.42) by woodstock.binhost.com with SMTP; 5 Jan 2006 18:51:59 -0000 Message-Id: <7.0.0.16.2.20060105134224.06746d38@vigilsec.com> Message-Id: <7.0.0.16.2.20060105133609.0670b810@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 05 Jan 2006 13:51:16 -0500 To: tls@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Subject: [TLS] The IESG Approved Recharter of the TLS WG Today 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org On the IESG Telechat today, the IESG approved the revised charter of the TLS WG. The approved charter is below. Russ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Transport Layer Security (tls) ============================== Chair(s): Eric Rescorla Pasi Eronen Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Russ Housley Technical Advisor(s): Allison Mankin Mailing Lists: General Discussion: tls@lists.ietf.org To Subscribe: tls-request@ietf.org Archive: http://www.imc.org/ietf-tls/mail-archive Description of Working Group: The TLS Working Group was established in 1996 to standardize a 'transport layer' security protocol. The working group began with SSL version 3.0. The TLS Working Group has completed a series of specifications that describe the Transport Layer Security protocol versions 1.0 and 1.1, extensions to the protocol, and new ciphersuites to be used with TLS. The primary goal of the WG is to publish a revision of TLS, version 1.2, that removes the protocol's dependency on the MD5 and SHA-1 digest algorithms, which have been either wholly or partially compromised by recent research. The TLS WG will also work on new authenticated encryption modes for TLS, including modes based on counter mode encryption (CTR) and combined encryption/authentication modes, and may define major new cipher suites for TLS for this purpose. In the preparation of TLS 1.2, the WG will attempt to avoid gratuitous changes to TLS 1.1. Goals and Milestones: Done Final draft for Secure Transport Layer Protocol ('STLP') Done TLS 1.1 specification 3/2006 First draft of TLS 1.2 specification, including CTR mode cipher suites 3/2006 First draft of specification for cipher suites with combined encryption/authentication modes 12/2006 Submit specification of TLS 1.2 specification to IESG for publication as Proposed Standard. 12/2006 Submit specification of cipher suites with combined encryption/authentication modes to IESG for publication, with at least one of these suites to be Proposed Standard. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jan 08 04:15:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvWb4-0004c1-Bi; Sun, 08 Jan 2006 04:12:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvWb0-0004bw-4D for tls@megatron.ietf.org; Sun, 08 Jan 2006 04:12:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11932 for ; Sun, 8 Jan 2006 04:10:56 -0500 (EST) Received: from tamar.os.biu.ac.il ([132.70.60.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvWhE-0007YS-UR for tls@ietf.org; Sun, 08 Jan 2006 04:18:42 -0500 Received: from ismss-2.biu.ac.il (ismss.biu.ac.il [132.70.84.151]) by tamar.os.biu.ac.il (8.12.11/8.12.11/BIU) with ESMTP id k089Bqqh2154628 for ; Sun, 8 Jan 2006 11:11:55 +0200 Received: from deer.cs.biu.ac.il ([132.70.1.11]) by ismss-2.biu.ac.il with InterScan Messaging Security Suite; Sun, 08 Jan 2006 11:12:02 +0200 Received: from [132.70.4.39] (herzbea-lt [132.70.4.39]) by deer.cs.biu.ac.il with ESMTP id k089BTRH010855; Sun, 8 Jan 2006 11:11:29 +0200 Message-ID: <43C0D72F.4030603@cs.biu.ac.il> Date: Sun, 08 Jan 2006 11:11:11 +0200 From: Amir Herzberg User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Salowey, Joe" , tls@ietf.org References: <7210B31550AC934A8637D6619739CE690667A6F6@e2k-sea-xch2.sea-alpha .cisco.com> In-Reply-To: <7210B31550AC934A8637D6619739CE690667A6F6@e2k-sea-xch2.sea-alph a.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.8 required=4.5 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on deer.cs.biu.ac.il X-imss-version: 2.035 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: hannes.tshofenig@siemens.com, pasi.reronen@nokia.com Subject: [TLS] Re: few comments on salowey-tls-ticket-03 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: herzbea@macs.biu.ac.il 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Joe, thanks. Few comments below. > I'm forwarding your comments to the TLS list where the this draft has I somehow got unsubscribed from TLS... resubscribed now. Tks! >>1. Expiration time. Tickets clearly would (usually) have expiration >>time. It makes sense for the server to indicate this, so that >>the client can discard expired tickets. It may make sense to give some >>guideline as to sensible expiration time, in particular so that people >>realize that it makes sense to use substantially longer periods cf. to the TLS >>session lifetime. > > [Joe] The client does not know the expiry time of the ticket, this is > consistent with current operation of TLS session resumption. If the > server does not accept the ticket then the conversation falls back to > the full handshake. Sure. But you ignored the point I made: the hope is that tickets can be cached for much longer than TLS session state. Therefore, ticket lifetime should be much longer - and clients need to know when to discard ticket. Also, ticket are sent by server and are variable length, probably often longer than TLS session state. The TLS tickets are comparable to HTTP cookies. > I think adding expiration times would complicate > the client implementation. We currently mention longer life tickets in > the introduction, but we do not discuss ticket lifetime much outside > this. I think that adding ticket lifetime is not substantial complication. Not including it now may lead to adding it later which will be more complex. Of course, the lifetime field can be optional, also clients are allowed to erase a ticket before the requests lifetime. > >>2. A missing security consideration: client identification >>(exposure to anonymity). TLS tickets may be cached for substantial ... >>mechanisms; I'm not sure if the complexity is worth the benefit, but at least >>this should be mentioned, imho. > > [Joe] Yes, it is probably worthwhile to add a section in the security > considerations on this. I agree that it probably isn't worth the > complexity to try to address this at this point. Ok, so we are in agreement here. > >>Is there a good reason for sending the newticket in the clear i.e. >>before CSS? Sending after CSS would have reduced this >>exposure, esp. if >>the server changed the ticket at every connection. > > [Joe] The TLS spec indicates that the Finished message must follow the > Change Cipher Spec message so we thought it would be more of a deviation > from the existing TLS standard and TLS implementations. It was also in > line with what was provided in [CSSC]. Hmmm. I'm not sure this is much of an argument. I think privacy adovcates may consider this an insuffient reason. But I'll leave it to them. > >>3. I think the `sample ticket` (section 4) should be given as >>a standard >>`ticket format`: this will facilitate multiple server >>implementations to >>support same ticket, which is a possible scenario; and why >>not? OTOH, I >>think the ticket should include a `ticket format identifier` (as an >>OID), allowing easy identification of the ticket format, for >>versioning >>and for supporting different ticket mechanisms. For same >>reason, it may >>make sense to allow sending multiple tickets. >> > > > [Joe] This comment has come up before. The specification is not intended > to provide interoperability between different server implementations. > This would require a lot more specification and complexity. The sample > ticket is included as a reasonable example that implementers can use > instead of trying to invent their own. The ticket is issued by the > server and understood by the server. Adding more structure to the ticket > will tempt clients into interpreting the ticket which will have negative > impacts on interoperability. If deployment experience shows that > interoperability between different servers is useful and achievable > then we can look at this again. Reasonable. Thanks! -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 09 21:03:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew8rT-0003qf-B0; Mon, 09 Jan 2006 21:03:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew8rR-0003pC-OW for tls@megatron.ietf.org; Mon, 09 Jan 2006 21:03:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21424 for ; Mon, 9 Jan 2006 21:02:25 -0500 (EST) Received: from mail-eur.microsoft.com ([213.199.128.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew8y2-0007Lm-Ig for tls@ietf.org; Mon, 09 Jan 2006 21:10:35 -0500 Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.196]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jan 2006 02:03:23 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Jan 2006 02:03:29 -0000 Message-ID: Thread-Topic: The TLS User Mapping Extension draft is available thread-index: AcYSKlAgBagoLzbjS/iePa5QL/yLAQDX0aOw From: "Stefan Santesson" To: X-OriginalArrivalTime: 10 Jan 2006 02:03:23.0792 (UTC) FILETIME=[09A20100:01C6158A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Cc: Subject: [TLS] The TLS User Mapping Extension draft is available 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org I submitted the draft a while ago but it got lost in the internet-drafts mail system (possibly got caught in the spam filter :). But finally it was resolved and the draft is now available from: http://www.ietf.org/internet-drafts/draft-santesson-tls-ume-00.txt Stefan Santesson Program Manager, Standards Liaison Windows Security _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 09 21:30:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew9Gv-0004ZG-Bu; Mon, 09 Jan 2006 21:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew9Gu-0004Yl-S5 for tls@megatron.ietf.org; Mon, 09 Jan 2006 21:30:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23394 for ; Mon, 9 Jan 2006 21:28:46 -0500 (EST) Received: from gw3.transactionware.com ([203.14.245.3] helo=new.transactionware.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ew9NT-0008Cl-Q0 for tls@ietf.org; Mon, 09 Jan 2006 21:36:55 -0500 Received: (qmail 36542 invoked by uid 1026); 10 Jan 2006 02:30:03 -0000 Received: from 192.168.1.32 by new.transactionware.com (envelope-from , uid 1003) with qmail-scanner-1.25 (spamassassin: 3.0.2. Clear:RC:1(192.168.1.32):. Processed in 2.647182 secs); 10 Jan 2006 02:30:03 -0000 Received: from janm.transactionware.com (HELO ?192.168.1.32?) (192.168.1.32) by new.transactionware.com with SMTP; 10 Jan 2006 02:30:00 -0000 Message-ID: <43C31CE2.9000406@transactionware.com> Date: Tue, 10 Jan 2006 13:33:06 +1100 From: Jan Mikkelsen User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050822) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Santesson Subject: Re: [TLS] The TLS User Mapping Extension draft is available References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Hi, I just had a quick look at your ID, and I have some minor comments. In the introduction, you say that if the server doesn't understand this extension, it will respond with a non-extended ServerHello. The server could respond with an extended ServerHello that doesn't include this extension; other extensions may be supported. The UpnDomainHint field "user_principle_name" should probably be "user_principal_name". It is correct elsewhere in the document. Having an enum name and a struct name both be "UpnDomainHint" is confusing. Perhaps the enum value could be "upn_domain_hint". The UserMappingData struct only allows a single hint type. Could it be useful to allow multiple hint types in a single session setup? The requirement that UpnDomainHint should have at least one member populated could also be met by separating the domain and principal hints and allowing multiple hints in UserMappingData. This is just from a quick reading; I haven't thought about the issues in any more detail. I hope this helps. Regards, Jan Mikkelsen _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jan 11 16:00:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewn4k-0004vf-Kz; Wed, 11 Jan 2006 16:00:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewn4i-0004vM-U4 for tls@megatron.ietf.org; Wed, 11 Jan 2006 16:00:09 -0500 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12121 for ; Wed, 11 Jan 2006 15:58:47 -0500 (EST) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Ewn4b-0001tM-QG; Wed, 11 Jan 2006 16:00:01 -0500 Content-Type: text/plain Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Wed, 11 Jan 2006 16:00:01 -0500 Cc: Pasi Eronen , tls@ietf.org Subject: [TLS] WG Action: RECHARTER: Transport Layer Security (tls) 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org The charter of the Transport Layer Security (tls) working group in the Security Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. +++ Transport Layer Security (tls) ============================== Current Status: Active Working Group Chair(s): Eric Rescorla Pasi Eronen Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Russ Housley Technical Advisor(s): Allison Mankin Mailing Lists: General Discussion: tls@lists.ietf.org To Subscribe: tls-request@ietf.org Archive: http://www.imc.org/ietf-tls/mail-archive Description of Working Group: The TLS Working Group was established in 1996 to standardize a 'transport layer' security protocol. The working group began with SSL version 3.0. The TLS Working Group has completed a series of specifications that describe the Transport Layer Security protocol versions 1.0 and 1.1, extensions to the protocol, and new ciphersuites to be used with TLS. The primary goal of the WG is to publish a revision of TLS, version 1.2, that removes the protocol's dependency on the MD5 and SHA-1 digest algorithms, which have been either wholly or partially compromised by recent research. The TLS WG will also work on new authenticated encryption modes for TLS, including modes based on counter mode encryption (CTR) and combined encryption/authentication modes, and may define major new cipher suites for TLS for this purpose. In the preparation of TLS 1.2, the WG will attempt to avoid gratuitous changes to TLS 1.1. Goals and Milestones: Done Final draft for Secure Transport Layer Protocol ('STLP') Done TLS 1.1 specification 3/2006 First draft of TLS 1.2 specification, including CTR mode cipher suites 3/2006 First draft of specification for cipher suites with combined encryption/authentication modes 12/2006 Submit specification of TLS 1.2 specification to IESG for publication as Proposed Standard. 12/2006 Submit specification of cipher suites with combined encryption/authentication modes to IESG for publication, with at least one of these suites to be Proposed Standard. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 12 02:01:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwwSP-0003Ai-BO; Thu, 12 Jan 2006 02:01:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwwSD-000361-8j for tls@megatron.ietf.org; Thu, 12 Jan 2006 02:01:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26453 for ; Thu, 12 Jan 2006 01:59:40 -0500 (EST) Received: from fw.hel.fi.ssh.com ([195.20.116.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwwZF-00021H-HS for tls@ietf.org; Thu, 12 Jan 2006 02:08:19 -0500 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.16) with SMTP id k0C70gjR024601 for ; Thu, 12 Jan 2006 09:00:42 +0200 (EET) Received: (qmail 27649 invoked from network); 12 Jan 2006 07:00:42 -0000 Received: from unknown (HELO ?127.0.0.1?) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 12 Jan 2006 07:00:42 -0000 Message-ID: <43C5FF00.5040704@ssh.com> Date: Thu, 12 Jan 2006 09:02:24 +0200 From: Sami Lehtinen User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051020) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: Subject: [TLS] questions regarding draft-ietf-tls-rfc2246-bis-13.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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Hello, In section 6.2.3.2. CBC block cipher: The encrypted data length (TLSCiphertext.length) is one more than the sum of TLSCompressed.length, CipherSpec.hash_size, and padding_length. Should this be: The encrypted data length (TLSCiphertext.length) is one more than the sum of CipherSpec.block_length, TLSCompressed.length, ^^^^^^^^^^^^^^^^^^^^^^^^^ CipherSpec.hash_size, and padding_length. to accommondate for the explicit IV? Also, there is conflicting text regarding message precedence (handshake vs. application data): In section 6.2.1. Fragmentation: 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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ records may be held if application data is pending. However, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ and in 7.4.1.1. Hello request: with a no_renegotiation alert. Since handshake messages are ^^^^^^^^^^^^^^^^^^^^^^ intended to have transmission precedence over application data, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ it is expected that the negotiation will begin before no more than a few records are received from the client. If the server Which text is correct? In RFC 2246, the text is 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 text to the same effect is also in section 7.4.1.1 of RFC2246. P.S: with regard to the recent charter changes, is there going to be any kind of RFC of TLS 1.1? -- sjl@ssh.com _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 12 04:59:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwzEj-0003x8-IE; Thu, 12 Jan 2006 04:59:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwzEi-0003x2-I2 for tls@megatron.ietf.org; Thu, 12 Jan 2006 04:59:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06336 for ; Thu, 12 Jan 2006 04:57:54 -0500 (EST) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwzLi-0006t1-PP for tls@ietf.org; Thu, 12 Jan 2006 05:06:36 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISZ009B15CQ7Y@szxga03-in.huawei.com> for tls@ietf.org; Thu, 12 Jan 2006 18:05:14 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISZ00CQ05CP43@szxga03-in.huawei.com> for tls@ietf.org; Thu, 12 Jan 2006 18:05:14 +0800 (CST) Received: from [10.18.18.211] by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPSA id <0ISZ009FI5QOZ7@szxml01-in.huawei.com>; Thu, 12 Jan 2006 18:13:41 +0800 (CST) Date: Thu, 12 Jan 2006 15:28:53 +0530 From: jimmy Subject: Re: [TLS] questions regarding draft-ietf-tls-rfc2246-bis-13.txt In-reply-to: <43C5FF00.5040704@ssh.com> To: Sami Lehtinen Message-id: <43C6285D.4040107@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.4.1 (Windows/20051006) References: <43C5FF00.5040704@ssh.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7BIT Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Sami Lehtinen wrote: > Hello, ... > Also, there is conflicting text regarding message precedence (handshake > vs. application data): > > In section 6.2.1. Fragmentation: > > 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 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > records may be held if application data is pending. However, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > and in 7.4.1.1. Hello request: > > with a no_renegotiation alert. Since handshake messages are > ^^^^^^^^^^^^^^^^^^^^^^ > intended to have transmission precedence over application data, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > it is expected that the negotiation will begin before no more > than a few records are received from the client. If the server > > Which text is correct? In RFC 2246, the text is > > 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 text to the same effect is also in section 7.4.1.1 of RFC2246. > I too had pointed this out in an earlier mail, but got no replies. It seems in a previous thread in this list Eric had replied to someone posing a similar query. He had actually mentioned data had lower precedence (similar to what's in tls1.0 & the earlier tls1.1_drafts. So, it's a bit confusing. tls1.1 is in the rfc editor queue, so is that why no clarifications are coming in (are these going to be addressed in tls 1.2?) -jb _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 12 10:41:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex4Zs-0006Xf-9y; Thu, 12 Jan 2006 10:41:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex4Zq-0006XL-Fu for tls@megatron.ietf.org; Thu, 12 Jan 2006 10:41:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25415 for ; Thu, 12 Jan 2006 10:40:04 -0500 (EST) Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex4gy-0007lw-Qy for tls@ietf.org; Thu, 12 Jan 2006 10:48:49 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 171931E8C4C; Thu, 12 Jan 2006 07:41:06 -0800 (PST) To: jimmy Subject: Re: [TLS] questions regarding draft-ietf-tls-rfc2246-bis-13.txt References: <43C5FF00.5040704@ssh.com> <43C6285D.4040107@huawei.com> From: Eric Rescorla Date: Thu, 12 Jan 2006 07:41:06 -0800 In-Reply-To: <43C6285D.4040107@huawei.com> (jimmy's message of "Thu, 12 Jan 2006 15:28:53 +0530") Message-ID: <86y81l314d.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org jimmy writes: > Sami Lehtinen wrote: >> Hello, > ... >> Also, there is conflicting text regarding message precedence >> (handshake vs. application data): >> In section 6.2.1. Fragmentation: >> 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 >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> records may be held if application data is pending. However, >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> and in 7.4.1.1. Hello request: >> with a no_renegotiation alert. Since handshake messages are >> ^^^^^^^^^^^^^^^^^^^^^^ >> intended to have transmission precedence over application data, >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> it is expected that the negotiation will begin before no more >> than a few records are received from the client. If the server >> Which text is correct? In RFC 2246, the text is >> 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 text to the same effect is also in section 7.4.1.1 of RFC2246. >> > > I too had pointed this out in an earlier mail, but got no replies. It > seems in a previous thread in this list Eric had replied to someone > posing a similar query. He had actually mentioned data had lower > precedence (similar to what's in tls1.0 & the earlier tls1.1_drafts. > > So, it's a bit confusing. tls1.1 is in the rfc editor queue, so is > that why no clarifications are coming in (are these going to be > addressed in tls 1.2?) This will be clarified in TLS 1.1 "Authors 48 hours" -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 12 11:18:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex59Q-0001o3-QM; Thu, 12 Jan 2006 11:18:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex59P-0001jp-0N for tls@megatron.ietf.org; Thu, 12 Jan 2006 11:18:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28122 for ; Thu, 12 Jan 2006 11:16:48 -0500 (EST) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex5GJ-0000bT-D4 for tls@ietf.org; Thu, 12 Jan 2006 11:25:34 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISZ0009FMVX0K@szxga03-in.huawei.com> for tls@ietf.org; Fri, 13 Jan 2006 00:23:57 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISZ008UTMVW8C@szxga03-in.huawei.com> for tls@ietf.org; Fri, 13 Jan 2006 00:23:57 +0800 (CST) Received: from [10.18.18.211] by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPSA id <0ISZ00GYQN44F1@szxml02-in.huawei.com>; Fri, 13 Jan 2006 00:28:56 +0800 (CST) Date: Thu, 12 Jan 2006 21:47:33 +0530 From: jimmy Subject: Re: [TLS] questions regarding draft-ietf-tls-rfc2246-bis-13.txt In-reply-to: <86y81l314d.fsf@raman.networkresonance.com> To: EKR Message-id: <43C6811D.4000101@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (Windows/20051201) References: <43C5FF00.5040704@ssh.com> <43C6285D.4040107@huawei.com> <86y81l314d.fsf@raman.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7BIT Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > jimmy writes: > >> I too had pointed this out in an earlier mail, but got no replies. It >> seems in a previous thread in this list Eric had replied to someone >> posing a similar query. He had actually mentioned data had lower >> precedence (similar to what's in tls1.0 & the earlier tls1.1_drafts. >> >> So, it's a bit confusing. tls1.1 is in the rfc editor queue, so is >> that why no clarifications are coming in (are these going to be >> addressed in tls 1.2?) > > This will be clarified in TLS 1.1 "Authors 48 hours" > > -Ekr > thankyou Eric, but which one will it be. does it mean application data gets higher precedence? -jimmy _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jan 12 11:25:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex5Gh-0004AJ-LR; Thu, 12 Jan 2006 11:25:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex5Gg-0004AE-2B for tls@megatron.ietf.org; Thu, 12 Jan 2006 11:25:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28630 for ; Thu, 12 Jan 2006 11:24:19 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex5Nl-0000pl-R4 for tls@ietf.org; Thu, 12 Jan 2006 11:33:05 -0500 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 9F183170E0; Thu, 12 Jan 2006 08:35:30 -0800 (PST) To: jimmy Subject: Re: [TLS] questions regarding draft-ietf-tls-rfc2246-bis-13.txt References: <43C5FF00.5040704@ssh.com> <43C6285D.4040107@huawei.com> <86y81l314d.fsf@raman.networkresonance.com> <43C6811D.4000101@huawei.com> From: Eric Rescorla Date: Thu, 12 Jan 2006 08:35:30 -0800 In-Reply-To: <43C6811D.4000101@huawei.com> (jimmy's message of "Thu, 12 Jan 2006 21:47:33 +0530") Message-ID: <86fyntjtf1.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.15 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org jimmy writes: > Eric Rescorla wrote: >> jimmy writes: >> > >>> I too had pointed this out in an earlier mail, but got no replies. It >>> seems in a previous thread in this list Eric had replied to someone >>> posing a similar query. He had actually mentioned data had lower >>> precedence (similar to what's in tls1.0 & the earlier tls1.1_drafts. >>> >>> So, it's a bit confusing. tls1.1 is in the rfc editor queue, so is >>> that why no clarifications are coming in (are these going to be >>> addressed in tls 1.2?) >> This will be clarified in TLS 1.1 "Authors 48 hours" >> -Ekr >> > > thankyou Eric, but which one will it be. does it mean application data > gets higher precedence? There should be no change from the 2246 language. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 13 03:44:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExKYG-0006ZB-B5; Fri, 13 Jan 2006 03:44:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExKYD-0006YO-5Y for tls@megatron.ietf.org; Fri, 13 Jan 2006 03:44:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13054 for ; Fri, 13 Jan 2006 03:43:26 -0500 (EST) Received: from fw.hel.fi.ssh.com ([195.20.116.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExKfR-00016K-6F for tls@ietf.org; Fri, 13 Jan 2006 03:52:20 -0500 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.16) with SMTP id k0D8iYK6022150 for ; Fri, 13 Jan 2006 10:44:34 +0200 (EET) Received: (qmail 12151 invoked from network); 13 Jan 2006 08:44:34 -0000 Received: from unknown (HELO ?127.0.0.1?) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 13 Jan 2006 08:44:34 -0000 Message-ID: <43C768D7.8000108@ssh.com> Date: Fri, 13 Jan 2006 10:46:15 +0200 From: Sami Lehtinen User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051020) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] questions regarding draft-ietf-tls-rfc2246-bis-13.txt References: <43C5FF00.5040704@ssh.com> <43C6285D.4040107@huawei.com> <86y81l314d.fsf@raman.networkresonance.com> <43C6811D.4000101@huawei.com> <86fyntjtf1.fsf@romeo.rtfm.com> In-Reply-To: <86fyntjtf1.fsf@romeo.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: [application data/handshake precedence] > There should be no change from the 2246 language. Thank you, Eric. Any take on my other question about the TLSCipherText.length? -- sjl@ssh.com _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jan 13 21:52:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExbWN-00041i-7s; Fri, 13 Jan 2006 21:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExbWK-000404-Ju for tls@megatron.ietf.org; Fri, 13 Jan 2006 21:52:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10859 for ; Fri, 13 Jan 2006 21:50:38 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Exbdl-0002eB-Jv for tls@ietf.org; Fri, 13 Jan 2006 21:59:42 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 13 Jan 2006 18:51:50 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 18:51:50 -0800 Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.196]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 18:51:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] The TLS User Mapping Extension draft is available Date: Sat, 14 Jan 2006 02:51:42 -0000 Message-ID: Thread-Topic: [TLS] The TLS User Mapping Extension draft is available thread-index: AcYVjbwciFSCZTFYRdiqIokJBQ8GCQDJXYcg From: "Stefan Santesson" To: "Jan Mikkelsen" X-OriginalArrivalTime: 14 Jan 2006 02:51:49.0693 (UTC) FILETIME=[77564ED0:01C618B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Thanks Jan for your quick and good review. We have discussed these comments and agree to most of them. I address them in-line below. Stefan Santesson Program Manager, Standards Liaison Windows Security -----Original Message----- From: Jan Mikkelsen [mailto:janm@transactionware.com]=20 Sent: den 9 januari 2006 18:33 To: Stefan Santesson Cc: tls@ietf.org Subject: Re: [TLS] The TLS User Mapping Extension draft is available Hi, I just had a quick look at your ID, and I have some minor comments. In the introduction, you say that if the server doesn't understand this=20 extension, it will respond with a non-extended ServerHello. The server=20 could respond with an extended ServerHello that doesn't include this=20 extension; other extensions may be supported. [Stefan] Agree. Editorial issue that will be fixed in next draft. The UpnDomainHint field "user_principle_name" should probably be=20 "user_principal_name". It is correct elsewhere in the document. [Stefan] This is an error that has survived through the development process of this extension. It will be corrected. Having an enum name and a struct name both be "UpnDomainHint" is=20 confusing. Perhaps the enum value could be "upn_domain_hint". [Stefan] Agree, this will be fixed in the next draft. The UserMappingData struct only allows a single hint type. Could it be=20 useful to allow multiple hint types in a single session setup? [Stefan] This is a tricky issue but I agree that it could be useful. On one hand we want to limit the complexity if decisions the server has to make upon receiving a hint and that complexity increases if multiple hints are allowed. On the other hand, if a new version of a hint is created in the future then it would be very hard to manage a transition with legacy servers and clients if you can't send both hint types in a single handshake. We will look into this and probably provide a solution for providing multiple hints.=20 The requirement that UpnDomainHint should have at least one member=20 populated could also be met by separating the domain and principal hints and allowing multiple hints in UserMappingData. [Stefan] We definitely don't want to allow multiple hints of the same type. Even though you probably could figure out a use case for this, it is not worth the extra complexity. I suggest that any such needs will have to be addressed in definition of future hints, if there is a need for it. In such case a new hint could have a more comprehensive structure. This is just from a quick reading; I haven't thought about the issues=20 in any more detail. I hope this helps. [Stefan] It certainly does. Thanks. Regards, Jan Mikkelsen _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jan 15 14:15:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyDLm-0001wp-0b; Sun, 15 Jan 2006 14:15:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyDLk-0001wh-DJ for tls@megatron.ietf.org; Sun, 15 Jan 2006 14:15:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08892 for ; Sun, 15 Jan 2006 14:14:11 -0500 (EST) Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyDTV-0007yB-OQ for tls@ietf.org; Sun, 15 Jan 2006 14:23:39 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 9A814222418 for ; Sun, 15 Jan 2006 11:16:57 -0800 (PST) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 18) Date: Sun, 15 Jan 2006 11:15:26 -0800 From: Eric Rescorla Message-Id: <20060115191657.9A814222418@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [TLS] Call for reviews on draft-ietf-tls-openpgp-keys-08 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org The authors believe that draft-ietf-tls-openpgp-keys-08 is ready for submission to the IESG as an Experimental RFC. I'd like to get two volunteers to review it in the next three weeks. If you're willing to do this review, please post your name to the list. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jan 17 18:50:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez0aR-0000QS-Ec; Tue, 17 Jan 2006 18:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez0aQ-0000Q0-F1 for tls@megatron.ietf.org; Tue, 17 Jan 2006 18:50:02 -0500 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06338 for ; Tue, 17 Jan 2006 18:48:37 -0500 (EST) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Ez0aQ-0004ju-0W; Tue, 17 Jan 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 17 Jan 2006 18:50:02 -0500 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-openpgp-keys-08.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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org --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 : Using OpenPGP keys for TLS authentication Author(s) : N. Mavroyanopoulos Filename : draft-ietf-tls-openpgp-keys-08.txt Pages : 14 Date : 2006-1-17 This memo proposes extensions to the TLS protocol to support the OpenPGP trust model and keys. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-openpgp-keys-08.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-openpgp-keys-08.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-openpgp-keys-08.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: <2006-1-17161012.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-openpgp-keys-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-openpgp-keys-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-17161012.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Thu Jan 19 18:00:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezilg-0001mq-H7; Thu, 19 Jan 2006 18:00:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezile-0001mj-V1 for tls@megatron.ietf.org; Thu, 19 Jan 2006 18:00:34 -0500 Received: from web31807.mail.mud.yahoo.com (web31807.mail.mud.yahoo.com [68.142.207.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05883 for ; Thu, 19 Jan 2006 17:59:06 -0500 (EST) Received: (qmail 74533 invoked by uid 60001); 19 Jan 2006 23:00:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=iBhnMYauxWVit9Pimqy0WbznVA/f4mBPZYVPF11psJ6h5B16UrybRMQpJEagRPugttO4HI5g6VPh7EaNXnQ70eXLcv6f61xm6vra3LgtQodl0VCKhH5Yzqp4680kb5X5gOcNyyR1CWP/MAlixZ/FXG6Bcr7rQ25XyI5j0Y8/ZYM= ; Message-ID: <20060119230001.74528.qmail@web31807.mail.mud.yahoo.com> Received: from [62.254.128.4] by web31807.mail.mud.yahoo.com via HTTP; Thu, 19 Jan 2006 15:00:01 PST Date: Thu, 19 Jan 2006 15:00:01 -0800 (PST) From: ahsan askari To: tls@ietf.org MIME-Version: 1.0 Cc: Subject: [TLS] A suggestion required 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="===============0561379793==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org --===============0561379793== Content-Type: multipart/alternative; boundary="0-719166000-1137711601=:73900" --0-719166000-1137711601=:73900 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA05883 Hi,=20 =20 I am student of MSc High Speed Network and Distributed System at Oxford= Brookes University UK. I have to choose a topic for my dissertation but = before that I want to give you my background. I have done my undergraduat= e in Software Development and worked as a software engineer for more than= a year before starting my MSc. I don't have a very sound background towa= rds networking side but I choose this course because I want to do somethi= ng related to network proramming. Currently I am looking for a dissertati= on topic which involves distributed application development, networks and= security. The idea in my mind is that to develop some kind of distribute= d firewall but I have to complete my dissertation in three months. I want= your suggestion in this regard and if you have some other ideas regardin= g this please tell me. Maybe this is my last educational degree so I want= ed to do something which helps me in my professional career a lot. One mo= re thing that I should tell you is that I have worked mostly on DotNet and Java. I had developed a project for my final= year undergraduate which is a set of webservices developed in DotNet for= a generalized library system. My future plans is to stick with programmi= ng but something like protocol development or application specific firewa= ll e.t.c. Hope that I haven't annoyned you people by sending this mail an= d If I had than I am sorry. Thank you and looking forward towards your re= ply.=20 Thank you =09 --------------------------------- Yahoo! Photos =96 Showcase holiday pictures in hardcover Photo Books. You design it and we=92ll bind it! --0-719166000-1137711601=:73900 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA05883
Hi,
 
=
I am student of MSc High Speed Network and Distributed System at O= xford Brookes University UK. I have to choose a topic for my dissertation= but before that I want to give you my background. I have done my undergr= aduate in Software Development and worked as a software engineer for more= than a year before starting my MSc. I don't have a very sound background= towards networking side but I choose this course because I want to do so= mething related to network proramming. Currently I am looking for a disse= rtation topic which involves distributed application development, network= s and security. The idea in my mind is that to develop some kind of distr= ibuted firewall but I have to complete my dissertation in three months. I= want your suggestion in this regard and if you have some other ideas reg= arding this please tell me. Maybe this is my last educational degree so I= wanted to do something which helps me in my professional career a lot. One more thing that I should tell you is that= I have worked mostly on DotNet and Java. I had developed a project for m= y final year undergraduate which is a set of webservices developed in Dot= Net for a generalized library system. My future plans is to stick with pr= ogramming but something like protocol development or application specific= firewall e.t.c. Hope that I haven't annoyned you people by sending this = mail and If I had than I am sorry. Thank you and looking forward towards = your reply.
Thank you

Yahoo! Photos =96 Showcase holiday pictures in hardcover=20 Photo Bo= oks. You design it and we=92ll bind it! --0-719166000-1137711601=:73900-- --===============0561379793== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0561379793==-- From tls-bounces@lists.ietf.org Mon Jan 23 16:08:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F18vk-0000U3-9z; Mon, 23 Jan 2006 16:08:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F18vj-0000Tq-Hc for tls@megatron.ietf.org; Mon, 23 Jan 2006 16:08:51 -0500 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19256 for ; Mon, 23 Jan 2006 16:07:20 -0500 (EST) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1F18ve-0000zS-P6; Mon, 23 Jan 2006 16:08:46 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 23 Jan 2006 16:08:46 -0500 Cc: tls chair , Internet Architecture Board , tls mailing list , RFC Editor Subject: [TLS] Document Action: 'ECC Cipher Suites for TLS' to Informational RFC 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org The IESG has approved the following document: - 'ECC Cipher Suites for TLS ' as an Informational RFC This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Russ Housley and Sam Hartman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-12.txt Technical Summary This document adds Elliptic Curve Cryptography (ECC) cipher suites to TLS 1.0 and TLS 1.1. These cipher suites have some technical advantages over the currently defined RSA and DH/DSS cipher suites in terms of key size and performance. This document does not entail any changes to the TLS base specification. Working Group Summary The WG was unable to achieve rough consensus on advancing this document to Proposed Standard, due to concerns about IPR and some concerns about complexity. The WG was able to achieve rough consensus on advancing this document to Informational (following failure to achieve consensus on standards track). Some concerns about complexity (in particular curve negotiation) remain, but the overall feeling in the WG was that this document was ready for publication as an Informational RFC. Protocol Quality This document was reviewed by Russ Housley for the IESG. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jan 24 19:42:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1YkR-00057I-4K; Tue, 24 Jan 2006 19:42:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1YkP-00057A-7n for tls@megatron.ietf.org; Tue, 24 Jan 2006 19:42:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21489 for ; Tue, 24 Jan 2006 19:41:22 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Yu2-0000Sd-OU for tls@ietf.org; Tue, 24 Jan 2006 19:52:52 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 24 Jan 2006 16:42:43 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0P0gfjt019946; Tue, 24 Jan 2006 16:42:42 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Jan 2006 16:49:08 -0800 Message-ID: <7210B31550AC934A8637D6619739CE690683CA31@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: few comments on salowey-tls-ticket-03 Thread-Index: AcYUNHVHm8g/Rgc+RfCtgUIqCRsGOANEvCig From: "Salowey, Joe" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: hannes.tshofenig@siemens.com, pasi.reronen@nokia.com Subject: [TLS] RE: few comments on salowey-tls-ticket-03 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org =20 > -----Original Message----- > From: Amir Herzberg [mailto:herzbea@macs.biu.ac.il]=20 > I think that adding ticket lifetime is not substantial=20 > complication. Not=20 > including it now may lead to adding it later which will be=20 > more complex.=20 > Of course, the lifetime field can be optional, also clients=20 > are allowed=20 > to erase a ticket before the requests lifetime. > >=20 [Joe] OK, how about=20 "The SessionTicket handshake message has been assigned the number TBD2. The definition of the SessionTicket handshake message is given at the end of this section. The message contains ticket_lifetime_hint which is a hint of the ticket's lifetime in seconds as a 32 bit unsigned integer in network byte order. A value of zero is reserved to indicate that the lifetime of the ticket is unspecified. A client MAY delete the ticket when the time expires. A server MAY treat a ticket as valid for a shorter or longer period of time than what is stated in the ticket_lifetime_hint. The client MAY delete the ticket before the lifetime has elapsed. struct { HandshakeType msg_type; uint24 length; select (HandshakeType) { case hello_request: HelloRequest; case client_hello: ClientHello; case server_hello: ServerHello; case certificate: Certificate; case server_key_exchange: ServerKeyExchange; case certificate_request: CertificateRequest; case server_hello_done: ServerHelloDone; case certificate_verify: CertificateVerify; case client_key_exchange: ClientKeyExchange; case finished: Finished; case session_ticket: SessionTicket; /* NEW */ } body; } Handshake; struct { uint32 ticket_lifetime_hint; opaque ticket<0..2^16-1>; } SessionTicket;=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jan 29 15:20:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3J1p-0003Ys-E7; Sun, 29 Jan 2006 15:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3J1m-0003X3-9r; Sun, 29 Jan 2006 15:20:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23799; Sun, 29 Jan 2006 15:18:16 -0500 (EST) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3JCE-00029z-4l; Sun, 29 Jan 2006 15:30:51 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 0D69CE0053; Sun, 29 Jan 2006 15:19:37 -0500 (EST) To: Jonathan Lennox References: <17373.4514.607960.660335@cnr.cs.columbia.edu> From: Sam Hartman Date: Sun, 29 Jan 2006 15:19:37 -0500 In-Reply-To: <17373.4514.607960.660335@cnr.cs.columbia.edu> (Jonathan Lennox's message of "Sun, 29 Jan 2006 14:04:02 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: mmusic@ietf.org, jon.peterson@neustar.biz, tls@ietf.org Subject: [TLS] Re: comedia-tls: proposed change for certificate identities 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org >>>>> "Jonathan" == Jonathan Lennox writes: Jonathan> * If your SDP was sent over an end-to-end authenticated Jonathan> and integrity-protected channel, there are no Jonathan> constraints on what identity you assert in your TLS Jonathan> certificates; you can use anything you want. Identity Jonathan> is handled by the transporting protocol. What about hop-by-hop authenticated with each hop integrity protected. IMHO in many environments, this presents acceptable man-in-the-middle risk. I think that it may present significantly easier to deal with usability issues so I think it should at least be allowed if not encouraged. Jonathan> * If it wasn't, however, you have to have use Jonathan> certificate that asserts either a) the host in your SDP Jonathan> c= line (which can be either an IP address or host Jonathan> name), or b) a URI representing the protocol Jonathan> transporting the SDP (which in practice usually means a Jonathan> SIP URI). Jonathan> * For self-signed certificates sent un-authenticated, Jonathan> you can use SSH "leap-of-faith" mode: you warn the user Jonathan> if you've never seen a certificate before for a given Jonathan> identity, or if the certificate you got for an identity Jonathan> is different from the one you have cached. This means Jonathan> that once you've communicated with someone, you can be Jonathan> sure no one's launching a man-in-the-middle on you in Jonathan> the future. It does, however, present usability Jonathan> problems when someone has to change their cert. Do you have explicit language that a self-signed cert cache must not get in the way of the rekeying in the previous two cases? Jonathan> The other question is whether it's worthwhile to say Jonathan> that single-hop sips connections should count as Jonathan> end-to-end integrity-protected. On the one hand, they Jonathan> are; on the other hand, allowing certain operational Jonathan> modes for single-hop but not multi-hop SIP seems like a Jonathan> bad idea, and it would break in the face of third-party Jonathan> call control and other back-to-back UAs. Jonathan> Do people have alternate suggestions, or thoughts on Jonathan> better solutions? I note that these requirements are Jonathan> strictly more lenient than the protocol mode which got Jonathan> through WGLC. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jan 30 15:51:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3fzc-0004bt-FE; Mon, 30 Jan 2006 15:51:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3fzS-0004Xp-LM; Mon, 30 Jan 2006 15:51:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26451; Mon, 30 Jan 2006 15:49:24 -0500 (EST) Received: from [66.114.247.24] (helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3gA6-0001bt-Uj; Mon, 30 Jan 2006 16:02:12 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id A4FF7E0053; Mon, 30 Jan 2006 15:50:36 -0500 (EST) To: Jonathan Lennox References: <17373.4514.607960.660335@cnr.cs.columbia.edu> <17374.4868.521418.118273@cnr.cs.columbia.edu> From: Sam Hartman Date: Mon, 30 Jan 2006 15:50:36 -0500 In-Reply-To: <17374.4868.521418.118273@cnr.cs.columbia.edu> (Jonathan Lennox's message of "Mon, 30 Jan 2006 08:22:12 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: mmusic@ietf.org, jon.peterson@neustar.biz, tls@ietf.org Subject: [TLS] Re: comedia-tls: proposed change for certificate identities 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org >>>>> "Jonathan" == Jonathan Lennox writes: Jonathan> * For self-signed certificates sent un-authenticated, Jonathan> you can use SSH "leap-of-faith" mode: you warn the user Jonathan> if you've never seen a certificate before for a given Jonathan> identity, or if the certificate you got for an identity Jonathan> is different from the one you have cached. This means Jonathan> that once you've communicated with someone, you can be Jonathan> sure no one's launching a man-in-the-middle on you in Jonathan> the future. It does, however, present usability Jonathan> problems when someone has to change their cert. >> Do you have explicit language that a self-signed cert cache >> must not get in the way of the rekeying in the previous two >> cases? Jonathan> I'm not sure how I distinguish rekeying from a Jonathan> man-in-the-middle attacker presenting a new certificate. Jonathan> Is there an obvious distinction here? Does it have to Jonathan> do with certificate expiration? Basically, what I never want to happen is: * you get a self signed cert in a previous session * In the current session you have end-to-end integrity and get errors/warnings because you are not getting the same cert you did in that previous session. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls