Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
Eric Rescorla <ekr@networkresonance.com> Sun, 20 May 2007 20:42 UTC
Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpsE7-0005DA-1G; Sun, 20 May 2007 16:42:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpsE5-0005C6-76; Sun, 20 May 2007 16:42:01 -0400
Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpsE3-0003EU-U3; Sun, 20 May 2007 16:42:01 -0400
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 9E0AE33C23; Sun, 20 May 2007 13:41:29 -0700 (PDT)
Date: Sun, 20 May 2007 13:41:29 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Tim Bray <tbray@textuality.com>
In-Reply-To: <517bf110705192034s6e4e5656r596a6f11883e6a9a@mail.gmail.com>
References: <45F6CE12.8020703@mozilla.com> <tsllki1rpyc.fsf@cz.mit.edu> <45F6EF91.7030008@mozilla.com> <tslk5xlq8ul.fsf@cz.mit.edu> <45F6FA2A.4060409@mozilla.com> <1C0F121E56ADA47B5683D263@caldav.corp.apple.com> <45F7EC16.1030904@zurich.ibm.com> <45F7F3FC.6020306@gmx.de> <86lkhzc22x.fsf@delta.rtfm.com> <68fba5c50705181605p66298f1fh31f119185f67d8e8@mail.gmail.com> <517bf110705192034s6e4e5656r596a6f11883e6a9a@mail.gmail.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20070520204129.9E0AE33C23@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: ietf@ietf.org, Julian Reschke <julian.reschke@gmx.de>, Cyrus Daboo <cyrus@daboo.name>, iesg@ietf.org, Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org
At Sat, 19 May 2007 20:34:06 -0700, Tim Bray wrote: > > On 5/18/07, Robert Sayre <sayrer@gmail.com> wrote: > > I think the substituted text is inadequate, because it is not clear > > which TLS version implementors MUST support. As I understand it, the > > fact that it is "tricky", implying there may be trade-offs, is not > > sufficient to avoid specifying a single, mandatory-to-implement TLS > > version. > > Well Rob, I think the community at large and the IESG in particular > would welcome suggestions on what to do with this one. In fact, we > know what's going to happen: implementors will use the default TLS > library for whatever platform they're on, and this will do the job, > most times. However, I think that we have better-than-rough consensus > that the specification landscape is a mess, making normative > references a bitch, and that this will probably bite nearly > everything in the Apps area from here on in. > > I hope someone with the necessary expertise will take this bull by the > horns. -Tim I agree that these specs should explicitly specify which TLS version to support. As a practical matter, this is either 1.0 or 1.1, since 1.2 is not yet finished. Unfortunately, which one to require isn't really something that can be decided on technical grounds: the protocols are very slightly different and (at least in theory) backward compatible. TLS 1.1 is slightly more secure and TLS 1.0 is quite a bit more widely deployed. On balance, I think this probably turns into a MUST for 1.0 and a SHOULD for 1.1, but I could certainly see this argued another way. -Ekr _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- TLS requirements (Last Call: draft-ietf-atompub-p… Robert Sayre
- Re: TLS requirements (Last Call: draft-ietf-atomp… Sam Hartman
- Re: TLS requirements (Last Call: draft-ietf-atomp… Robert Sayre
- Re: TLS requirements (Last Call: draft-ietf-atomp… Sam Hartman
- Re: TLS requirements (Last Call: draft-ietf-atomp… Robert Sayre
- Re: TLS requirements (Last Call: draft-ietf-atomp… Brian E Carpenter
- Re: TLS requirements (Last Call: draft-ietf-atomp… Julian Reschke
- Already Last-Called downrefs (was: ...) Pekka Savola
- Re: TLS requirements (Last Call: draft-ietf-atomp… EKR
- Re: Already Last-Called downrefs Brian E Carpenter
- Re: TLS requirements (Last Call: draft-ietf-atomp… Robert Sayre
- Re: TLS requirements (Last Call: draft-ietf-atomp… Julian Reschke
- Re: TLS requirements (Last Call: draft-ietf-atomp… Tim Bray
- Re: TLS requirements (Last Call: draft-ietf-atomp… Julian Reschke
- Re: TLS requirements (Last Call: draft-ietf-atomp… Eric Rescorla
- Re: TLS requirements (Last Call: draft-ietf-atomp… Eric Rescorla
- Re: TLS requirements (Last Call: draft-ietf-atomp… Robert Sayre
- Re: TLS requirements (Last Call: draft-ietf-atomp… Jeffrey Hutzelman
- Re: TLS requirements (Last Call: draft-ietf-atomp… Philip Guenther
- Re: TLS requirements (Last Call: draft-ietf-atomp… Brian E Carpenter
- Re: TLS requirements (Last Call: draft-ietf-atomp… Philip Guenther
- AW: Last Call: draft-ietf-geopriv-radius-lo (Carr… Doug Ewell
- Re: TLS requirements (Last Call: draft-ietf-atomp… Julian Reschke
- Re: TLS requirements (Last Call: draft-ietf-atomp… Cyrus Daboo