From n.mavrogiannopoulos@gmail.com Fri Jun 1 02:38:12 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C1821F8534 for ; Fri, 1 Jun 2012 02:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kU3u0jVgZ7v for ; Fri, 1 Jun 2012 02:38:11 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6328D21F8532 for ; Fri, 1 Jun 2012 02:38:11 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1229969wgb.13 for ; Fri, 01 Jun 2012 02:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=rU4hvIqe/Q/H2jPW+AX8szVPOgpzC3KZMZY9Hf1q1WQ=; b=RXAgmL1UsHITvwhwcOOuJUM9PSs3IsLHkEXkgj7Y9Ex3RT00KVFjSLxKF0sADGhJBO u+MMsDzO4pO4I95mgSNrNxzspLyYleLruQpjGR/YUcGJ4D5BnGlgF2UaL2TT+sLKlMr6 h9aAHHHWXkmOuhsVu0BFUee3wiOcG5pnbQQXZy8qfekqvtSab+XQQy00OmOKh7dfzvps QH1fApT9yX3u0TluerpG2JKIl5NqdOi0cMDW8fnpaxiZuVXej3JWDCwdDQM0LygxDOgf 8sGsZTfGTirTr/jmBRMC5GkL+t/JrSwz42Yd19ponfY2ZDiK6Bq4xw8kcpdp8Ksobu/x +rKw== MIME-Version: 1.0 Received: by 10.216.145.97 with SMTP id o75mr1794985wej.7.1338543490471; Fri, 01 Jun 2012 02:38:10 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.180.103.228 with HTTP; Fri, 1 Jun 2012 02:38:10 -0700 (PDT) In-Reply-To: <4FB55702.3090408@extendedsubset.com> References: <4FB55702.3090408@extendedsubset.com> Date: Fri, 1 Jun 2012 11:38:10 +0200 X-Google-Sender-Auth: ahu1vSKucufrlCiJv2ptoUbcGH8 Message-ID: From: Nikos Mavrogiannopoulos To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [TLS] Preventing cross-protocol attacks in TLS protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 01 Jun 2012 09:38:12 -0000 On Thu, May 17, 2012 at 9:52 PM, Marsh Ray wrote: > I think this is a good robustness improvement to the protocol and may bring > other benefits. I actually considered including a very similar change in > draft-ray-encrypted-handshake, but did not do so primarily due to scope. > However, draft-mavrogiannopoulos-tls-server-key-exchage does not protect > against the attack described. I have improved the document to handle the case where both server and client support the extension but the client does not require it to be present. This comes at the cost of reducing the server random bytes to 28. http://www.ietf.org/id/draft-mavrogiannopoulos-tls-cross-protocol-00.txt regards, Nikos From nick.lewis@usa.g4s.com Wed May 30 02:23:05 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC2021F867E for ; Wed, 30 May 2012 02:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lgb0Rk7BOhmK for ; Wed, 30 May 2012 02:23:04 -0700 (PDT) Received: from mail194.messagelabs.com (mail194.messagelabs.com [85.158.140.211]) by ietfa.amsl.com (Postfix) with ESMTP id 955CA21F86C6 for ; Wed, 30 May 2012 02:23:03 -0700 (PDT) X-Env-Sender: nick.lewis@usa.g4s.com X-Msg-Ref: server-12.tower-194.messagelabs.com!1338369781!14767825!1 X-Originating-IP: [89.206.228.155] X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21442 invoked from network); 30 May 2012 09:23:01 -0000 Received: from unallocated.star.net.uk (HELO gbtwk10s038.Technology.local) (89.206.228.155) by server-12.tower-194.messagelabs.com with RC4-SHA encrypted SMTP; 30 May 2012 09:23:01 -0000 Received: from GBTWK10E001.Technology.local ([10.234.1.29]) by gbtwk10s038.Technology.local ([10.234.1.40]) with mapi; Wed, 30 May 2012 10:23:01 +0100 From: "Lewis, Nick" To: "'tls@ietf.org'" Date: Wed, 30 May 2012 10:23:00 +0100 Thread-Topic: Registering SHA256 null encryption ciphersuites Thread-Index: Ac0+Re2aZmLzhljNTKeQfTnEx/LFcg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AAE0766F5AF36B46BAB7E0EFB92732060686EE495FGBTWK10E001Te_" MIME-Version: 1.0 Subject: [TLS] Registering SHA256 null encryption ciphersuites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 01 Jun 2012 12:39:35 -0000 --_000_AAE0766F5AF36B46BAB7E0EFB92732060686EE495FGBTWK10E001Te_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable May I please have the views of the people on this list as to the merit of r= egistering some SHA256 null encryption cipher suites We have a requirement for secure authenticated communications that does not= involve the passing of shared keys, PINs, PII or other confidential data a= nd therefore no encryption is required RFC4492 defines the following null encryption cipher suites: TLS_ECDH_ECDSA_WITH_NULL_SHA TLS_ECDHE_ECDSA_WITH_NULL_SHA TLS_ECDH_RSA_WITH_NULL_SHA TLS_ECDHE_RSA_WITH_NULL_SHA These cipher suites are closest to our requirements. However we cannot use = 160bit SHA require that SHA256 be used. I am thinking that it may be appropriate to have new cipher suite identifie= rs registered in the IANA TLS Cipher Suite Registry for the following: TLS_ECDH_ECDSA_WITH_NULL_SHA256 TLS_ECDHE_ECDSA_WITH_NULL_SHA256 TLS_ECDH_RSA_WITH_NULL_SHA256 TLS_ECDHE_RSA_WITH_NULL_SHA256 Is this suggestion sensible? Although not required in our application, is it also worth including ECDH_a= non_WITH_NULL_SHA256 and SHA384 variants of the ciphersuites too? Best Regards Nick Nick Lewis nick.lewis@usa.g4s.com +44 1684 277137 www.g4stechnology.com New Challenge House, International Drive, Tewkesbury, Gloucestershire, GL20= 8UQ, UK P Please consider the environment before printing this email ________________________________ The details of this company are as follows: G4S Technology Limited, Registered Office: Challenge House, International D= rive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 23823= 38. This communication may contain information which is confidential, personal = and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution= , forwarding, copying or use of this communication or the information in it= is strictly prohibited. Any personal views expressed in this e-mail are those of the individual sen= der and the company does not endorse or accept responsibility for them. Prior to taking any action based upon this e-mail message, you should seek = appropriate confirmation of its authenticity. This e-mail has been scanned for all viruses by MessageLabs. --_000_AAE0766F5AF36B46BAB7E0EFB92732060686EE495FGBTWK10E001Te_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

May I please have the views of the people on this li= st as to the merit of registering some SHA256 null encryption cipher suites=

 

We have a requirement for secure authenticated commu= nications that does not involve the passing of shared keys, PINs, PII or ot= her confidential data and therefore no encryption is required

 

RFC4492 defines the following null encryption cipher= suites:

 

TLS_ECDH_ECDSA_WITH_NUL= L_SHA

TLS_ECDHE_ECDSA_WITH_NU= LL_SHA

TLS_ECDH_RSA_WITH_NULL_= SHA

TLS_ECDHE_RSA_WITH_NULL= _SHA

 

These cipher suites are closest to our requirements.= However we cannot use 160bit SHA require that SHA256 be used.

 

I am thinking that it may be appropriate to have new= cipher suite identifiers registered in the IANA TLS Cipher Suite Registry = for the following:

 

TLS_ECDH_ECDSA_WITH_NUL= L_SHA256

TLS_ECDHE_ECDSA_WITH_NU= LL_SHA256

TLS_ECDH_RSA_WITH_NULL_= SHA256

TLS_ECDHE_RSA_WITH_NULL= _SHA256

 

Is this suggestion sensible?

 

Although not required in our application, is it also= worth including ECDH_anon_WITH_NULL_SHA256 and SHA384 variants of the ciph= ersuites too?

 

Best Regards

Nick

 

Nick Lewis

nick.lewis@usa.g4s.c= om

+44 1684 277137=

www.g4stec= hnology.com

New Cha= llenge House, International Drive, Tewkesbury, Gloucestershire, GL20 8UQ, U= K

 

P Please consider the environment before printing this email<= /span>

 


The details of this company = are as follows:
G4S Technology Limited, Registered Office: Challenge House, International D= rive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 23823= 38.

This communication may contain information which is confidential, personal = and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution= , forwarding, copying or use of this communication or the information in it= is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sen= der and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek = appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.
 --_000_AAE0766F5AF36B46BAB7E0EFB92732060686EE495FGBTWK10E001Te_-- From mrex@sap.com Fri Jun 1 08:08:59 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760F721F8AB1 for ; Fri, 1 Jun 2012 08:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.211 X-Spam-Level: X-Spam-Status: No, score=-10.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FH+tzTe14Ik for ; Fri, 1 Jun 2012 08:08:59 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id ADB4421F8AB0 for ; Fri, 1 Jun 2012 08:08:58 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q51F8sW8002137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2012 17:08:55 +0200 (MEST) In-Reply-To: <4FC75249.3050805@comodo.com> To: Rob Stradling Date: Fri, 1 Jun 2012 17:08:54 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120601150854.C33F81A094@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] CRL Stapling? (was Re: I-D Action: draft-ietf-tls-multiple-cert-status-extension-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.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: , X-List-Received-Date: Fri, 01 Jun 2012 15:08:59 -0000 Rob Stradling wrote: > > IIRC, when Opera does an online revocation check, it currently checks > CRLs for intermediate CA certificates and OCSP for end-entity > certificates. This makes sense because: > - CRLs covering intermediate CA certificates tend to be roughly the > same size (sometimes smaller!) as the equivalent OCSP Responses (since > it's quite rare for intermediate CA certificates to be revoked). > - Possessing a current CRL means you won't have to do an online > revocation check if you encounter another certificate issued by the same > issuer. > > [...] > > How about changing the scope of the multi-stapling I-D so that it *only* > covers the intermediate CA certificate(s) in the chain? This would significantly increase the complexity without adding value. OCSP responses can be cached just as long as the CRLs on which they're based. > > With this approach, an end-entity OCSP Response could be stapled using > the RFC6066 TLS extension, and the intermediate CRL(s) could be stapled > using the new multi-stapling TLS extension. This would require the complexity of two TLS extensions where a single TLS extension is perfectly sufficient (i.e. a lot more code and a lot more bugs). While I might eventually look into implementing the multi-stapling TLS extension, I will never consider doing the rfc6066 single OCSP extension. -Martin From ekr@rtfm.com Fri Jun 1 08:14:40 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E26311E81A9 for ; Fri, 1 Jun 2012 08:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vvvs6OMgei9J for ; Fri, 1 Jun 2012 08:14:39 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4C44F11E817F for ; Fri, 1 Jun 2012 08:14:39 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1512673vbb.31 for ; Fri, 01 Jun 2012 08:14:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=acwEqqmjmZXYbwyTeW31vepRt6B2AwDofIoi7/L3ylc=; b=kBikhysTY/LgpiV8QOrVADiP0p5YrbXoVy8qAArjfLuoE/WKCS4f5th6Dff68cPLj2 KBoPebFa7MR4JjN2l85pLJVz6arnHVzPhaSFMXghbl/oGcYQdchtBMCFNhTJvFAshJ9+ 5n26XKyaRXB+fqsPOzfQgUpdDu5zDIsjEYa5zHhFy9xq02l2bOC7/PhCaZ1R+ilGfaum 40fSbALzIZpK1QN2dTxFTYmVIZv/kgIgdjjFAkf77w3XIwWLW0xMfLWA0nmQx4IOlxuF yIDVRMRjVi/tKpRChhA5ZfU/9Ob1V7zIvtCBomXDocLdlOQxOggrIgXChZ+kTO+libJh aD8A== Received: by 10.220.240.73 with SMTP id kz9mr2916674vcb.9.1338563678458; Fri, 01 Jun 2012 08:14:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Fri, 1 Jun 2012 08:13:57 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <20120601150854.C33F81A094@ld9781.wdf.sap.corp> References: <4FC75249.3050805@comodo.com> <20120601150854.C33F81A094@ld9781.wdf.sap.corp> From: Eric Rescorla Date: Fri, 1 Jun 2012 08:13:57 -0700 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkojrp0XgY7Algj/UyFwP1yWDD9c54J9lSbiWoSxSW/eNjR12+dLw/SoNjaxD4oKlexmHtw Cc: tls@ietf.org Subject: Re: [TLS] CRL Stapling? (was Re: I-D Action: draft-ietf-tls-multiple-cert-status-extension-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 01 Jun 2012 15:14:40 -0000 On Fri, Jun 1, 2012 at 8:08 AM, Martin Rex wrote: > Rob Stradling wrote: >> >> IIRC, when Opera does an online revocation check, it currently checks >> CRLs for intermediate CA certificates and OCSP for end-entity >> certificates. =A0This makes sense because: >> =A0 =A0- CRLs covering intermediate CA certificates tend to be roughly t= he >> same size (sometimes smaller!) as the equivalent OCSP Responses (since >> it's quite rare for intermediate CA certificates to be revoked). >> =A0 =A0- Possessing a current CRL means you won't have to do an online >> revocation check if you encounter another certificate issued by the same >> issuer. >> >> =A0 [...] >> >> How about changing the scope of the multi-stapling I-D so that it *only* >> covers the intermediate CA certificate(s) in the chain? > > This would significantly increase the complexity without adding value. > OCSP responses can be cached just as long as the CRLs on which they're > based. > >> >> With this approach, an end-entity OCSP Response could be stapled using >> the RFC6066 TLS extension, and the intermediate CRL(s) could be stapled >> using the new multi-stapling TLS extension. > > This would require the complexity of two TLS extensions where a single > TLS extension is perfectly sufficient (i.e. a lot more code and a lot > more bugs). > > > While I might eventually look into implementing the multi-stapling > TLS extension, I will never consider doing the rfc6066 single OCSP > extension. FWIW, Chrome already supports RFC 6066 and it's in process for Firefox. -Ekr From iesg-secretary@ietf.org Fri Jun 1 09:42:06 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFA021F86F0; Fri, 1 Jun 2012 09:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxUl+3CD0-PX; Fri, 1 Jun 2012 09:42:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552C121F8467; Fri, 1 Jun 2012 09:42:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120601164205.25357.54620.idtracker@ietfa.amsl.com> Date: Fri, 01 Jun 2012 09:42:05 -0700 Cc: tls@ietf.org Subject: [TLS] Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 01 Jun 2012 16:42:06 -0000 The IESG has received a request from the TLS Working Group to reclassify RF= C 2818 (HTTP Over TLS) to Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final= comments on this action. Please send substantive comments to the ietf at i= etf.org mailing lists by 2012-06-15. Exceptionally, comments may be sent to= iesg at ietf.org instead. In either case, please retain the beginning of t= he Subject line to allow automated sorting. Abstract = This memo describes how to use TLS to secure HTTP connections over the Inte= rnet. Current practice is to layer HTTP over SSL (the predecessor to TLS), = distinguishing secured traffic from insecure traffic by the use of a differ= ent server port. This document documents that practice using TLS. A compani= on document describes a method for using HTTP/TLS over the same port as nor= mal HTTP [RFC2817]. The file can be obtained via http://www.rfc-editor.org/rfc/rfc2818.txt No IPR declarations have been submitted directly on this I-D. From stpeter@stpeter.im Fri Jun 1 09:45:37 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBE811E80C2 for ; Fri, 1 Jun 2012 09:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aM6mLiUHe5bG for ; Fri, 1 Jun 2012 09:45:36 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A739911E8074 for ; Fri, 1 Jun 2012 09:45:36 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BEB8040075 for ; Fri, 1 Jun 2012 11:02:10 -0600 (MDT) Message-ID: <4FC8F1AF.2040409@stpeter.im> Date: Fri, 01 Jun 2012 10:45:35 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tls@ietf.org References: <20120601164205.25357.54620.idtracker@ietfa.amsl.com> In-Reply-To: <20120601164205.25357.54620.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 01 Jun 2012 16:45:37 -0000 On 6/1/12 10:42 AM, IESG Secretary wrote: > The IESG has received a request from the TLS Working Group to reclassify RFC 2818 (HTTP Over TLS) to Proposed Standard. Interesting. Are there also plans to modernize this spec by working on 2818bis? Peter -- Peter Saint-Andre https://stpeter.im/ From aerowolf@gmail.com Fri Jun 1 10:15:22 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1740321F897E; Fri, 1 Jun 2012 10:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OQqqAgAj9OM; Fri, 1 Jun 2012 10:15:21 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAFF21F897B; Fri, 1 Jun 2012 10:15:21 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so3212760pbc.31 for ; Fri, 01 Jun 2012 10:15:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type; bh=cZE1h19HOFGf/bFXGHBFrGKO/T6L1uR5tuMWk+rCoDs=; b=pOyNaUmqRWIRJcUCDxZUn7LoSBD7CrOsWna/WdAZxB9ph4BFN5PwOioL4RmvIlrqgf c73uVp87nrOEWypgcvfGJd8uNlDbaGPXuRSd0N2y3XypoeE8bDKIryeFDyJlknD92uk+ IyH7NOy9AJo6Wt4zUcNKHpXAkaJMPvoRYMLpxAG9e5rM9ocOnTqhQECJI5hMsIyCgzqz J15wlERr1TLsDuqx6d73VP2LVsj4AvWdk5tbd2S1jTiU2o1Sat0D5owvWHI4nxsnQ2ix TIC45AXEgXTBwj3cRdpgSrWErEe8DSnCHtKZ5QTthH0Tr4Z9C/U5JITIErR2EDIpMCGY gL7w== Received: by 10.68.222.9 with SMTP id qi9mr11639053pbc.164.1338570920943; Fri, 01 Jun 2012 10:15:20 -0700 (PDT) Received: from penango (user-64-9-235-60.googlewifi.com. [64.9.235.60]) by mx.google.com with ESMTPS id of1sm3348237pbb.15.2012.06.01.10.15.16 (version=SSLv3 cipher=OTHER); Fri, 01 Jun 2012 10:15:17 -0700 (PDT) From: "Kyle Hamilton" To: "IESG Secretary" Date: Fri, 1 Jun 2012 10:15:48 -0700 (Pacific Daylight Time) Message-ID: In-Reply-To: <20120601164205.25357.54620.idtracker@ietfa.amsl.com> References: <20120601164205.25357.54620.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.7.2eqh2xiky4eflcspj56162 Cc: tls@ietf.org, IETF Announcement List Subject: Re: [TLS] Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 01 Jun 2012 17:15:22 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.7.2eqh2xiky4eflcspj56162 Content-Type: text/plain; format=flowed; charset=us-ascii Content-Transfer-Encoding: 7bit This is damaging, and I recommend against. This is something which must be handled by HTTP and its demands of its transports, not TLS and its claim to support what it thinks its clients want. Among other things, this RFC more than any other is responsible for the "Server Name Indication" requirement. If it had not been the case, SNI would never have been necessary, and IESG/IETF would never have had to deal with it. I suggest instead that it be moved to HISTORIC, and a 2818bis drafted which describes how the various TLS extensions play with HTTP. -Kyle H On Fri, Jun 1, 2012 at 9:42 AM, IESG Secretary wrote: > The IESG has received a request from the TLS Working Group to reclassify RFC 2818 (HTTP Over TLS) to Proposed Standard. > > The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf at ietf.org mailing lists by 2012-06-15. Exceptionally, comments may be sent to iesg at ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. > > Abstract > > This memo describes how to use TLS to secure HTTP connections over the Internet. Current practice is to layer HTTP over SSL (the predecessor to TLS), distinguishing secured traffic from insecure traffic by the use of a different server port. This document documents that practice using TLS. A companion document describes a method for using HTTP/TLS over the same port as normal HTTP [RFC2817]. > > The file can be obtained via > http://www.rfc-editor.org/rfc/rfc2818.txt > > No IPR declarations have been submitted directly on this I-D. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --gmsm1.9.7.2eqh2xiky4eflcspj56162 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIT0DCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMIIGyDCCBbCgAwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNTha MIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5yQ004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNV BAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJp ZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNVBAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG 9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQsXi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7q xMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aHfVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoV k+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbc IlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46vRFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pc L2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0CAwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYD VR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz 14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYw FIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0gBIIBOTCCATUwggExBgsrBgEEAYG1NwECATCC ASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYB BQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUF BwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBkUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2Vj dGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9z dWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5j b20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76e TBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHMnviFSMXhrGZWNsian4JOutmQS61MHjLg+qth fpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+peAnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1a Xu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJOsyom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf 1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMxAiYmk/ImAwN6LWWKZatQdHbZoTZUMYIDzTCC A8kCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICCMQwCQYFKw4DAhoFAKCCAg4w GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNjAxMTcxNTQ4WjAj BgkqhkiG9w0BCQQxFgQUEdRmzBtiWE4gD687HuphhqAwW0IwXwYJKoZIhvcNAQkPMVIwUDALBglg hkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgEoMIGkBgkrBgEEAYI3EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICCMQwgaYGCyqGSIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAgjEMA0GCSqGSIb3DQEBAQUABIIBADkdEF2DYMAmpAs8+li6N4RS3w24Ru017qka LdeePRPeIOoetELEzCU+qMAWlr9KOaINU7nZnwmW7Tkuwz18t4yNCPQLAtk38I4kFnYGYEt9mOjZ jusXGJ6c9zu8LS0z7zO95iksEzkyu0UTcZ0xA7evl9TxaQbWTXAnUGdEdF2Icuya6ABOqq/au/Ud SNHttuZwKlVpALmA/VUWOmVLEcFplgV1qVt4cthR42D8McTfoMT4izE3JkvzQS1CTjfJoh63T1fx pvqXPlbFStFDtOzKwhyadBXP06gGbRosSbmSzzX8thkpkkOVDru5Alkrn5RHEsD0lcy2LEwrdMsV REEAAAAAAAA= --gmsm1.9.7.2eqh2xiky4eflcspj56162-- From ekr@rtfm.com Fri Jun 1 10:29:32 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF64311E80B4 for ; Fri, 1 Jun 2012 10:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93+6xmF6mRbM for ; Fri, 1 Jun 2012 10:29:32 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4D42C11E8074 for ; Fri, 1 Jun 2012 10:29:32 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1609431vcq.31 for ; Fri, 01 Jun 2012 10:29:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=eFZCgBdc85AnNyMeGHZzZKslQ9yoAH13a3HF6TOuQRQ=; b=eLHOrWzv+36Zcx8lynSv124862oR65FCLf1JwrZqs4PgVOvDDIZ5ea7cBupglDxE1M BSCFd+ERiNt1/iSiPDBPXpk25C+M9qwBeM/76FgMQM9FbI/mgx0m5XZwjV9gGVoMkMTB Z0Aq2VK5AIOzO5WXZAK5qjiogJBqChw+Dz528Q2hDQ9dToZXoh6FXmWtc16WSVFMVJuu M8L6QJs//eF4/hml6y7GY2b4zPkshxB5N9Av8+Jw14VfARJ7y3j6IulLxrcyQXHseaSK C8CLVapBMZj1NXW/E1COpUwXmkDte4hO6SZ0glDPzr5VYHQktex3sGEuvlOra0/Essdi Z6NA== Received: by 10.220.154.2 with SMTP id m2mr3357625vcw.2.1338571771555; Fri, 01 Jun 2012 10:29:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Fri, 1 Jun 2012 10:28:51 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: References: <20120601164205.25357.54620.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Fri, 1 Jun 2012 10:28:51 -0700 Message-ID: To: Kyle Hamilton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkYUES3DzaskpricoX0uQARYN5hWt0YXIyhxWE3FY6JUhCIMsuj9x4dPSmdDxlpcCP8Q/Sc Cc: IESG Secretary , tls@ietf.org, IETF Announcement List Subject: Re: [TLS] Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 01 Jun 2012 17:29:33 -0000 On Fri, Jun 1, 2012 at 10:15 AM, Kyle Hamilton wrote: > This is damaging, and I recommend against. =A0This is something which mus= t be > handled by HTTP and its demands of its transports, not TLS and its claim = to > support what it thinks its clients want. > > Among other things, this RFC more than any other is responsible for the > "Server Name Indication" requirement. =A0If it had not been the case, SNI > would never have been necessary, and IESG/IETF would never have had to de= al > with it. Huh? As stated in the abstract, RFC 2818 documented what was already established practice at the time it was published. Yes, that practice leads directly to SNI, but it's not like it's the fault of 2818. > I suggest instead that it be moved to HISTORIC, and a 2818bis drafted whi= ch > describes how the various TLS extensions play with HTTP. I don't understand what that would mean. At the time 2818 was published, there were already complaints about the HTTPS mechanism (though primarily directed towards the use of a separate port) and the IETF took a stab at trying to define a protocol that it liked better (2817). That was hardly a success. It's hard to believe that we're going to make fundamental architectural changes now, given that HTTPS is far more entrenched. -Ekr From ekr@rtfm.com Fri Jun 1 10:30:39 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17DB11E8074 for ; Fri, 1 Jun 2012 10:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgyrWM2X2kjR for ; Fri, 1 Jun 2012 10:30:39 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6792411E808A for ; Fri, 1 Jun 2012 10:30:39 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1610125vcq.31 for ; Fri, 01 Jun 2012 10:30:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=KCRutUYC0cPqjKScUiIroB3MeLNjgropKNQ3ioD56JE=; b=c1tgxYG0QgAJYj4IhArq7vOeBnPo9ZD52OxuaqFbGlSFmgRzzA5VLc5rw3pn7sapwX TeOH4zKddrDmhubeI8K/5MxyPAhm97ma+m5eknrx8WdCPfRNAXHGIf3iAPdu0BGXgbDS ctIbf8Kuvv6sf78sYCKwbKcrBJz5qGfQFWaRUwDZg6qUKPBFgbbOuROTnXN0o9uH0ieI LZPMqNeXuLC7+4bSEI0txMZkc7PUi0eqSPrZrUtaiUMCRCj5fBBXaXNz7dgyl2Y45bIC Pt6Y+v1Dc4Tw2wV9A8557TQkgRw34onMlbR+88whGx4VUtU2kcMBeveJ0P1Y9+LXokES 9W4Q== Received: by 10.52.93.133 with SMTP id cu5mr3057384vdb.125.1338571838991; Fri, 01 Jun 2012 10:30:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Fri, 1 Jun 2012 10:29:58 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: <4FC8F1AF.2040409@stpeter.im> References: <20120601164205.25357.54620.idtracker@ietfa.amsl.com> <4FC8F1AF.2040409@stpeter.im> From: Eric Rescorla Date: Fri, 1 Jun 2012 10:29:58 -0700 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmNBtyywKj0CONY0rfrtvrfQ5Iv5DXcuOuEFNQRGD2p3M4Tud3WYSQtxF8ipz3iWLhQ7p8Q Cc: tls@ietf.org Subject: Re: [TLS] Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 01 Jun 2012 17:30:40 -0000 On Fri, Jun 1, 2012 at 9:45 AM, Peter Saint-Andre wrote: > On 6/1/12 10:42 AM, IESG Secretary wrote: >> The IESG has received a request from the TLS Working Group to reclassify RFC 2818 (HTTP Over TLS) to Proposed Standard. > > Interesting. Are there also plans to modernize this spec by working on > 2818bis? I would be willing to work on this if we could come up with a clear list of improvements. -Ekr From mrex@sap.com Fri Jun 1 10:44:25 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD80D21F8A5B; Fri, 1 Jun 2012 10:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.184 X-Spam-Level: X-Spam-Status: No, score=-10.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLWVeteiYRBs; Fri, 1 Jun 2012 10:44:25 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 12F1E21F8A5A; Fri, 1 Jun 2012 10:44:24 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q51HiNQq026206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2012 19:44:23 +0200 (MEST) In-Reply-To: To: Kyle Hamilton Date: Fri, 1 Jun 2012 19:44:22 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120601174422.CFC9B1A094@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: IESG Secretary , tls@ietf.org, IETF Announcement List Subject: Re: [TLS] Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.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: , X-List-Received-Date: Fri, 01 Jun 2012 17:44:26 -0000 Kyle Hamilton wrote: > This is damaging, and I recommend against. This is something which must > be handled by HTTP and its demands of its transports, not TLS and its > claim to support what it thinks its clients want. > > Among other things, this RFC more than any other is responsible for the > "Server Name Indication" requirement. If it had not been the case, > SNI would never have been necessary, and IESG/IETF would never have > had to deal with it. The RFC(s) responsible for the "Server Name Indication" requirement is/are 2068/2616 "HTTP/1.1", which introduced the concept of virtual hosting: http://tools.ietf.org/html/rfc2068#section-14.23 http://tools.ietf.org/html/rfc2616#section-14.23 > > I suggest instead that it be moved to HISTORIC, and a 2818bis drafted > which describes how the various TLS extensions play with HTTP. While I would be OK with creating rfc2818bis that explicitly describes additional requirements implied by the virtual hosting concept of HTTP/1.1 and refers to TLS extension SNI rfc4366 (for TLSv1.0+v1.1) and rfc6066 (for TLSv1.2+), I fail to see why we should move rfc2818 to historic _before_ such a 2818bis is ready for publication. -Martin From turners@ieca.com Fri Jun 1 11:49:35 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D8C11E8096 for ; Fri, 1 Jun 2012 11:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.057 X-Spam-Level: X-Spam-Status: No, score=-102.057 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCyEWry23Dga for ; Fri, 1 Jun 2012 11:49:35 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.56.142.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0B39021F89FC for ; Fri, 1 Jun 2012 11:49:35 -0700 (PDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 983C378E93DFA for ; Fri, 1 Jun 2012 13:49:34 -0500 (CDT) Received: from [71.191.8.30] (port=35120 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SaWuk-0005vF-A1 for tls@ietf.org; Fri, 01 Jun 2012 13:49:34 -0500 Message-ID: <4FC90EBD.1050803@ieca.com> Date: Fri, 01 Jun 2012 14:49:33 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tls@ietf.org References: <20120601164205.25357.54620.idtracker@ietfa.amsl.com> In-Reply-To: <20120601164205.25357.54620.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [71.191.8.30]:35120 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [TLS] Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 01 Jun 2012 18:49:35 -0000 So....I wasn't clear enough when I asked for this IETF LC. I initiated this process as an AD not at the request of the WG. My rationale was that it's in the downref registry and that there's 66 or so RFCs that refer to 2818 and a lot of them are normative. If it ends up that folks prefer the 2818bis -> PS coupled with 2818 -> Historic. I'd be all right with that too. spt On 6/1/12 12:42 PM, IESG Secretary wrote: > The IESG has received a request from the TLS Working Group to reclassify RFC 2818 (HTTP Over TLS) to Proposed Standard. > > The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf at ietf.org mailing lists by 2012-06-15. Exceptionally, comments may be sent to iesg at ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. > > Abstract > > This memo describes how to use TLS to secure HTTP connections over the Internet. Current practice is to layer HTTP over SSL (the predecessor to TLS), distinguishing secured traffic from insecure traffic by the use of a different server port. This document documents that practice using TLS. A companion document describes a method for using HTTP/TLS over the same port as normal HTTP [RFC2817]. > > The file can be obtained via > http://www.rfc-editor.org/rfc/rfc2818.txt > > No IPR declarations have been submitted directly on this I-D. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From yngve@opera.com Fri Jun 1 12:15:46 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A84711E8112 for ; Fri, 1 Jun 2012 12:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4P8KColdbkra for ; Fri, 1 Jun 2012 12:15:45 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 25ED211E80EE for ; Fri, 1 Jun 2012 12:15:44 -0700 (PDT) Received: from acorna.invalid.invalid (106.170.202.84.customer.cdi.no [84.202.170.106]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q51JFgjT003052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Jun 2012 19:15:43 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Peter Saint-Andre" , "Eric Rescorla" References: <20120601164205.25357.54620.idtracker@ietfa.amsl.com> <4FC8F1AF.2040409@stpeter.im> Date: Fri, 01 Jun 2012 21:15:54 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: User-Agent: Opera Mail/11.64 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 01 Jun 2012 19:15:46 -0000 On Fri, 01 Jun 2012 19:29:58 +0200, Eric Rescorla wrote: > On Fri, Jun 1, 2012 at 9:45 AM, Peter Saint-Andre > wrote: >> On 6/1/12 10:42 AM, IESG Secretary wrote: >>> The IESG has received a request from the TLS Working Group to >>> reclassify RFC 2818 (HTTP Over TLS) to Proposed Standard. >> >> Interesting. Are there also plans to modernize this spec by working on >> 2818bis? > > I would be willing to work on this if we could come up with > a clear list of improvements. My list for a bis: - Update protocol reference to TLS 1.2, preferably with a suggestion to support at least that version, and a reiteration of version and extension tolerance for servers. - Update sec. 3.1 to use RFC 6125 for the server identity. - Reference the HTTP CONNECT method for connecting through a proxy. - As I recall, more recent TLS versions have changed the requirements for unexpected connection closure and session reuse, so sec 2.2 should probably reflect that. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ******************************************************************** From paul.hoffman@vpnc.org Fri Jun 1 12:16:40 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB4711E80AD for ; Fri, 1 Jun 2012 12:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.277 X-Spam-Level: X-Spam-Status: No, score=-102.277 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZejpqbMz6y2 for ; Fri, 1 Jun 2012 12:16:40 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E997011E80A4 for ; Fri, 1 Jun 2012 12:16:39 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q51JGaCK096354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Jun 2012 12:16:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4FC90EBD.1050803@ieca.com> Date: Fri, 1 Jun 2012 12:16:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <38A40014-322F-4904-80E5-A48CF576DDB2@vpnc.org> References: <20120601164205.25357.54620.idtracker@ietfa.amsl.com> <4FC90EBD.1050803@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1278) Cc: tls@ietf.org Subject: Re: [TLS] Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 01 Jun 2012 19:16:40 -0000 On Jun 1, 2012, at 11:49 AM, Sean Turner wrote: > So....I wasn't clear enough when I asked for this IETF LC. I = initiated this process as an AD not at the request of the WG. >=20 > My rationale was that it's in the downref registry and that there's 66 = or so RFCs that refer to 2818 and a lot of them are normative. If it = ends up that folks prefer the 2818bis -> PS coupled with 2818 -> = Historic. I'd be all right with that too. That seems the best way to go, given how much things have changed in the = last decade. --Paul Hoffman From stpeter@stpeter.im Fri Jun 1 12:25:21 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F48811E80A0 for ; Fri, 1 Jun 2012 12:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VNtkECHO2MO for ; Fri, 1 Jun 2012 12:25:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AB17411E812D for ; Fri, 1 Jun 2012 12:25:20 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1C82940075; Fri, 1 Jun 2012 13:41:55 -0600 (MDT) Message-ID: <4FC9171E.2050503@stpeter.im> Date: Fri, 01 Jun 2012 13:25:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <20120601164205.25357.54620.idtracker@ietfa.amsl.com> <4FC90EBD.1050803@ieca.com> <38A40014-322F-4904-80E5-A48CF576DDB2@vpnc.org> In-Reply-To: <38A40014-322F-4904-80E5-A48CF576DDB2@vpnc.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 01 Jun 2012 19:25:21 -0000 On 6/1/12 1:16 PM, Paul Hoffman wrote: > On Jun 1, 2012, at 11:49 AM, Sean Turner wrote: > >> So....I wasn't clear enough when I asked for this IETF LC. I >> initiated this process as an AD not at the request of the WG. >> >> My rationale was that it's in the downref registry and that there's >> 66 or so RFCs that refer to 2818 and a lot of them are normative. >> If it ends up that folks prefer the 2818bis -> PS coupled with 2818 >> -> Historic. I'd be all right with that too. > > That seems the best way to go, given how much things have changed in > the last decade. Agreed. I don't see any harm in having lots of RFCs pointing to this entry in the downref registry, and it seems better to update 2818 than to have people thinking that 2818 is standards-track as it is today. Peter -- Peter Saint-Andre https://stpeter.im/ From nico@cryptonector.com Fri Jun 1 12:30:51 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D5511E80BD for ; Fri, 1 Jun 2012 12:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FryPgjHAodSU for ; Fri, 1 Jun 2012 12:30:51 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 22C1311E80A0 for ; Fri, 1 Jun 2012 12:30:51 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id B1308318074 for ; Fri, 1 Jun 2012 12:30:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=AAoKfuQBCLqr+QgsAS96bEcT7dsMiMaeSirxMWkHvDay VXqpCyoCjwSv+9AKvu2Bc+dJH2aj28dGMflcwubCl4GHerTyMqa99caNCAda7xGk /JaFt7sKm89PNb2c4aAZZ5dnebCQmTQLzZlHOMyoTFE8rRRtBoJhYU0ZqUj2QtM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=lU4KIoe3WB0vAnWBkRfCzg6aofs=; b=n1P15VfO0V9 ha7Smn3oEAnqeNt0k3+b51i//hGEy9huGbRPfrD0vYUv44u9gBZ00CeYflsPvAUR eIhi52roMw3QNKxcwoR6FdAzumv/tEOenA8Odk8Z7HRb7dk/+IP9tMEukevOe8tK rmlKYIjM+MTtjB3WNhIsdpFfVEEtCl18= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 8FFB5318064 for ; Fri, 1 Jun 2012 12:30:50 -0700 (PDT) Received: by dacx6 with SMTP id x6so3176404dac.31 for ; Fri, 01 Jun 2012 12:30:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.203.7 with SMTP id km7mr13274384pbc.7.1338579050292; Fri, 01 Jun 2012 12:30:50 -0700 (PDT) Received: by 10.68.15.134 with HTTP; Fri, 1 Jun 2012 12:30:50 -0700 (PDT) In-Reply-To: <4FC9171E.2050503@stpeter.im> References: <20120601164205.25357.54620.idtracker@ietfa.amsl.com> <4FC90EBD.1050803@ieca.com> <38A40014-322F-4904-80E5-A48CF576DDB2@vpnc.org> <4FC9171E.2050503@stpeter.im> Date: Fri, 1 Jun 2012 14:30:50 -0500 Message-ID: From: Nico Williams To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , tls@ietf.org Subject: Re: [TLS] Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 01 Jun 2012 19:30:51 -0000 On Fri, Jun 1, 2012 at 2:25 PM, Peter Saint-Andre wrot= e: > On 6/1/12 1:16 PM, Paul Hoffman wrote: >> On Jun 1, 2012, at 11:49 AM, Sean Turner wrote: >>> My rationale was that it's in the downref registry and that there's >>> 66 or so RFCs that refer to 2818 and a lot of them are normative. >>> If it ends up that folks prefer the 2818bis -> PS coupled with 2818 >>> -> Historic. =C2=A0I'd be all right with that too. >> >> That seems the best way to go, given how much things have changed in >> the last decade. > > Agreed. I don't see any harm in having lots of RFCs pointing to this > entry in the downref registry, and it seems better to update 2818 than > to have people thinking that 2818 is standards-track as it is today. +1. Moving an RFC to Proposed Standard should come with a discussion of whether that RFC is OK as-is. It looks like RFC2818 isn't/ Nico -- From ekr@rtfm.com Fri Jun 1 12:46:25 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED30A11E809B for ; Fri, 1 Jun 2012 12:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLna90pmM-tE for ; Fri, 1 Jun 2012 12:46:24 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EB6C111E80A3 for ; Fri, 1 Jun 2012 12:46:23 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1689461vbb.31 for ; Fri, 01 Jun 2012 12:46:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=Noi4zOumuXE6RrsaOCg07Q2O7kn76sWmyOinmWFaiJg=; b=BdEQr/lz678IxIsyaBBEfskrX9OC6/Q1Qe9s66scsJzuUJAl9Wa93k+f0Aqyd1OGuM f8Ojz2/bXmU1AvLXL7ZYz9r3iaa9RICZvzOE9zub6Z8+7Bsqr334ooW3G8u5+J5Y5iKe NDTyo6VVKG0Lg3mEe0UwM0R1PHPyuNkePyHDPlak6dXUpgAoWEUMHTF+PTJ0RQkriY7f KXcwzUlkpCAaJVCHL2625lo9UvAcOIpV9iOsKZe7wTdU8k/koKRDqUGiJaaMWvTyukzq z6/lTx3ojczUs6VF0/SmJpqzosIOb3MmgDlHukC/T45fb+c+92b85SMYGTDbtrS0Zq2x lVrw== Received: by 10.220.108.130 with SMTP id f2mr1930251vcp.26.1338579983097; Fri, 01 Jun 2012 12:46:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Fri, 1 Jun 2012 12:45:42 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: References: <20120601164205.25357.54620.idtracker@ietfa.amsl.com> <4FC8F1AF.2040409@stpeter.im> From: Eric Rescorla Date: Fri, 1 Jun 2012 12:45:42 -0700 Message-ID: To: "Yngve N. Pettersen (Developer Opera Software ASA)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn90VvaTE9XQr6gFKxQczfcAIlpiiGbGJAmibzwdAgPperFJvqKgHFuxtwrYB0RgiD+isBn Cc: tls@ietf.org Subject: Re: [TLS] Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 01 Jun 2012 19:46:25 -0000 On Fri, Jun 1, 2012 at 12:15 PM, Yngve N. Pettersen (Developer Opera Software ASA) wrote: > On Fri, 01 Jun 2012 19:29:58 +0200, Eric Rescorla wrote: > >> On Fri, Jun 1, 2012 at 9:45 AM, Peter Saint-Andre >> wrote: >>> >>> On 6/1/12 10:42 AM, IESG Secretary wrote: >>>> >>>> The IESG has received a request from the TLS Working Group to reclassi= fy >>>> RFC 2818 (HTTP Over TLS) to Proposed Standard. >>> >>> >>> Interesting. Are there also plans to modernize this spec by working on >>> 2818bis? >> >> >> I would be willing to work on this if we could come up with >> a clear list of improvements. > > > My list for a bis: > > - Update protocol reference to TLS 1.2, preferably with a suggestion to > support at least that version, and a reiteration of version and extension > tolerance for servers. Agreed. > - Update sec. 3.1 to use RFC 6125 for the server identity. I'm not sure I agree with this. 2818 is intended to document HTTPS client behavior. This may or may not be what we recommend for other protocols (and indeed, the terms under which 6125 was approved included that it not override 2818 for HTTPS). > - Reference the HTTP CONNECT method for connecting through a proxy. IIRC, this is documented in 2817. We would have to decide if we wanted to move that, ref it, or... > - As I recall, more recent TLS versions have changed the requirements for > unexpected connection closure and session reuse, so sec 2.2 should probab= ly > reflect that. Probably. -Ekr > -- > Sincerely, > Yngve N. Pettersen > ******************************************************************** > Senior Developer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Email: yngve@ope= ra.com > Opera Software ASA =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://www.opera.c= om/ > Phone: =A0+47 23 69 32 60 =A0 =A0 =A0 =A0 =A0 =A0 =A0Fax: =A0 =A0+47 23 6= 9 24 01 > ******************************************************************** From ekr@rtfm.com Fri Jun 1 12:50:59 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2218A21F8797 for ; Fri, 1 Jun 2012 12:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5BVZL82I5BE for ; Fri, 1 Jun 2012 12:50:58 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8032C21F8790 for ; Fri, 1 Jun 2012 12:50:58 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1692307vbb.31 for ; Fri, 01 Jun 2012 12:50:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=IiGZD5oZKnULdMU5mqQybZMuK2ERCy/pc5TOTIXwmdw=; b=LZ8UIdsxVkvG9U5WC0hjnKl9GTF6qxfWBjIOTWqLAGJB7+Tl7RxBOcEovPqVsvhZ1h S5I3x03xFevkSpZ0M0N+I8jXc91eII0B3yvdN0FylLVMEWjBcDyte5qCLZuupA6ra/Q0 odc2vLSrbak/oKW0WKi5Hn/oezJnIFERCIFIL+6daerHF2bm8wZZV6SACHlXbjAMP9x1 y2YtyJtXXzDxjN79jfnQc6yalc4bJKaBZL0dAZhcThfLLBKEeMiiXNtpOnjXUFXc/Kt+ Q/fH5biyiTb1hVA7/R24GpfjoG/kNnQ2I2bLgJd5DFeddm6RCO8upmJm9lSKDP6q9jZi FY/Q== Received: by 10.52.22.50 with SMTP id a18mr3564331vdf.60.1338580257597; Fri, 01 Jun 2012 12:50:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Fri, 1 Jun 2012 12:50:17 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: References: <20120601164205.25357.54620.idtracker@ietfa.amsl.com> <4FC90EBD.1050803@ieca.com> <38A40014-322F-4904-80E5-A48CF576DDB2@vpnc.org> <4FC9171E.2050503@stpeter.im> From: Eric Rescorla Date: Fri, 1 Jun 2012 12:50:17 -0700 Message-ID: To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQllXRiVAkYt+jXbBaiF1Q0ssSdMYx8Ge126RZXpFpCZ/Aiihfpp7PzQajy4c7r5zX7v2n/W Cc: Paul Hoffman , tls@ietf.org Subject: Re: [TLS] Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 01 Jun 2012 19:50:59 -0000 On Fri, Jun 1, 2012 at 12:30 PM, Nico Williams wrot= e: > On Fri, Jun 1, 2012 at 2:25 PM, Peter Saint-Andre wr= ote: >> On 6/1/12 1:16 PM, Paul Hoffman wrote: >>> On Jun 1, 2012, at 11:49 AM, Sean Turner wrote: >>>> My rationale was that it's in the downref registry and that there's >>>> 66 or so RFCs that refer to 2818 and a lot of them are normative. >>>> If it ends up that folks prefer the 2818bis -> PS coupled with 2818 >>>> -> Historic. =A0I'd be all right with that too. >>> >>> That seems the best way to go, given how much things have changed in >>> the last decade. >> >> Agreed. I don't see any harm in having lots of RFCs pointing to this >> entry in the downref registry, and it seems better to update 2818 than >> to have people thinking that 2818 is standards-track as it is today. > > +1. > > Moving an RFC to Proposed Standard should come with a discussion of > whether that RFC is OK as-is. =A0It looks like RFC2818 isn't/ FWIW, I don't really care what the status of this RFC is. That said, it looks kinda silly to have a document that describes a huge ch= unk of how the Internet works and that is referred to normatively all over the place be Informational because the IESG of 2000 thought that HTTP and HTTPS should run over the same port. -Ekr From stpeter@stpeter.im Fri Jun 1 13:43:51 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998DD11E8097 for ; Fri, 1 Jun 2012 13:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljEZfTB+IFkQ for ; Fri, 1 Jun 2012 13:43:51 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2218011E808A for ; Fri, 1 Jun 2012 13:43:51 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C463A40075; Fri, 1 Jun 2012 15:00:25 -0600 (MDT) Message-ID: <4FC92985.2050809@stpeter.im> Date: Fri, 01 Jun 2012 14:43:49 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <20120601164205.25357.54620.idtracker@ietfa.amsl.com> <4FC8F1AF.2040409@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 01 Jun 2012 20:43:51 -0000 On 6/1/12 1:45 PM, Eric Rescorla wrote: > On Fri, Jun 1, 2012 at 12:15 PM, Yngve N. Pettersen (Developer Opera > Software ASA) wrote: > >> - Update sec. 3.1 to use RFC 6125 for the server identity. > > I'm not sure I agree with this. 2818 is intended to document HTTPS client > behavior. This may or may not be what we recommend for other protocols I see two approaches: 1. Profile 6125 in 2818bis, as we've done for email and XMPP. 2. Define something 6125-ish (but shorter) in 2818bis. > (and indeed, the terms under which 6125 was approved included that > it not override 2818 for HTTPS). Indeed. Another topic it would be good to clarify (or affirm) in 2818bis is wildcards. Peter -- Peter Saint-Andre https://stpeter.im/ From turners@ieca.com Fri Jun 1 13:55:35 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BF621F8A02 for ; Fri, 1 Jun 2012 13:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.071 X-Spam-Level: X-Spam-Status: No, score=-102.071 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wnWKmqVmB5z for ; Fri, 1 Jun 2012 13:55:35 -0700 (PDT) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.216.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3617021F8A03 for ; Fri, 1 Jun 2012 13:55:34 -0700 (PDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway03.websitewelcome.com (Postfix) with ESMTP id 231D0794C2537 for ; Fri, 1 Jun 2012 15:55:33 -0500 (CDT) Received: from [71.191.8.30] (port=39632 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SaYse-0008Bg-Op; Fri, 01 Jun 2012 15:55:32 -0500 Message-ID: <4FC92C43.4030900@ieca.com> Date: Fri, 01 Jun 2012 16:55:31 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Peter Saint-Andre References: <20120601164205.25357.54620.idtracker@ietfa.amsl.com> <4FC8F1AF.2040409@stpeter.im> <4FC92985.2050809@stpeter.im> In-Reply-To: <4FC92985.2050809@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [71.191.8.30]:39632 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: tls@ietf.org Subject: Re: [TLS] Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 01 Jun 2012 20:55:35 -0000 On 6/1/12 4:43 PM, Peter Saint-Andre wrote: > On 6/1/12 1:45 PM, Eric Rescorla wrote: >> On Fri, Jun 1, 2012 at 12:15 PM, Yngve N. Pettersen (Developer Opera >> Software ASA) wrote: >> >>> - Update sec. 3.1 to use RFC 6125 for the server identity. >> >> I'm not sure I agree with this. 2818 is intended to document HTTPS client >> behavior. This may or may not be what we recommend for other protocols > > I see two approaches: > > 1. Profile 6125 in 2818bis, as we've done for email and XMPP. > > 2. Define something 6125-ish (but shorter) in 2818bis. > >> (and indeed, the terms under which 6125 was approved included that >> it not override 2818 for HTTPS). > > Indeed. > > Another topic it would be good to clarify (or affirm) in 2818bis is > wildcards. That would address the errata filed against 2818. spt From geoffk@geoffk.org Fri Jun 1 13:55:42 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223CC21F8A0C for ; Fri, 1 Jun 2012 13:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WXBKgDZO-oJ for ; Fri, 1 Jun 2012 13:55:41 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED4921F8A07 for ; Fri, 1 Jun 2012 13:55:39 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 1E23F33D043; Fri, 1 Jun 2012 20:55:38 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Eric Rescorla References: <20120601164205.25357.54620.idtracker@ietfa.amsl.com> <4FC8F1AF.2040409@stpeter.im> From: Geoffrey Keating Date: 01 Jun 2012 13:55:37 -0700 In-Reply-To: Message-ID: Lines: 32 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tls@ietf.org Subject: Re: [TLS] Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 01 Jun 2012 20:55:42 -0000 Eric Rescorla writes: > On Fri, Jun 1, 2012 at 12:15 PM, Yngve N. Pettersen (Developer Opera > Software ASA) wrote: > > - Update sec. 3.1 to use RFC 6125 for the server identity. > > I'm not sure I agree with this. 2818 is intended to document HTTPS client > behavior. This may or may not be what we recommend for other protocols > (and indeed, the terms under which 6125 was approved included that > it not override 2818 for HTTPS). One substantive change here is that instead of "MUST" for using the commonName field, it would become "MAY". I think this is an appropriate change, especially given that clients will not always accept the commonName field (for example, if it contains spaces, or if it isn't in DNS 'preferred name syntax', or if the certificate does not have an extendedKeyUsage field indicating it is intended for server authentication). Another change is that wildcards are also optional in RFC 6215, and in particular 6215 recommends a more restricted wildcard match than 2818 requires. I think to promote interoperability, 2818bis should specify that wildcards MUST be accepted but SHOULD be accepted only in the left-most label. Since 2818 is presently just Informational, and was intended to describe current practice, I wouldn't describe these as changes, but rather as corrections. Or, perhaps, an 'update', since current practice has changed in the 12 years since the RFC was published! I would oppose moving 2818 to Proposed Standard without the commonName correction, as this would introduce a security flaw. From ekr@rtfm.com Fri Jun 1 14:06:32 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BA411E80E2 for ; Fri, 1 Jun 2012 14:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SaQoVOXrIhY for ; Fri, 1 Jun 2012 14:06:31 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A2FDE11E8097 for ; Fri, 1 Jun 2012 14:06:31 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1736695vbb.31 for ; Fri, 01 Jun 2012 14:06:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=3JSSB/K8tIUv1ED3RnI48BCrZ2GcZNNploe6u7fUUB4=; b=n8GheIGQHbhzorQQ2oVRNVjAQMMqiCRSUvSzoSNbXBDHmUilyOQoReMKl+hygvSqXO uG4iDxwpkZ8EkN4sm5jsiZZpt2QL7iZZje/0WIiakh8u5V7+cfkZKAJN4o6RRqho+Y5t TBRCslo4xkSbt6crJBsW/Us/Wu0xVcLP5AKQwR1xZddYE/6IO3wLyrZIn9IZ/0c5v4w/ eGDCn/C286bwAmKmIqszhVY4o5hrCaXqNtZffsCNbOUirzGL1jnLskoufA6qpzmFA3Cz bX5+Hus8b/WeRi5co8SvhbVwtjk7j8r2EyhROS0vpX2yur2Pnmcd3elNLV9JMU7ETLbv keiA== Received: by 10.52.88.170 with SMTP id bh10mr816595vdb.11.1338584791099; Fri, 01 Jun 2012 14:06:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Fri, 1 Jun 2012 14:05:50 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: References: <20120601164205.25357.54620.idtracker@ietfa.amsl.com> <4FC8F1AF.2040409@stpeter.im> From: Eric Rescorla Date: Fri, 1 Jun 2012 14:05:50 -0700 Message-ID: To: Geoffrey Keating Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkUgCeZBgXz3BU5qm3fVFpeJqxHg0G7DUqRQRbJpJ+n68Vp+k6MuD+3rK+ku88YoGhJ+mSx Cc: tls@ietf.org Subject: Re: [TLS] Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 01 Jun 2012 21:06:33 -0000 On Fri, Jun 1, 2012 at 1:55 PM, Geoffrey Keating wrote: > Eric Rescorla writes: > >> On Fri, Jun 1, 2012 at 12:15 PM, Yngve N. Pettersen (Developer Opera >> Software ASA) wrote: >> > - Update sec. 3.1 to use RFC 6125 for the server identity. >> >> I'm not sure I agree with this. 2818 is intended to document HTTPS clien= t >> behavior. This may or may not be what we recommend for other protocols >> (and indeed, the terms under which 6125 was approved included that >> it not override 2818 for HTTPS). > > One substantive change here is that instead of "MUST" for using the > commonName field, it would become "MAY". =A0I think this is an > appropriate change, especially given that clients will not always > accept the commonName field (for example, if it contains spaces, or if > it isn't in DNS 'preferred name syntax', I'm not sure I follow this. If the CN isn't a valid domain name, then won't it fail to match the DNS name it is intended to match? What am I missing? > or if the certificate does > not have an extendedKeyUsage field indicating it is intended for > server authentication). My read of this note suggests that at least NSS (and thus potentially Firefox and Chrome) does not enforce EKU's presence. http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn3.html > Another change is that wildcards are also optional in RFC 6215, and in > particular 6215 recommends a more restricted wildcard match than 2818 > requires. =A0I think to promote interoperability, 2818bis should specify > that wildcards MUST be accepted but SHOULD be accepted only in the > left-most label. > > Since 2818 is presently just Informational, and was intended to > describe current practice, I wouldn't describe these as changes, but > rather as corrections. =A0Or, perhaps, an 'update', since current > practice has changed in the 12 years since the RFC was published! My view is that if we republish this document (at any level) , it should be made to conform to common practice. -Ekr From geoffk@geoffk.org Fri Jun 1 14:51:15 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C51C11E809A for ; Fri, 1 Jun 2012 14:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WktkcSzmalM for ; Fri, 1 Jun 2012 14:51:14 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id B8A1D11E80E2 for ; Fri, 1 Jun 2012 14:51:14 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id C0EBA33D043; Fri, 1 Jun 2012 21:51:11 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Eric Rescorla References: <20120601164205.25357.54620.idtracker@ietfa.amsl.com> <4FC8F1AF.2040409@stpeter.im> From: Geoffrey Keating Date: 01 Jun 2012 14:51:11 -0700 In-Reply-To: Message-ID: Lines: 45 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 01 Jun 2012 21:51:15 -0000 Eric Rescorla writes: > On Fri, Jun 1, 2012 at 1:55 PM, Geoffrey Keating wrot= e: > > Eric Rescorla writes: > > > >> On Fri, Jun 1, 2012 at 12:15 PM, Yngve N. Pettersen (Developer Opera > >> Software ASA) wrote: > >> > - Update sec. 3.1 to use RFC 6125 for the server identity. > >> > >> I'm not sure I agree with this. 2818 is intended to document HTTPS cli= ent > >> behavior. This may or may not be what we recommend for other protocols > >> (and indeed, the terms under which 6125 was approved included that > >> it not override 2818 for HTTPS). > > > > One substantive change here is that instead of "MUST" for using the > > commonName field, it would become "MAY". =C2=A0I think this is an > > appropriate change, especially given that clients will not always > > accept the commonName field (for example, if it contains spaces, or if > > it isn't in DNS 'preferred name syntax', >=20 > I'm not sure I follow this. If the CN isn't a valid domain name, then > won't it fail to match the DNS name it is intended to match? > What am I missing? Suppose you have a cookie for ".example.com" which I'd like to steal. I MITM you but you're using SSL and the cookie is marked as 'secure' so I can't just grab it. I manage to acquire a valid e-mail certificate with a common name of "somename@mail.example.com". Now I fake your DNS so that 'somename@mail.example.com' appears to be a valid hostname (that is, I cause your DNS request to return an A record for 'somename@mail' in the domain 'example.com') pointing at my server, and wait for you to open a non-TLS web page, in which I inject HTML which includes a frame or an image from 'https://somename%40mail.example.com/somefile'. The cookie will be sent as part of this request, and it'll be sent to my server. The name 'somename@mail' is not in the 'preferred name syntax' but DNS will quite happily serve it---DNS labels are 8-bit strings that can even contain NUL characters. Another approach is that I could get a certificate with a common name of 'Some Name'. If your DNS search path is set to include 'example.com' (or if I can force this by controlling your DHCP), I might be able to do the same thing with a URL of 'https://Some%20Name/somefile'. From stpeter@stpeter.im Fri Jun 1 14:51:32 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E96D11E810C for ; Fri, 1 Jun 2012 14:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.686 X-Spam-Level: X-Spam-Status: No, score=-102.686 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oJ6OTGLrBJM for ; Fri, 1 Jun 2012 14:51:31 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD5B11E8081 for ; Fri, 1 Jun 2012 14:51:31 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3E90640075; Fri, 1 Jun 2012 16:08:06 -0600 (MDT) Message-ID: <4FC93962.90906@stpeter.im> Date: Fri, 01 Jun 2012 15:51:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <20120601164205.25357.54620.idtracker@ietfa.amsl.com> <4FC8F1AF.2040409@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Geoffrey Keating , tls@ietf.org Subject: Re: [TLS] Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 01 Jun 2012 21:51:32 -0000 On 6/1/12 3:05 PM, Eric Rescorla wrote: > On Fri, Jun 1, 2012 at 1:55 PM, Geoffrey Keating wrote: >> Eric Rescorla writes: >> >>> On Fri, Jun 1, 2012 at 12:15 PM, Yngve N. Pettersen (Developer Opera >>> Software ASA) wrote: >>>> - Update sec. 3.1 to use RFC 6125 for the server identity. >>> >>> I'm not sure I agree with this. 2818 is intended to document HTTPS client >>> behavior. This may or may not be what we recommend for other protocols >>> (and indeed, the terms under which 6125 was approved included that >>> it not override 2818 for HTTPS). >> >> One substantive change here is that instead of "MUST" for using the >> commonName field, it would become "MAY". I think this is an >> appropriate change, especially given that clients will not always >> accept the commonName field (for example, if it contains spaces, or if >> it isn't in DNS 'preferred name syntax', > > I'm not sure I follow this. If the CN isn't a valid domain name, then > won't it fail to match the DNS name it is intended to match? > What am I missing? Jeff and I covered the Common Name topic in RFC 6125 (see for instance Section 2.3 and Section 6.4.4). Basically we tried to push folks in the direction of deprecating Common Name in favor of subjectAltName entries of type dNSName (or other strongly typed data fields such as SRVName and uniformResourceIdentifier). We had some degree of success, but we still allow CN checking if the presented certificate does not contain DNS-ID, SRV-ID, or URI-ID. Peter -- Peter Saint-Andre https://stpeter.im/ From ekr@rtfm.com Fri Jun 1 14:59:34 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D715A21F887D for ; Fri, 1 Jun 2012 14:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.91 X-Spam-Level: X-Spam-Status: No, score=-102.91 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3z+rego6LYI for ; Fri, 1 Jun 2012 14:59:34 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2A91B21F887C for ; Fri, 1 Jun 2012 14:59:34 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1762284vbb.31 for ; Fri, 01 Jun 2012 14:59:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=pXDufyz1I9kxuzzZn1vTQl3hC4KzrnJ0H9oUWvMUxOY=; b=OudtDd1eWpyHg3TOK4cGjtOCi7O7TNWZbBYbpqr1mG4TJWF1bz9oABa09hmUrc4ZSQ KVNZhZ1o1aICxnuDLTNGfQVFu00QCD1GExGpmxYTEXDaDh2ukb93G1y7EX5D15AooFbv 8tpfy5vnoenit0+mweWIdZJ3fYYfxMIcFw4EZvJ11Ef0IzkFk5fa+ccregH/P8BmLhGT llP5QfdRIM0U7rp+WcN+vKT/JJt+U0SHKMIBA2OTciRTDDu+nd3L7pNVchkV1GfiYCJm 9dUUvCUMhIg2HjYVSl5pf+v+0LljLA58bWMXnq355csMP9/FFgZI1VkDtEH3BXMdYG+G vzog== Received: by 10.52.88.170 with SMTP id bh10mr944326vdb.11.1338587973579; Fri, 01 Jun 2012 14:59:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Fri, 1 Jun 2012 14:58:53 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: References: <20120601164205.25357.54620.idtracker@ietfa.amsl.com> <4FC8F1AF.2040409@stpeter.im> From: Eric Rescorla Date: Fri, 1 Jun 2012 14:58:53 -0700 Message-ID: To: Geoffrey Keating Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnsNIbj89Uvi23IKKqKygkIIg2+R46XQGA7qc1ILUojBr9jg0PzZCAjHaJXukBL8mDLOCXu Cc: tls@ietf.org Subject: Re: [TLS] Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 01 Jun 2012 21:59:34 -0000 On Fri, Jun 1, 2012 at 2:51 PM, Geoffrey Keating wrote: > Eric Rescorla writes: > >> On Fri, Jun 1, 2012 at 1:55 PM, Geoffrey Keating wro= te: >> > Eric Rescorla writes: >> > >> >> On Fri, Jun 1, 2012 at 12:15 PM, Yngve N. Pettersen (Developer Opera >> >> Software ASA) wrote: >> >> > - Update sec. 3.1 to use RFC 6125 for the server identity. >> >> >> >> I'm not sure I agree with this. 2818 is intended to document HTTPS cl= ient >> >> behavior. This may or may not be what we recommend for other protocol= s >> >> (and indeed, the terms under which 6125 was approved included that >> >> it not override 2818 for HTTPS). >> > >> > One substantive change here is that instead of "MUST" for using the >> > commonName field, it would become "MAY". =A0I think this is an >> > appropriate change, especially given that clients will not always >> > accept the commonName field (for example, if it contains spaces, or if >> > it isn't in DNS 'preferred name syntax', >> >> I'm not sure I follow this. If the CN isn't a valid domain name, then >> won't it fail to match the DNS name it is intended to match? >> What am I missing? > > Suppose you have a cookie for ".example.com" which I'd like to steal. > I MITM you but you're using SSL and the cookie is marked as 'secure' > so I can't just grab it. =A0I manage to acquire a valid e-mail > certificate with a common name of "somename@mail.example.com". =A0Now I > fake your DNS so that 'somename@mail.example.com' appears to be a valid > hostname (that is, I cause your DNS request to return an A record for > 'somename@mail' in the domain 'example.com') pointing at my server, and > wait for you to open a non-TLS web page, in which I inject HTML which > includes a frame or an image from > 'https://somename%40mail.example.com/somefile'. =A0The cookie will be sen= t > as part of this request, and it'll be sent to my server. > > The name 'somename@mail' is not in the 'preferred name syntax' but DNS > will quite happily serve it---DNS labels are 8-bit strings that can > even contain NUL characters. OK, I see the issue. I do wonder how a browser would actually behave in thi= s case. I.e., I would hope that it would either parse this as https://mail.example.com/ with a username of somename or alternately expect that the certificate cont= ain the %40, but regardless I agree it's not great. > Another approach is that I could get a certificate with a common name > of 'Some Name'. =A0If your DNS search path is set to include > 'example.com' (or if I can force this by controlling your DHCP), I > might be able to do the same thing with a URL of > 'https://Some%20Name/somefile'. Wouldn't this be an issue with or without a space? I.e., I get a certificat= e with CN "foo" and then serve https://foo/? -Ekr From yngve@opera.com Mon Jun 4 03:31:46 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF32821F87A4 for ; Mon, 4 Jun 2012 03:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdELUTp-zuw2 for ; Mon, 4 Jun 2012 03:31:45 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6E921F8771 for ; Mon, 4 Jun 2012 03:31:44 -0700 (PDT) Received: from acorna.invalid.invalid (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q54AVbSH024486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Jun 2012 10:31:38 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Rob Stradling" References: <20120509153513.11861.32080.idtracker@ietfa.amsl.com> <4FC75249.3050805@comodo.com> Date: Mon, 04 Jun 2012 12:31:39 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: <4FC75249.3050805@comodo.com> User-Agent: Opera Mail/11.64 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] CRL Stapling? (was Re: I-D Action: draft-ietf-tls-multiple-cert-status-extension-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Mon, 04 Jun 2012 10:31:47 -0000 On Thu, 31 May 2012 13:13:13 +0200, Rob Stradling wrote: > Yngve, > > IIRC, when Opera does an online revocation check, it currently checks > CRLs for intermediate CA certificates and OCSP for end-entity > certificates. This makes sense because: > - CRLs covering intermediate CA certificates tend to be roughly the > same size (sometimes smaller!) as the equivalent OCSP Responses (since > it's quite rare for intermediate CA certificates to be revoked). > - Possessing a current CRL means you won't have to do an online > revocation check if you encounter another certificate issued by the same > issuer. > > How would you feel about updating the multi-stapling I-D so that it > permits CRLs to be stapled (with a note to implementers that they should > only staple CRLs that are deemed to be "small enough")? Like Martin Rex, I am concerned that this would significantly increase the complexity of the system: - The servers would have to download both, and then decide which to use. - Clients might need to associate the CRL data with the relevant CRL URL in their cache (in case the client can use it later), but this might lead to cache poisoning (the CRL might be valid, but it has been obsoleted by a newer CRL revoking some cert). - The record format would have to be adapted, possibly including a datatype for each entry in the list, alternatively a completely new record (which would assume just one datatype was used for the intermediates) - Each server having a cert from the same CA would each send the CRL from that CA, which might require duplicate resolving if the CRL is newer than the one currently cached. - This is not suitable for the cached info extension for caching across multiple servers: There might be a lot of these entries, increasing handshake size, and it might be abused to learn which sites the user have visited, since the extension must be sent before we know which certificate the site will present. All in all, this adds so much complexity that I don't think it would be worth the effort. > Simply adding something like "case crl_multi: CRLList;" to your > definition of CertificateStatus.response would be problematic, because > it would require the server to staple a (potentially huge!) CRL for the > end-entity certificate too. So... > > How about changing the scope of the multi-stapling I-D so that it *only* > covers the intermediate CA certificate(s) in the chain? > > > With this approach, an end-entity OCSP Response could be stapled using > the RFC6066 TLS extension, and the intermediate CRL(s) could be stapled > using the new multi-stapling TLS extension. This would be even more complex, as we would either need a new handshake message for the new extension, or allow multiple messages, both of which would change the current TLS state engine. > > (End-entity certificate stapling is already defined in RFC6066 and this > existing TLS extension is already supported by many clients and servers. > So why not make the multi-stapling TLS extension complement it, rather > than replace it?) > > > On 09/05/12 16:35, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Transport Layer Security >> Working Group of the IETF. >> >> Title : The TLS Multiple Certificate Status Request Extension >> Author(s) : Yngve N. Pettersen >> Filename : draft-ietf-tls-multiple-cert-status-extension-00.txt >> Pages : 9 >> Date : 2012-05-09 >> >> This document defines the Transport Layer Security (TLS) Certificate >> Status Version 2 Extension to allow clients to specify and support >> multiple certificate status methods. Also defined is a new method >> based on the Online Certificate Status Protocol (OCSP) that servers >> can use to provide status information not just about the server's >> own >> certificate, but also the status of intermediate certificates in the >> chain. >> >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-tls-multiple-cert-status-extension-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-multiple-cert-status-extension-00.txt >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension/ >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ******************************************************************** From agl@google.com Tue Jun 5 13:39:48 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5238521F8512 for ; Tue, 5 Jun 2012 13:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMU6aIcbYDsu for ; Tue, 5 Jun 2012 13:39:47 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B2D0C21F87D2 for ; Tue, 5 Jun 2012 13:39:47 -0700 (PDT) Received: by yenq13 with SMTP id q13so4873246yen.31 for ; Tue, 05 Jun 2012 13:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record; bh=dFTN6NVdRQfHUXHtwGNOTcZ+H8psYGsGuXNtTlhrtCU=; b=M0rgEthWpPPBVtdxKZ2M9dBV3cmZ4NmTCLbth0lK1hL7qkW0mVuGsB2/wHMqgdt5GL DsFOe9T9d8ga0nOSCA5BDG/SuUhSDQC7N/Ehh51scQO3F4QEb02OY/2HdauvqnMyNSzm sO14m76KrUue5beMxlg7f/dWceQybRby19OCh2FwzJBqZtz7fHl4lRe8eh3aybDEEXKP xpGNnnQSvieSgbPJX5eEIe2tpZBoibKlw5RsLnkLludy0thFysyiRgtxCs7DMbe6I+3u RSagVjag21rmWhqkYAEZsZ/4RD0cxYea1MGzagDCfyW0H1YMuSWCpH+3XiWvGKzLcDXX jj9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record:x-gm-message-state; bh=dFTN6NVdRQfHUXHtwGNOTcZ+H8psYGsGuXNtTlhrtCU=; b=moeaYWOaeiufHvASCr4dDoVr8pNlcfHwkDyq8O8He1ZQ364USto2OXrhMHV4tiANg2 sspWbBZ4zH0jS4ZtI0knGib7DKHeKM51P7IJtntrIzXS0G8ab1qyjevGdy8MwtXO/eGK OfpAWAnBChzJQzx2LJ7O1JRmK0rJ8ASuaQ9W5bLQAJTQYyfb0fvTFxIXd2JZec/cY4Ob J8wPV11FsT8eWcNg6k/02r+E1dtHxRZY4DLsGvfSkUAc+YV9sJwF7RwFqMbTetmP9i3R gEe9thHGFiq3WAbnOAWfTimhFPO1GTzmUoevwpRTFV97MCFi/BhWgzRlMqVkrrf9PJTE t/HA== Received: by 10.50.163.99 with SMTP id yh3mr4358881igb.53.1338928786955; Tue, 05 Jun 2012 13:39:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.163.99 with SMTP id yh3mr4358866igb.53.1338928786788; Tue, 05 Jun 2012 13:39:46 -0700 (PDT) Received: by 10.231.5.201 with HTTP; Tue, 5 Jun 2012 13:39:46 -0700 (PDT) Date: Tue, 5 Jun 2012 16:39:46 -0400 Message-ID: From: Adam Langley To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlSdFWIDfNhQHaotoMWKSGxusI1cyRiFXnTkkDJSqPL0dX+0fhAXsr809miMg9sOOVYWk7sR1GyBFxBTM2QPdT6rUkcPBh6rr5TljIhTlBRuSlmheHjepn31+2gUJ+KV25TdWvb Subject: [TLS] Cipher suite values to indicate TLS capability X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Tue, 05 Jun 2012 20:39:48 -0000 (I'm floating this idea before implementing it.) All major HTTPS clients (and possibly other TLS clients too) implement fallback in order to workaround buggy networks and buggy servers. If a handshake fails with any one of a number of spoofable errors, the client will retry with more conservative options enabled. Eventually the client will retry the connection with vanilla SSLv3. There is no indication that the world is going to improve to the point where we can remove this fallback any time soon. About 1% of connections still need to do it. However, with the downgrade to SSLv3 we loose an important security feature: ECDHE. As SSLv3 doesn't support ECDHE, an attacker can cause the key-agreement algorithm to switch from ECDHE-RSA to RSA (this affects Google at least). On the server side, we're not going to switch on multiplicative DH at a strength similar to P-256 because of the DoS impact so clients will loose forward security. Also, with a plain RSA ciphersuite, it's possible for an attacker with the server's private key to decrypt the pre-master secret and assume control of a TLS connection. This means that the attacker will be authenticated with any client-certificate used, something that isn't possible with forward secure ciphersuites. So I'd like to introduce TLS_CAPABLE_SCSV (0x00fe) in SSLv3 handshakes. TLS_EMPTY_RENEGOTIATION_INFO_SCSV has shown that we can deploy new ciphersuites for SSLv3 and the semantics of TLS_CAPABLE_SCSV would be that servers would reject any SSLv3 handshakes that included this ciphersuite with a fatal error. (Thus TLS_CAPABLE_SCSV would only be included when the handshake was the result of a fallback.) That begs the question of whether we should introduce TLS_1_1_CAPABLE_SCSV and TLS_1_2_CAPABLE_SCSV. At the moment we don't have any critical security benefits in TLS 1.1 or 1.2 that an attacker could deny us by forcing a fallback, therefore I don't see a pressing need for them at the moment. If there aren't any solid objections, I'll write up a draft. Cheers AGL From paul.hoffman@vpnc.org Tue Jun 5 14:17:18 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00CE21F87E7 for ; Tue, 5 Jun 2012 14:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkxv4SpZU2Av for ; Tue, 5 Jun 2012 14:17:18 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D6CBA21F87E9 for ; Tue, 5 Jun 2012 14:17:17 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q55LHGWC052187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 5 Jun 2012 14:17:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Jun 2012 14:17:16 -0700 References: <4FCE6431.6050808@ieca.com> To: tls@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [TLS] Fwd: [saag] Pinning X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Tue, 05 Jun 2012 21:17:18 -0000 =46rom the SAAG mailing list, but appropriate here. I bet that Sean = would appreciate all discussion to go on on the SAAG mailing list... Begin forwarded message: > From: Sean Turner > Subject: [saag] Pinning > Date: June 5, 2012 12:55:29 PM PDT > To: saag@ietf.org >=20 > All, >=20 > There are many proposals for how to say which key or certificate or = trust anchor should be used by the client in a TLS session that it is = about to open. These proposals include making that decision in the DNS = (https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/), in the = application after TLS has happened once, to be remembered in the future = (https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/), and = in the TLS handshake (https://datatracker.ietf.org/doc/draft-perrin = tls-tack/). If more than one of these protocols are deployed, = operational mistakes could lead to a client getting conflicting = information. >=20 > Similarly, there are also proposals on how to say whether or not a = client should expect to see a particular service running under TLS. = These proposals include making that indication in the DNS (draft = hoffman-server-has-tls, expired but might be revived) and in the = application after TLS has happened once, to be remembered in the future = (https://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport = sec/). If more than one of these protocols are deployed, operational = mistakes could lead to a client getting conflicting information. >=20 > Is a standards-track operations statement needed to describe the = choices that a TLS server administrator has, and to deal with conflicts = between the proposals? >=20 > spt > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From agl@google.com Tue Jun 5 14:23:13 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0D821F884C for ; Tue, 5 Jun 2012 14:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AADk5ODJkw2D for ; Tue, 5 Jun 2012 14:23:13 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E7A2421F8841 for ; Tue, 5 Jun 2012 14:23:12 -0700 (PDT) Received: by ghbg16 with SMTP id g16so5282276ghb.31 for ; Tue, 05 Jun 2012 14:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-system-of-record; bh=3s9T5vm9Cl+QLSadj6mNXKtvwd8XO1Tay0YLhE7AG4Y=; b=YQT2MIorMMKHzmRs7LeWSnlgnawXQg6ejLtbhSbi970oFO9o7d++JZrIvseufBwTSP N7tQO0KzsS9XcRKMUGc/fMtEJl6kNVx5T84edCTrTSOMYEgED9t9yLIfXfTtYv2BIpET oPkRazxBXSlVJg1CrTUWF/B8sy2xbzXTwOpgVjfSBD2tAt9T82xR8bNySnOYXxBFgpQU Cxsonv7Ea+70zKOSpSpeeKIIHHzDcInE5aNaoygnYejNr3BzP2ANwAYozk0TAseI//FW XqQxebmnkqwet+jD+QAXZm7YcGQ7lSEXKZWgk8HiHR/gD1cJ8T69kgTHC116komMgtpD fWIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-system-of-record:x-gm-message-state; bh=3s9T5vm9Cl+QLSadj6mNXKtvwd8XO1Tay0YLhE7AG4Y=; b=GkvMyPWdF76dTL2nsAnyKyzI6F7+ZNRflwiLFyRfvihV0hdf4QIOyLiaX4CYzQdXAl B7WW9B+PqCaBIcgWvGPixDs3bDadYhzsssNIGsRgYyHOMaV0XDgdVMYuhOaagGWn0Uq9 RezIOhVIideZdIi5Vqe+3PJ6mxt+0SuV4D+F9aG+ecgaIeE9hdgGjy2rJlbcz+h26B/c RAbaC9xhNsccbvNFk7V5k7Yk3+d/jBDfo6mKmvGAffk+VpwRfpK2scAYCqegbWZtd6Ip zf/mkxc6hC0kZJEeyZ0Pe4xM5Vgml1qIVDi6oHElCe8HvChQtueIrNF+dbEztcl2QgUZ fhpA== Received: by 10.50.57.167 with SMTP id j7mr4491338igq.53.1338931392065; Tue, 05 Jun 2012 14:23:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.57.167 with SMTP id j7mr4491335igq.53.1338931391972; Tue, 05 Jun 2012 14:23:11 -0700 (PDT) Received: by 10.231.5.201 with HTTP; Tue, 5 Jun 2012 14:23:11 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Jun 2012 17:23:11 -0400 Message-ID: From: Adam Langley To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQncxf1x0REfkIqJrETuPNmYJogsT5KqGvmbPenlG+XUSMX2hePDU94Cho5MIXSwrQY1DMrZscIYMicixIqEbNrcoDIRhGw2x6S/6Vqxz8aacmLp/c29ljRaLGcWfSpBjDJ0+qae Subject: Re: [TLS] Cipher suite values to indicate TLS capability X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Tue, 05 Jun 2012 21:23:13 -0000 wtc pointed out http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt from last year. I didn't build on that because it didn't seem to go anywhere, sadly. Although it's worth noting that my previous comment: "This doesn't really make the deployment of new TLS versions that much easier. The client would still have to try 1.2, 1.1, 1.0 etc. What would be helpful is if the server, seeing a TLS 1.2 SCSV, treated the client as if it has advertised 1.2." Has turned out to be false. We're now aware of networks which filter on the version in the returned ServerHello. Yngve's point about just using the renegotiation extension as an indication, client-side, that we shouldn't have done a fallback is still a possibility. Cheers AGL From geoffk@geoffk.org Tue Jun 5 16:16:33 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6BC921F863C for ; Tue, 5 Jun 2012 16:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcmX+3ZPjl5V for ; Tue, 5 Jun 2012 16:16:33 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB5D21F8639 for ; Tue, 5 Jun 2012 16:16:33 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id E771933D077; Tue, 5 Jun 2012 23:16:31 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Adam Langley References: From: Geoffrey Keating Date: 05 Jun 2012 16:16:31 -0700 In-Reply-To: Message-ID: Lines: 51 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tls@ietf.org Subject: Re: [TLS] Cipher suite values to indicate TLS capability X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Tue, 05 Jun 2012 23:16:33 -0000 Adam Langley writes: > (I'm floating this idea before implementing it.) > > All major HTTPS clients (and possibly other TLS clients too) implement > fallback in order to workaround buggy networks and buggy servers. If a > handshake fails with any one of a number of spoofable errors, the > client will retry with more conservative options enabled. Eventually > the client will retry the connection with vanilla SSLv3. > > There is no indication that the world is going to improve to the point > where we can remove this fallback any time soon. About 1% of > connections still need to do it. > > However, with the downgrade to SSLv3 we loose an important security > feature: ECDHE. As SSLv3 doesn't support ECDHE, an attacker can cause > the key-agreement algorithm to switch from ECDHE-RSA to RSA (this > affects Google at least). On the server side, we're not going to > switch on multiplicative DH at a strength similar to P-256 because of > the DoS impact so clients will loose forward security. Also, with a > plain RSA ciphersuite, it's possible for an attacker with the server's > private key to decrypt the pre-master secret and assume control of a > TLS connection. This means that the attacker will be authenticated > with any client-certificate used, something that isn't possible with > forward secure ciphersuites. Could you simply send the ECDHE values anyway? If the remote end accepts them, you can reasonably be sure you're under a downgrade attack (but see below). > So I'd like to introduce TLS_CAPABLE_SCSV (0x00fe) in SSLv3 > handshakes. TLS_EMPTY_RENEGOTIATION_INFO_SCSV has shown that we can > deploy new ciphersuites for SSLv3 and the semantics of > TLS_CAPABLE_SCSV would be that servers would reject any SSLv3 > handshakes that included this ciphersuite with a fatal error. (Thus > TLS_CAPABLE_SCSV would only be included when the handshake was the > result of a fallback.) One problem with this proposal is that in practice it isn't really indicating 'TLS 1.0 capable'. A system might actually support TLS 1.0, but not extensions, or it might have trouble parsing the particular EC extensions you sent, or some other extension, or it might not like the negotiated cipher suite, or the total number of proposed cipher suites, or the compression algorithm. Or it could have mysteriously failed (once) for reasons unconnected to the TLS negotiation. So, I don't think this is a good candidate for standardization. You'd need to come up with a 'preferred' client hello, and then have the cipher suite value mean very specifically that the preferred client hello should have been accepted... From agl@google.com Tue Jun 5 16:35:38 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C92E11E8086 for ; Tue, 5 Jun 2012 16:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4mjDgoomfeL for ; Tue, 5 Jun 2012 16:35:37 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A0D3921F86F9 for ; Tue, 5 Jun 2012 16:35:37 -0700 (PDT) Received: by yenq13 with SMTP id q13so5001999yen.31 for ; Tue, 05 Jun 2012 16:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=5gpANkNupz5i2Rd+/SU1CJQEUf6s7f3C1//DHctwcMI=; b=PwamFLA3PxmeNnPDSRlipypKLuFrxQfL6fgvnzrGCAJVMMX5p/5iaz58rgrPINwJhP YDK0GpCQnuH8dyZ98UwFooEyPIRwSndRDeizS//PQt15G2e0HqRGDn5mHBLfAhVXS/BP vxkPtlcb2wCgTstGUw0wMwKJAxprq510XoYuFxD96xeVucgoFKQjl9ZFEGy25IxcIrux nl09h70eKI/3kv/4LSMVeKrJuBeLOJULZeoEkd/d+XMdztW3smIMJfEXDtnSfKTULfKL 3vfVB0gpcIJpoBx4jjSXuC06IXAEnsK360shwrKuyrpRHuUZgtPaNr+jF8RTrwfLdMhl /hgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=5gpANkNupz5i2Rd+/SU1CJQEUf6s7f3C1//DHctwcMI=; b=Gccv3xkjuaPMwdA5cOJ43HXuGaC93SxUMqIzqxQajZwPO83mJYQgquqfTTFNoUTl9v ccLmewKAUMtOvt57En/QAXRoH6aAE8ljuOhX982tDy3rNSwmJ6w1cyqcuwpVY5rZWQ6k IfvrsMEPO+t12WeiSmgIZnbeBGMOdO52SyreMohjQzuSv8K07i1vUxjT/njd4KEEbBL6 hSZjDd6TFHfxWhC4Lm0Rw0olBwMcdmI8mbgUGEUmNWdXZLKSFH0AkqT86QMqmF+RoVoO c2/Lgsb4gcnHCOQx+53Cu/UZ9S4KC/OJCf70hQtbwF418ntXSsZ+dpNRCRmX0YDvLZY3 CpHA== Received: by 10.50.185.163 with SMTP id fd3mr4949122igc.22.1338939331568; Tue, 05 Jun 2012 16:35:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.185.163 with SMTP id fd3mr4949116igc.22.1338939331395; Tue, 05 Jun 2012 16:35:31 -0700 (PDT) Received: by 10.231.5.201 with HTTP; Tue, 5 Jun 2012 16:35:31 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Jun 2012 19:35:31 -0400 Message-ID: From: Adam Langley To: Geoffrey Keating Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQlV0+GegE0M8UiL2aGz7ddZflRm6+e+GJthPrxhsj3xWorpfK0kmdxhMVL/4Yft1rE2H3iB2vhEomGu65bltIzPHZED6Qmp7qFlMsPBq3GHGE2Mm62XtkVP2AIBajdpo0OGsJdQ Cc: tls@ietf.org Subject: Re: [TLS] Cipher suite values to indicate TLS capability X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Tue, 05 Jun 2012 23:35:38 -0000 On Tue, Jun 5, 2012 at 7:16 PM, Geoffrey Keating wrote: > Could you simply send the ECDHE values anyway? =C2=A0If the remote end > accepts them, you can reasonably be sure you're under a downgrade > attack (but see below). We would need to send both the ECDHE ciphersuites and the extensions outlining the acceptable curves and point formats. Adding all that would reasonably cause SSLv3-only servers to reject the ClientHello. > One problem with this proposal is that in practice it isn't really > indicating 'TLS 1.0 capable'. =C2=A0A system might actually support TLS > 1.0, but not extensions, or it might have trouble parsing the > particular EC extensions you sent, or some other extension, or it > might not like the negotiated cipher suite, or the total number of > proposed cipher suites, or the compression algorithm. =C2=A0Or it could > have mysteriously failed (once) for reasons unconnected to the TLS > negotiation. Well, all of those save the last are failures to implement TLS correctly, so then it's not TLS capable :) (As for transient network errors: these happen but fallback isn't intended to work around them. Whatever reconnection logic we might have is orthogonal to this and would be common between HTTP and HTTPS connections. We don't actually do fallback from TLS to SSLv3 for TCP level errors in Chrome.) Obviously this is a sacrifice of elegance on the alter of practical need. What the SCSV effectively says is that the server implements TLS to a level that was common at the time that servers started to be patched with SCSV support. That isn't perfect, or even good, but it is still very useful. Cheers AGL From geoffk@geoffk.org Tue Jun 5 16:41:45 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B268621F8736 for ; Tue, 5 Jun 2012 16:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFZ5xmjLwPDf for ; Tue, 5 Jun 2012 16:41:45 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id 47C5221F8734 for ; Tue, 5 Jun 2012 16:41:45 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id D7AD233D077; Tue, 5 Jun 2012 23:41:44 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Adam Langley References: From: Geoffrey Keating Date: 05 Jun 2012 16:41:44 -0700 In-Reply-To: Message-ID: Lines: 13 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Cipher suite values to indicate TLS capability X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Tue, 05 Jun 2012 23:41:45 -0000 Adam Langley writes: > On Tue, Jun 5, 2012 at 7:16 PM, Geoffrey Keating wrot= e: > > Could you simply send the ECDHE values anyway? =C2=A0If the remote end > > accepts them, you can reasonably be sure you're under a downgrade > > attack (but see below). >=20 > We would need to send both the ECDHE ciphersuites and the extensions > outlining the acceptable curves and point formats. Adding all that > would reasonably cause SSLv3-only servers to reject the ClientHello. Why would you need to send the extensions? (The RFC says they're optional.) From agl@google.com Tue Jun 5 16:51:49 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6689111E80A1 for ; Tue, 5 Jun 2012 16:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGVk6ZqLa5lx for ; Tue, 5 Jun 2012 16:51:48 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B9A8711E80A0 for ; Tue, 5 Jun 2012 16:51:48 -0700 (PDT) Received: by yhq56 with SMTP id 56so4942405yhq.31 for ; Tue, 05 Jun 2012 16:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=CBqFGYnfmDMf6HhBk7vNqkUEl3mn+/e8rYLvyGbqCXo=; b=nhI7VwB5anr+NOMFI6Z2zWDJ4Zfx/5o7UGpOanL8RGdJy8tc//piY5YppJokTcXldT s9zv0lyzNe1G4XfAcC6+rkYQUU6OiZ/Fwk3OZ/NRXAJFvkP5YHX6zJm1OdgINNNnYXE+ EwQgUEoq3IRu5HJCodlK+x+eqtpNx/Qn0LTl3jSxRw2Mnvk6oDel7W0BJVDRN8MKpohq vR30LEl2VWsJc6qD3Q6ZdY+yHHRK0WuWjssVA2HvXLedaGTaUb6/iqaSJRMKoAmWyIvw S48KbhCYSlFRnacwtNkFGtwO+47rZ1t4yGAPl4KOFtgvOQTwoweuhE5aI5N2eiKjx/X5 7h4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=CBqFGYnfmDMf6HhBk7vNqkUEl3mn+/e8rYLvyGbqCXo=; b=OdHqU/cTdLzuVh0xmgqQJPH/SRNjF7lX+CQO2T4PsfYUz01XCN0kkfFlwlNDGa+8hq XHP8HSrkcWov+7s5/ImR/zqmF1V2BKvLJ8WPAV4n/gFo+6H9uqpiQuf1H7ZU5rVqNHNk AhemALCAqB1sbf3308fJJetD9F3FrhnXeS3I8kntKdLT21KFxTLQUM1lh+mXKpRPiHEF GCFaXR8fdgqx05KHTuD6VZeU9jjvsfuRs228fRatWbJQI5LadSGkqfKIaD+rRiPuZ/z+ GbcVkzT/T6yVkYxVb+c36ZzWLf4C/Yh+10y5KRJlzvcMTmLyJIQdUkrNtYySxTxv+sxn PMOg== Received: by 10.42.62.211 with SMTP id z19mr5913354ich.2.1338940307874; Tue, 05 Jun 2012 16:51:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.62.211 with SMTP id z19mr5913349ich.2.1338940307777; Tue, 05 Jun 2012 16:51:47 -0700 (PDT) Received: by 10.231.5.201 with HTTP; Tue, 5 Jun 2012 16:51:47 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Jun 2012 19:51:47 -0400 Message-ID: From: Adam Langley To: Geoffrey Keating Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQmcpLKKIhxXkWJ1JuhSQs0pYNSoXl4CbIxeijeSMBZaofCvt8qvnQSwjDMUPW1VTm+A8ECQ1ILCIr5pN3Lm9q5FE569oLMnUiGsSRJJ8OArQDZbythj9eujVwOWX++MSq2ibSnn Cc: tls@ietf.org Subject: Re: [TLS] Cipher suite values to indicate TLS capability X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Tue, 05 Jun 2012 23:51:49 -0000 On Tue, Jun 5, 2012 at 7:41 PM, Geoffrey Keating wrote: > Why would you need to send the extensions? =C2=A0(The RFC says they're > optional.) Well, we could cross our fingers and hope that the server picks something acceptable I guess (or simply define the set of acceptable values for SSLv3). But extending SSLv3 to support ECDHE seems rather specific: There's also the issue of captive portals which tend to trigger fallbacks by doing things like sending HTTP replies on port 443. If the user authorises during the fallback process then we downgrade to SSLv3, omit SNI and throw a nasty certificate error for any SNI requiring domain names. I'd rather throw a network error than a certificate error that trains users to ignore them. (This has actually been happening to some of our users, although we significantly ameliorated it by being more aggressive in stepping back up to TLS after a fallback.) Cheers AGL From geoffk@geoffk.org Tue Jun 5 17:06:59 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A6A21F85BB for ; Tue, 5 Jun 2012 17:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gZ+iZPh7VRI for ; Tue, 5 Jun 2012 17:06:59 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id 30AEC21F8596 for ; Tue, 5 Jun 2012 17:06:59 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id A867033D077; Wed, 6 Jun 2012 00:06:56 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Adam Langley References: From: Geoffrey Keating Date: 05 Jun 2012 17:06:56 -0700 In-Reply-To: Message-ID: Lines: 21 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Cipher suite values to indicate TLS capability X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Wed, 06 Jun 2012 00:06:59 -0000 Adam Langley writes: > On Tue, Jun 5, 2012 at 7:41 PM, Geoffrey Keating wrot= e: > > Why would you need to send the extensions? =C2=A0(The RFC says they're > > optional.) >=20 > Well, we could cross our fingers and hope that the server picks > something acceptable I guess (or simply define the set of acceptable > values for SSLv3). But extending SSLv3 to support ECDHE seems rather > specific: I think I'll go out on a limb and say that there are not any SSLv3-only servers which actually support ECDHE, so if you fall back to SSLv3 and yet ECDHE gets picked, you're under a downgrade attack and the appropriate thing is to close that connection (and fall back up, or whatever). It doesn't matter what the server picks for the parameters, you'd never want to use them. Likewise there are probably not any SSLv3-only clients which support ECDHE, so if you're a server and you get such a request, you can probably close that connection too. From agl@google.com Tue Jun 5 17:44:28 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB2521F8622 for ; Tue, 5 Jun 2012 17:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9U89qgy8TELU for ; Tue, 5 Jun 2012 17:44:27 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 820EB21F8620 for ; Tue, 5 Jun 2012 17:44:27 -0700 (PDT) Received: by ggnc4 with SMTP id c4so5043434ggn.31 for ; Tue, 05 Jun 2012 17:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=VueRRcFASucKuev0kSXEO2F/0q2Uw29XhOJ4NpqRw+4=; b=NYxNHUdM0TPBjF8tBnWZ7nscF8YR6gds4q1bu8+PMB3vgdHzZOd+Ycp9mFSJsDxzJl oCJFNukjEi+aFH3cHpgugb5xUUpN1yJsZehVwEuBjfgYZjeDnri76fXyWKHrg/+ByK0+ PuZxXY7muNYxDoerCc3zoPRHwZw6flgQTrRY8nshxt1hScTuS/zc2IOyRAAWpDZfFkGP +cTTENqGV7XY7ThD+VpELEmIdz74P8qaKO60heTSrzI3v1xPoEd0MU5TZ24VRFlnaJAL xakR3h3N5xVvTjrUntERVxWfKVmIM+LEgax0CHp40TPAmLgqtADsjw/fJNs/7lusPytv 1+wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=VueRRcFASucKuev0kSXEO2F/0q2Uw29XhOJ4NpqRw+4=; b=YNZ+cNqMaHsTK2dCxN7TSNXZ1xhara0OvZs6+BY1zLEWaf/JZAKj/Jec8yDEdiZwaG 2alCpnEjE0o49QIlNtvpcYIoExXshjIlpoba8UFM3ZD5hy2L5tkOuvT3stl/b/on2amr JH8VJI4gaIA/JAphiDwepRejGqwsunZsCnlbqspSKXQE/+tg5A8BOkgF5VkTyAlDbXix +6vXS7E2Jnn2/4TwGcb8grKEekIda4iAF2wmymJIlwOWm/NmHuTYKWr4L06TGlGi3eY2 AVxfJPbm5bkMeAVbedIpZh0HVj56YP6XtrrbBFN1BEv07aQyLctID7LIq8xyJghLx9dJ OoaA== Received: by 10.42.150.136 with SMTP id a8mr12328368icw.42.1338943466539; Tue, 05 Jun 2012 17:44:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.150.136 with SMTP id a8mr12328361icw.42.1338943466426; Tue, 05 Jun 2012 17:44:26 -0700 (PDT) Received: by 10.231.5.201 with HTTP; Tue, 5 Jun 2012 17:44:26 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Jun 2012 20:44:26 -0400 Message-ID: From: Adam Langley To: Geoffrey Keating Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQk/Xs/Wo/wnnBFJObakEtqyKCwkrHfcdvIHuQJNlj0AZXSDdSuB9gHDRxrZGQ4k2ws9lFpBoSXSeEGnL9UoYWep88VN6Hr2JJOZ7AGRP3GzqVxzEKmwoHT+qkHAKEPC0oHxEyrm Cc: tls@ietf.org Subject: Re: [TLS] Cipher suite values to indicate TLS capability X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Wed, 06 Jun 2012 00:44:28 -0000 On Tue, Jun 5, 2012 at 8:06 PM, Geoffrey Keating wrote: > Likewise there are probably not any SSLv3-only clients which support > ECDHE, so if you're a server and you get such a request, you can > probably close that connection too. It sounds like you basically agree with the plan, you just want to reuse an ECDHE ciphersuite value for it :) Cheers AGL From chris@randomnonce.org Tue Jun 5 18:11:35 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E7311E80AC for ; Tue, 5 Jun 2012 18:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzKNWpoZZMRK for ; Tue, 5 Jun 2012 18:11:24 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BC9A611E80AB for ; Tue, 5 Jun 2012 18:11:22 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so1275721obb.31 for ; Tue, 05 Jun 2012 18:11:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=orcOVj74UPS/DdYF5aRq7aZSD+UDjqflASm5Fv5PTts=; b=HmdEUnGVJlNuKI+8YE1vo6q+wWjseuPrZWX4glxqDl6AFzce9Ymcf1sCX3KllCx3yP /SkptHpOzK3+d/aF99VKmd911hBumKOn49mHQqhaA9nd9vNXayb1IyeNGHfkT3alIGDO r5xG6iAknqtBl7DZMsU1RXOiWLJJ8YGHUyd1H40ceZFtkpR45KakxYJVGGqV0wIQspZE gGTw7Nv0zNuq9SSCviMyO2GDKe4UaHTmplOysxWid1+tC7bROuTwGniPC7by8YXe7FiY qYyYuL2wM0jJh6jixBvqJnK/euOxVkEUhnVRql1mbeNJjKiZ0Qt75FLfY+R0/ae5j1U6 K+3Q== MIME-Version: 1.0 Received: by 10.60.20.70 with SMTP id l6mr18918991oee.38.1338945082341; Tue, 05 Jun 2012 18:11:22 -0700 (PDT) Received: by 10.76.87.33 with HTTP; Tue, 5 Jun 2012 18:11:22 -0700 (PDT) X-Originating-IP: [98.117.34.27] In-Reply-To: References: Date: Tue, 5 Jun 2012 21:11:22 -0400 Message-ID: From: Chris Richardson To: Adam Langley Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmdaWWoTDSD37tJmZyHPqViwS8jTSnkznLDLM7Iei4Uk1g389M4j4wmV2jE3cPD7i/KMONG Cc: tls@ietf.org Subject: Re: [TLS] Cipher suite values to indicate TLS capability X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Wed, 06 Jun 2012 01:11:36 -0000 On Tue, Jun 5, 2012 at 4:39 PM, Adam Langley wrote: > However, with the downgrade to SSLv3 we loose an important security > feature: ECDHE. ... > So I'd like to introduce TLS_CAPABLE_SCSV (0x00fe) in SSLv3 > handshakes. TLS_EMPTY_RENEGOTIATION_INFO_SCSV has shown that we can > deploy new ciphersuites for SSLv3 and the semantics of > TLS_CAPABLE_SCSV would be that servers would reject any SSLv3 > handshakes that included this ciphersuite with a fatal error. Thinking through various scenarios... if I'm a TLS-capable server that does not support foward-secure cipher suites, what reason would I have any reason to reject an SSLv3 hello containing the TLS_CAPABLE_SCSV? -- Chris From wtc@google.com Tue Jun 5 18:18:39 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13C821F857A for ; Tue, 5 Jun 2012 18:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TGi77s1cIH6 for ; Tue, 5 Jun 2012 18:18:39 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE2321F856F for ; Tue, 5 Jun 2012 18:18:39 -0700 (PDT) Received: by ggnc4 with SMTP id c4so5060795ggn.31 for ; Tue, 05 Jun 2012 18:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=CS6AAeruK/rTCP+WJaYS6unJ29cDgki5V1zH7vGZ3Zc=; b=YyYdkS4tN21vH4JToLmfKreS6iGhgzmKTmZjJXuec3IGVcOeDCBbsIKVAkJu+Jk4DG cWfJQ/nCwVglcBQiTlIa4Ql0L/DMlQhN1nmLQyeUpEPC27Kq9INozvq7kiW2dFDaM6FH kykb9Yo7G8AO7W6/WkkkZouQBlsGnt/0pPHzxkKlTcinCm+2l68HgNPaPBu2s+BxyG2g 863H3C6AJpGzNHfAG7EIhj8TNRgOUa45K15CzEsrD9dEuKSyLqHCkR7sL3AG4Xhc2aeD kux6z74gP+hDgzVa9zzezBxaM6BCWDYKMMhuJso6aE3XiNq3/363Aj4OISvMaOW7BfwZ DDpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=CS6AAeruK/rTCP+WJaYS6unJ29cDgki5V1zH7vGZ3Zc=; b=kJUgptMjBSl7Shj/iUSEGLlrhiOsIDWiScnMYxuWYYm+XQHB5AjQAzpgyGrbS7KKjn TX3dITZLexwVDbhLz0AXanf/rKXUu7flr8tc83/z6vBwy0SncxcuIdDp2+Nu8zHmd1c5 i45yAF4yp0saO7kfyoJPSyaqwLY0Gss0eko7BABdCWlXXo5tLQ9PjpOFihahZSUKHwoh z4A+MDEvOAPr2R66hDxV2KLkZsMf7dLgY9BV+2Tg4z/yw+JCBegeH0AItMOAgNbgIyxR aKT5MWFnY1u6ki3Ebbr9nZ/gHHAz79qgFNXPr8WQJHTxbpdOl1Nx6xU/Z1F4tY1FRkxj EWSQ== Received: by 10.50.189.134 with SMTP id gi6mr5031590igc.55.1338945518410; Tue, 05 Jun 2012 18:18:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.189.134 with SMTP id gi6mr5031583igc.55.1338945518248; Tue, 05 Jun 2012 18:18:38 -0700 (PDT) Received: by 10.231.245.74 with HTTP; Tue, 5 Jun 2012 18:18:38 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Jun 2012 18:18:38 -0700 Message-ID: From: Wan-Teh Chang To: Adam Langley Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm+EyJ5WoRHfZKI25pHwkjedDaUruEwszHUlAOBJxGpJqt6lxgCdQGQt7tqOKv9uLbh3ZiBguNn4QZu00KcXaiiRiWXg15357qrwsCzD3j6kiKRwgdDH4KjpgDfGaal89EC4oh+ Cc: Geoffrey Keating , tls@ietf.org Subject: Re: [TLS] Cipher suite values to indicate TLS capability X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Wed, 06 Jun 2012 01:18:40 -0000 ECDHE is not the only feature we lose when downgrading to SSLv3. We also lost all the features implemented using TLS extensions, such as server name indication, OCSP stapling, and the ability to negotiate SPDY. It would be nice if the server could indicate support of TLS in a less destructive way than rejecting the handshake. Perhaps a new alert message at the warning level? As for TLS_1_1_CAPABLE_SCSV and TLS_1_2_CAPABLE_SCSV, it seems that TLS_1_2_CAPABLE_SCSV could be useful because TLS 1.2 is important to the people who want to avoid SHA-1 and MD5 or comply with NSA Suite B. Wan-Teh From ynir@checkpoint.com Tue Jun 5 22:17:32 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756E921F8625 for ; Tue, 5 Jun 2012 22:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.553 X-Spam-Level: X-Spam-Status: No, score=-10.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6A+q2ZmHJhS for ; Tue, 5 Jun 2012 22:17:31 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A2EAA21F85D7 for ; Tue, 5 Jun 2012 22:17:25 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (dlpgw.checkpoint.com [194.29.34.27]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q565HK3l026234; Wed, 6 Jun 2012 08:17:21 +0300 X-CheckPoint: {4FCEF3D5-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 6 Jun 2012 08:17:18 +0300 From: Yoav Nir To: Chris Richardson Date: Wed, 6 Jun 2012 08:17:24 +0300 Thread-Topic: [TLS] Cipher suite values to indicate TLS capability Thread-Index: Ac1Do6RTfnMiPnbtTCi2h281Y3yRaA== Message-ID: <002AA72F-D47E-4C7C-930C-D78A0E48D059@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 112984e98ce1382f3076532df01bd230e7a6e64ba5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Cipher suite values to indicate TLS capability X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Wed, 06 Jun 2012 05:17:32 -0000 On Jun 6, 2012, at 4:11 AM, Chris Richardson wrote: > On Tue, Jun 5, 2012 at 4:39 PM, Adam Langley wrote: >> However, with the downgrade to SSLv3 we loose an important security >> feature: ECDHE. > ... >> So I'd like to introduce TLS_CAPABLE_SCSV (0x00fe) in SSLv3 >> handshakes. TLS_EMPTY_RENEGOTIATION_INFO_SCSV has shown that we can >> deploy new ciphersuites for SSLv3 and the semantics of >> TLS_CAPABLE_SCSV would be that servers would reject any SSLv3 >> handshakes that included this ciphersuite with a fatal error. >=20 > Thinking through various scenarios... if I'm a TLS-capable server that > does not support foward-secure cipher suites, what reason would I have > any reason to reject an SSLv3 hello containing the TLS_CAPABLE_SCSV? Because the client says it supports TLS, but is connecting using SSLv3. Tha= t is evidence of a downgrade attack. Regardless of what benefit the attacke= r intends to get from downgrading the connection to SSLv3, it should be abo= rted.= From ynir@checkpoint.com Tue Jun 5 22:20:37 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A1C21F8595 for ; Tue, 5 Jun 2012 22:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2JV214gKfZA for ; Tue, 5 Jun 2012 22:20:37 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D987B21F8516 for ; Tue, 5 Jun 2012 22:20:36 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (dlpgw.checkpoint.com [194.29.34.27]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q565KSpo026657; Wed, 6 Jun 2012 08:20:28 +0300 X-CheckPoint: {4FCEF491-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 6 Jun 2012 08:20:26 +0300 From: Yoav Nir To: Wan-Teh Chang Date: Wed, 6 Jun 2012 08:20:32 +0300 Thread-Topic: [TLS] Cipher suite values to indicate TLS capability Thread-Index: Ac1DpBQeXARpW0p9RvSNIx1EHXG/Kw== Message-ID: <982A8992-3218-4C3A-9955-190848DD3216@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 112ad10e1bbcee3abb11e081c22dd07780f046b85e Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Geoffrey Keating , "tls@ietf.org" Subject: Re: [TLS] Cipher suite values to indicate TLS capability X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Wed, 06 Jun 2012 05:20:38 -0000 On Jun 6, 2012, at 4:18 AM, Wan-Teh Chang wrote: > ECDHE is not the only feature we lose when downgrading to SSLv3. We > also lost all the features implemented using TLS extensions, such as > server name indication, OCSP stapling, and the ability to negotiate > SPDY. >=20 > It would be nice if the server could indicate support of TLS in a less > destructive way than rejecting the handshake. Perhaps a new alert > message at the warning level? >=20 > As for TLS_1_1_CAPABLE_SCSV and TLS_1_2_CAPABLE_SCSV, it seems that > TLS_1_2_CAPABLE_SCSV could be useful because TLS 1.2 is important to > the people who want to avoid SHA-1 and MD5 or comply with NSA Suite B. TLS 1.1 may also be important to people, because it is not vulnerable to th= e BEAST attack. With TLS 1.0 you have to use RC4 to avoid being flagged by = PCI compliance scans and SSL Pulse. And NIST has long recommended to avoid RC4. Yoav= From n.mavrogiannopoulos@gmail.com Wed Jun 6 00:12:57 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FAB11E8094 for ; Wed, 6 Jun 2012 00:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHt6532vIwx7 for ; Wed, 6 Jun 2012 00:12:56 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E99F11E808C for ; Wed, 6 Jun 2012 00:12:56 -0700 (PDT) Received: by ghbg16 with SMTP id g16so5567580ghb.31 for ; Wed, 06 Jun 2012 00:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=BhyO9HYV1Eu7iaZRNCepb1rmUiSqRtYtCgqMJ1DWXDc=; b=mzAGOUnLNg2RAXldrxY7PSY89hlVsNpGRjR5c9R9yXHEgDT+U6WzGLe0vw6/iEslOz Q2yOtkMZ2boVkSYgvEGnjtV8mT3BuLya1goEiMfKFwRuKMU/8P+Ze3NoVHYtB4dF5n36 AtxUJ09CKmz+sSXI+8XftDVxJ+KWCLCSg31JN9x1nuzFGbgU8AiPShJtJYKm64wYIyn6 4NdQoGgOIGrT1aMP9/h4qyRav+VpE7n3HxDg3prbqns4fm8yVi2Jfm1muRTknFGLLiNP JzGdUDB+ZhDpdynlJ8kRfeVS75G/GocwrvL1fbD6coRHJZ/pVlo0sUGfk5UUfO7w3hN8 8aPg== MIME-Version: 1.0 Received: by 10.50.160.202 with SMTP id xm10mr5593584igb.10.1338966775513; Wed, 06 Jun 2012 00:12:55 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.231.80.15 with HTTP; Wed, 6 Jun 2012 00:12:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 6 Jun 2012 09:12:55 +0200 X-Google-Sender-Auth: T7Bf-OsNRaqCh2JH7W87awbFb5E Message-ID: From: Nikos Mavrogiannopoulos To: Adam Langley Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] Cipher suite values to indicate TLS capability X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Wed, 06 Jun 2012 07:12:57 -0000 On Tue, Jun 5, 2012 at 10:39 PM, Adam Langley wrote: [...] > However, with the downgrade to SSLv3 we loose an important security > feature: ECDHE. As SSLv3 doesn't support ECDHE, an attacker can cause > the key-agreement algorithm to switch from ECDHE-RSA to RSA (this > affects Google at least). On the server side, we're not going to > switch on multiplicative DH at a strength similar to P-256 because of > the DoS impact so clients will loose forward security. Also, with a > plain RSA ciphersuite, it's possible for an attacker with the server's > private key to decrypt the pre-master secret and assume control of a > TLS connection. This means that the attacker will be authenticated > with any client-certificate used, something that isn't possible with > forward secure ciphersuites. In the situation you describe, I see two issues: 1. Various TLS extensions never mention whether they should be implemented in SSL 3.0. I've raised that previously in this ML [0] with no particular outcome. An alternative way to this issue is to explicitly allow SSL 3.0 to use elliptic curves. 2. The fallback strategy implemented by the browsers is weaker than the TLS protocol itself. The TLS protocol protects only if you do a fallback within the protocol. and btw why fallback to RSA and not DHE-RSA if forward secrecy is an issue? There are techniques to bring DHE-RSA efficiency close to elliptic curves. [0]. http://www.ietf.org/mail-archive/web/tls/current/msg08509.html > So I'd like to introduce TLS_CAPABLE_SCSV (0x00fe) in SSLv3 > handshakes. TLS_EMPTY_RENEGOTIATION_INFO_SCSV has shown that we can > deploy new ciphersuites for SSLv3 and the semantics of > TLS_CAPABLE_SCSV would be that servers would reject any SSLv3 > handshakes that included this ciphersuite with a fatal error. (Thus > TLS_CAPABLE_SCSV would only be included when the handshake was the > result of a fallback.) What will happen if the attacker makes such a handshake fail? Would browsers reconnect without this ciphersuite? (I remember there used to be SSL servers that closed the connection once encountered with a ciphersuite they didn't understand). Who will benefit from that? 1. Is that a user that wanted forward secrecy? In that case using DHE-RSA would mitigate the issue. 2. Is that a user that did not want to use SSL 3.0? Then SSL 3.0 should have been disabled. regards, Nikos From geoffk@geoffk.org Wed Jun 6 00:25:20 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D85B21F8543 for ; Wed, 6 Jun 2012 00:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxdgpyY-9kuY for ; Wed, 6 Jun 2012 00:25:17 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5A021F853E for ; Wed, 6 Jun 2012 00:25:16 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 368F133D077; Wed, 6 Jun 2012 07:25:15 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Adam Langley References: From: Geoffrey Keating Date: 06 Jun 2012 00:25:15 -0700 In-Reply-To: Message-ID: Lines: 15 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tls@ietf.org Subject: Re: [TLS] Cipher suite values to indicate TLS capability X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Wed, 06 Jun 2012 07:25:21 -0000 Adam Langley writes: > On Tue, Jun 5, 2012 at 8:06 PM, Geoffrey Keating wrote: > > Likewise there are probably not any SSLv3-only clients which support > > ECDHE, so if you're a server and you get such a request, you can > > probably close that connection too. > > It sounds like you basically agree with the plan, you just want to > reuse an ECDHE ciphersuite value for it :) I think the whole fallback thing is terrible, and I don't agree with it at all. But if we must do it, then this makes it slightly better, and does so without standardizing bad practice. (I think it also works with many existing hosts, therefore making the deployment problem significantly simpler.) From code@funwithsoftware.org Wed Jun 6 00:35:48 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F25B21F85AD for ; Wed, 6 Jun 2012 00:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGpoHbFG5bND for ; Wed, 6 Jun 2012 00:35:47 -0700 (PDT) Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id DC23221F85A3 for ; Wed, 6 Jun 2012 00:35:29 -0700 (PDT) Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.39]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 0934C3CB148 for ; Wed, 6 Jun 2012 03:29:51 -0400 (EDT) Received: (qmail 4819 invoked from network); 6 Jun 2012 07:29:41 -0000 Received: by simscan 1.4.0 ppid: 18881, pid: 31332, t: 1.2360s scanners: clamav: m: Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO PatrickMBP.local) (ppelleti@[69.17.96.185]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 6 Jun 2012 07:29:40 -0000 Message-ID: <4FCF06DB.6050302@funwithsoftware.org> Date: Wed, 06 Jun 2012 00:29:31 -0700 From: Patrick Pelletier User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Registering SHA256 null encryption ciphersuites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Wed, 06 Jun 2012 07:35:48 -0000 On 5/30/12 2:23 AM, Lewis, Nick wrote: > Although not required in our application, is it also worth including > ECDH_anon_WITH_NULL_SHA256 and SHA384 variants of the ciphersuites too? I could easily be missing something, but what would the intended use of this ciphersuite (or any "*_anon_WITH_NULL_*" ciphersuite) be? Since it has no encryption, it doesn't offer any protection against passive eavesdroppers. But since it has no authentication, it doesn't offer any protection against active attackers. What sort of attack is it meant to protect against? (There is currently one "*_anon_WITH_NULL_*" ciphersuite registered with IANA, TLS_ECDH_anon_WITH_NULL_SHA, and my puzzlement extends to that ciphersuite, as well.) --Patrick From nick.lewis@usa.g4s.com Thu Jun 7 01:08:24 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A032A21F8631 for ; Thu, 7 Jun 2012 01:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.451 X-Spam-Level: X-Spam-Status: No, score=-4.451 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ty2wJSYSmg4P for ; Thu, 7 Jun 2012 01:08:23 -0700 (PDT) Received: from mail193.messagelabs.com (mail193.messagelabs.com [85.158.140.195]) by ietfa.amsl.com (Postfix) with ESMTP id EC89D21F84E6 for ; Thu, 7 Jun 2012 01:08:21 -0700 (PDT) X-Env-Sender: nick.lewis@usa.g4s.com X-Msg-Ref: server-12.tower-193.messagelabs.com!1339056500!12309062!1 X-Originating-IP: [89.206.228.155] X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10977 invoked from network); 7 Jun 2012 08:08:20 -0000 Received: from unallocated.star.net.uk (HELO gbtwk10s037.Technology.local) (89.206.228.155) by server-12.tower-193.messagelabs.com with RC4-SHA encrypted SMTP; 7 Jun 2012 08:08:20 -0000 Received: from GBTWK10E001.Technology.local ([10.234.1.29]) by gbtwk10s037.Technology.local ([10.234.1.39]) with mapi; Thu, 7 Jun 2012 09:08:19 +0100 From: "Lewis, Nick" To: "'tls@ietf.org'" Date: Thu, 7 Jun 2012 09:08:19 +0100 Thread-Topic: Re: [TLS] Registering SHA256 null encryption ciphersuites Thread-Index: Ac1EhNWeF8EwauMySdqjQpnlHIqb9w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AAE0766F5AF36B46BAB7E0EFB92732060686EE4975GBTWK10E001Te_" MIME-Version: 1.0 Subject: Re: [TLS] Registering SHA256 null encryption ciphersuites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Thu, 07 Jun 2012 08:08:24 -0000 --_000_AAE0766F5AF36B46BAB7E0EFB92732060686EE4975GBTWK10E001Te_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >I could easily be missing something, but what would the intended use of th= is ciphersuite (or >any "*_anon_WITH_NULL_*" ciphersuite) be? Since it has no encryption, it = doesn't offer any >protection against passive eavesdroppers. But since it has no authenticat= ion, it doesn't offer >any protection against active attackers. What sort of attack is it meant = to protect against? > >(There is currently one "*_anon_WITH_NULL_*" ciphersuite registered with I= ANA, >TLS_ECDH_anon_WITH_NULL_SHA, and my puzzlement extends to that ciphersuite= , as well.) > >--Patrick I guess anon_with_null could be used when only data integrity is required o= r for long lived sessions in which the environment is known to be free from= middlemen or impersonators at the time of the diffie-hellman exchange but = tampering could occur thereafter. Would you suggest that TLS_ECDH_anon_WITH= _NULL_SHA256 be omitted? What about SHA384 variants? In practice our requir= ements are limited to the authenticated SHA256 variants. Is it best to proc= eed exclusively with these? --Nick Nick Lewis nick.lewis@usa.g4s.com +44 1684 277137 www.g4stechnology.com New Challenge House, International Drive, Tewkesbury, Gloucestershire, GL20= 8UQ, UK P Please consider the environment before printing this email ________________________________ The details of this company are as follows: G4S Technology Limited, Registered Office: Challenge House, International D= rive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 23823= 38. This communication may contain information which is confidential, personal = and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution= , forwarding, copying or use of this communication or the information in it= is strictly prohibited. Any personal views expressed in this e-mail are those of the individual sen= der and the company does not endorse or accept responsibility for them. Prior to taking any action based upon this e-mail message, you should seek = appropriate confirmation of its authenticity. This e-mail has been scanned for all viruses by MessageLabs. --_000_AAE0766F5AF36B46BAB7E0EFB92732060686EE4975GBTWK10E001Te_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>I could easily be missing something, but what= would the intended use of this ciphersuite (or

>any "*_anon_WITH_NULL_*" ciphersuit= e) be?  Since it has no encryption, it doesn't offer any

>protection against passive eavesdroppers.&nbs= p; But since it has no authentication, it doesn't offer

>any protection against active attackers. = ; What sort of attack is it meant to protect against?

> 

>(There is currently one "*_anon_WITH_NUL= L_*" ciphersuite registered with IANA,

>TLS_ECDH_anon_WITH_NULL_SHA, and my puzzlemen= t extends to that ciphersuite, as well.)

> 

>--Patrick

 

I guess anon_with_null could be used when only data = integrity is required or for long lived sessions in which the environment i= s known to be free from middlemen or impersonators at the time of the diffi= e-hellman exchange but tampering could occur thereafter. Would you suggest that TLS_ECDH_anon_WITH_NULL_SHA256 be= omitted? What about SHA384 variants? In practice our requirements are limi= ted to the authenticated SHA256 variants. Is it best to proceed exclusively= with these?

 

--Nick

 

 

Nick Lewis

nick.lewis@usa.g4s.c= om

+44 1684 277137=

www.g4stec= hnology.com

New Cha= llenge House, International Drive, Tewkesbury, Gloucestershire, GL20 8UQ, U= K

 

P Please consider the environment before printing this email<= /span>

 


The details of this company = are as follows:
G4S Technology Limited, Registered Office: Challenge House, International D= rive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 23823= 38.

This communication may contain information which is confidential, personal = and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution= , forwarding, copying or use of this communication or the information in it= is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sen= der and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek = appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.
 --_000_AAE0766F5AF36B46BAB7E0EFB92732060686EE4975GBTWK10E001Te_-- From chris@randomnonce.org Thu Jun 7 15:34:55 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CE911E80AE for ; Thu, 7 Jun 2012 15:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACIww7kpfHFt for ; Thu, 7 Jun 2012 15:34:55 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id F33D321F84CD for ; Thu, 7 Jun 2012 15:34:54 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so1807418obb.31 for ; Thu, 07 Jun 2012 15:34:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=EbYnBrMfej9UNByXpYU/HuO9tRMMt7+GRSHAczFwrZI=; b=DbjaMhUdVvp55zkZticrQwjiCJepjrEWsQluBXIeIvO8ocfxukwR/JvyTBIBz9Eozn LgO9DmcvvGeRSlr+1LQBlFzZD3nXwOxio2I4J/kMqQptmdedgDsm5e8vBTK6BSUShY+l /wEYkPDZ5jV8PgkWsBICNJ3F5yPqqIZ0mrHHc8nJo4OpxLGPCnpAWYQiVXyxJJuaffSh 4BZBqKAL96Y3gS6xqqQqqNtTHl9EgQCeADxSWMdGj4n8GGdbeDyJswlqmDfQCfMtGBVy /dcos8RE98nsrPlco9WWYON8Rm6JJk/yjmtL/JiMwHB106H83Ze6V3PX4VCUk9qIdyxq 4eBg== MIME-Version: 1.0 Received: by 10.60.32.113 with SMTP id h17mr3905678oei.40.1339108494488; Thu, 07 Jun 2012 15:34:54 -0700 (PDT) Received: by 10.76.87.33 with HTTP; Thu, 7 Jun 2012 15:34:54 -0700 (PDT) X-Originating-IP: [98.117.34.27] In-Reply-To: <002AA72F-D47E-4C7C-930C-D78A0E48D059@checkpoint.com> References: <002AA72F-D47E-4C7C-930C-D78A0E48D059@checkpoint.com> Date: Thu, 7 Jun 2012 18:34:54 -0400 Message-ID: From: Chris Richardson To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmZOPSa3Zuktf4VLY9Qie0FLOZLmfP1LBCJnHNFfYGmJ6A0L8ABRvjv+ZG/VdmQ+heeTr+c Cc: "tls@ietf.org" Subject: Re: [TLS] Cipher suite values to indicate TLS capability X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Thu, 07 Jun 2012 22:34:55 -0000 (replying to the entire list this time...) As a server, I could: 1: Support TLSv1 and SSLv3, and not support the SCSV 2: Support TLSv1 and SSLv3, and support the SCSV 3: Support TLSv1 but not SSLv3, and the SCSV is irrelevant. With (1), I'm willing to support SSLv3 for anyone. With (2), I'm wiling to support SSLv3, but only for clients who aren't TLSv1 capable. With (3), I'm unwilling to support SSLv3 for anyone. Behind the SCSV is the suggestion is that SSLv3 should be considered harmful. If SSLv3 is harmful, then why only reject it for TLSv1-capable clients? Why not reject it for everyone? (One benefit of the SCSV that I can see is that a downgrade-to-SSLv3 attack can be detected, which would be an indication that SSLv3 should be considered harmful, even if we don't know why.) On Wed, Jun 6, 2012 at 1:17 AM, Yoav Nir wrote: > > On Jun 6, 2012, at 4:11 AM, Chris Richardson wrote: > >> On Tue, Jun 5, 2012 at 4:39 PM, Adam Langley wrote: >>> However, with the downgrade to SSLv3 we loose an important security >>> feature: ECDHE. >> ... >>> So I'd like to introduce TLS_CAPABLE_SCSV (0x00fe) in SSLv3 >>> handshakes. TLS_EMPTY_RENEGOTIATION_INFO_SCSV has shown that we can >>> deploy new ciphersuites for SSLv3 and the semantics of >>> TLS_CAPABLE_SCSV would be that servers would reject any SSLv3 >>> handshakes that included this ciphersuite with a fatal error. >> >> Thinking through various scenarios... if I'm a TLS-capable server that >> does not support foward-secure cipher suites, what reason would I have >> any reason to reject an SSLv3 hello containing the TLS_CAPABLE_SCSV? > > Because the client says it supports TLS, but is connecting using SSLv3. That is evidence of a downgrade attack. Regardless of what benefit the attacker intends to get from downgrading the connection to SSLv3, it should be aborted. From tom@ritter.vg Thu Jun 7 16:23:49 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BBA11E80E4 for ; Thu, 7 Jun 2012 16:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=-2.149, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5gae3PrLEOv for ; Thu, 7 Jun 2012 16:23:48 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 75A2611E8088 for ; Thu, 7 Jun 2012 16:23:28 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so1860992obb.31 for ; Thu, 07 Jun 2012 16:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=W62zi85KWnLRhjIrgyh78HunAYLNdEmfDLIVLDdUbbo=; b=YrZ1MWNbnwbNW9kS6iMc8UZ5101k1NRnVN4oPuEcXO/ieyVIB4NvBTHLpstZj3WX40 XaC+69+3IfsesgYm/pCVm3QQrQ4aOLMw6Pt89n4djZhi28P4wmuUWMSXeHWPl8Mkvezi g+w1SydUqYtUwHlyDLnZgArJgrbdGvqE97yJ4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding:x-gm-message-state; bh=W62zi85KWnLRhjIrgyh78HunAYLNdEmfDLIVLDdUbbo=; b=dF15ACI3z5WcFy3bVcbyjysBIqk1OW/de8pGvxFAWHLNFkzMa2KiCoZPepTctH5Fk5 u7shBZLDO2izCqrdNmr0ZkeJ5Efz/Q0Tls+mg4zg9fRp+E9OtUvvwkJMrGa927Bxw3Xu 5F8pPQEt0N3e+0iEXK8zvScvxdtQET8iI4oLfFmKXVcG0htG5nYDUThOVqE6l2tsG2bK gGRbc/1+CafXm6jaSGq/Jklq+By+mYm7ymiWKQTmrvGVrqm8C13Ge0MSoDelTpH9U0mC JsJhN5i60jz0OspsGANLgb2/Y9D3yy51nXObrnSFAxDZHcbRtF3aN9uOiG3s83cH6Dlc OTvA== Received: by 10.60.4.165 with SMTP id l5mr3981526oel.41.1339111408035; Thu, 07 Jun 2012 16:23:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.213.102 with HTTP; Thu, 7 Jun 2012 16:23:07 -0700 (PDT) In-Reply-To: References: <002AA72F-D47E-4C7C-930C-D78A0E48D059@checkpoint.com> From: Tom Ritter Date: Thu, 7 Jun 2012 19:23:07 -0400 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnusgisushz1dO6OoV9iamgYOtSog8PGWXjgrGwH84/UA4JozHH7hMmLyPjat/ETxisgOwY Subject: Re: [TLS] Cipher suite values to indicate TLS capability X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Thu, 07 Jun 2012 23:23:49 -0000 On 7 June 2012 18:34, Chris Richardson wrote: > Behind the SCSV is the suggestion is that SSLv3 should be considered > harmful. =A0If SSLv3 is harmful, then why only reject it for > TLSv1-capable clients? =A0Why not reject it for everyone? > > (One benefit of the SCSV that I can see is that a downgrade-to-SSLv3 > attack can be detected, which would be an indication that SSLv3 should > be considered harmful, even if we don't know why.) This proposal, and a few others being worked on in various places, aim to address the problem we have with hard fail and backwards capability. In some scenarios TLSv1, DNSSEC, DANE, etc all fail not because someone is performing an attack, but because some piece of software can't handle some portion of the secure protocol. And because Operating Systems and Browsers have an incentive to make things work for their users, they retry will less, or no, security. Attackers can exploit this mechanism to get the advantages of the lesser form (less or no security). If we don't move the line in the sand forward, if we don't make a decision that says "We will support this buggy or incomplete software no more", there's no point in defining new security protocols. What's the point in DNSSEC if it only is used when someone's not attacking you? What's the point in TLSv1, 1.1, or 1.2 if the security gains (correct IV, DHE, AEAD, SHA256) will never be realized when there's an attacker there? If there's a practical way to detect an attacker trying to downgrade you, that doesn't shred the protocol, I think it's pretty useful. SCSV's are ugly and a slippery slope, but when someone in an accurate position tells you "We're going to have the fallback behavior for a long time" one or two more to gain the advantage of these new protocols looks pretty good. (The other approach being taken is drawing a little enclave and saying "In this zone, we will hard fail, and if your software can't handle TLS1.0 or DNSSEC, people can't connect to you.", but that's not really applicable here.) On 6 June 2012 03:12, Nikos Mavrogiannopoulos wrote: > 2. Is that a user that did not want to use SSL 3.0? Then SSL 3.0 > should have been disabled. I would say it was a user who wanted to use the more secure version of the protocol available, and not be downgraded by an attacker. On 6 June 2012 03:25, Geoffrey Keating wrote: > I think the whole fallback thing is terrible, and I don't agree with > it at all. =A0But if we must do it, then this makes it slightly better, > and does so without standardizing bad practice. =A0(I think it also > works with many existing hosts, therefore making the deployment > problem significantly simpler.) Reusing a ECDHE ciphersuite is standardizing less of a bad practice, but it's more un-intuitive. Does ECDHE indicate support of ECDHE or TLS 1.0? (An AES-GCM ciphersuite would conclusively indicate TLS 1.2 - until we have TLS 1.3) Would it make sense to define all three: TLS_1_{0,1,2}_CAPABLE_SCSV and send only the highest one from the client? I think if people are adding in the code to handle the SCSV, the code could be written in a sturdy and reusable way such that adding a fourth later on wouldn't even require a code change, just another item to an array. -tom From n.mavrogiannopoulos@gmail.com Fri Jun 8 00:35:10 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCDD21F86D4 for ; Fri, 8 Jun 2012 00:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXcnyvb9FNk8 for ; Fri, 8 Jun 2012 00:35:10 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEFB21F8564 for ; Fri, 8 Jun 2012 00:35:09 -0700 (PDT) Received: by eaaq13 with SMTP id q13so1011362eaa.31 for ; Fri, 08 Jun 2012 00:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=uVHT2k+o2wkqnYJBjQEFq8g5IAbbzLjRiCYPGJLob3E=; b=kACnpskdClxgqB/rld6qLEE9f+k7ZyU85EMmgPRPiGzSpkaJV/snZ+/M3jGXE4coyV tfaZ/tlRfwi8yFOa4UQPZ3lMW28wvXQkPCUQ9NTyLsd6FySDiMuz3yE+uK954Fs0Yxjl 6GoGPdDiJnhzWszRzrGHTymw22ChXKElV3z+5N3uUuW0/0HyefrHeEo4MhvZtWZZjuV4 FpVPUVTvhxKw08pYA5euM1av/rp+molTWKY2s7L+uSyzarYSUKUQGcprw4LWN2/RB8x6 g6p8sfiwwCkH1GsKLQnf615lpxLosQwJ1Y+uyV0WTrEZKdTP5Ok+HTBaQyrT/BdhI5hw hJlg== Received: by 10.14.96.73 with SMTP id q49mr3209286eef.76.1339140909148; Fri, 08 Jun 2012 00:35:09 -0700 (PDT) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id f16sm19093043eec.2.2012.06.08.00.35.07 (version=SSLv3 cipher=OTHER); Fri, 08 Jun 2012 00:35:08 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4FD1AB25.7070101@gnutls.org> Date: Fri, 08 Jun 2012 09:35:01 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Tom Ritter References: <002AA72F-D47E-4C7C-930C-D78A0E48D059@checkpoint.com> In-Reply-To: X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] Cipher suite values to indicate TLS capability X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 08 Jun 2012 07:35:11 -0000 On 06/08/2012 01:23 AM, Tom Ritter wrote: > On 7 June 2012 18:34, Chris Richardson wrote: >> Behind the SCSV is the suggestion is that SSLv3 should be considered >> harmful. If SSLv3 is harmful, then why only reject it for >> TLSv1-capable clients? Why not reject it for everyone? >> >> (One benefit of the SCSV that I can see is that a downgrade-to-SSLv3 >> attack can be detected, which would be an indication that SSLv3 should >> be considered harmful, even if we don't know why.) > > This proposal, and a few others being worked on in various places, aim > to address the problem we have with hard fail and backwards > capability. In some scenarios TLSv1, DNSSEC, DANE, etc all fail not > because someone is performing an attack, but because some piece of > software can't handle some portion of the secure protocol. And > because Operating Systems and Browsers have an incentive to make > things work for their users, they retry will less, or no, security. > Attackers can exploit this mechanism to get the advantages of the > lesser form (less or no security). > If we don't move the line in the sand forward, if we don't make a > decision that says "We will support this buggy or incomplete software > no more", there's no point in defining new security protocols. What's > the point in DNSSEC if it only is used when someone's not attacking > you? What's the point in TLSv1, 1.1, or 1.2 if the security gains > (correct IV, DHE, AEAD, SHA256) will never be realized when there's an > attacker there? I don't quite get the point. If the goal of the attacker is to perform denial of service on the secure protocol so that the user uses the insecure protocol (plaintext), how does this approach help? It doesn't. If you want to only prevent against the attacker that wants to rollback the session to SSL 3.0, then all you need to do is to perform the proper TLS protocol negotiation, which protects against that. If it doesn't work warn the user. In reality however, there is the fact that several buggy servers do not implement the TLS protocol but rather a wrong variant of it, that fails performing the fallback. To account for that issue several browsers perform non-standard TLS version fallback in a way that is not protected by the handshake. Hacking the protocol to understand and detect this non-standard fallback will create another protocol in par with the TLS protocol, which we have no guarantees that will be better implemented than the original protocol. What happens if we have a buggy server that incorrectly implements the fallback detection mechanism? We define another one? If the problem is incorrect implementations, then just fix the incorrect implementations. If you cannot, then do not interoperate with them. If all major browsers do that, the owners would fix it. My point is that TLS is already complex. Making it more complex will not make it easier to implement it, but harder, and it will introduce more points of failure and interoperability rather than less. regards, Nikos From agl@google.com Fri Jun 8 08:18:10 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4C221F894E for ; Fri, 8 Jun 2012 08:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkYAwgT5yWMr for ; Fri, 8 Jun 2012 08:18:09 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B63A721F8955 for ; Fri, 8 Jun 2012 08:18:09 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1552580ghb.31 for ; Fri, 08 Jun 2012 08:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=+b7VcuOhmrjACHHg1Q4c0viIIHGWkcmi8bMRAooi9KY=; b=PA8kuEndEVixTwc5OK1rvLiiy3b2IvEOj/Pe5J/v+/GRXyz36TLhRwZPjQXarlX+PQ /TavtfS2YdOhkDayckwAxhYZrk9ztlXxMK3GpWjGBsta+E8cHgHo4yCEKpAr4qoZaZf4 Qb+pA+j/65mcXe9bIFwUiZfCM0jP5ugwNWi3DvtmnUKoEwrH2fbOjAN6Otr1M/mFicIs MimUPRmICiqfVtjZrnlfR1kr2eoFiFEePhlW/KIEY1QJ5ZHrK2QRgZlAkCbQbjNfcABH 38u3eY9eh6kFF/XcpIX4+ZEoIgJmIlEpnvQdPzcZ9ktoxQfnO8QdseicZxIRtitU4yit MI/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=+b7VcuOhmrjACHHg1Q4c0viIIHGWkcmi8bMRAooi9KY=; b=gRrRpMgJbxSxkM7FJe+jsHYeF5lOUrerBtTZqR967O0EpB7c+la12YovJPbcJKJdmp 8v9zpM4dAmI3SYXRd0+g9Te41G4oTHhr9DvgZ6xez6UUQ6wa0KnkC3hv0hTc/u3U2tPN rIce92j0e63JvY2VBjAEQqfVsW3LnoXqSimU2m63oxkZVlUfPGQE929NXZUpi6YojqVF +J7b9tYHkXOvgNFu/TxP2UCWpA4RSqhqeKJfseyTJwGYy7lsmDe19u24eagXjUIPRs3N 0PgouZ6/XQFwJIyOMRYFs8vr9420Qx0dOqtyrJe7CjmZ1Yct4hVrKrATcemhr9HEs1po oc8w== Received: by 10.50.179.101 with SMTP id df5mr3071221igc.22.1339168689019; Fri, 08 Jun 2012 08:18:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.179.101 with SMTP id df5mr3071211igc.22.1339168688876; Fri, 08 Jun 2012 08:18:08 -0700 (PDT) Received: by 10.231.5.201 with HTTP; Fri, 8 Jun 2012 08:18:08 -0700 (PDT) In-Reply-To: <4FD1AB25.7070101@gnutls.org> References: <002AA72F-D47E-4C7C-930C-D78A0E48D059@checkpoint.com> <4FD1AB25.7070101@gnutls.org> Date: Fri, 8 Jun 2012 11:18:08 -0400 Message-ID: From: Adam Langley To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkPex/K1dpljIS5uzMCwhzHO/WfM1KakUKaZeoPCd5cA8LWANLj6IkUcOMaNISPtb7T3seGMXB8htewC/jEOEkLHuHWHIlWHix813LYwBSPOrbJbgNco5hBZdJdFsYb1IdK1Uxi Cc: "tls@ietf.org" Subject: Re: [TLS] Cipher suite values to indicate TLS capability X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 08 Jun 2012 15:18:10 -0000 On Fri, Jun 8, 2012 at 3:35 AM, Nikos Mavrogiannopoulos wrote: > If you want to only prevent against the attacker that wants to rollback > the session to SSL 3.0, then all you need to do is to perform the proper > TLS protocol negotiation, which protects against that. If it doesn't > work warn the user. Yes, the aim is to prevent an attacker performing a downgrade attack to SSLv3. Warning the user assumes that the user can understand what we're trying to tell them which is not true here. > What happens if we have a buggy server that incorrectly implements the > fallback detection mechanism? We define another one? The SCSV for the renegotiation indication extension was deployed without any serious issues, which is strong evidence that we can viably deploy other SCSV values. > If the problem is incorrect implementations, then just fix the incorrect > implementations. If you cannot, then do not interoperate with them. If > all major browsers do that, the owners would fix it. It's not clear, from a global point of view, that the benefits of avoiding SSLv3 downgrades exceed the cost of updating all these servers. By definition these servers are unmaintained and probably very expensive to update. They're also quite numerous. Certainly, from a moral point of view, we should not be baring the costs of these server's bugs. By abandoning these buggy devices on the network, vendors (which presumably turned a profit by doing so) are imposing externalities on the world. It's basically a form of pollution. I understand and share an anger towards these practices but, none the less, we find ourselves with these barrels of toxic waste lying around and have to deal with it. It's the cost of an open network and I'd still choose it over a closed network. Cheers AGL From n.mavrogiannopoulos@gmail.com Fri Jun 8 15:08:59 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD0411E80E8 for ; Fri, 8 Jun 2012 15:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnbHuHKn0k-c for ; Fri, 8 Jun 2012 15:08:59 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E4D9411E80AA for ; Fri, 8 Jun 2012 15:08:58 -0700 (PDT) Received: by eekd4 with SMTP id d4so1772913eek.31 for ; Fri, 08 Jun 2012 15:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=IyucPbNu2Xm8hbdta45H/cKkg9EbODDIdaah6We/fZY=; b=EsevBeFwuf7+Ey9jQaXiq39nF16eJGcjvEhT26Kjo1BrYpVDt6VCIGDGHdUAA+yxj2 nsq9H+VgaVM/kVjj+WfhWEc/TENv1Naibygi6vglHPAPVyNtwr8zQomiiNaK94bzw7sx iTChZnWZZtcNDNC6F+mhEZz+7WjJdVKBPKn1irPdSqrG1Xe4Gr2oYA/A/a5FQB6yYISp OVyGaBXg0UXjJkaMj/5Yz7+6QiIkv55fGeCAM/pigQmOxNL9VMbWFh0DSg81sQn21g6v SqrelyHoK2XUnWPGOwJ2ofklelRlDgI5VjYDASEq/yknZNobyS4FlWs61Gf9FTFBObvd bCSw== Received: by 10.14.53.6 with SMTP id f6mr4029341eec.169.1339193337865; Fri, 08 Jun 2012 15:08:57 -0700 (PDT) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id q53sm26405944eef.8.2012.06.08.15.08.56 (version=SSLv3 cipher=OTHER); Fri, 08 Jun 2012 15:08:56 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4FD277F2.30603@gnutls.org> Date: Sat, 09 Jun 2012 00:08:50 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Adam Langley References: <002AA72F-D47E-4C7C-930C-D78A0E48D059@checkpoint.com> <4FD1AB25.7070101@gnutls.org> In-Reply-To: X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] Cipher suite values to indicate TLS capability X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Fri, 08 Jun 2012 22:08:59 -0000 On 06/08/2012 05:18 PM, Adam Langley wrote: > On Fri, Jun 8, 2012 at 3:35 AM, Nikos Mavrogiannopoulos wrote: >> If you want to only prevent against the attacker that wants to rollback >> the session to SSL 3.0, then all you need to do is to perform the proper >> TLS protocol negotiation, which protects against that. If it doesn't >> work warn the user. > Yes, the aim is to prevent an attacker performing a downgrade attack to SSLv3. > Warning the user assumes that the user can understand what we're > trying to tell them which is not true here. It may not be true, but what would you do if the SCSV check fails? Wouldn't you warn the user? Why do you think he'd better understand that warning? Most probably he'd say that your browser doesn't work. Let's try the other one (which doesn't support SCSV and thus wouldn't detect a possible attack). >> What happens if we have a buggy server that incorrectly implements the >> fallback detection mechanism? We define another one? > The SCSV for the renegotiation indication extension was deployed > without any serious issues, which is strong evidence that we can > viably deploy other SCSV values. Indeed, but this was the case in initial TLS deployments. You rarely have issues when you implement the protocol you defined, the issues arise when 3rd parties try to implement their understanding of your protocol. What if a new server comes out that the SCSV fails for some random reason? I agree that it helps to mitigate some problem, but my concern is, does any gain obtained justify the introduced protocol complexity? regards, Nikos From agl@google.com Mon Jun 11 08:29:52 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341C821F864F for ; Mon, 11 Jun 2012 08:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ffuTnSQD9MD for ; Mon, 11 Jun 2012 08:29:51 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFFD21F859E for ; Mon, 11 Jun 2012 08:29:51 -0700 (PDT) Received: by yhq56 with SMTP id 56so3112318yhq.31 for ; Mon, 11 Jun 2012 08:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=YdVH0KIPHUvPmcGHWBI3Htb5Y1z5j76FVY2VYEOOapI=; b=kbYT0urodB6nyxJ/Kcg9VGqLs5mitnLgJ0CuR5ZKLR//WqU9MX5xqvij0Iktib6MeD EHcMgi/9WL0vDWq5ot+3OBTyxE0diIxnFWZ1IiieVM6kTFzDbaxtFBlM2bwkxBu1dOX6 lI30ywE0/WNRuGB5Mi74OCGkyazrs1mQKFDROLuqZE6JzUZIhPNOhgWRhg897AdepEP4 3pGX5N2KlPFlpCoqtz01fi/72WSYeZ9wdZD4rURriSU8S7VFlixDmg6yX7+UZZYhwQrg 6tuGwYCFMgi/fe+aamphQaFrkcZMCy5W114kMmPiDcr5vQcVRdj8O0wzCdnrl3Rdq3LL 0mRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=YdVH0KIPHUvPmcGHWBI3Htb5Y1z5j76FVY2VYEOOapI=; b=axF0xGlrHjUSlZuphWgNcbbdtOAQgS6lI1+Vl0a+vbZueDq8ZTkKw2RE/cOtHRb6As wenPrWUkJNBMdGs7wHv10rvtW7WJ0xbKgT/O1Wult+k4CDyOb1zRNBA83UGx1lcirjMc vYE4LGUFDQQdp9ti7SXEr0qve03/uaNca1aJjPGGNCA1/QrgHB1U+vO/MpnQODu8x3ih GeeJ4w6SrRMGwVw0zuEW0+J7NpYzhetFs/VhJs6BJDA0yHUdbFILi0jsHPk718duAnJj Qm+z/LJpHpkbx2xM4l1mletdWtioPZNFUOijBpGDO0AcSWyArdb84kxMmbVv3sxCJ8DY z/Qg== Received: by 10.50.190.163 with SMTP id gr3mr6731132igc.22.1339428586913; Mon, 11 Jun 2012 08:29:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.190.163 with SMTP id gr3mr6730974igc.22.1339428585064; Mon, 11 Jun 2012 08:29:45 -0700 (PDT) Received: by 10.231.5.201 with HTTP; Mon, 11 Jun 2012 08:29:44 -0700 (PDT) In-Reply-To: <4FD277F2.30603@gnutls.org> References: <002AA72F-D47E-4C7C-930C-D78A0E48D059@checkpoint.com> <4FD1AB25.7070101@gnutls.org> <4FD277F2.30603@gnutls.org> Date: Mon, 11 Jun 2012 11:29:44 -0400 Message-ID: From: Adam Langley To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnyDj0vDQArCxss1+RVb7coK5RbOuHX/FDjpM8qSZE70sRb0Dc54m/vNBK+nSmINW2AJ8axA+Mn+h8UfT/S/BAvyU58BMEEVoJQ2j5Uha3+vzkCFZsaRouqOaCFyu15RVmxIu1F Cc: "tls@ietf.org" Subject: Re: [TLS] Cipher suite values to indicate TLS capability X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Mon, 11 Jun 2012 15:29:52 -0000 On Fri, Jun 8, 2012 at 6:08 PM, Nikos Mavrogiannopoulos wrote: > It may not be true, but what would you do if the SCSV check fails? > Wouldn't you warn the user? We would either go back to TLS, or return the original network error that caused the fallback. We're not going to try telling the user that they "may be under attack" or such. > Most probably he'd say that your browser doesn't work. Let's > try the other one (which doesn't support SCSV and thus wouldn't detect a > possible attack). That's always a possibility but the argument that users will try other browsers, while true, is also true of many other changes that we've made: rejecting tiny EDH groups, rejecting RSA keys < 1024-bits, rejecting MD4 and MD5 signatures. With each of these we have, undoubtedly, lost users to browsers that don't implement these things. But we have also motivated people to fix things and provided cover for other browsers to make the same changes. This tension between breaking things for the common good and keeping users happy always exists in large software and I know that this proposal, even for just SSLv3, will break users behind a certain vendor's firewall product. But that's a cost to be balanced rather than a fatal flaw (and I'm already taking to that vendor). > What if a new server comes out that the SCSV fails for some > random reason? Once we start to use the SCSV, we draw a line in the sand and it's much less likely that there will be compatibility problems in the future. > I agree that it helps to mitigate some problem, but my > concern is, does any gain obtained justify the introduced protocol > complexity? Well, the complexity decision depends substantially on an individual's preferences. I obviously believe that this is worthwhile: the SCSV is a relatively minor addition and the downgrade attack is real. But from my point of view the protocol is already subject to several of these warts [1] that the specified protocol doesn't include. This would be a rather obvious wart on the spec, even if it's not so big compared to my reality. [1] http://www.imperialviolet.org/2011/02/04/oppractices.html Cheers AGL From mrex@sap.com Mon Jun 11 10:55:42 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BFE21F854C for ; Mon, 11 Jun 2012 10:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmucMcPv2WDV for ; Mon, 11 Jun 2012 10:55:41 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 19A2D21F8543 for ; Mon, 11 Jun 2012 10:55:40 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q5BHtXa7004093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Jun 2012 19:55:33 +0200 (MEST) In-Reply-To: To: Adam Langley Date: Mon, 11 Jun 2012 19:55:33 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120611175533.AFB801A0A5@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Cipher suite values to indicate TLS capability X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.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: , X-List-Received-Date: Mon, 11 Jun 2012 17:55:42 -0000 Adam Langley wrote: > > So I'd like to introduce TLS_CAPABLE_SCSV (0x00fe) in SSLv3 > handshakes. TLS_EMPTY_RENEGOTIATION_INFO_SCSV has shown that we can > deploy new ciphersuites for SSLv3 and the semantics of > TLS_CAPABLE_SCSV would be that servers would reject any SSLv3 > handshakes that included this ciphersuite with a fatal error. (Thus > TLS_CAPABLE_SCSV would only be included when the handshake was the > result of a fallback.) Similar to my criticism of Eric's original proposal, I very much dislike new proposals that try to make communication fail, rather than succeed. How about changing the proposal to indicate what cipher suite IDs were meant to be used for in the first place: A specific set of algorithms to use for protection of the communication, and in a fashion that it can be included with an extension-free SSLv3 ClientHello or even an initial SSLv2 CLIENT-HELLO. i.e. define a _small_ set of cipher suite IDs that imply: - one single (or a very small set of) namedCurves for ECDHE - implied support of SHA256 for digital signatures - implied support of TLSv1.0 (or the version that you consider appropriate) and allow the server to use this implied information for processing the ClientHello, rather than what is conveyed in other places of ClientHello for backwards compatibility, including sending back a ServerHelloExtension for supported Elliptic Curves. For robustness/easier implementation, it should be specified that these special cipher suites should be ignored whenever an explicit Supported Elliptic Curves Extension is present in ClientHello. -Martin From jmdesp@free.fr Tue Jun 12 07:50:41 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7304F21F86D9 for ; Tue, 12 Jun 2012 07:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnC1VAbMqxCk for ; Tue, 12 Jun 2012 07:50:40 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by ietfa.amsl.com (Postfix) with ESMTP id 1A96621F86DD for ; Tue, 12 Jun 2012 07:50:38 -0700 (PDT) Received: from [10.253.4.26] (unknown [76.70.33.39]) (Authenticated sender: jmdesp) by smtp5-g21.free.fr (Postfix) with ESMTPA id B2F2CD480B5; Tue, 12 Jun 2012 16:50:30 +0200 (CEST) Message-ID: <4FD75734.5030809@free.fr> Date: Tue, 12 Jun 2012 10:50:28 -0400 From: Jean-Marc Desperrier User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120604 Thunderbird/14.0a2 MIME-Version: 1.0 To: "Yngve N. Pettersen (Developer Opera Software ASA)" , tls@ietf.org References: <20120509153513.11861.32080.idtracker@ietfa.amsl.com> <4FC75249.3050805@comodo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] CRL Stapling? (was Re: I-D Action: draft-ietf-tls-multiple-cert-status-extension-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Tue, 12 Jun 2012 14:50:41 -0000 On 04/06/2012 06:31, Yngve N. Pettersen (Developer Opera Software ASA) wrote: > Like Martin Rex, I am concerned that this would significantly increase > the complexity of the system: > - The servers would have to download both, and then decide which to use. Not necessarily, the extension is still very useful if the servers systematically downloads the OCSP where available, and CRL when the intermediate CA have no OCSP. Or has been initially configured to do only one of the two. The biggest problem with the OCSP only mode is that in many cases intermediate CA do not have OCSP responders, so that in practice, either the client doesn't check intermediate levels, or it will still have to do several network requests when using multi. > - Clients might need to associate the CRL data with the relevant CRL > URL in their cache (in case the client can use it later), but this > might lead to cache poisoning (the CRL might be valid, but it has been > obsoleted by a newer CRL revoking some cert). > Sounds valid until you realize that the CRL protocol currently does *nothing* to try to protect against outdated CRL poisoning. It is not an aim, and if it were to become one, there would be a lot of other things to change. They are many different strategy an attacker can currently use to poison the CRL cache with outdated entries, or to send a large scale attack target that will work against all victims that have their cache loaded with an old version of the CRL. > - The record format would have to be adapted, possibly including a > datatype for each entry in the list, alternatively a completely new > record (which would assume just one datatype was used for the > intermediates) It makes sense to try to keep this as simple as possible and not handle too many different cases. This could be done by adding just one additional status_type for the response, that includes the same OCSPResponseList format as ocsp_multi, but where all level except the end entity one are defined to contain CRL entries. And maybe making it a MUST for client to also accept this format when they request a multi-cert status. > - Each server having a cert from the same CA would each send the CRL > from that CA, which might require duplicate resolving if the CRL is > newer than the one currently cached. I'm sorry I don't get what you mean exactly here. Duplicate resolving of what ? Duplicate downloading maybe. > - This is not suitable for the cached info extension for caching > across multiple servers: There might be a lot of these entries, > increasing handshake size, and it might be abused to learn which sites > the user have visited, since the extension must be sent before we know > which certificate the site will present. Right now the cached info extension draft defines caching of only certificates path and trusted CA, not revocation info. Sending a lot of cached info entries quite defeats the purpose of the extension IMO. They are a few sites that use multiple certificates under separate hierarchies for the same dns name, but I don't really get how multi with CRL makes the situation actually worse as compared to the current case with OCSP only. And also the best path would be not to implement support for this case in the constrained clients that are the target of thecached information extension and evangelize the concerned sites to just not do that. If the site really has many different certificates, won't this overflow the cache capacity of the constrained client anyway ? > All in all, this adds so much complexity that I don't think it would > be worth the effort. It would be nice to have also the opinion of other implementers. And of the CAs for which emitting new intermediate certs with OCSP information, and managing the added OCSP responder is a significant burden. It would not be nice if the end result is that cert multi is of no use with them since they don't provide the intermediate OCSP anyway. Let's be honest, it's the small CAs that are the most significant security risk. From mrex@sap.com Tue Jun 12 22:51:20 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7140521F874C for ; Tue, 12 Jun 2012 22:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZdHCFNqWcNj for ; Tue, 12 Jun 2012 22:51:19 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE7421F874A for ; Tue, 12 Jun 2012 22:51:18 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q5D5pF8Z025365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Jun 2012 07:51:15 +0200 (MEST) In-Reply-To: <4FD75734.5030809@free.fr> To: Jean-Marc Desperrier Date: Wed, 13 Jun 2012 07:51:15 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120613055115.75A5D1A065@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] CRL Stapling? (was Re: I-D Action: draft-ietf-tls-multiple-cert-status-extension-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.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: , X-List-Received-Date: Wed, 13 Jun 2012 05:51:20 -0000 Jean-Marc Desperrier wrote: > > Yngve N. Pettersen (Developer Opera Software ASA) wrote: > > > > Like Martin Rex, I am concerned that this would significantly increase > > the complexity of the system: > > - The servers would have to download both, and then decide which to use. > > Not necessarily, the extension is still very useful if the servers > systematically downloads the OCSP where available, and CRL when the > intermediate CA have no OCSP. Or has been initially configured to do > only one of the two. Nope. When intermediate CAs have no OCSP, no OCSP check will be performed. Personally, I would never do CRL processing on a client during Online authentication, because CRL processing is so completely screwed in the standards (CRLs offers tons of complex features that have a guidance -- if you don't understand this, get another CRL ...). In terms of processing it, OCSP responses are a magnitude more reasonable than CRLs (except that expecting the cert receiver instead of the cert owner to shop around, that's a problem inherited from CRLs). > > > - Clients might need to associate the CRL data with the relevant CRL > > URL in their cache (in case the client can use it later), but this > > might lead to cache poisoning (the CRL might be valid, but it has been > > obsoleted by a newer CRL revoking some cert). > > > Sounds valid until you realize that the CRL protocol currently does > *nothing* to try to protect against outdated CRL poisoning. > It is not an aim, and if it were to become one, there would be a lot of > other things to change. > > They are many different strategy an attacker can currently use to poison > the CRL cache with outdated entries, or to send a large scale attack > target that will work against all victims that have their cache loaded > with an old version of the CRL. The use of the CRL to verify the server cert is to protect against the *network peer* being the attacker. Since the network peer in the case of OCSP stapling is the source of these CRLs, this argument does not apply. > > > - Each server having a cert from the same CA would each send the CRL > > from that CA, which might require duplicate resolving if the CRL is > > newer than the one currently cached. > > I'm sorry I don't get what you mean exactly here. Duplicate resolving of > what ? Duplicate downloading maybe. I'm also slightly confused. For the sake of robust and deterministically predictable behaviour, either the conveyed stapled data ought to be used, or the handshake aborted with an error. Overriding data sent by the server with stuff already in the cache or ignoring a fraction of them and newly obtaining them sounds like a recipe for breaking this feature badly, resulting in a user experience "works for some peers, but not for others", similar to the transvalid server certificate nonsense resulting from browser re-sorting and adding missing certs to the certification path of the servers Certificate handshake message instead of reporting a broken Server-side SSL/TLS implementation that is clueless about reasonably managing PKI credentials and correctly implementing TLS, and a server configuration that does not accommodate for such brokenness of the SSL/TLS implementation of the server. > > > - This is not suitable for the cached info extension for caching > > across multiple servers: There might be a lot of these entries, > > increasing handshake size, and it might be abused to learn which sites > > the user have visited, since the extension must be sent before we know > > which certificate the site will present. > > Right now the cached info extension draft defines caching of only > certificates path and trusted CA, not revocation info. Sending a lot of > cached info entries quite defeats the purpose of the extension IMO. They > are a few sites that use multiple certificates under separate > hierarchies for the same dns name, but I don't really get how multi with > CRL makes the situation actually worse as compared to the current case > with OCSP only. I believe it is not as bad as you describe it. When two communication peers perform lots of TLS handshakes with each other in short time, they should be using the abbreviated TLS handshake aka "TLS session resume", in which case the server should not send any stapled OCSP responses in the ServerHello at all. If there is a problem with SSL session caching&resume, then that problem should be taken care of and fixed. > > And also the best path would be not to implement support for this case > in the constrained clients that are the target of thecached information > extension and evangelize the concerned sites to just not do that. If the > site really has many different certificates, won't this overflow the > cache capacity of the constrained client anyway ? Huh? For a constrained client, not having to implement OCSP/CRL chasing (= wget/curl) would be a great savings, if revocation does matter at all. -Martin From geoffk@geoffk.org Wed Jun 13 14:16:44 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC72A11E8099 for ; Wed, 13 Jun 2012 14:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9800-aeNdBF for ; Wed, 13 Jun 2012 14:16:44 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id 638CE11E8097 for ; Wed, 13 Jun 2012 14:16:44 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 55A7B33D0BE; Wed, 13 Jun 2012 21:16:43 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Jean-Marc Desperrier References: <20120509153513.11861.32080.idtracker@ietfa.amsl.com> <4FC75249.3050805@comodo.com> <4FD75734.5030809@free.fr> From: Geoffrey Keating Date: 13 Jun 2012 14:16:43 -0700 In-Reply-To: <4FD75734.5030809@free.fr> Message-ID: Lines: 33 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tls@ietf.org Subject: Re: [TLS] CRL Stapling? (was Re: I-D Action: draft-ietf-tls-multiple-cert-status-extension-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Wed, 13 Jun 2012 21:16:45 -0000 Jean-Marc Desperrier writes: > On 04/06/2012 06:31, Yngve N. Pettersen (Developer Opera Software ASA) > wrote: > > Like Martin Rex, I am concerned that this would significantly > > increase the complexity of the system: > > - The servers would have to download both, and then decide which to use. > Not necessarily, the extension is still very useful if the servers > systematically downloads the OCSP where available, and CRL when the > intermediate CA have no OCSP. Or has been initially configured to do > only one of the two. > > The biggest problem with the OCSP only mode is that in many cases > intermediate CA do not have OCSP responders, so that in practice, > either the client doesn't check intermediate levels, or it will still > have to do several network requests when using multi. Although most intermediate CAs don't have OCSP responders, the intermediate certificates most commonly used on the Internet do. That is to say, when I look at intermediate certificates visible on the Internet, unexpired and signed by the CAs recognised by OS X, I see only about 25% have OCSP responders named (321 out of 1256). But, when counting them by the number of IP addresses which send the certificate, the numbers reverse and 74% of the certificates sent (2071453 out of 2813712) have OCSP responders named. These numbers should only improve in the future, as the CABforum baseline requirements require new intermediate CAs to have OCSP responders. So, I wouldn't put a lot of effort into making CRLs more efficient in situations where OCSP can be used instead. From yngve@opera.com Wed Jun 20 04:56:00 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248B521F86EA for ; Wed, 20 Jun 2012 04:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2woNgFneeLz for ; Wed, 20 Jun 2012 04:55:59 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id E01C321F86E0 for ; Wed, 20 Jun 2012 04:55:58 -0700 (PDT) Received: from damia.oslo.osa (oslo.jvpn.opera.com [213.236.208.46]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q5KBttlT005935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jun 2012 11:55:56 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes Organization: Opera Software References: <20120509153513.11861.32080.idtracker@ietfa.amsl.com> <4FC75249.3050805@comodo.com> <4FD75734.5030809@free.fr> To: tls@ietf.org, "Jean-Marc Desperrier" From: "Yngve Nysaeter Pettersen" Date: Wed, 20 Jun 2012 13:55:53 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <4FD75734.5030809@free.fr> User-Agent: Opera Mail/11.64 (Win32) Subject: Re: [TLS] CRL Stapling? (was Re: I-D Action: draft-ietf-tls-multiple-cert-status-extension-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: , X-List-Received-Date: Wed, 20 Jun 2012 11:56:00 -0000 On Tue, 12 Jun 2012 16:50:28 +0200, Jean-Marc Desperrier wrote: > On 04/06/2012 06:31, Yngve N. Pettersen (Developer Opera Software ASA) > wrote: >> Like Martin Rex, I am concerned that this would significantly increase >> the complexity of the system: >> - The servers would have to download both, and then decide which to >> use. > Not necessarily, the extension is still very useful if the servers > systematically downloads the OCSP where available, and CRL when the > intermediate CA have no OCSP. Or has been initially configured to do > only one of the two. > > The biggest problem with the OCSP only mode is that in many cases > intermediate CA do not have OCSP responders, so that in practice, either > the client doesn't check intermediate levels, or it will still have to > do several network requests when using multi. Many intermediate CAs already indicate OCSP. In fact, for a number of CAs I polled, 30% of their OCSP traffic is for their intermediates from clients that use that instead of CRLs to verify the intermediates. Additionally, indicating OCSP is required by the CABForum Baseline Requirements for CAs in all non-root certificates. When OCSP is not available for one or more intermediates then server can send an empty entry for that certificate, and leave it to the client to obtain revocation information through other means. >> - Clients might need to associate the CRL data with the relevant CRL >> URL in their cache (in case the client can use it later), but this >> might lead to cache poisoning (the CRL might be valid, but it has been >> obsoleted by a newer CRL revoking some cert). >> > Sounds valid until you realize that the CRL protocol currently does > *nothing* to try to protect against outdated CRL poisoning. > It is not an aim, and if it were to become one, there would be a lot of > other things to change. > > They are many different strategy an attacker can currently use to poison > the CRL cache with outdated entries, or to send a large scale attack > target that will work against all victims that have their cache loaded > with an old version of the CRL. My main issue is that it makes it easier to poison the cached CRL for a given CA >> - The record format would have to be adapted, possibly including a >> datatype for each entry in the list, alternatively a completely new >> record (which would assume just one datatype was used for the >> intermediates) > It makes sense to try to keep this as simple as possible and not handle > too many different cases. > > This could be done by adding just one additional status_type for the > response, that includes the same OCSPResponseList format as ocsp_multi, > but where all level except the end entity one are defined to contain CRL > entries. > And maybe making it a MUST for client to also accept this format when > they request a multi-cert status. The main issue is that the would likely need a *mix* of OCSP and CRL responses. Non-EV EE CRLs are likely to be big (EV CRLs have a specific download time requirement, limiting their size). Therefore a flexible format is needed, which can decide OCSP or CRL for each item in the list. That would lead to much more complexity, and I don't think the flexibility is worth it. >> - Each server having a cert from the same CA would each send the CRL >> from that CA, which might require duplicate resolving if the CRL is >> newer than the one currently cached. > I'm sorry I don't get what you mean exactly here. Duplicate resolving of > what ? Duplicate downloading maybe. If you get two different CRL responses from two servers, for the same CDP URL, which one should you cache? >> - This is not suitable for the cached info extension for caching >> across multiple servers: There might be a lot of these entries, >> increasing handshake size, and it might be abused to learn which sites >> the user have visited, since the extension must be sent before we know >> which certificate the site will present. > Right now the cached info extension draft defines caching of only > certificates path and trusted CA, not revocation info. Sending a lot of > cached info entries quite defeats the purpose of the extension IMO. They > are a few sites that use multiple certificates under separate > hierarchies for the same dns name, but I don't really get how multi with > CRL makes the situation actually worse as compared to the current case > with OCSP only. Revocation information is a likely candidate for cached info, even though I am uncertain that it will reduce overhead by much. The revocation information is only needed when a full handshake is performed, and on a well configured server the session should be valid for many hours, by which time the server could/ought to have refreshed its response copies. In this case, I am pointing out that the only way to save general bandwidth for CRL using cached info is to indicate the knowledge in all connection attempts, which will be a bandwidth hog, and a privacy issue, and therefore not suitable. It might be used for a single server, but that means we get lots of duplicates if we are to cache the responses for use with non-extension handshakes. > And also the best path would be not to implement support for this case > in the constrained clients that are the target of thecached information > extension and evangelize the concerned sites to just not do that. If the > site really has many different certificates, won't this overflow the > cache capacity of the constrained client anyway ? I was not talking about one site having many certificates, I was talking about cross-site caching of the CRL info (extreme scenario). -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 ********************************************************************