From pkix@inbox.lv Mon Mar 4 07:03:52 2013 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 C922821F852C for ; Mon, 4 Mar 2013 07:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 sgTey1W3KGhV for ; Mon, 4 Mar 2013 07:03:52 -0800 (PST) Received: from shark4.inbox.lv (shark4.inbox.lv [89.111.3.84]) by ietfa.amsl.com (Postfix) with ESMTP id 3795E21F8522 for ; Mon, 4 Mar 2013 07:03:51 -0800 (PST) Received: by shark4.inbox.lv (Postfix, from userid 1000) id 8D9A32620D; Mon, 4 Mar 2013 17:03:44 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by shark4-plain-b64d2.inbox.lv (Postfix) with ESMTP id 3AF74261FB for ; Mon, 4 Mar 2013 17:03:44 +0200 (EET) Received: from localhost ([10.0.1.17]) by localhost (shark4.inbox.lv [10.0.1.80]) (spamfilter, port 27) with ESMTP id To56-jNWiF53 for ; Mon, 4 Mar 2013 17:03:44 +0200 (EET) Received: from 193.40.12.10 ( [193.40.12.10]) by mail.inbox.lv with HTTP; Mon, 04 Mar 2013 17:03:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Compose: web=mail.inbox.lv, node=w7.inbox.lv, l=en, compose=Plaintext X-REMOTE-ADDR: 193.40.12.10 X-HTTP-USER-AGENT: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Ubuntu Chromium/24.0.1312.56 Chrome/24.0.1312.56 Safari/537.17 Message-ID: <1362409424.5134b7d013f8f@mail.inbox.lv> Date: Mon, 04 Mar 2013 17:03:44 +0200 From: "Andris Berzins" To: "tls@ietf.org" User-Agent: Inbox.lv Webmail Subject: [TLS] TLS 1.0 CertificateVerify signature length 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 Mar 2013 15:03:52 -0000 Hi, Here is CertificateVerify TLS handshake message observed on the wire, given= by client using 2048-bit RSA key: --------- Handshake type: 15 (1 byte) Length: 258 (3 bytes) Length2: 256 (2 bytes) Signature: ... (256 bytes) --------- Looking on TLS 1.0 RFC I can't see where does this "Length2" fields is desc= ribed: =20 struct { HandshakeType msg_type; uint24 length; select (HandshakeType) { case certificate_verify: CertificateVerify; } body; } Handshake; struct { Signature signature; } CertificateVerify; select (SignatureAlgorithm) { case rsa: digitally-signed struct { opaque md5_hash[16]; opaque sha_hash[20]; }; } Signature; Is there type in RFC or implementation? From juhovh@iki.fi Mon Mar 4 07:36:54 2013 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 12ECE21F8921 for ; Mon, 4 Mar 2013 07:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] 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 pt41azYFHaDa for ; Mon, 4 Mar 2013 07:36:52 -0800 (PST) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id CF11321F88E6 for ; Mon, 4 Mar 2013 07:36:51 -0800 (PST) Received: from [10.48.187.168] (188.238.62.168) by jenni2.inet.fi (8.5.140.03) id 50871399085E2F6C; Mon, 4 Mar 2013 17:36:49 +0200 Content-Type: multipart/alternative; boundary=Apple-Mail-26F63CA4-50F7-4B06-903C-9F9A234FC7FA Content-Transfer-Encoding: 7bit References: <1362409424.5134b7d013f8f@mail.inbox.lv> From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= Mime-Version: 1.0 (1.0) In-Reply-To: <1362409424.5134b7d013f8f@mail.inbox.lv> Message-Id: <7C3A911B-BEED-4BEC-B33D-E07B9B8CD04C@iki.fi> Date: Mon, 4 Mar 2013 17:36:07 +0200 To: Andris Berzins X-Mailer: iPhone Mail (10B146) Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.0 CertificateVerify signature length 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 Mar 2013 15:36:54 -0000 --Apple-Mail-26F63CA4-50F7-4B06-903C-9F9A234FC7FA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On 4.3.2013, at 17.03, "Andris Berzins" wrote: > select (SignatureAlgorithm) > { > case rsa: > digitally-signed struct { > opaque md5_hash[16]; > opaque sha_hash[20]; > }; > } Signature; >=20 > Is there type in RFC or implementation? I think neither, see section 4.7: In digital signing, one-way hash functions are used as input for a signing a= lgorithm. A digitally-signed element is encoded as an opaque vector <0..2^16= -1>, where the length is specified by the signing algorithm and key. Juho --Apple-Mail-26F63CA4-50F7-4B06-903C-9F9A234FC7FA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 4.3.2013, at 17.03, "Andris Berzins" <pkix@inbox.lv> wrote:
   select (Signa= tureAlgorithm)
      {=
          case r= sa:
         &= nbsp;    digitally-signed struct {
&nbs= p;            &n= bsp;    opaque md5_hash[16];
 &nbs= p;            &n= bsp;   opaque sha_hash[20];
  &nbs= p;           };
      } Signature;

Is there type in RFC or implementation?

I think neither, see section 4.7:
   In digital signing, one-way hash function=
s are used as input for a
   signing algorithm. A digitally-signed element is encoded as an opaque
   vector <0..2^16-1>, where the length is specified by the signing
   algorithm and key.

<=
/font>
=
Juho

= --Apple-Mail-26F63CA4-50F7-4B06-903C-9F9A234FC7FA-- From housley@vigilsec.com Tue Mar 5 11:36:35 2013 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 2980721F8542 for ; Tue, 5 Mar 2013 11:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 EROasA0l4aKx for ; Tue, 5 Mar 2013 11:36:34 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id ACFB221F8540 for ; Tue, 5 Mar 2013 11:36:34 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id F02509A401F for ; Tue, 5 Mar 2013 14:36:43 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id DIUGDTbeshzA for ; Tue, 5 Mar 2013 14:36:23 -0500 (EST) Received: from [192.168.2.100] (pool-96-255-37-162.washdc.fios.verizon.net [96.255.37.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 2C7979A4018 for ; Tue, 5 Mar 2013 14:36:40 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Mar 2013 14:36:28 -0500 References: <20130305173730.1979.16157.idtracker@ietfa.amsl.com> To: IETF TLS Message-Id: <8CA23B5C-03F7-4E0F-8CEF-C41D5853DE60@vigilsec.com> Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [TLS] Fwd: IPR Disclosure: Cable Television Laboratories, Inc's Statement about IPR related to draft-dthakore-tls-authz-03 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 Mar 2013 19:36:35 -0000 FYI ... > From: IETF Secretariat > Date: March 5, 2013 12:37:30 PM EST > To: d.thakore@cablelabs.com > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Cable Television Laboratories, Inc's = Statement about IPR related to draft-dthakore-tls-authz-03 >=20 >=20 > Dear Darshak Thakore: >=20 > An IPR disclosure that pertains to your Internet-Draft entitled = "Transport > Layer Security (TLS) Authorization Using DTCP Certificate" = (draft-dthakore-tls- > authz) was submitted to the IETF Secretariat on 2013-03-01 and has = been posted > on the "IETF Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/2006/). The title of the IPR = disclosure is > "Cable Television Laboratories, Inc's Statement about IPR related to = draft- > dthakore-tls-authz-03.""); >=20 > The IETF Secretariat >=20 From ietf-ipr@ietf.org Mon Feb 25 11:43:06 2013 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 BECFF21E80BB; Mon, 25 Feb 2013 11:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.412 X-Spam-Level: X-Spam-Status: No, score=-102.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IY62AFAcYqbi; Mon, 25 Feb 2013 11:43:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2F421F8BBD; Mon, 25 Feb 2013 11:43:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: michael.glenn.williams@gmail.com, tuexen@fh-muenster.de, seggelmann@fh-muenster.de X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225194303.15590.34289.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 11:43:03 -0800 X-Mailman-Approved-At: Wed, 06 Mar 2013 10:02:30 -0800 Cc: tls@ietf.org, ipr-announce@ietf.org Subject: [TLS] IPR Disclosure: SSH Communications Security Corporation's Statement about IPR related to RFC 6520 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, 25 Feb 2013 19:43:06 -0000 Dear Michael Williams, Michael Tuexen, Robin Seggelmann: An IPR disclosure that pertains to your RFC entitled "Transport Layer Secu= rity (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension" (RFC6520) was submitted to the IETF Secretariat on 2013-02-23 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2002/). The title of the IPR disclosure is "SSH Communications Security Corporation's Statement about IPR related to R= FC 6520.""); The IETF Secretariat From seonghan.shin@aist.go.jp Mon Mar 11 12:09:40 2013 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 9513121F8DE6 for ; Mon, 11 Mar 2013 12:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 0L1usNuOajnp for ; Mon, 11 Mar 2013 12:09:39 -0700 (PDT) Received: from na3sys010aog111.obsmtp.com (na3sys010aog111.obsmtp.com [74.125.245.90]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFF021F8DE3 for ; Mon, 11 Mar 2013 12:09:38 -0700 (PDT) Received: from mail-la0-f72.google.com ([209.85.215.72]) (using TLSv1) by na3sys010aob111.postini.com ([74.125.244.12]) with SMTP ID DSNKUT4r8qiNaFx7SrewHrIgWUdsckO8slX7@postini.com; Mon, 11 Mar 2013 12:09:39 PDT Received: by mail-la0-f72.google.com with SMTP id gw10so7318096lab.7 for ; Mon, 11 Mar 2013 12:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=azOrdxpEw5BjwXY4Gg9H3fks6GOsmmdANKc2S5IU7cU=; b=mW2BYGPbVBYl3KhxfpUX45SE7KpdmT3hLYokTg2AeRJZpjToyLE5bCvZPv8K+USajQ Q1GOmjr1LLQoHwTJxsYnfp6bYBF9lafumcX1CesfQteVtnY8sG8VoM1aE6Uxgzk2t+Zy VdDEpsDir7xRmdWguEN+ehnwNmmjj5zttv4PQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=azOrdxpEw5BjwXY4Gg9H3fks6GOsmmdANKc2S5IU7cU=; b=b5Py7f45d9/8xRCvd3Xcwi3bvR3pkYItx3c34je8hw+Ao1lfJyR/XfXdarX9sGNbC2 orRRbhmb1PVydinsGthnvmWWAQx1cGp/HJGX2NirROkBggdfPnmlJSCIvJEziFs+92qY jnMvruZ/7MzLYO1m9u4z0ZM/EMf8hPBnWXW7njRsnEaiON2wtjE3axcCMbf82QXIjGgN HrNoGhyHmz4nZ5IOQZu/I4qBSbXTPbQOHz+GIVPLe1f2jnCyvyBFjU53RW+sYHM9EqkL 5QcNvh5I2bmWTOPluVpmfbqN41lGBW4Ex+2F+v5Fdo8JeCu1IFIMq1W1+Nx7V9HGYoNr BgmQ== X-Received: by 10.112.8.233 with SMTP id u9mr5002143lba.97.1363028977155; Mon, 11 Mar 2013 12:09:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.8.233 with SMTP id u9mr5002136lba.97.1363028976916; Mon, 11 Mar 2013 12:09:36 -0700 (PDT) Received: by 10.112.97.9 with HTTP; Mon, 11 Mar 2013 12:09:36 -0700 (PDT) In-Reply-To: <20130311150417.491.21405.idtracker@ietfa.amsl.com> References: <20130311150417.491.21405.idtracker@ietfa.amsl.com> Date: Tue, 12 Mar 2013 04:09:36 +0900 Message-ID: From: SeongHan Shin To: tls@ietf.org Content-Type: multipart/alternative; boundary=e0cb4efe2dc2fcfb9704d7aae9ea X-Gm-Message-State: ALoCoQlzW8egoZRyvOxTAWhO1+1KR3KExSqenNPnkrQ5RtRjtOqQBo/Vsz9GapkYCaO22NqnIUeGYQCqaNqEJZevNIEXsa84knBTE3PwVPyawIA6VqA3D9i1KuINwFHTXZCSmckA0eUd Cc: =?UTF-8?B?5Y+k5Y6f5ZKM6YKm?= Subject: [TLS] Fwd: New Version Notification for draft-shin-tls-augpake-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, 11 Mar 2013 19:09:40 -0000 --e0cb4efe2dc2fcfb9704d7aae9ea Content-Type: text/plain; charset=ISO-8859-1 Dear all, As below, we have submitted an I-D regarding AugPAKE (PAKE) for TLS. Any comments are welcome. Best regards, Shin ---------- Forwarded message ---------- From: Date: Tue, Mar 12, 2013 at 12:04 AM Subject: New Version Notification for draft-shin-tls-augpake-00.txt To: seonghan.shin@aist.go.jp Cc: kobara_conf-ml@aist.go.jp A new version of I-D, draft-shin-tls-augpake-00.txt has been successfully submitted by SeongHan Shin and posted to the IETF repository. Filename: draft-shin-tls-augpake Revision: 00 Title: Augmented Password-Authenticated Key Exchange for Transport Layer Security (TLS) Creation date: 2013-03-11 Group: Individual Submission Number of pages: 17 URL: http://www.ietf.org/internet-drafts/draft-shin-tls-augpake-00.txt Status: http://datatracker.ietf.org/doc/draft-shin-tls-augpake Htmlized: http://tools.ietf.org/html/draft-shin-tls-augpake-00 Abstract: This document describes an efficient augmented password-authenticated key exchange (AugPAKE) protocol where a user remembers a low-entropy password and its verifier is registered in the intended server. In general, the user password is chosen from a small set of dictionary whose space is within the off-line dictionary attacks. The AugPAKE protocol described here is secure against passive attacks, active attacks and off-line dictionary attacks (on the obtained messages with passive/active attacks), and also provides resistance to server compromise (in the context of augmented PAKE security). Based on the AugPAKE protocol, this document also specifies a new password-only authentication handshake for Transport Layer Security (TLS) protocol. The IETF Secretariat -- ------------------------------------------------------------------ SeongHan Shin Research Institute for Secure Systems (RISEC), National Institute of Advanced Industrial Science and Technology (AIST), Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan Tel : +81-29-861-2670/5284 Fax : +81-29-861-5285 E-mail : seonghan.shin@aist.go.jp ------------------------------------------------------------------ --e0cb4efe2dc2fcfb9704d7aae9ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all,

As below, we have submitted an I-D regarding AugPAKE (PAKE= ) for TLS.
Any comments are welcome.

Best regards,
Shin
---------- Forwarded message ----------
From= : <internet-drafts@ietf.org>
Date: Tue, Mar 12, 2013 at 12:04 AM
Subject: New Version Notification fo= r draft-shin-tls-augpake-00.txt
To: seonghan.shin@aist.go.jp
Cc: kobara_conf-ml@aist.go.jp



A new version of I-D, draft-shin-tls-augpake-00.txt
has been successfully submitted by SeongHan Shin and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-shin-tls-augpake
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Augmented Password-Authenticated Key Exchange fo= r Transport Layer Security (TLS)
Creation date: =A0 2013-03-11
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 17
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/inter= net-drafts/draft-shin-tls-augpake-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-= shin-tls-augpake
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-shin-tls-= augpake-00


Abstract:
=A0 =A0This document describes an efficient augmented password-authenticate= d
=A0 =A0key exchange (AugPAKE) protocol where a user remembers a low-entropy=
=A0 =A0password and its verifier is registered in the intended server. =A0I= n
=A0 =A0general, the user password is chosen from a small set of dictionary<= br> =A0 =A0whose space is within the off-line dictionary attacks. =A0The AugPAK= E
=A0 =A0protocol described here is secure against passive attacks, active =A0 =A0attacks and off-line dictionary attacks (on the obtained messages =A0 =A0with passive/active attacks), and also provides resistance to server=
=A0 =A0compromise (in the context of augmented PAKE security). =A0Based on = the
=A0 =A0AugPAKE protocol, this document also specifies a new password-only =A0 =A0authentication handshake for Transport Layer Security (TLS) protocol= .




The IETF Secretariat




--
------------------------------------------------------------------
S= eongHan Shin
Research Institute for Secure Systems (RISEC),
National Ins= titute of Advanced Industrial Science and Technology (AIST),
Central 2, = 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +81-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : = seonghan.shin@aist.go.jp
------------------------------------= ------------------------------
--e0cb4efe2dc2fcfb9704d7aae9ea-- From emile.stephan@orange.com Tue Mar 12 11:03:23 2013 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 E9EE511E811F for ; Tue, 12 Mar 2013 11:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] 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 lj0AW82d3zEU for ; Tue, 12 Mar 2013 11:03:20 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7D16211E80D7 for ; Tue, 12 Mar 2013 11:03:14 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 634E1264928 for ; Tue, 12 Mar 2013 19:03:13 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 463694C066 for ; Tue, 12 Mar 2013 19:03:13 +0100 (CET) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Tue, 12 Mar 2013 19:03:13 +0100 From: To: "tls@ietf.org" Thread-Topic: ALPN or NPN ? Thread-Index: Ac4fS4/pCw0qsUTCSMOaz+CCsKSG8g== Date: Tue, 12 Mar 2013 18:03:08 +0000 Message-ID: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4PEXCVZYM14corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.12.161519 Subject: [TLS] ALPN or NPN ? 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 Mar 2013 18:03:24 -0000 --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4PEXCVZYM14corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, ALPN and NPN seem very close. Nevertheless they impact differently the perf= ormance and the complexity of migration scenario. More and more applications are being migrated over TLS. Consequently revers= e proxies have to deal with more and more complex situations and need to kn= ow the application protocol to guide incoming TLS sessions toward the right= servers. ALPN is very efficient because with ALPN a reverse proxy is able = to start the resource selection immediately after the processing of the Cli= entHello. NPN is less efficient as the reverse proxy has to wait an additio= nal TLS exchange before initiating the resource. More and more applications are being partially or totally virtualized and c= arried over TLS. In these cases reverse proxies rely on information like Se= rver Name Indication to select the server credential to return in the Serve= rHello. There are situations where the selection of the server credential r= equires the knowledge of the Server Name and of the Application Protocol. A= LPN and SNI provide this information in time as there are both carried in t= he ClientHello. This is not possible with NPN as the Application Protocol i= s determined by the client after receiving the ServerHello. Hope it helps the discussions. Emile ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4PEXCVZYM14corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /span>

ALPN and NPN seem very close. Nevertheless the= y impact differently the performance and the complexity of migration scenar= io.

 <= /span>

More and more applications are being migrated = over TLS. Consequently reverse proxies have to deal with more and more comp= lex situations and need to know the application protocol to guide incoming TLS sessions toward the right servers. ALPN is = very efficient because with ALPN a reverse proxy is able to start the resou= rce selection immediately after the processing of the ClientHello. NPN is l= ess efficient as the reverse proxy has to wait an additional TLS exchange before initiating the resource.

 <= /span>

More and more applications are being partially= or totally virtualized and carried over TLS. In these cases reverse proxie= s rely on information like Server Name Indication to select the server credential to return in the ServerHello. There are si= tuations where the selection of the server credential requires the knowledg= e of the Server Name and of the Application Protocol. ALPN and SNI provide = this information in time as there are both carried in the ClientHello. This is not possible with NPN as the = Application Protocol is determined by the client after receiving the Server= Hello.

 <= /span>

Hope it helps the discussions.

Emile

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4PEXCVZYM14corpora_-- From dkg@fifthhorseman.net Tue Mar 12 11:28:34 2013 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 8A60111E8156 for ; Tue, 12 Mar 2013 11:28:34 -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=[AWL=0.000, 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 VQZL3VXhPUzj for ; Tue, 12 Mar 2013 11:28:34 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id CB2B311E8159 for ; Tue, 12 Mar 2013 11:28:33 -0700 (PDT) Received: from [192.168.13.132] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 1A045F979; Tue, 12 Mar 2013 14:28:20 -0400 (EDT) Message-ID: <513F73C5.8000805@fifthhorseman.net> Date: Tue, 12 Mar 2013 14:28:21 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130112 Icedove/17.0.2 MIME-Version: 1.0 To: emile.stephan@orange.com References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> In-Reply-To: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> X-Enigmail-Version: 1.6a1pre Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2GGMVAOBWHVFSLSOCHKGE" Cc: "tls@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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 Mar 2013 18:28:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2GGMVAOBWHVFSLSOCHKGE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/12/2013 02:03 PM, emile.stephan@orange.com wrote: > More and more applications are being migrated over TLS. Consequently re= verse proxies have to deal with more and more complex situations and need= to know the application protocol to guide incoming TLS sessions toward t= he right servers. ALPN is very efficient because with ALPN a reverse prox= y is able to start the resource selection immediately after the processin= g of the ClientHello. NPN is less efficient as the reverse proxy has to w= ait an additional TLS exchange before initiating the resource. >=20 > More and more applications are being partially or totally virtualized a= nd carried over TLS. In these cases reverse proxies rely on information l= ike Server Name Indication to select the server credential to return in t= he ServerHello. There are situations where the selection of the server cr= edential requires the knowledge of the Server Name and of the Application= Protocol. ALPN and SNI provide this information in time as there are bot= h carried in the ClientHello. This is not possible with NPN as the Applic= ation Protocol is determined by the client after receiving the ServerHell= o. these two points seem to be marks in favor of ALPN. However, NPN does not advertise the client's selection of protocol to any sniffing or intercepting middleware, while ALPN does leak this information to middleware (as well as anyone on the network path). =46rom a communications privacy and robustness perspective, this is a serious mark in favor of NPN. Regards, --dkg ------enig2GGMVAOBWHVFSLSOCHKGE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJRP3PFXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpqtYQAIoveN+zZ/AAiiGsVcg2d8XH tZyFCSbZ9EWl34n5Ysp0cupsNAxkluLhDOK1Wqo6k8riUoUMZLr5Y4foaT/fmqpH ZEM6NVMC1KI4GBDgb8/DbbfGnxTRJ7+RthvktYdmOhZzvvbsChF4cy0R1DRKnDTW Tx17xVj5au2orQxdcd38UYowu0eOSlFdLv0B0BZfLvj1UQCbbElDH7WuTrqUFyJW 2QVOD3Zqt0tmv9xtnkWl0EF/ORYy8gdhBtfo1EJB0clCY+11pggn5PGHjcuq/OgV vSF5/xo2pPp6mzUUIRwyw4WArtw/+eAhOHYSWKtD5XvXRRHMZV/WcAPR6SPIH3b5 VTbpBS5gulvl5y8FsE5RZj+asIglDj3r3672zStP+Xwzp0rrh71rIDA7PlC37aC0 KyN53iM9hJ/CHD2DIaqlFsZ4KNp/R1Vjpp/oQWlMBYcGHl6ITv7PHCQObwZydhWE P+qGDwIJStY+no2TwETC01JhUeHKX/pWbJp3jt5MrYYT60d6E9FQKA9WMnXW0oNz OvfEc62BGCo0pR+YdvWr+CxYVoLfWkn80SVn1mV1FBaniaYnjFs3uPKIZfzyZg+v /5OTALBcB3U9EaO6ol6O6+Jq7fJ1so9zrQkih+B4bh6qPhLKckspEb7AGGFTmwqX Y7XdmM3qaQ0YnYFK9Ntl =ze6A -----END PGP SIGNATURE----- ------enig2GGMVAOBWHVFSLSOCHKGE-- From yngve@spec-work.net Tue Mar 12 12:28:27 2013 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 CB09D1F0C74 for ; Tue, 12 Mar 2013 12:28:27 -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 qIGjgX+znT81 for ; Tue, 12 Mar 2013 12:28:26 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6C01F0C36 for ; Tue, 12 Mar 2013 12:28:26 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:59355 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UFUs4-0005ti-Vj; Tue, 12 Mar 2013 20:28:25 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org, "Sean Turner" References: <51278B81.9070809@ieca.com> Date: Tue, 12 Mar 2013 20:28:15 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <51278B81.9070809@ieca.com> User-Agent: Opera Mail/12.14 (Win32) Subject: Re: [TLS] AD review of draft-ietf-tls-multiple-cert-status-extension 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 Mar 2013 19:28:27 -0000 On Fri, 22 Feb 2013 16:15:13 +0100, Sean Turner wrote: > Two questions, one comment, and one thing to note: > > Q1: Is text needed that restricts the number of requests that can go > with case ocsp to 1? e.g.,: > > The list of CertificateStatusRequestItem entries MUST be in > order of preference. When used with case ocsp, only one request > item is allowed. When used with case ocsp_multi, more than one > request is allowed. Theoretically, I can envision implementations that signal several ResponderID lists, perhaps with different Extensions, where the server picks RespondersIDs that it know, possibly with the default as a backup. In that case you would want to have several of each type of request. E.g. ocsp_multi(Resp1, ext1) ocsp(Resp1, ext1) ocsp_multi(Resp2, ext2) ocsp(Resp2, ext2) ocsp_multi() ocsp() I agree it is unlikely that we will see such a scenario, but should we explicitly forbid it? The reason for this extension is, after all, that the original extension accidentally became too limited. > Q2: Should there be an error if case ocsp is used with multiple requests > or when case ocsp_multi is used with only one request? Given the above, only if we decide to restrict things. Requiring errors for non-fatal problems could lead to implementation differences. Checking for duplicates is also a possible programming issue; it is implicitly required for the entire extension system, though. > C1: CCITT was long ago renamed ITU. How about we change: > r/[CCITT.X680.2002]/[X680.2002] > r/[CCITT.X690.2002]/[X690.2002] > > and use the same references from RFC 5246: > > [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, > Information technology - Abstract Syntax Notation One > (ASN.1): Specification of basic notation. > > [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, > Information technology - ASN.1 encoding Rules: > Specification of Basic Encoding Rules (BER), Canonical > Encoding Rules (CER) and Distinguished Encoding Rules > (DER). The main thing about this is that the reference IDs are forced, at least in part, by the central bibliography index file, since I am only importing those via the XML2RFC file, and there is no entries with shorter reference names in the index, and I would rather avoid duplicating the entire index entry > N1: OCSP is also about to be in last call so the references will likely > be updated to point to it at some point. We'll handle that if/when it becomes relevant. -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From dkg@fifthhorseman.net Tue Mar 12 12:42:26 2013 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 C05D011E8114 for ; Tue, 12 Mar 2013 12:42:26 -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 wPoTT-aWNB6V for ; Tue, 12 Mar 2013 12:42:26 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id DD28411E8112 for ; Tue, 12 Mar 2013 12:42:25 -0700 (PDT) Received: from [192.168.13.132] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 5ADCAF979; Tue, 12 Mar 2013 15:42:21 -0400 (EDT) Message-ID: <513F851A.9010302@fifthhorseman.net> Date: Tue, 12 Mar 2013 15:42:18 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130112 Icedove/17.0.2 MIME-Version: 1.0 To: Alfredo Pironti References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <513F73C5.8000805@fifthhorseman.net> In-Reply-To: X-Enigmail-Version: 1.6a1pre Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2JCADLRSFESVPNDMALDCK" Cc: "tls@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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 Mar 2013 19:42:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2JCADLRSFESVPNDMALDCK Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/12/2013 03:26 PM, Alfredo Pironti wrote: > This looks only superficially true to me. I agree NPN does protect the > client choice against an occasional sniffer; however, a motivated > attacker can mount a known version rollback attack to retrieve the > value of that field (see > http://www.ietf.org/mail-archive/web/tls/current/msg08909.html and > followup for more details on the attack). hm, good point, thanks for the reminder. This seems to be a fundamental tension: If NPN or ALPN (or SNI, for that matter) are used by the server to select which credentials to present in the first place, then the client *cannot* prevent leaking information about its desired peer to a MITM attacker who is willing to cause a failed handshake to find out the information. For servers which do not select their own credentials based on these extensions, a client could be configured to make initial connections without the extension, and then immediately renegotiate (supply the desired extension during the renegotiation) upon confirming/verifying the server's credentials/identity. This incurs more round-trips, of course, but it avoids leaking the information to an as-yet-unauthenticated peer (and it doesn't seem to require any change in the existing protocol, iiuc). How commonly do people expect these extensions to be used by the server to select alternate credentials? Are there other practical defenses a client could take to defend itself against an active MITM that is willing to cause a handshake failure to extract this information? --dkg ------enig2JCADLRSFESVPNDMALDCK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJRP4UaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpz84P/3w0+faac/dQQncWbhqmiwqQ Tifsy+quKU0hc22BNGUrzz3Vb47Bf9t4If/Vup5WwEE9jzgoy/sNwsa/oGDb0hAa /dS7Mjfb57K7X8YigzDUuF0/2QmtKeaC2DVlg95Y4f0UxbMin7KdZMH6ckc9Hg/e s7LPyrUM0NjZfq8jn4VEsbrieNq8yL/PWive2o8SuAO2XmxLBnfAedj0JcGElWI9 QuGQZwqp+znaWqQzrIijt42ihOfDEfMpVF3ruU2Pn8Oq9PysTmVt7F9OVKVSsvfQ ue3jQQ2JBABR2cLX46ph6EyMI0LRV6dl+PFZ4SfoTb37gg2T9jKg3JReJsO5yndT zxVzX8151Eqj18709YLV9P730+gdowp9v64mp/hGP9/he80cYpAHcqlu2U8dFNTQ /sndGqRNJZ/RLaUrJTGyXRUK2nzJEAQ13RNnOQ0GZ1tcd6EqTJQJutclTR4Lpet1 bneV9QKKlkSeA3sObeGCtn6u7V+pftH8gQaVDIbyVxZbLBxfqZnB9wP7inqrnE+P SLXUKBU53FUa3NorBpgy0Rog7u6gIrTcxo8ohyspwG14j0O2ETHlSsAg72tjDM5a PsnBetRJsMT2CAWYMkaSuDD1bKQbEyUp07FTU7vVdblSwBAYpEDdKS4VnDmK6xx7 0ilWp5pcnoHjJQXEyLzq =f6b6 -----END PGP SIGNATURE----- ------enig2JCADLRSFESVPNDMALDCK-- From alfredo@pironti.eu Tue Mar 12 12:26:16 2013 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 5FBBF11E80E3 for ; Tue, 12 Mar 2013 12:26:16 -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 3YuW8Aux7YMc for ; Tue, 12 Mar 2013 12:26:15 -0700 (PDT) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id C3C4411E80D5 for ; Tue, 12 Mar 2013 12:26:14 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id h2so239944oag.24 for ; Tue, 12 Mar 2013 12:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qizH+2HUbU6JLz74/LJehYV3+BzYX9QxXdbbW7rMf+I=; b=C0bnoaOrnEMhHnSU0GOTEQ266pb06keMexdg3XsfkeJc1/WY2yVPnQHrREabYqYOWa SeKcbXpMSYV2smW4kkNQ6/F5Cblj3LNsxAiIsiKySLC30GZeIXnn3whNazxCYrT/KbsB sw9kRMKLeAHF6C9V4sxU58xSf71E/iGBCGAtw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=qizH+2HUbU6JLz74/LJehYV3+BzYX9QxXdbbW7rMf+I=; b=g67MpDiP3/12DUZQ/MTXlzfLAovpRj0n0pAoF5uy3BCsSSf4WHuJ+ocQKj0ADp+huK tmsNMDhDUcDGDQMRMPe+08NQWyBAy8+weq8KzfiVrvv88Qq2aG4cUt4U6nedB+QQ008l k5iGtIlQ7xTmsG7wTcE4aeEPQqrWOFA/b1Vn8slhhaYDlbWKdkUxtA1OseqHaH8RO9Wv SPsY5myHoUTPog471wy/pgo7HBE4ibbdnY6smiNJ6T/wIXFHRNFQzoFP0ymYqi2uPFvF uafrJWLC1d7VXOmUZ87uxVUo778jSGBWo5yPnztIR9lCiL4vTULThx8+p89jnJpQ3zbH IE9g== MIME-Version: 1.0 X-Received: by 10.182.86.196 with SMTP id r4mr13024518obz.56.1363116374146; Tue, 12 Mar 2013 12:26:14 -0700 (PDT) Received: by 10.76.89.163 with HTTP; Tue, 12 Mar 2013 12:26:13 -0700 (PDT) X-Originating-IP: [82.224.193.99] In-Reply-To: <513F73C5.8000805@fifthhorseman.net> References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <513F73C5.8000805@fifthhorseman.net> Date: Tue, 12 Mar 2013 20:26:13 +0100 Message-ID: From: Alfredo Pironti To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmb0TSW+P9g1WqYi7Kg+ZAqSAspX56COwDKuyzhOoqHrn95HY+CvogiO5VwXjc7ImaXD0N8 X-Mailman-Approved-At: Tue, 12 Mar 2013 12:45:31 -0700 Cc: "tls@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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 Mar 2013 19:26:16 -0000 On Tue, Mar 12, 2013 at 7:28 PM, Daniel Kahn Gillmor wrote: > On 03/12/2013 02:03 PM, emile.stephan@orange.com wrote: >> More and more applications are being migrated over TLS. Consequently rev= erse proxies have to deal with more and more complex situations and need to= know the application protocol to guide incoming TLS sessions toward the ri= ght servers. ALPN is very efficient because with ALPN a reverse proxy is ab= le to start the resource selection immediately after the processing of the = ClientHello. NPN is less efficient as the reverse proxy has to wait an addi= tional TLS exchange before initiating the resource. >> >> More and more applications are being partially or totally virtualized an= d carried over TLS. In these cases reverse proxies rely on information like= Server Name Indication to select the server credential to return in the Se= rverHello. There are situations where the selection of the server credentia= l requires the knowledge of the Server Name and of the Application Protocol= . ALPN and SNI provide this information in time as there are both carried i= n the ClientHello. This is not possible with NPN as the Application Protoco= l is determined by the client after receiving the ServerHello. > > these two points seem to be marks in favor of ALPN. > > However, NPN does not advertise the client's selection of protocol to > any sniffing or intercepting middleware, while ALPN does leak this > information to middleware (as well as anyone on the network path). This looks only superficially true to me. I agree NPN does protect the client choice against an occasional sniffer; however, a motivated attacker can mount a known version rollback attack to retrieve the value of that field (see http://www.ietf.org/mail-archive/web/tls/current/msg08909.html and followup for more details on the attack). On one hand, decrypting that field once may be enough for a firewall to block all future connections generated by the victim client; on the other hand, a QoS system may have a hard time doing its job on all connections. Let me stress once more that the main point worrying me about NPN is exactly this "false" sense of security that it gives. Best, Alfredo > > From a communications privacy and robustness perspective, this is a > serious mark in favor of NPN. > > Regards, > > --dkg > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From turners@ieca.com Tue Mar 12 12:46:40 2013 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 1874811E80F0 for ; Tue, 12 Mar 2013 12:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.24 X-Spam-Level: X-Spam-Status: No, score=-102.24 tagged_above=-999 required=5 tests=[AWL=0.025, 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 SNVJCXkLpaxJ for ; Tue, 12 Mar 2013 12:46:38 -0700 (PDT) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [67.18.137.87]) by ietfa.amsl.com (Postfix) with ESMTP id 9978D11E8164 for ; Tue, 12 Mar 2013 12:46:37 -0700 (PDT) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id 3FC07C3BD5140; Tue, 12 Mar 2013 14:46:37 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway15.websitewelcome.com (Postfix) with ESMTP id 342B1C3BD511C for ; Tue, 12 Mar 2013 14:46:37 -0500 (CDT) Received: from [198.180.150.142] (port=53070 helo=dhcp-5422.meeting.ietf.org) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UFV9h-0002ui-14; Tue, 12 Mar 2013 14:46:37 -0500 Message-ID: <513F861C.2040703@ieca.com> Date: Tue, 12 Mar 2013 15:46:36 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Yngve N. Pettersen" References: <51278B81.9070809@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; 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: (dhcp-5422.meeting.ietf.org) [198.180.150.142]:53070 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 10 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: tls@ietf.org Subject: Re: [TLS] AD review of draft-ietf-tls-multiple-cert-status-extension 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 Mar 2013 19:46:40 -0000 On 3/12/13 3:28 PM, Yngve N. Pettersen wrote: > On Fri, 22 Feb 2013 16:15:13 +0100, Sean Turner wrote: > >> Two questions, one comment, and one thing to note: >> >> Q1: Is text needed that restricts the number of requests that can go >> with case ocsp to 1? e.g.,: >> >> The list of CertificateStatusRequestItem entries MUST be in >> order of preference. When used with case ocsp, only one request >> item is allowed. When used with case ocsp_multi, more than one >> request is allowed. > > > > Theoretically, I can envision implementations that signal several > ResponderID lists, perhaps with different Extensions, where the server > picks RespondersIDs that it know, possibly with the default as a backup. > In that case you would want to have several of each type of request. > > E.g. > > ocsp_multi(Resp1, ext1) > ocsp(Resp1, ext1) > ocsp_multi(Resp2, ext2) > ocsp(Resp2, ext2) > ocsp_multi() > ocsp() > > I agree it is unlikely that we will see such a scenario, but should we > explicitly forbid it? The reason for this extension is, after all, that > the original extension accidentally became too limited. > > >> Q2: Should there be an error if case ocsp is used with multiple >> requests or when case ocsp_multi is used with only one request? > > Given the above, only if we decide to restrict things. > > Requiring errors for non-fatal problems could lead to implementation > differences. Checking for duplicates is also a possible programming issue; > it is implicitly required for the entire extension system, though. Okay so on Q1 and Q2 it looks like no. If somebody cares, then they should say something on Friday otherwise I'll IETF LC it after the session. >> C1: CCITT was long ago renamed ITU. How about we change: >> r/[CCITT.X680.2002]/[X680.2002] >> r/[CCITT.X690.2002]/[X690.2002] >> >> and use the same references from RFC 5246: >> >> [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, >> Information technology - Abstract Syntax Notation One >> (ASN.1): Specification of basic notation. >> >> [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, >> Information technology - ASN.1 encoding Rules: >> Specification of Basic Encoding Rules (BER), Canonical >> Encoding Rules (CER) and Distinguished Encoding Rules >> (DER). > > The main thing about this is that the reference IDs are forced, at least > in part, by the central bibliography index file, since I am only > importing those via the XML2RFC file, and there is no entries with > shorter reference names in the index, and I would rather avoid > duplicating the entire index entry Okay, I'll get the RFC editor to fix this. >> N1: OCSP is also about to be in last call so the references will >> likely be updated to point to it at some point. > > We'll handle that if/when it becomes relevant. I plan to IETF LC this one at about the same time, but we can always fix the reference later. This was more of a heads up. spt From mbadra@gmail.com Tue Mar 12 14:44:40 2013 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 D0E6C21F8626 for ; Tue, 12 Mar 2013 14:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 2Fy-6-ReULZv for ; Tue, 12 Mar 2013 14:44:40 -0700 (PDT) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by ietfa.amsl.com (Postfix) with ESMTP id 84F2521F845D for ; Tue, 12 Mar 2013 14:44:33 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id cz11so270151veb.17 for ; Tue, 12 Mar 2013 14:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PVGOM1EqpS4j43Mjye/y8Pe10kbkt/ZdTAoPgoRtQhc=; b=N534YaPvEOgASNLRa3ACWCwKbFdyNKZ2BbkreyBNiWpL5WydYJkJSe+tNbKSDup5c8 dxdU8cu/ItomGD/W19tL5zTg1FnnZ4m3UOSg2jOXuGfFrFZTR7zQD4nA7jf5o6V8O++E psKzWflBghnNfG4Lw+lLEESYNJSI8fazCG1U8c4M6kAqsVw8M3GXtAGbw5jy4WNClbzE wNrZM+PaGAcLzmRN4hncMDH5ciVfsvY4yhNOJEyJTj/HnmIkK0EKN2lB4q0P/Apv6MEH Yk4uB0IpgT04UfwjDJEyb9N077rSqllVBxkMFYVSO2SzLjvORRUs1oV8G60cvyqJ92fV tnWQ== MIME-Version: 1.0 X-Received: by 10.220.103.7 with SMTP id i7mr3060936vco.7.1363124662114; Tue, 12 Mar 2013 14:44:22 -0700 (PDT) Received: by 10.220.234.194 with HTTP; Tue, 12 Mar 2013 14:44:21 -0700 (PDT) In-Reply-To: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> Date: Wed, 13 Mar 2013 01:44:21 +0400 Message-ID: From: Mohamad Badra To: emile.stephan@orange.com Content-Type: multipart/alternative; boundary=047d7b3438b445505f04d7c131e2 Cc: "tls@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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 Mar 2013 21:44:41 -0000 --047d7b3438b445505f04d7c131e2 Content-Type: text/plain; charset=ISO-8859-1 Hello Using one of these two extensions, would it be possible to protect multiple protocols over the established TLS session or only a single protocol will be protected over that session? Since we are using port 443 to run the protocol X, so I guess protocol X traffic will be encapsulated into HTTP Requests/Responses before being encrypted by TLS Record, true? Best regards Badra On Tue, Mar 12, 2013 at 10:03 PM, wrote: > Hi,**** > > **** > > ALPN and NPN seem very close. Nevertheless they impact differently the > performance and the complexity of migration scenario.**** > > **** > > More and more applications are being migrated over TLS. Consequently > reverse proxies have to deal with more and more complex situations and need > to know the application protocol to guide incoming TLS sessions toward the > right servers. ALPN is very efficient because with ALPN a reverse proxy is > able to start the resource selection immediately after the processing of > the ClientHello. NPN is less efficient as the reverse proxy has to wait an > additional TLS exchange before initiating the resource. **** > > **** > > More and more applications are being partially or totally virtualized and > carried over TLS. In these cases reverse proxies rely on information like > Server Name Indication to select the server credential to return in the > ServerHello. There are situations where the selection of the server > credential requires the knowledge of the Server Name and of the Application > Protocol. ALPN and SNI provide this information in time as there are both > carried in the ClientHello. This is not possible with NPN as the > Application Protocol is determined by the client after receiving the > ServerHello. **** > > **** > > Hope it helps the discussions.**** > > Emile**** > > ** ** > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --047d7b3438b445505f04d7c131e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello

Using one of these two extensions= , would it be possible to protect multiple protocols over the established T= LS session or only a single protocol will be protected over that session?

Since we are using port 443 to run the protocol X, so I= guess protocol X traffic will be encapsulated into HTTP Requests/Responses= before being encrypted by TLS Record, true?

Best = regards
Badra

On Tue, Mar 12, 2013 at= 10:03 PM, <emile.stephan@orange.com> wrote:

Hi,<= /span>

=A0<= /span>

ALPN and NPN seem very close. Nevertheless the= y impact differently the performance and the complexity of migration scenar= io.

=A0<= /span>

More and more applications are being migrated = over TLS. Consequently reverse proxies have to deal with more and more comp= lex situations and need to know the application protocol to guide incoming TLS sessions toward the right servers. ALPN is = very efficient because with ALPN a reverse proxy is able to start the resou= rce selection immediately after the processing of the ClientHello. NPN is l= ess efficient as the reverse proxy has to wait an additional TLS exchange before initiating the resource.

=A0<= /span>

More and more applications are being partially= or totally virtualized and carried over TLS. In these cases reverse proxie= s rely on information like Server Name Indication to select the server credential to return in the ServerHello. There are si= tuations where the selection of the server credential requires the knowledg= e of the Server Name and of the Application Protocol. ALPN and SNI provide = this information in time as there are both carried in the ClientHello. This is not possible with NPN as the = Application Protocol is determined by the client after receiving the Server= Hello.

=A0<= /span>

Hope it helps the discussions.

Emile

=A0

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls


--047d7b3438b445505f04d7c131e2-- From mbadra@gmail.com Tue Mar 12 15:00:23 2013 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 7B39D11E80E0 for ; Tue, 12 Mar 2013 15:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 GHblv7muDUNm for ; Tue, 12 Mar 2013 15:00:22 -0700 (PDT) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id D711111E80D5 for ; Tue, 12 Mar 2013 15:00:21 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jx10so272787veb.25 for ; Tue, 12 Mar 2013 15:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qfhDO6jeg4qIL9El/bMmcLZ35dd/t05L9ppD/occ8JI=; b=wh94jzGUFqfRNDQCkFz8uwuLou4n4PgOHP1CdlUxbDUpl9ChUP6wQ7QXu02cqXTACF cF4Xme+3PLd42GTUwQo6lHDZJVP4Qk3iECRnfwt8kR1sDrWwEPJ7zk0rbzIuiF/SWcrU KwnudDn9F9ICcVLEPHeX8bPwrK8Kb1GF27+xTddXGId1P5jHPwalJ22Hcc7SWNJB/sQd tagrEccEgBHwEGd3A3l15mckRYH+ugpG8I0BlR2vJ/yzkF7Ubas4xAbJANW+qoy5d27Q aZjmyGXf1CApUauParPeb+7AlBoE9+5nCyKDhFL++NKE7u1AcBmh/3UAKuBkb5xmAM6k 0TyQ== MIME-Version: 1.0 X-Received: by 10.58.224.101 with SMTP id rb5mr7451169vec.17.1363125620402; Tue, 12 Mar 2013 15:00:20 -0700 (PDT) Received: by 10.220.234.194 with HTTP; Tue, 12 Mar 2013 15:00:20 -0700 (PDT) In-Reply-To: <513fa3af.0e7ccd0a.61eb.4f01@mx.google.com> References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <513fa3af.0e7ccd0a.61eb.4f01@mx.google.com> Date: Wed, 13 Mar 2013 02:00:20 +0400 Message-ID: From: Mohamad Badra To: Christian Kahlo Content-Type: multipart/alternative; boundary=089e0117635f63a76904d7c16af0 Cc: tls@ietf.org Subject: Re: [TLS] ALPN or NPN ? 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 Mar 2013 22:00:23 -0000 --089e0117635f63a76904d7c16af0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Christian, > yes, it would be possible to protect multiple independent protocols. > > If multiple protocols will be protected over a single TLS session, so how to multiplex between these protocols' traffic? > No, you won=92t wrap these protocols in HTTP.**** > > ** > Got it. Thanks! Best regards Badra > ** > > *Von:* tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] *Im Auftrag von > *Mohamad Badra > *Gesendet:* Dienstag, 12. M=E4rz 2013 22:44 > *An:* emile.stephan@orange.com > *Cc:* tls@ietf.org > *Betreff:* Re: [TLS] ALPN or NPN ?**** > > ** ** > > Hello**** > > ** ** > > Using one of these two extensions, would it be possible to protect > multiple protocols over the established TLS session or only a single > protocol will be protected over that session?**** > > ** ** > > Since we are using port 443 to run the protocol X, so I guess protocol X > traffic will be encapsulated into HTTP Requests/Responses before being > encrypted by TLS Record, true?**** > > ** ** > > Best regards**** > > Badra**** > > ** ** > > On Tue, Mar 12, 2013 at 10:03 PM, wrote:**** > > Hi,**** > > **** > > ALPN and NPN seem very close. Nevertheless they impact differently the > performance and the complexity of migration scenario.**** > > **** > > More and more applications are being migrated over TLS. Consequently > reverse proxies have to deal with more and more complex situations and ne= ed > to know the application protocol to guide incoming TLS sessions toward th= e > right servers. ALPN is very efficient because with ALPN a reverse proxy i= s > able to start the resource selection immediately after the processing of > the ClientHello. NPN is less efficient as the reverse proxy has to wait a= n > additional TLS exchange before initiating the resource. **** > > **** > > More and more applications are being partially or totally virtualized and > carried over TLS. In these cases reverse proxies rely on information like > Server Name Indication to select the server credential to return in the > ServerHello. There are situations where the selection of the server > credential requires the knowledge of the Server Name and of the Applicati= on > Protocol. ALPN and SNI provide this information in time as there are both > carried in the ClientHello. This is not possible with NPN as the > Application Protocol is determined by the client after receiving the > ServerHello. **** > > **** > > Hope it helps the discussions.**** > > Emile**** > > **** > > _________________________________________________________________________= ________________________________________________**** > > ** ** > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc**** > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler**** > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration,**** > > France Telecom - Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci.**** > > ** ** > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law;**** > > they should not be distributed, used or copied without authorisation.**** > > If you have received this email in error, please notify the sender and de= lete this message and its attachments.**** > > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified.**** > > Thank you.**** > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls**** > > ** ** > --089e0117635f63a76904d7c16af0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Christian,
=A0

yes, it would be possible to protect multiple independent protocols= .

No, you won=92t wrap these protocols = in HTTP.


Got it. Thanks!
Be= st regards
Badra
=A0

Von:<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif""> tls-b= ounces@ietf.org [mailto:tls-bounces@ietf.org] Im Auftrag von Mohamad Badra Gesendet: Dienstag, 12. M=E4rz 2013 22:44
An: emile.stephan@orange.com<= /a>
Cc: tls@iet= f.org
Betreff: Re: [TLS] ALPN or NPN ?

=A0

Hello

= =A0

Using one of these two extensions, would = it be possible to protect multiple protocols over the established TLS sessi= on or only a single protocol will be protected over that session?=

=A0

Since we are using port 443 to run the protocol X, so I gues= s protocol X traffic will be encapsulated into HTTP Requests/Responses befo= re being encrypted by TLS Record, true?

=A0

Best regards

Badra

=A0<= /u>

On Tue, Mar 12, 2013 at 10:03 PM, <emile.stephan@orange.com> wrote:

Hi,<= /span>

=A0

ALPN and NPN seem very close. Neverthel= ess they impact differently the performance and the complexity of migration= scenario.

=A0

More and more applications are being mi= grated over TLS. Consequently reverse proxies have to deal with more and mo= re complex situations and need to know the application protocol to guide in= coming TLS sessions toward the right servers. ALPN is very efficient becaus= e with ALPN a reverse proxy is able to start the resource selection immedia= tely after the processing of the ClientHello. NPN is less efficient as the = reverse proxy has to wait an additional TLS exchange before initiating the = resource.

=A0

More and more applications are being pa= rtially or totally virtualized and carried over TLS. In these cases reverse= proxies rely on information like Server Name Indication to select the serv= er credential to return in the ServerHello. There are situations where the = selection of the server credential requires the knowledge of the Server Nam= e and of the Application Protocol. ALPN and SNI provide this information in= time as there are both carried in the ClientHello. This is not possible wi= th NPN as the Application Protocol is determined by the client after receiv= ing the ServerHello.

=A0

Hope it helps the discussions.

Emile

=A0

= 
_________________________________________________________=
________________________________________________________________<=
/u>
=A0
<=
span lang=3D"FR">Ce message et ses pieces jointes peuvent contenir des info=
rmations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
u>
a l'expediteur et le detruire=
 ainsi que les pieces jointes. Les messages electroniques etant susceptible=
s d'alteration,
France Telecom - Orange decline toute responsabilite=
 si ce message a ete altere, deforme ou falsifie. Merci.
=A0
This message and its attachments may contain confidential or privi=
leged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you h=
ave received this email in error, please notify the sender and delete this =
message and its attachments.
As emails may be altered, France Telecom - Orange is=
 not liable for messages that have been modified, changed or falsified.<=
/u>
Thank you.


___________= ____________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/ma= ilman/listinfo/tls

=A0

<= /div>

--089e0117635f63a76904d7c16af0-- From paul.hoffman@vpnc.org Wed Mar 13 05:23:09 2013 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 B895721F8DAC for ; Wed, 13 Mar 2013 05:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 6+YtcfRVv8C7 for ; Wed, 13 Mar 2013 05:23:09 -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 4545021F8DA4 for ; Wed, 13 Mar 2013 05:23:09 -0700 (PDT) Received: from dhcp-438e.meeting.ietf.org (dhcp-438e.meeting.ietf.org [130.129.67.142]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r2DCN7r5033953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 13 Mar 2013 05:23:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> Date: Wed, 13 Mar 2013 08:23:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> To: "TLS@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [TLS] ALPN or NPN ? 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 Mar 2013 12:23:09 -0000 Firewall vendors love to add features to firewalls that allow blocking = of content, even if that blocking is often harmful. If you don't believe = me, walk down to your IT department and ask for a 15-minute tour of the = UI on the corporate firewall. If we go with ALPN, firewall vendors *will* add blocking of various = applications as a firewall feature. Some IT departments will turn this = on incorrectly, just as they turn on stuff now that makes network = operations harder. (Fred Baker and I are writing a document in OPSAWG = about this.) Thus, I prefer NPN. I can live with ALPN, but it will cause unnecessary = breakage of secure services. --Paul Hoffman= From ynir@checkpoint.com Wed Mar 13 06:32:22 2013 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 4B22721F8A6F for ; Wed, 13 Mar 2013 06:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.581 X-Spam-Level: X-Spam-Status: No, score=-10.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 F8ILIv7QNYJ0 for ; Wed, 13 Mar 2013 06:32:19 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A7A3F21F8CBB for ; Wed, 13 Mar 2013 06:32:18 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2DDWG0A024004; Wed, 13 Mar 2013 15:32:16 +0200 X-CheckPoint: {51407F12-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.95]) with mapi id 14.02.0342.003; Wed, 13 Mar 2013 15:32:15 +0200 From: Yoav Nir To: Paul Hoffman Thread-Topic: [TLS] ALPN or NPN ? Thread-Index: Ac4fS4/pCw0qsUTCSMOaz+CCsKSG8gAiTGQAAAJpqIA= Date: Wed, 13 Mar 2013 13:32:14 +0000 Message-ID: References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> In-Reply-To: <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.86] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <2B7B35AED1EE7447B40544E56C74B9E1@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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 Mar 2013 13:32:22 -0000 [firewall vendor hat firmly on] On Mar 13, 2013, at 8:23 AM, Paul Hoffman wrote: > Firewall vendors love to add features to firewalls that allow blocking of= content, even if that blocking is often harmful. If you don't believe me, = walk down to your IT department and ask for a 15-minute tour of the UI on t= he corporate firewall. Agreed, but they don't do it because of our love of blocking things, but be= cause those same IT department people would like to have fine-grained contr= ol over what does and does not pass the firewall. > If we go with ALPN, firewall vendors *will* add blocking of various appli= cations as a firewall feature. They will add such a blocking feature regardless. With ALPN this can be don= e by observing the ClientHello. With NPN this requires being a transparent = proxy, which inevitably lowers performance or throughput. > Some IT departments will turn this on incorrectly, just as they turn on s= tuff now that makes network operations harder. (Fred Baker and I are writin= g a document in OPSAWG about this.) >=20 > Thus, I prefer NPN. I can live with ALPN, but it will cause unnecessary b= reakage of secure services. I don't think people would want to block, as long as NPN/ALPN is used only = for distinguishing HTTP/1 from HTTP/2. But I can see this used in the futur= e to mark other applications, such as SSL-VPN tunneling client, like Micros= oft's SSTP, Cisco's "SSL VPN client", or my company's SNX. If a future fire= wall has a new feature for blocking tunneling clients, then that feature is= going to work regardless of whether we choose NPN or ALPN. The only questi= on is whether it's going to require being an SSL proxy or not. But if the I= T people would like to block tunneling clients, and that requires activatin= g an SSL proxy, then they will do it.=20 This is not an argument for ALPN. If they really want to block tunneling cl= ients, they have to decrypt the traffic anyway to validate that it's just r= egular web traffic. I'm just saying that the firewall users require control= over everything that goes through the network. NPN will not be able to sto= p firewall vendors from supplying that kind of control. Yoav From alangley@gmail.com Wed Mar 13 06:50:11 2013 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 951D821F8BF2 for ; Wed, 13 Mar 2013 06:50:11 -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 y1xixINiAzjC for ; Wed, 13 Mar 2013 06:50:08 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 294FD21F8B9F for ; Wed, 13 Mar 2013 06:50:07 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id n3so961877lbo.34 for ; Wed, 13 Mar 2013 06:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KDg60Dk4ovpGkoaB1/Jvtr+7+M5yG3+VKKywzzdpIuc=; b=sNPuhifFxaWu6r8o1vFq5pxpNXK/tnsCqeGEa1tHumYJVWNMJkFjpQmBCsTf2U2ebe i/NNzaOvfwHPfssgLpcWU2txjA4zxt2xkJ2PuRa8exH+a/me0DISa0FlLOUhyBEhj/S5 zNRgLSp724jrITkjBF1A0dFFuy3ja5xbfJfwVnJy3B1y7I9b3zts5+EB2kYwvRwSiKaO yJo3megZ3aWpTqQC30C+w48IUYJWgXOnXgddhj2n8+yckZVcqWEUol5yvWh9Q2zDgjFS QXrOiroPlH2xcS3mam9M4qNEz6bh+9WuV+9uumLAUy60YjrVujwqQEoQpCEuFIFWI6/g ji4A== MIME-Version: 1.0 X-Received: by 10.152.105.244 with SMTP id gp20mr17726703lab.34.1363182607022; Wed, 13 Mar 2013 06:50:07 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.42.230 with HTTP; Wed, 13 Mar 2013 06:50:06 -0700 (PDT) In-Reply-To: References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> Date: Wed, 13 Mar 2013 09:50:06 -0400 X-Google-Sender-Auth: 4XTzjfmnISG6ZPGHxoopQIJzpvw Message-ID: From: Adam Langley To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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 Mar 2013 13:50:11 -0000 On Wed, Mar 13, 2013 at 9:32 AM, Yoav Nir wrote: > They will add such a blocking feature regardless. With ALPN this can be done by observing the ClientHello. With NPN this requires being a transparent proxy, which inevitably lowers performance or throughput. In the event that the client machines are controlled to the extent that MITM certificates can be installed then you're certainly correct, although one could equally well lock down the machine to prevent the use of software that would ever try to send other protocols over TLS. However, there is a huge gap between between that and sending it in the clear. As a browser vendor we observe almost every unfortunate middlebox behaviour you can imagine. The first example that comes to mind: there was a small ISP that blocked ECDHE ciphersuites. It's not even clear why, but the ciphersuite is negotiated in the clear and someone, knowingly or otherwise, filtered on it. The inevitable result of a negotiation in the clear is that the extension will fray around the edges in the same fashion. Perhaps not for SPDY, which might make the whitelist, but other users will end up paying the cost of weird behaviour at scale. I could spend all day, every day, trying to debug the crazy network behaviour that Chrome users suffer, esp with TLS. It's those lessons that NPN is trying to learn from, although inevitably it trades away other some benefits to do so. Cheers AGL From alfredo@pironti.eu Wed Mar 13 05:42:56 2013 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 63AC521F8C0C for ; Wed, 13 Mar 2013 05:42:56 -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 la2eIB11rd7X for ; Wed, 13 Mar 2013 05:42:54 -0700 (PDT) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4699521F854C for ; Wed, 13 Mar 2013 05:42:53 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i18so1025546oag.1 for ; Wed, 13 Mar 2013 05:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CQVUG0CeUBzSINTPIUzUDNYTvR8PrAlSnW/I7zMsVjM=; b=aD+pKjyEt84npJC3hfFgmchFj97a6+/Qh7C42des9gA0yyGlyND/JjD1rF/eUmWy+i lhCKKAM69LIrvimQwwkMiCWBA/lyUpV5X3AFAj1EKIt9lDqwv0Yljqf38zT7fOd/VIxI gzHHK2VQCF44tVKH4u8VGUSoqVuq6ITBVJBDY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=CQVUG0CeUBzSINTPIUzUDNYTvR8PrAlSnW/I7zMsVjM=; b=mrRQ2N85Gq4HNAveie38SEqF3mRUzFfUf1VuGc+K1d2EOBjgg/zeh2ouKj7I9Y2kga TiDnvuRyFSKgnKFeKY5Ojxi9K2HKc1tCLgpuMNLRInqFWLKPRTMPlD9KUgWFLzVTnkH7 4joH0z2hTSRrBLEuqbQv+B/Tfh6HplPWIFSWaqpX+bSgxik0T4rAoxJ5bxt9NssEj4wM zIvfcaVcU0037tSetPYcL88mng1Tzp19ApdLAbOH1ycFOh8gFos01VQsI2Vhzy2XeZVA lNBMKI48itvZE08mqmKN8JkmguobuXzyyyIN2AykZGygMWtjORQz1JQMUX4hYgSfaXKT Kk5w== MIME-Version: 1.0 X-Received: by 10.60.28.2 with SMTP id x2mr15200749oeg.65.1363178572804; Wed, 13 Mar 2013 05:42:52 -0700 (PDT) Received: by 10.76.86.201 with HTTP; Wed, 13 Mar 2013 05:42:52 -0700 (PDT) X-Originating-IP: [82.224.193.99] In-Reply-To: <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> Date: Wed, 13 Mar 2013 13:42:52 +0100 Message-ID: From: Alfredo Pironti To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnfx6zFP9rf6gTmoqCCXqvHc3lqvRHOJ6tFjNUmgcM6wzBEUHM+iCITW1u8FKzGdAz/vlI6 X-Mailman-Approved-At: Wed, 13 Mar 2013 07:33:23 -0700 Cc: "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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 Mar 2013 12:42:56 -0000 On Wed, Mar 13, 2013 at 1:23 PM, Paul Hoffman wrote= : > Firewall vendors love to add features to firewalls that allow blocking of= content, even if that blocking is often harmful. If you don't believe me, = walk down to your IT department and ask for a 15-minute tour of the UI on t= he corporate firewall. > > If we go with ALPN, firewall vendors *will* add blocking of various appli= cations as a firewall feature. Some IT departments will turn this on incorr= ectly, just as they turn on stuff now that makes network operations harder.= (Fred Baker and I are writing a document in OPSAWG about this.) Is there any interest in a compromise solution? For example, sending the NPN information *after* the Finished message. This adds one round-trip, but makes the message exchange as secure as any other application data. (In general, the idea would be to perform a further round of negotiation after handshake completion.) I'm not at all against NPN and the reasons behind it; I just feel a bit uncomfortable with releasing a spec with a known security issue. > > Thus, I prefer NPN. I can live with ALPN, but it will cause unnecessary b= reakage of secure services. > > --Paul Hoffman > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From paul.hoffman@vpnc.org Wed Mar 13 07:37:39 2013 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 D87BD21F8E4E for ; Wed, 13 Mar 2013 07:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 Xi6G9+gIaXnJ for ; Wed, 13 Mar 2013 07:37:39 -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 109B321F8E5C for ; Wed, 13 Mar 2013 07:37:38 -0700 (PDT) Received: from dhcp-6061.meeting.ietf.org (dhcp-6061.meeting.ietf.org [130.129.96.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r2DEbbWw038873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 13 Mar 2013 07:37:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Wed, 13 Mar 2013 10:37:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> To: "TLS@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [TLS] ALPN or NPN ? 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 Mar 2013 14:37:40 -0000 On Mar 13, 2013, at 9:32 AM, Yoav Nir wrote: > [firewall vendor hat firmly on] [firewall tester hat firmly on] > On Mar 13, 2013, at 8:23 AM, Paul Hoffman = wrote: >=20 >> Firewall vendors love to add features to firewalls that allow = blocking of content, even if that blocking is often harmful. If you = don't believe me, walk down to your IT department and ask for a = 15-minute tour of the UI on the corporate firewall. >=20 > Agreed, but they don't do it because of our love of blocking things, = but because those same IT department people would like to have = fine-grained control over what does and does not pass the firewall. Noted. If you were an automaker, the fact that 1% of your customers want = to be able to drive your car faster than 100 MPH in case of emergency, = you would in fact make the car able to go that fast, but not include a = way to test if the driver was an adolescent male in the proximity of = other adolescent males. A feature is a feature. >> If we go with ALPN, firewall vendors *will* add blocking of various = applications as a firewall feature. >=20 > They will add such a blocking feature regardless. With ALPN this can = be done by observing the ClientHello. With NPN this requires being a = transparent proxy, which inevitably lowers performance or throughput. This is a false dichotomy. All modern firewall vendors already have TLS = proxyhing (which is only somewhat "transparent") as a feature already. = If this WG chooses NPN or ALPN, that feature will still be there. >> Some IT departments will turn this on incorrectly, just as they turn = on stuff now that makes network operations harder. (Fred Baker and I are = writing a document in OPSAWG about this.) >>=20 >> Thus, I prefer NPN. I can live with ALPN, but it will cause = unnecessary breakage of secure services. >=20 > I don't think people would want to block, as long as NPN/ALPN is used = only for distinguishing HTTP/1 from HTTP/2. But I can see this used in = the future to mark other applications, such as SSL-VPN tunneling client, = like Microsoft's SSTP, Cisco's "SSL VPN client", or my company's SNX. If = a future firewall has a new feature for blocking tunneling clients, then = that feature is going to work regardless of whether we choose NPN or = ALPN. The only question is whether it's going to require being an SSL = proxy or not. But if the IT people would like to block tunneling = clients, and that requires activating an SSL proxy, then they will do = it.=20 Correct. > This is not an argument for ALPN. If they really want to block = tunneling clients, they have to decrypt the traffic anyway to validate = that it's just regular web traffic. I'm just saying that the firewall = users require control over everything that goes through the network. NPN = will not be able to stop firewall vendors from supplying that kind of = control. We disagree about "the firewall users" and "require". A small number of = firewall administrators have that requirement, but offering the = filtering will cause more to do so. --Paul Hoffman From nico@cryptonector.com Wed Mar 13 08:52:27 2013 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 7B52721F8D76 for ; Wed, 13 Mar 2013 08:52:27 -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 z8VJonEwZ7jd for ; Wed, 13 Mar 2013 08:52:26 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id C8F6521F8930 for ; Wed, 13 Mar 2013 08:52:26 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 8CCB23B800B for ; Wed, 13 Mar 2013 08:52:26 -0700 (PDT) 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=k8Nyno8iJLalvjpEjlDNvGxrBAU=; b=wnMh95SZZ+8 59dlmQkvnfvqWtzhzadsug9QKe2PPN6VbQQi8CDMsF15MdRrg+qt7SeREWdEcriw xGreZcLmk5pQlzy61YShc18/ywZb6Xb34MfAKStVNzAyLOKx43ko5gyjWKVZvao3 gcPo9KX7pIrS2un3mzP9eVWndEAeTcAE= Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 259233B805C for ; Wed, 13 Mar 2013 08:52:25 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id ez12so910601wid.12 for ; Wed, 13 Mar 2013 08:52:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.94.69 with SMTP id da5mr27923447wib.30.1363189944498; Wed, 13 Mar 2013 08:52:24 -0700 (PDT) Received: by 10.216.148.193 with HTTP; Wed, 13 Mar 2013 08:52:24 -0700 (PDT) In-Reply-To: <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> Date: Wed, 13 Mar 2013 10:52:24 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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 Mar 2013 15:52:27 -0000 On Wed, Mar 13, 2013 at 7:23 AM, Paul Hoffman wrote= : > Firewall vendors love to add features to firewalls that allow blocking of= content, even if that blocking is often harmful. If you don't believe me, = walk down to your IT department and ask for a 15-minute tour of the UI on t= he corporate firewall. > > If we go with ALPN, firewall vendors *will* add blocking of various appli= cations as a firewall feature. Some IT departments will turn this on incorr= ectly, just as they turn on stuff now that makes network operations harder.= (Fred Baker and I are writing a document in OPSAWG about this.) > > Thus, I prefer NPN. I can live with ALPN, but it will cause unnecessary b= reakage of secure services. +1 and +1 to Adam L.'s response to Yoav's. Given my current and past roles at various organizations, I understand the desire to perform deep filtering at various companies. I believe they should use MITM certs or else they should limit external access greatly. After all, users now have the ability to BYON -- they bring their own network via 3G and 4G devices, so being much more extreme in limiting external access is much less burdensome on users today. (Of course, BYOD also means that data exfiltration via analog holes and USB devices has become much more of a problem, but that was true with or without BYON. Where data exfiltration is a serious problem I advocate much more strict device and network access policies.) Nico -- From X.Wu@F5.com Wed Mar 13 11:17:51 2013 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 E21E321F8EAE for ; Wed, 13 Mar 2013 11:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 X1RaX0+VFacb for ; Wed, 13 Mar 2013 11:17:51 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 064AE21F8EAD for ; Wed, 13 Mar 2013 11:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=X.Wu@f5.com; q=dns/txt; s=seattle; t=1363198671; x=1394734671; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2T5zswsstZ9N/v5OItoM3dy2+v21wgmyWzvU2c4zH2k=; b=wMovZz93nZ6uXeIXybhZ6JtPGOSYiQ3J87gV0tRETcZeAU9tFGG7P18o n7J7d5ddzqYk5i6Jjs0+D6b7WxTV3CWhBLBb0yWoHq5lA/nANJrbKlc7k qaUi+svE0LRPet7AQo4+cJE81qRm4RuT5V5TVaGrKQgGlgHM0v8yB6T2e g=; X-IronPort-AV: E=Sophos;i="4.84,838,1355097600"; d="scan'208";a="65307631" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.240]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 13 Mar 2013 18:17:50 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0123.003; Wed, 13 Mar 2013 11:17:50 -0700 From: Xiaoyong Wu To: Alfredo Pironti , Paul Hoffman Thread-Topic: [TLS] ALPN or NPN ? Thread-Index: AQHOH/e7lKqkJUClI026oVoPr+x1sJij7GnA Date: Wed, 13 Mar 2013 18:17:50 +0000 Message-ID: References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.200] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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 Mar 2013 18:17:52 -0000 > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > Alfredo Pironti > Sent: Wednesday, March 13, 2013 5:43 AM > To: Paul Hoffman > Cc: TLS@ietf.org > Subject: Re: [TLS] ALPN or NPN ? >=20 > On Wed, Mar 13, 2013 at 1:23 PM, Paul Hoffman > wrote: > > Firewall vendors love to add features to firewalls that allow blocking = of > content, even if that blocking is often harmful. If you don't believe me,= walk > down to your IT department and ask for a 15-minute tour of the UI on the > corporate firewall. > > > > If we go with ALPN, firewall vendors *will* add blocking of various > > applications as a firewall feature. Some IT departments will turn this > > on incorrectly, just as they turn on stuff now that makes network > > operations harder. (Fred Baker and I are writing a document in OPSAWG > > about this.) >=20 > Is there any interest in a compromise solution? For example, sending the > NPN information *after* the Finished message. This adds one round-trip, > but makes the message exchange as secure as any other application data. (= In > general, the idea would be to perform a further round of negotiation afte= r > handshake completion.) >=20 > I'm not at all against NPN and the reasons behind it; I just feel a bit > uncomfortable with releasing a spec with a known security issue. +1 on this. A false sense of security is no better than no security. If we = believe the NPN information is sensitive and should be protected, we should= have this after the Finished message. >=20 > > > > Thus, I prefer NPN. I can live with ALPN, but it will cause unnecessary > breakage of secure services. > > > > --Paul Hoffman > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nico@cryptonector.com Wed Mar 13 11:21:17 2013 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 C249C21F8E57 for ; Wed, 13 Mar 2013 11:21:16 -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 MrskK4b3dc8K for ; Wed, 13 Mar 2013 11:21:16 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 297B121F8E4C for ; Wed, 13 Mar 2013 11:21:16 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 6A8881E076 for ; Wed, 13 Mar 2013 11:21:15 -0700 (PDT) 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; s=cryptonector.com; bh=Z9/lIRwNf+r0RPDy7CCK Y/3vSbQ=; b=KIjQl8Ebv1+oIUwPmNdViKO0/Z1uqubtLeBkSYN7nk4WGDZJ6SyI fUecdXjgSt7BFrTRGYSnM4Qj4RsIEl0Gg0rRG2dcZLmfr6t2fJfpT8C8fGtZLuem AjDNI5sLLMQAUNriOel9fzR8Z6qpfPBc/a/GEuCI46Vk+rwEGh38V+g= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id E8A911E064 for ; Wed, 13 Mar 2013 11:21:14 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hm14so3053241wib.9 for ; Wed, 13 Mar 2013 11:21:09 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.60.195 with SMTP id j3mr36075777wjr.33.1363198869924; Wed, 13 Mar 2013 11:21:09 -0700 (PDT) Received: by 10.216.148.193 with HTTP; Wed, 13 Mar 2013 11:21:09 -0700 (PDT) In-Reply-To: References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> Date: Wed, 13 Mar 2013 13:21:09 -0500 Message-ID: From: Nico Williams To: Xiaoyong Wu Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , Alfredo Pironti , "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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 Mar 2013 18:21:17 -0000 On Wed, Mar 13, 2013 at 1:17 PM, Xiaoyong Wu wrote: >> I'm not at all against NPN and the reasons behind it; I just feel a bit >> uncomfortable with releasing a spec with a known security issue. > > +1 on this. A false sense of security is no better than no security. If we believe the NPN information is sensitive and should be protected, we should have this after the Finished message. It can't be entirely after the Finished message. The server at least has to signal willingness to negotiate an application protocol after the Finished message exchange, and we should not use a handshake record for it (because then the presence of either re-nego or app protocol nego will be obvious to middleboxes. Nico -- From alfredo@pironti.eu Wed Mar 13 11:33:11 2013 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 750D121F8A5E for ; Wed, 13 Mar 2013 11:33:11 -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 TjC5s88+hhPZ for ; Wed, 13 Mar 2013 11:33:10 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id B534021F8A14 for ; Wed, 13 Mar 2013 11:33:09 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id j8so803900qah.7 for ; Wed, 13 Mar 2013 11:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=3taUyC/VThNCicg/zrbv3TOamNkPoOJ4e+SC3AeTMjw=; b=BtIfZPORXA3/9JCT6HxxqEfYiJY54zUBiaIJsokiqLKstICD0Ko/bTTu2+kv2AgxC9 wg2w0CC1TXzu9ixc0K1RNEm8DcPxpP8d9SbXMm85l0DpKhcTfD11h7R/JspythtCodLd 8xWlh6xT7uXN786SygQGoMkczDftHkt34GRsM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=3taUyC/VThNCicg/zrbv3TOamNkPoOJ4e+SC3AeTMjw=; b=fqtbQdwhVHGDlKS4AEl0sq7picZxe+Bu7zmhePJ01MbHrkMaFzYNPYSkmlyqJSdmVi VTzjyHMxDCSEU7sQEZ8wbh9X46EqEjKFZYUrj2rFzx/sRHO5t372aGV/4cZwhdoJ+P8Y 2QZL0XQ115CSQT2MqzTgZtxLTcPbN8TvLjYLWAjLOGIQJs36YjwSn6Vk2oDsH58ddvaP 3l5/+wjJIVe5Bsn27WxfIxWIcVDe7RzNuS1uTwG7InXqnSmidAUDYhPsguAbiOGsJKAg RkRyTus16j8h8IWeYtFdVGDr8KvJ7aI6S1YkByKSaz+TddpmMLIx8G6Lks4GtfwupVrS IxJw== MIME-Version: 1.0 X-Received: by 10.224.189.10 with SMTP id dc10mr29342416qab.55.1363199589280; Wed, 13 Mar 2013 11:33:09 -0700 (PDT) Received: by 10.49.30.66 with HTTP; Wed, 13 Mar 2013 11:33:09 -0700 (PDT) X-Originating-IP: [82.224.193.99] In-Reply-To: References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> Date: Wed, 13 Mar 2013 19:33:09 +0100 Message-ID: From: Alfredo Pironti To: Nico Williams Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlu93QTIEAjxDguGDPbtcqIR2piqJ4EupXe2vzA6mo/xLEtCeL59eqCoGnxZYzoqC3xU6ep Cc: "TLS@ietf.org" , Paul Hoffman Subject: Re: [TLS] ALPN or NPN ? 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 Mar 2013 18:33:11 -0000 On Wed, Mar 13, 2013 at 7:21 PM, Nico Williams wrote: > On Wed, Mar 13, 2013 at 1:17 PM, Xiaoyong Wu wrote: >>> I'm not at all against NPN and the reasons behind it; I just feel a bit >>> uncomfortable with releasing a spec with a known security issue. >> >> +1 on this. A false sense of security is no better than no security. If we believe the NPN information is sensitive and should be protected, we should have this after the Finished message. > > It can't be entirely after the Finished message. The server at least > has to signal willingness to negotiate an application protocol after > the Finished message exchange, and we should not use a handshake > record for it (because then the presence of either re-nego or app > protocol nego will be obvious to middleboxes. To some extent, I believe we are not trying to hide the usage of the extension itself, but only its content. A simple sniffer would already be able to tell if current NPN is used or not. Alfredo > > Nico > -- From dkg@fifthhorseman.net Wed Mar 13 12:06:28 2013 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 C877511E8192 for ; Wed, 13 Mar 2013 12:06:27 -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 2+qr-E2Ioacr for ; Wed, 13 Mar 2013 12:06:27 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 11E3911E8114 for ; Wed, 13 Mar 2013 12:06:26 -0700 (PDT) Received: from [192.168.23.229] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 82A18F979; Wed, 13 Mar 2013 15:06:22 -0400 (EDT) Message-ID: <5140CE2B.5020006@fifthhorseman.net> Date: Wed, 13 Mar 2013 15:06:19 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130112 Icedove/17.0.2 MIME-Version: 1.0 To: Xiaoyong Wu References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> In-Reply-To: X-Enigmail-Version: 1.6a1pre Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2KKJJGDVEHMKEBHURHPJA" Cc: Paul Hoffman , Alfredo Pironti , "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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 Mar 2013 19:06:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2KKJJGDVEHMKEBHURHPJA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/13/2013 02:17 PM, Xiaoyong Wu wrote: > +1 on this. A false sense of security is no better than no security. If= we believe the NPN information is sensitive and should be protected, we = should have this after the Finished message. It's worth remembering that there is actually a practical, real-world distinction between "in the clear" and "accessible to a MITM who is willing to cause a connection handshake to fail". Client software can at least observe that the information leaked in the latter case, and can advise the user. (how helpful this is in the face of a malicious adversary might be hard to assess without thinking through the full user experience) Note also that moving the NPN information after the Finished message is already possible in some sense by doing a second handshake. Or is there some restriction on renegotiation that says you MUST not supply NPN on subsequent handshakes if it was not supplied initially? However, moving the NPN info after the handshake means that the server won't have an opportunity to select different credentials based on the NPN info. --dkg ------enig2KKJJGDVEHMKEBHURHPJA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJRQM4rXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcO4cP/2SfCJVtIKWN5cUagLAhZzo3 16HL9K/4GPCYV3E1cXxPzalGbKteJWP/KyuuigX2kHJftM6YtUE4/x2WGyBa7iqx 0aSSztg5iKieOdznWp2+cJJgBGhWscfg2Aj0tKgIq9PSjWeLHT8ig0mBUZ25s53/ qTwQsd76ktjfq/814OVfkIImI5bjdWj9wzjcPGAdJyqghcNdsS6RN9ILLFBYnlU3 E/fuNSFirhhCGRj2hzMNse/y9mvJYbZlUpgr9zUxQpHZFJ/078Yq9J6ejw24ly+u ceSuOYGthBttDqKrlvla8HQ6TOw3YfnagnX8Eutk9P4PzcdakLa68+6OGXKy0i0F XZ7rcrNhOq1ORHWRAwc6/0DSPoDSvHVdW40cOIJUsCDOX9gQvH2hdXB2FW0LGKsd r3GjaW1K5d+jb3OOJj5+1yga2kQ2fHLsNehIBtsHIQjohLzOxlWdG9E/LCToXR1N SweejMFqx2dormz/7PeZRJVcKarMWqA7hOSVH2FBO5t4/tIeFk5a60Q7PKbc2GsE qOx/s54BlEVh6o0vSuu0GmkqUUD0rqKkx27vkyZKX8xAkA1i0Uzm3bUopAa/VHBq dunV1BFreGU5FNe5pD9OCfw+zU/yifefDjsSvAHBkulB5vbc6a90zt/6UwO5m1JY p5m5UCULIuV+HK1EHaww =B0Ky -----END PGP SIGNATURE----- ------enig2KKJJGDVEHMKEBHURHPJA-- From Andrei.Popov@microsoft.com Wed Mar 13 12:59:33 2013 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 A7B9721F8614 for ; Wed, 13 Mar 2013 12:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] 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 zx6XizURcCbk for ; Wed, 13 Mar 2013 12:59:32 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) by ietfa.amsl.com (Postfix) with ESMTP id 7C27821F84B2 for ; Wed, 13 Mar 2013 12:59:32 -0700 (PDT) Received: from BY2FFO11FD022.protection.gbl (10.1.15.204) by BY2FFO11HUB029.protection.gbl (10.1.14.114) with Microsoft SMTP Server (TLS) id 15.0.620.12; Wed, 13 Mar 2013 19:45:06 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD022.mail.protection.outlook.com (10.1.15.211) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Wed, 13 Mar 2013 19:45:06 +0000 Received: from DB8EHSOBE042.bigfish.com (157.54.51.114) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 13 Mar 2013 19:44:18 +0000 Received: from mail206-db8-R.bigfish.com (10.174.8.245) by DB8EHSOBE042.bigfish.com (10.174.4.105) with Microsoft SMTP Server id 14.1.225.23; Wed, 13 Mar 2013 19:43:55 +0000 Received: from mail206-db8 (localhost [127.0.0.1]) by mail206-db8-R.bigfish.com (Postfix) with ESMTP id 9EAF94C0140 for ; Wed, 13 Mar 2013 19:43:54 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -22 X-BigFish: PS-22(zzbb2dI98dI9371I542Idb82hzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dhz31h2a8h668h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah9a9j1155h) Received-SPF: softfail (mail206-db8: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=Andrei.Popov@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BN1PR03MB069; H:BN1PR03MB072.namprd03.prod.outlook.com; LANG:en; Received: from mail206-db8 (localhost.localdomain [127.0.0.1]) by mail206-db8 (MessageSwitch) id 1363203831986258_27968; Wed, 13 Mar 2013 19:43:51 +0000 (UTC) Received: from DB8EHSMHS009.bigfish.com (unknown [10.174.8.251]) by mail206-db8.bigfish.com (Postfix) with ESMTP id BD5593C004C; Wed, 13 Mar 2013 19:43:51 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by DB8EHSMHS009.bigfish.com (10.174.4.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 13 Mar 2013 19:43:47 +0000 Received: from BN1PR03MB069.namprd03.prod.outlook.com (10.255.225.153) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.275.5; Wed, 13 Mar 2013 19:43:44 +0000 Received: from BN1PR03MB072.namprd03.prod.outlook.com (10.255.225.156) by BN1PR03MB069.namprd03.prod.outlook.com (10.255.225.153) with Microsoft SMTP Server (TLS) id 15.0.620.20; Wed, 13 Mar 2013 19:43:44 +0000 Received: from BN1PR03MB072.namprd03.prod.outlook.com ([169.254.7.90]) by BN1PR03MB072.namprd03.prod.outlook.com ([169.254.7.102]) with mapi id 15.00.0620.020; Wed, 13 Mar 2013 19:43:44 +0000 From: Andrei Popov To: Daniel Kahn Gillmor , Xiaoyong Wu Thread-Topic: [TLS] ALPN or NPN ? Thread-Index: Ac4fS4/pCw0qsUTCSMOaz+CCsKSG8gAmfUcAAACwbgAAC7LVAAABsXqAAAA0DZA= Date: Wed, 13 Mar 2013 19:43:43 +0000 Message-ID: <833d8576911745a3a4837dcb4047f7a2@BN1PR03MB072.namprd03.prod.outlook.com> References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <5140CE2B.5020006@fifthhorseman.net> In-Reply-To: <5140CE2B.5020006@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.124.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OrganizationHeadersPreserved: BN1PR03MB069.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%PIRONTI.EU$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%VPNC.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%FIFTHHORSEMAN.NET$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%F5.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(479174001)(199002)(24454001)(377454001)(13464002)(31966008)(6806001)(56816002)(46102001)(23676001)(51856001)(16676001)(47776003)(63696002)(20776003)(80022001)(50466001)(4396001)(50986001)(54356001)(65816001)(79102001)(49866001)(15202345001)(54316002)(47976001)(76482001)(33646001)(561944001)(53806001)(74662001)(56776001)(59766001)(47446002)(69226001)(5343655001)(44976002)(74502001)(47736001)(77982001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB029; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0784C803FD Cc: Paul Hoffman , Alfredo Pironti , "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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 Mar 2013 19:59:33 -0000 TlBOIGRyYWZ0IChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtYWdsLXRscy1uZXh0cHJv dG9uZWctMDQudHh0KSBzYXlzOg0KIiAgLi4uIGFmdGVyIGEgaGFuZHNoYWtlIGhhcyBiZWVuIHBl cmZvcm1lZCBmb3IgYQ0KICAgZ2l2ZW4gY29ubmVjdGlvbiwgcmVuZWdvdGlhdGlvbnMgb24gdGhl IHNhbWUgY29ubmVjdGlvbiBNVVNUIE5PVA0KICAgaW5jbHVkZSB0aGUgIm5leHRfcHJvdG9jb2xf bmVnb3RpYXRpb24iIGV4dGVuc2lvbi4iDQoNClNvIE5QTiBleHRlbnNpb24gY2Fubm90IGJlIHVz ZWQgYXMgcGFydCBvZiBhIHJlbmVnb3RpYXRpb24gb24gdGhlIHNhbWUgY29ubmVjdGlvbi4NCkl0 IGxvb2tzIGxpa2Ugb25lIGNhbid0IGhhdmUgdHJ1ZSBjb25maWRlbnRpYWxpdHkgZ3VhcmFudGVl cyB3aXRoIE5QTiwgYXMgZGVmaW5lZC4NCg0KVGhlcmUgaXMgYSBicm9hZCBzcGVjdHJ1bSBvZiBv cGluaW9ucyBpbiB0aGUgV0cgcmVnYXJkaW5nIHRoZSBuZWVkIGZvciBoaWRpbmcgYXBwbGljYXRp b24gcHJvdG9jb2wgaW5mb3JtYXRpb246DQotIExpc3Qgb2YgcHJvdG9jb2xzIGFuZFxvciB0aGUg bmVnb3RpYXRlZCBwcm90b2NvbCBuZWVkIHRvIGJlIHRydWx5IGNvbmZpZGVudGlhbC4NCi0gSXQg aXMgZW5vdWdoIHRvIHByb3RlY3QgIGFwcGxpY2F0aW9uIHByb3RvY29sIGRhdGEgZnJvbSBwYXNz aXZlIE1JVE0gYXR0YWNrLg0KLSBBcHBsaWNhdGlvbiBwcm90b2NvbCBkYXRhIHNob3VsZCBiZSB2 aXNpYmxlIHRvIHRoZSBuZXR3b3JrIGVsZW1lbnRzIGZvciBvcHRpbWFsIHJvdXRpbmcvYWNjb3Vu dGluZy9maWx0ZXJpbmcgZXRjLg0KDQpDbGVhcmx5IHRoZXJlIGFyZSBtdWx0aXBsZSBzY2VuYXJp b3MgdGhhdCBuZWVkIHRvIGJlIHN1cHBvcnRlZC4gUGVyaGFwcyBpdCB3aWxsIGJlIGVhc2llciBm b3IgYWxsIHRoZSBwYXJ0aWVzIGludm9sdmVkIHRvIGNvbWUgdG8gYW4gYWdyZWVtZW50IGlmIHdl IGRlY291cGxlIHRoZSBwcm9ibGVtIG9mIG5lZ290aWF0aW5nIGFuIGFwcGxpY2F0aW9uIHByb3Rv Y29sIGZyb20gdGhlIHByb2JsZW0gb2YgbWFraW5nIHZhcmlvdXMgY29udGVudHMgb2YgdGhlIFRM UyBoYW5kc2hha2UgY29uZmlkZW50aWFsIChvciBwcm90ZWN0ZWQgZnJvbSBwYXNzaXZlIGF0dGFj aywgb2JmdXNjYXRlZCwgZXRjLikNCg0KVGhlcmUgYXJlIHNlcGFyYXRlIHByb3Bvc2FscyB0aGF0 IGFkZHJlc3MgdGhlIGNvbmZpZGVudGlhbGl0eSBpc3N1ZSBpbiBhIHN5c3RlbWljIHdheSwgc3Vj aCB0aGF0IHRoZSBwcm90ZWN0aW9uIHdvdWxkIGFwcGx5IG5vdCBvbmx5IHRvIHRoZSBhcHBsaWNh dGlvbiBwcm90b2NvbCBkYXRhLCBidXQgYWxzbyB0aGUgY2xpZW50IGNlcnQsIFNOSSBpbmZvcm1h dGlvbiwgZXRjLiAoc2VlIGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1yYXktdGxzLWVu Y3J5cHRlZC1oYW5kc2hha2UtMDAudHh0IGlzIGFuIGV4YW1wbGUpLg0KDQpDaGVlcnMsDQoNCkFu ZHJlaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdGxzLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhbmllbCBL YWhuIEdpbGxtb3INClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMTMsIDIwMTMgMTI6MDYgUE0NClRv OiBYaWFveW9uZyBXdQ0KQ2M6IFBhdWwgSG9mZm1hbjsgQWxmcmVkbyBQaXJvbnRpOyBUTFNAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbVExTXSBBTFBOIG9yIE5QTiA/DQoNCk9uIDAzLzEzLzIwMTMg MDI6MTcgUE0sIFhpYW95b25nIFd1IHdyb3RlOg0KPiArMSBvbiB0aGlzLiBBIGZhbHNlIHNlbnNl IG9mIHNlY3VyaXR5IGlzIG5vIGJldHRlciB0aGFuIG5vIHNlY3VyaXR5LiBJZiB3ZSBiZWxpZXZl IHRoZSBOUE4gaW5mb3JtYXRpb24gaXMgc2Vuc2l0aXZlIGFuZCBzaG91bGQgYmUgcHJvdGVjdGVk LCB3ZSBzaG91bGQgaGF2ZSB0aGlzIGFmdGVyIHRoZSBGaW5pc2hlZCBtZXNzYWdlLg0KDQpJdCdz IHdvcnRoIHJlbWVtYmVyaW5nIHRoYXQgdGhlcmUgaXMgYWN0dWFsbHkgYSBwcmFjdGljYWwsIHJl YWwtd29ybGQgZGlzdGluY3Rpb24gYmV0d2VlbiAiaW4gdGhlIGNsZWFyIiBhbmQgImFjY2Vzc2li bGUgdG8gYSBNSVRNIHdobyBpcyB3aWxsaW5nIHRvIGNhdXNlIGEgY29ubmVjdGlvbiBoYW5kc2hh a2UgdG8gZmFpbCIuDQoNCkNsaWVudCBzb2Z0d2FyZSBjYW4gYXQgbGVhc3Qgb2JzZXJ2ZSB0aGF0 IHRoZSBpbmZvcm1hdGlvbiBsZWFrZWQgaW4gdGhlIGxhdHRlciBjYXNlLCBhbmQgY2FuIGFkdmlz ZSB0aGUgdXNlci4gIChob3cgaGVscGZ1bCB0aGlzIGlzIGluIHRoZSBmYWNlIG9mIGEgbWFsaWNp b3VzIGFkdmVyc2FyeSBtaWdodCBiZSBoYXJkIHRvIGFzc2VzcyB3aXRob3V0IHRoaW5raW5nIHRo cm91Z2ggdGhlIGZ1bGwgdXNlciBleHBlcmllbmNlKQ0KDQpOb3RlIGFsc28gdGhhdCBtb3Zpbmcg dGhlIE5QTiBpbmZvcm1hdGlvbiBhZnRlciB0aGUgRmluaXNoZWQgbWVzc2FnZSBpcyBhbHJlYWR5 IHBvc3NpYmxlIGluIHNvbWUgc2Vuc2UgYnkgZG9pbmcgYSBzZWNvbmQgaGFuZHNoYWtlLiAgT3Ig aXMgdGhlcmUgc29tZSByZXN0cmljdGlvbiBvbiByZW5lZ290aWF0aW9uIHRoYXQgc2F5cyB5b3Ug TVVTVCBub3Qgc3VwcGx5IE5QTiBvbiBzdWJzZXF1ZW50IGhhbmRzaGFrZXMgaWYgaXQgd2FzIG5v dCBzdXBwbGllZCBpbml0aWFsbHk/DQoNCkhvd2V2ZXIsIG1vdmluZyB0aGUgTlBOIGluZm8gYWZ0 ZXIgdGhlIGhhbmRzaGFrZSBtZWFucyB0aGF0IHRoZSBzZXJ2ZXIgd29uJ3QgaGF2ZSBhbiBvcHBv cnR1bml0eSB0byBzZWxlY3QgZGlmZmVyZW50IGNyZWRlbnRpYWxzIGJhc2VkIG9uIHRoZSBOUE4g aW5mby4NCg0KCS0tZGtnDQoNCg== From nico@cryptonector.com Wed Mar 13 14:11:35 2013 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 2E81021F8E53 for ; Wed, 13 Mar 2013 14:11:35 -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=[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 VIQm73yKspEM for ; Wed, 13 Mar 2013 14:11:34 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 91B4921F8E50 for ; Wed, 13 Mar 2013 14:11:34 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 4D76459807B for ; Wed, 13 Mar 2013 14:11:34 -0700 (PDT) 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; s=cryptonector.com; bh=fo9Q1mE9RG0ZQByqQa+e pbfOYN0=; b=WkBSb2Vmc6NLnvMfjaJ87jO4gGaW+3oK5c736sl3XctRSlvjAwhp BABb9aXuOj6T0cgJX9eZRNKXtJtXGj8bIJp8JJpBWsxlfyHMvG3dOwK7JCTaXK/t lwoXFbq5hbC8yzk1tFUicYFpUvU3VIp4B3Ye8oFKVSDzEufadQc8uEY= Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id E360B598057 for ; Wed, 13 Mar 2013 14:11:33 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id fn15so1455867wgb.32 for ; Wed, 13 Mar 2013 14:11:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.74.228 with SMTP id x4mr30126443wiv.0.1363209092458; Wed, 13 Mar 2013 14:11:32 -0700 (PDT) Received: by 10.216.148.193 with HTTP; Wed, 13 Mar 2013 14:11:32 -0700 (PDT) In-Reply-To: <5140CE2B.5020006@fifthhorseman.net> References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <5140CE2B.5020006@fifthhorseman.net> Date: Wed, 13 Mar 2013 16:11:32 -0500 Message-ID: From: Nico Williams To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Cc: "TLS@ietf.org" , Paul Hoffman , Alfredo Pironti Subject: Re: [TLS] ALPN or NPN ? 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 Mar 2013 21:11:35 -0000 On Wed, Mar 13, 2013 at 2:06 PM, Daniel Kahn Gillmor wrote: > On 03/13/2013 02:17 PM, Xiaoyong Wu wrote: >> +1 on this. A false sense of security is no better than no security. If we believe the NPN information is sensitive and should be protected, we should have this after the Finished message. > > It's worth remembering that there is actually a practical, real-world > distinction between "in the clear" and "accessible to a MITM who is > willing to cause a connection handshake to fail". > > Client software can at least observe that the information leaked in the > latter case, and can advise the user. (how helpful this is in the face > of a malicious adversary might be hard to assess without thinking > through the full user experience) > > Note also that moving the NPN information after the Finished message is > already possible in some sense by doing a second handshake. Or is there > some restriction on renegotiation that says you MUST not supply NPN on > subsequent handshakes if it was not supplied initially? The 'type' field of all records goes in the clear. The fact that re-negotiation is happening is visible. Nico -- From nico@cryptonector.com Wed Mar 13 14:13:38 2013 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 60A2111E8136 for ; Wed, 13 Mar 2013 14:13:38 -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 7TxeH3pu6Rmg for ; Wed, 13 Mar 2013 14:13:37 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id C8E4411E8135 for ; Wed, 13 Mar 2013 14:13:37 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 8665421DE71 for ; Wed, 13 Mar 2013 14:13:37 -0700 (PDT) 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; s=cryptonector.com; bh=z7QKON83sFM5PZ1gxQnF 4gCNGTg=; b=iFx3CEkkUgAgt/x0V46Y4CTsPfn0VlVp5O6VutyytFLnQwmNMXsA NzikLVuyBGgl3Xno2dSC13y5XsaRZCPrbRCelOafV6RPMLYBh6gxv4/KuthPsNgt HxjhWlo5c9dDtrWxwhujlly68ZJBpdp7P8ZeRN2Nry2PZTA67dYJnHo= Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 0C77921DE56 for ; Wed, 13 Mar 2013 14:13:36 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id hi8so3189710wib.7 for ; Wed, 13 Mar 2013 14:13:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.77.129 with SMTP id s1mr37215254wjw.17.1363209215773; Wed, 13 Mar 2013 14:13:35 -0700 (PDT) Received: by 10.216.148.193 with HTTP; Wed, 13 Mar 2013 14:13:35 -0700 (PDT) In-Reply-To: References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <5140CE2B.5020006@fifthhorseman.net> Date: Wed, 13 Mar 2013 16:13:35 -0500 Message-ID: From: Nico Williams To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Cc: "TLS@ietf.org" , Paul Hoffman , Alfredo Pironti Subject: Re: [TLS] ALPN or NPN ? 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 Mar 2013 21:13:38 -0000 It might not be a bad idea to negotiate hiding the record type by moving the real record type into the the encrypted payload (into the plaintext to be encrypted). Nico -- From dkg@fifthhorseman.net Wed Mar 13 14:18:15 2013 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 6F79B11E8134 for ; Wed, 13 Mar 2013 14:18:15 -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 qn8XNtZGP6ZG for ; Wed, 13 Mar 2013 14:18:15 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id DE81411E8116 for ; Wed, 13 Mar 2013 14:18:14 -0700 (PDT) Received: from [192.168.23.229] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 0D119F979; Wed, 13 Mar 2013 17:18:11 -0400 (EDT) Message-ID: <5140ED10.4060308@fifthhorseman.net> Date: Wed, 13 Mar 2013 17:18:08 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130112 Icedove/17.0.2 MIME-Version: 1.0 To: Nico Williams References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <5140CE2B.5020006@fifthhorseman.net> In-Reply-To: X-Enigmail-Version: 1.6a1pre Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2PBMUKDDIHJETFTFOSWVS" Cc: "TLS@ietf.org" , Paul Hoffman , Alfredo Pironti Subject: Re: [TLS] ALPN or NPN ? 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 Mar 2013 21:18:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2PBMUKDDIHJETFTFOSWVS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/13/2013 05:13 PM, Nico Williams wrote: > It might not be a bad idea to negotiate hiding the record type by > moving the real record type into the the encrypted payload (into the > plaintext to be encrypted). tcpmux [0] over TLS ? It's certainly doable (at the cost of more round trips). Of course, the server couldn't use this to select among a set of credentials to offer in this model. --dkg [0] https://tools.ietf.org/html/rfc1078 ------enig2PBMUKDDIHJETFTFOSWVS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJRQO0RXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpckXAP/RZ8V8sVoBZ45n72d9hzr3uF 51GcJxAG0H70O17HwtTRz9yNA1psn7swarngata9apobhHJeLQsIViwe5X355wju vsv6YGNWJ+A/MEu3Cd1kh4fSwyTagWJjX6DH3zeAOvAx4G+8Rzu1NzGYyzFZvGbJ Bmpln2nbLtYE2V5xvHVzI8D9jIcNmQbNeubtfCzoBF7SuVy10lcA/iSMSkA6S5A8 YZqujnSNqEnqZTgZWgRWU/3CkrqIa0+vWqoUNRCe6U3YQhiPBgpYT/11AuC9lhgC PNWMoM4sUmAUpA2tvmkIIrFHJP/emkGF4WLfLLaDlMS8tYzqBiTMw85DODugqjAK 6StGrrJZtwW5491heJe4OfrIlGJJhJC8w4SbEoylpg565+OtE4vSMfp0os61PhG3 XIYf+Q77oY+EAYtHfHZIi76LIFyY36UM4DB15e7hHgIamoI+JxFQMlXcQwab08gO mNKQPKzXkIbB4uSYFhuN5r/gwggXebYe2tkdvrrIZLhnOQY+wWEQ8iPbtkyAvtYV DGZgS+mqzvxTyz8F7kzP6Ep1+nu10xhqw73LHLwp9DSfXh2HiabnqlKUQZWiQsJR 7iZTfvmp8j+oE9UO3ugk5q1gwqmbpt6S6rNHHwNTlZ0nPwT8ynk8HJjL6iFg2pBL qojSzyZBD35uOZHN4meN =XSwL -----END PGP SIGNATURE----- ------enig2PBMUKDDIHJETFTFOSWVS-- From dkg@fifthhorseman.net Wed Mar 13 14:44:35 2013 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 0012421F8A55 for ; Wed, 13 Mar 2013 14:44:34 -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 mX2nxLCcZaqG for ; Wed, 13 Mar 2013 14:44:34 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id E74EB21F89B5 for ; Wed, 13 Mar 2013 14:44:33 -0700 (PDT) Received: from [192.168.23.229] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id C3EEDF979; Wed, 13 Mar 2013 17:44:30 -0400 (EDT) Message-ID: <5140F33B.5000308@fifthhorseman.net> Date: Wed, 13 Mar 2013 17:44:27 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130112 Icedove/17.0.2 MIME-Version: 1.0 To: Nico Williams References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <5140CE2B.5020006@fifthhorseman.net> <5140ED10.4060308@fifthhorseman.net> In-Reply-To: X-Enigmail-Version: 1.6a1pre Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2QMJOACSAVJPFARXRVBMG" Cc: "TLS@ietf.org" , Paul Hoffman , Alfredo Pironti Subject: Re: [TLS] ALPN or NPN ? 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 Mar 2013 21:44:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2QMJOACSAVJPFARXRVBMG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/13/2013 05:35 PM, Nico Williams wrote: > On Wed, Mar 13, 2013 at 4:18 PM, Daniel Kahn Gillmor wrote: >> tcpmux [0] over TLS ? It's certainly doable (at the cost of more roun= d >> trips). Of course, the server couldn't use this to select among a set= >> of credentials to offer in this model. >=20 > No. Just the record type, as in hadnshake vs. application vs. alert. ah, sorry, i'd misunderstood you. if an alert about failure of the encryption layer, stuffing it inside the failing encryption layer seems like a chicken-and-egg problem. Otherwise, i think this would be a worthwhile extension to consider. It certainly avoids some established leaks about the state of the session. > Muxing multiple application protocols over one TLS connection might > well be interesting, but brings up the whole SSHv1/v2 multiplexing > experience -i.e., lots of problems-, so I'd rather stay away from > that. fwiw, tcpmux doesn't multiplex multiple applications over a single TLS connection -- it is just a well-defined (archaic) way to allow a single port to serve multiple different protocols -- but only one per TCP session (or in this case, one per TLS connection). --dkg ------enig2QMJOACSAVJPFARXRVBMG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJRQPM7XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcIQ8QAKPAkZEBWbSMYCCLQRoXy6Rf b3V9KhjQ94MJbrbwsRzSbG2M0NzOa/fleME2epY2W41GRDZA9icL0u2jyN7JNQaZ g4EZmmuHwmrWnqKJiVVo9jGydWIfnRJbfEyoi9oxP7J/pACkpro9id6NimUQJkze wEjGh5qixDEQWfFgwWsDJrSJLQO6F1Yb98i8l805kncKN95Ig5yCeR46g/WlQoQY vw0DhV+AnpzUUYKxiiizkjcm5jcOtx8frSDcON0vK9Wb996zpvLrNDL2TIi4OcGW lifPoyBPBnFmHgVw2zdzDUrS5awz0FCGGULGZHbghNIU+AvBz2wN29J+DftOUSnb iUj/o7wQl23NtI7VDL5tMdCzbEe1Adtij6oPB8eaaHmOePrm88T5RPkYl1MHaqgD Xhu/2D4Q/pG7zu5WFechKvBRecSOClBzRQrLpnCQHkwD9jkaehdQ9KfUOtYBK4af CVFor/j30EzHjVk49AP02gOV/XLLXYSoqz24w+iAz1EX7k5teB8+TRf9AV4lbOkE E3YG3C5oBC7uc6i8LdTS8YdQGN7jZCC396iJ7RweyCTCpCxaWB9edglYXxS2rCcH MheQZKedkFQS/RCAB1U9kV4/CInb957oUsEa2AGpiIpsmy24CuBnyguH6YgFGU+6 fAq7xUXCiT+ChMj+uvG/ =0xoO -----END PGP SIGNATURE----- ------enig2QMJOACSAVJPFARXRVBMG-- From nico@cryptonector.com Wed Mar 13 14:53:26 2013 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 0F1D511E80D9 for ; Wed, 13 Mar 2013 14:53:26 -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 Yhhbs9vykmyF for ; Wed, 13 Mar 2013 14:53:25 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 059F311E80A3 for ; Wed, 13 Mar 2013 14:53:24 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 952C54280F4 for ; Wed, 13 Mar 2013 14:53:24 -0700 (PDT) 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; s=cryptonector.com; bh=fy5iYHLJZFWx8GWPq/JA Bfjiwsk=; b=WG+cnxCle5YNueqS74j/Y92l2nTBqx/ASUrRbtHhMf0mFCnnoW2m HrcbMFMqSxYhBpqPGFixwDmuj4IczRET8ynjXwZAI7tUl/+Uuc+P5kxqx8tHZSwT G7ZbIghfVKth+T/Ebe/eFz40OPdU3RLxgL2e9EDV0oF11l27Ix/36G8= Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id EFBE41D80D1 for ; Wed, 13 Mar 2013 14:35:25 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id 12so417756wgh.1 for ; Wed, 13 Mar 2013 14:35:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.80.35 with SMTP id o3mr30202593wix.9.1363210524421; Wed, 13 Mar 2013 14:35:24 -0700 (PDT) Received: by 10.216.148.193 with HTTP; Wed, 13 Mar 2013 14:35:24 -0700 (PDT) In-Reply-To: <5140ED10.4060308@fifthhorseman.net> References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <5140CE2B.5020006@fifthhorseman.net> <5140ED10.4060308@fifthhorseman.net> Date: Wed, 13 Mar 2013 16:35:24 -0500 Message-ID: From: Nico Williams To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Cc: "TLS@ietf.org" , Paul Hoffman , Alfredo Pironti Subject: Re: [TLS] ALPN or NPN ? 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 Mar 2013 21:53:26 -0000 On Wed, Mar 13, 2013 at 4:18 PM, Daniel Kahn Gillmor wrote: > On 03/13/2013 05:13 PM, Nico Williams wrote: >> It might not be a bad idea to negotiate hiding the record type by >> moving the real record type into the the encrypted payload (into the >> plaintext to be encrypted). > > tcpmux [0] over TLS ? It's certainly doable (at the cost of more round > trips). Of course, the server couldn't use this to select among a set > of credentials to offer in this model. No. Just the record type, as in hadnshake vs. application vs. alert. Muxing multiple application protocols over one TLS connection might well be interesting, but brings up the whole SSHv1/v2 multiplexing experience -i.e., lots of problems-, so I'd rather stay away from that. Nico -- From nico@cryptonector.com Wed Mar 13 15:20:46 2013 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 A113321F899E for ; Wed, 13 Mar 2013 15:20:46 -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 Yd5aEU-OBnIf for ; Wed, 13 Mar 2013 15:20:46 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 3376B21F894D for ; Wed, 13 Mar 2013 15:20:46 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 0573B428076 for ; Wed, 13 Mar 2013 15:20:46 -0700 (PDT) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id A970C428072 for ; Wed, 13 Mar 2013 15:20:45 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id t44so1528812wey.40 for ; Wed, 13 Mar 2013 15:20:44 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.60.195 with SMTP id j3mr33573wjr.33.1363213244149; Wed, 13 Mar 2013 15:20:44 -0700 (PDT) Received: by 10.216.148.193 with HTTP; Wed, 13 Mar 2013 15:20:43 -0700 (PDT) In-Reply-To: <5140F33B.5000308@fifthhorseman.net> References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <5140CE2B.5020006@fifthhorseman.net> <5140ED10.4060308@fifthhorseman.net> <5140F33B.5000308@fifthhorseman.net> Date: Wed, 13 Mar 2013 17:20:43 -0500 Message-ID: From: Nico Williams To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Cc: "TLS@ietf.org" , Paul Hoffman , Alfredo Pironti Subject: Re: [TLS] ALPN or NPN ? 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 Mar 2013 22:20:46 -0000 On Wed, Mar 13, 2013 at 4:44 PM, Daniel Kahn Gillmor wrote: > On 03/13/2013 05:35 PM, Nico Williams wrote: >> On Wed, Mar 13, 2013 at 4:18 PM, Daniel Kahn Gillmor wrote: >>> tcpmux [0] over TLS ? It's certainly doable (at the cost of more round >>> trips). Of course, the server couldn't use this to select among a set >>> of credentials to offer in this model. >> >> No. Just the record type, as in hadnshake vs. application vs. alert. > > ah, sorry, i'd misunderstood you. if an alert about failure of the > encryption layer, stuffing it inside the failing encryption layer seems > like a chicken-and-egg problem. Otherwise, i think this would be a > worthwhile extension to consider. It certainly avoids some established > leaks about the state of the session. Sure. >> Muxing multiple application protocols over one TLS connection might >> well be interesting, but brings up the whole SSHv1/v2 multiplexing >> experience -i.e., lots of problems-, so I'd rather stay away from >> that. > > fwiw, tcpmux doesn't multiplex multiple applications over a single TLS > connection -- it is just a well-defined (archaic) way to allow a single > port to serve multiple different protocols -- but only one per TCP > session (or in this case, one per TLS connection). Ah, that, yes, but that's pretty much what NPN is, isn't it. From ynir@checkpoint.com Wed Mar 13 17:53:31 2013 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 460BF11E8106 for ; Wed, 13 Mar 2013 17:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.585 X-Spam-Level: X-Spam-Status: No, score=-10.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 xFtwJ-CznULp for ; Wed, 13 Mar 2013 17:53:30 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4B36911E80F4 for ; Wed, 13 Mar 2013 17:53:30 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2E0r18u011936; Thu, 14 Mar 2013 02:53:02 +0200 X-CheckPoint: {51411E99-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.95]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 02:53:01 +0200 From: Yoav Nir To: Xiaoyong Wu Thread-Topic: [TLS] ALPN or NPN ? Thread-Index: Ac4fS4/pCw0qsUTCSMOaz+CCsKSG8gAiTGQAAACwbgAAC7LWAAANzMUA Date: Thu, 14 Mar 2013 00:53:00 +0000 Message-ID: <681BE181-C3AD-4DD9-98AB-95CBE549CCA1@checkpoint.com> References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.156] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <0A93D5AC00FD9F4296AEA28719370C05@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Hoffman , Alfredo Pironti , "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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, 14 Mar 2013 00:53:31 -0000 On Mar 13, 2013, at 2:17 PM, Xiaoyong Wu wrote: >=20 >> -----Original Message----- >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of >> Alfredo Pironti >> Sent: Wednesday, March 13, 2013 5:43 AM >> To: Paul Hoffman >> Cc: TLS@ietf.org >> Subject: Re: [TLS] ALPN or NPN ? >>=20 >> On Wed, Mar 13, 2013 at 1:23 PM, Paul Hoffman >> wrote: >>> Firewall vendors love to add features to firewalls that allow blocking = of >> content, even if that blocking is often harmful. If you don't believe me= , walk >> down to your IT department and ask for a 15-minute tour of the UI on the >> corporate firewall. >>>=20 >>> If we go with ALPN, firewall vendors *will* add blocking of various >>> applications as a firewall feature. Some IT departments will turn this >>> on incorrectly, just as they turn on stuff now that makes network >>> operations harder. (Fred Baker and I are writing a document in OPSAWG >>> about this.) >>=20 >> Is there any interest in a compromise solution? For example, sending the >> NPN information *after* the Finished message. This adds one round-trip, >> but makes the message exchange as secure as any other application data. = (In >> general, the idea would be to perform a further round of negotiation aft= er >> handshake completion.) >>=20 >> I'm not at all against NPN and the reasons behind it; I just feel a bit >> uncomfortable with releasing a spec with a known security issue. >=20 > +1 on this. A false sense of security is no better than no security. If w= e believe the NPN information is sensitive and should be protected, we shou= ld have this after the Finished message. I don't believe that the NPN information is sensitive. At this point, there= is only one interesting value: HTTP/2, and maybe HTTP/1. And those two kin= ds of connections should be easy to distinguish by traffic analysis. Also, = knowing which version of HTTP someone uses, is not a particularly interesti= ng piece of information for the attacker to get. It's only if different ser= vices begin to use this information that things become interesting, but sti= ll I don't see any point to this. Suppose we choose NPN, and the server adv= ertises HTTP/1.1, HTTP/2.0, and SSTP. What advantage does the attacker lose= by not knowing which one the client chose? If anything, this comprehensive= list exposes more information about the server than would be exposed by AL= PN: If a browser connects to this server, NPN exposes all three services, w= hile ALPN does not expose SSTP (which the browser won't show). So I believe that NPN offers no security advantage. As a lazy implementer, = ALPN requires less code change, and less changes to the state machine. Yoav From ynir@checkpoint.com Wed Mar 13 18:05:01 2013 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 CF78411E80E0 for ; Wed, 13 Mar 2013 18:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.585 X-Spam-Level: X-Spam-Status: No, score=-10.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 TkmcrFmueGT3 for ; Wed, 13 Mar 2013 18:05:01 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B98EF21F8700 for ; Wed, 13 Mar 2013 18:05:00 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2E14oe3013139; Thu, 14 Mar 2013 03:04:59 +0200 X-CheckPoint: {5141215E-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.95]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 03:04:52 +0200 From: Yoav Nir To: Paul Hoffman Thread-Topic: [TLS] ALPN or NPN ? Thread-Index: Ac4fS4/pCw0qsUTCSMOaz+CCsKSG8gAiTGQAAAJpqIAAAki4gAAV58EA Date: Thu, 14 Mar 2013 01:04:51 +0000 Message-ID: <8EE96183-E8F4-4208-B602-4C308F0515FB@checkpoint.com> References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> In-Reply-To: <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.156] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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, 14 Mar 2013 01:05:02 -0000 On Mar 13, 2013, at 10:37 AM, Paul Hoffman wrote: > On Mar 13, 2013, at 9:32 AM, Yoav Nir wrote: >=20 >> [firewall vendor hat firmly on] >=20 > [firewall tester hat firmly on] >=20 >> On Mar 13, 2013, at 8:23 AM, Paul Hoffman wrote: >>=20 >>> Firewall vendors love to add features to firewalls that allow blocking = of content, even if that blocking is often harmful. If you don't believe me= , walk down to your IT department and ask for a 15-minute tour of the UI on= the corporate firewall. >>=20 >> Agreed, but they don't do it because of our love of blocking things, but= because those same IT department people would like to have fine-grained co= ntrol over what does and does not pass the firewall. >=20 > Noted. If you were an automaker, the fact that 1% of your customers want = to be able to drive your car faster than 100 MPH in case of emergency, you = would in fact make the car able to go that fast, but not include a way to t= est if the driver was an adolescent male in the proximity of other adolesce= nt males. A feature is a feature. That's pretty much what all automakers do. The speedometer on my car goes t= o 220 KM/h (137 MPH), although considering how it handles at 100 KM/h this = seems more like wishful thinking on Fiat's part than anything to do with re= ality. >>> If we go with ALPN, firewall vendors *will* add blocking of various app= lications as a firewall feature. >>=20 >> They will add such a blocking feature regardless. With ALPN this can be = done by observing the ClientHello. With NPN this requires being a transpare= nt proxy, which inevitably lowers performance or throughput. >=20 > This is a false dichotomy. All modern firewall vendors already have TLS p= roxyhing (which is only somewhat "transparent") as a feature already. If th= is WG chooses NPN or ALPN, that feature will still be there. They do, but they only activate it if the features that are enabled require= it. So if you turn on URL filtering based only on IP addresses and host na= mes, these can be filtered without proxying. If you filter by deeper parts = of the path, you have to proxy.=20 >=20 >>> Some IT departments will turn this on incorrectly, just as they turn on= stuff now that makes network operations harder. (Fred Baker and I are writ= ing a document in OPSAWG about this.) >>>=20 >>> Thus, I prefer NPN. I can live with ALPN, but it will cause unnecessary= breakage of secure services. >>=20 >> I don't think people would want to block, as long as NPN/ALPN is used on= ly for distinguishing HTTP/1 from HTTP/2. But I can see this used in the fu= ture to mark other applications, such as SSL-VPN tunneling client, like Mic= rosoft's SSTP, Cisco's "SSL VPN client", or my company's SNX. If a future f= irewall has a new feature for blocking tunneling clients, then that feature= is going to work regardless of whether we choose NPN or ALPN. The only que= stion is whether it's going to require being an SSL proxy or not. But if th= e IT people would like to block tunneling clients, and that requires activa= ting an SSL proxy, then they will do it.=20 >=20 > Correct. >=20 >> This is not an argument for ALPN. If they really want to block tunneling= clients, they have to decrypt the traffic anyway to validate that it's jus= t regular web traffic. I'm just saying that the firewall users require cont= rol over everything that goes through the network. NPN will not be able to = stop firewall vendors from supplying that kind of control. >=20 > We disagree about "the firewall users" and "require". A small number of f= irewall administrators have that requirement, but offering the filtering wi= ll cause more to do so. If vendors went by what customers are asking for, Apple would never release= a capacitative touch-screen phone without a physical keyboard or a stylus.= Once they did, everybody else also released phones with similar properties= . Firewalls block SPDY now, not because customers demand it, but to get the= browsers to fall back to HTTP/1, which they have parsers for. This will ch= ange as firewall vendors develop parsers for HTTP/2, but the capability to = block will remain regardless of what signaling mechanism we choose. That's why I think we should ignore the threat of firewalls, and concentrat= e on what is best for TLS in terms of round-trips, latency and implementati= on convenience vs the alleged security gain from hiding chosen application = from Eve. Yoav From nico@cryptonector.com Wed Mar 13 21:00:22 2013 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 AEB6811E80D2 for ; Wed, 13 Mar 2013 21:00:22 -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 SUD9YJRMBmkD for ; Wed, 13 Mar 2013 21:00:18 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2B921F8CA3 for ; Wed, 13 Mar 2013 21:00:18 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 5A735438081 for ; Wed, 13 Mar 2013 21:00:18 -0700 (PDT) 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; s=cryptonector.com; bh=QsFCyGZqOjt6GN1lt7sx bUSXGaM=; b=ocPpANM2CBx1rEYWyetpgu8ACBVpy3OMMXVA8WQxpd7d8VMWNfop YTsglGqyWKwQj/KXz5QbnDB9dKBRpS2db1vv4lr5XVw7qi1DpZDEE/H+ojbfwLlo yozBso+5Se5mjKWcPEozblXAWoeljLD8+mDHIEW0093hhHU8pGIGsbk= Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 0EA4B43807F for ; Wed, 13 Mar 2013 21:00:17 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id p43so1709243wea.24 for ; Wed, 13 Mar 2013 21:00:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.76.84 with SMTP id i20mr1206560wiw.9.1363233615308; Wed, 13 Mar 2013 21:00:15 -0700 (PDT) Received: by 10.216.148.193 with HTTP; Wed, 13 Mar 2013 21:00:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Mar 2013 23:00:14 -0500 Message-ID: From: Nico Williams To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org, paul.hoffman@vpnc.org, alfredo@pironti.eu Subject: Re: [TLS] ALPN or NPN ? 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, 14 Mar 2013 04:00:22 -0000 On Wed, Mar 13, 2013 at 9:13 PM, Peter Gutmann wrote: > Nico Williams writes: >>It can't be entirely after the Finished message. The server at least has to >>signal willingness to negotiate an application protocol after the Finished >>message exchange, and we should not use a handshake record for it (because >>then the presence of either re-nego or app protocol nego will be obvious to >>middleboxes. > > This got discussed to some extent among some TLS folks at the RSA conference a > week or so back, rather than having a specific NPN facility we should really > be thinking about a generalised mechanism to allow extensions to additionally > be specified once the handshake has entered the encrypted phase. In other > words there's an insecure-extensions negotiation during the handshake, and a > secure-extension negotiation after the handshake has completed. The analogy > used was STARTTLS, you negotiate any initial options before you switch to TLS, > and then renegotiate anything critical inside the TLS security envelope. The > use of the standard extension mechanism allows them to be handled identically > to the way extensions are already done, and doesn't limit things to only > dealing with NPN. Count me as all for this, as long as it's coupled with not leaking that the records following the handshake are also handshake records. We could even have a fast second handshake that requires just half a round trip, something like this: - ClientHello says "I support protecting the the record type" - ServerHello says "I support protecting the record type", and "I support negotiation of application protocols (optionally: and also these applications: X, Y, and Z)" - - Client sends a new handshake message saying "No need to do a new handshake, but I want to speak application protocol X", and then sends an application record - if the server doesn't support application protocol X it replies with a [protected] alert record saying as much and optionally listing supported application protocols, which gives the client a chance to try some other protocol. This costs no extra round trips and is exceedingly simple. Middleboxes will see the client and server advertise this feature but won't know which application protocol, if any, the two negotiate (unless the middleboxes are MITM middleboxes). Nico -- From pgut001@cs.auckland.ac.nz Wed Mar 13 22:10:30 2013 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 1AF0B21F8E91 for ; Wed, 13 Mar 2013 22:10:30 -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=[AWL=0.000, 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 2P2lbp3cccPm for ; Wed, 13 Mar 2013 22:10:28 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 43EA121F8E90 for ; Wed, 13 Mar 2013 22:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1363237828; x=1394773828; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=gR32SCQVfHAY3M0CLEbmWu7ctXcuYDbmT+1U214h/YE=; b=HQSlzHG73r0sVbE7MxAW+VhlsIFC6GVs9F/9OkyzUwnjlGcCfEii9W7h PQZTuAkYDJ3HIoqm4/RNww5lLXVj0A1+SNyYVrNPVtKdR9hGiuC6peGiJ 3wnDjQrLTc7/eVpgT+tOF9gt5D/vpQl//Ey3zKLu98JuSM5jlMS7dg024 g=; X-IronPort-AV: E=Sophos;i="4.84,842,1355050800"; d="scan'208";a="175393529" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 14 Mar 2013 18:10:24 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.110]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 18:10:24 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] ALPN or NPN ? Thread-Index: Ac4gcjtKSugdSJqPSd+Iup4grcWU0Q== Date: Thu, 14 Mar 2013 05:10:23 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73375E0B61@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] ALPN or NPN ? 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, 14 Mar 2013 05:10:30 -0000 Nico Williams writes:=0A= >On Wed, Mar 13, 2013 at 1:17 PM, Xiaoyong Wu wrote:=0A= >>> I'm not at all against NPN and the reasons behind it; I just feel a bit= =0A= >>> uncomfortable with releasing a spec with a known security issue.=0A= >>=0A= >> +1 on this. A false sense of security is no better than no security. If = we=0A= >> believe the NPN information is sensitive and should be protected, we sho= uld=0A= >> have this after the Finished message.=0A= >=0A= >It can't be entirely after the Finished message. The server at least has = to=0A= >signal willingness to negotiate an application protocol after the Finished= =0A= >message exchange, and we should not use a handshake record for it (because= =0A= >then the presence of either re-nego or app protocol nego will be obvious t= o=0A= >middleboxes.=0A= =0A= This got discussed to some extent among some TLS folks at the RSA conferenc= e a=0A= week or so back, rather than having a specific NPN facility we should reall= y=0A= be thinking about a generalised mechanism to allow extensions to additional= ly=0A= be specified once the handshake has entered the encrypted phase. In other= =0A= words there's an insecure-extensions negotiation during the handshake, and = a=0A= secure-extension negotiation after the handshake has completed. The analog= y=0A= used was STARTTLS, you negotiate any initial options before you switch to T= LS,=0A= and then renegotiate anything critical inside the TLS security envelope. T= he=0A= use of the standard extension mechanism allows them to be handled identical= ly=0A= to the way extensions are already done, and doesn't limit things to only=0A= dealing with NPN.=0A= =0A= Peter.= From pgut001@cs.auckland.ac.nz Wed Mar 13 22:15:19 2013 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 B8F6421F8C4F for ; Wed, 13 Mar 2013 22:15:18 -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 mhuUCDIVHSYY for ; Wed, 13 Mar 2013 22:15:17 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD3321F8A71 for ; Wed, 13 Mar 2013 22:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1363238118; x=1394774118; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=j5icZANaDAnH7Fx+8ibllI6Yl34TLOiu/Lca0rsh1Gg=; b=kGj+dsZ4pz/81n6/46Cz9WBKmF3mcXxp+UGqJYRpa8F/DeZAwk5uGxB+ X+JNYEpPbf44+iajdGJYuc/ve91pYi6n8xgARp/5zleVYnCHnI+OUgd2j Fex/8J/+mjho07tB/yM3qIXG8gHQOeci2BmCDHniNJDWqVyewsD4d0oNI o=; X-IronPort-AV: E=Sophos;i="4.84,842,1355050800"; d="scan'208";a="175393947" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 14 Mar 2013 18:15:16 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.110]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 18:15:16 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] ALPN or NPN ? Thread-Index: Ac4gcumEd/l551yzQo2ZtwJKL3TWXw== Date: Thu, 14 Mar 2013 05:15:15 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73375E0B6E@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] ALPN or NPN ? 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, 14 Mar 2013 05:15:19 -0000 Nico Williams writes:=0A= =0A= >Count me as all for this, as long as it's coupled with not leaking that th= e=0A= >records following the handshake are also handshake records. We could even= =0A= >have a fast second handshake that requires just half a round trip, somethi= ng=0A= >like this:=0A= >=0A= > - ClientHello says "I support protecting the the record type"=0A= > - ServerHello says "I support protecting the record type", and "I support= =0A= >negotiation of application protocols (optionally: and also these=0A= >applications: X, Y, and Z)"=0A= > - =0A= =0A= It'd have to be quite carefully designed, if a middlebox can tell the=0A= difference between a (short, fixed-length) Finished and a Finished+Extensio= ns=0A= then they can at least tell that something else is going on. Depends on=0A= whether we're defending against plain interception or interception+traffic= =0A= analysis (which is much harder, no matter what we decide to do).=0A= =0A= In any case though when it was discussed the STARTTLS-style extensions-befo= re=0A= and extensions-after seemed to make the most send, both in terms of general= ity=0A= and being able to re-use existing specs and code.=0A= =0A= Peter.= From nico@cryptonector.com Wed Mar 13 22:52:52 2013 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 93ED121F8758 for ; Wed, 13 Mar 2013 22:52:52 -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, HTML_MESSAGE=0.001] 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 Ut2Q5khtd9so for ; Wed, 13 Mar 2013 22:52:51 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id E33D221F8640 for ; Wed, 13 Mar 2013 22:52:51 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id F2B4867407B for ; Wed, 13 Mar 2013 22:52:44 -0700 (PDT) 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; s=cryptonector.com; bh=vlQPoqdkrd57oGsgA+F2 ucICFZI=; b=B0inHOfPQGewIdF8m3wbq/kBBFvrMj27I5X9SyHkNO6FVN+pK4Re RV8CMQNOnTsL2Z7BQ3tHLtc1TOQNJ+rlOUh6avXiDbKw9JCEzxQY2Fug0cB4soFe 3vIZ/FO1S3Ls1SKEWBNfh3DAIuU9/TUnZBzGoVBAPYYlWTduY6unt6I= Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 8133B674070 for ; Wed, 13 Mar 2013 22:52:44 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id t57so1784761wey.27 for ; Wed, 13 Mar 2013 22:52:43 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.94.69 with SMTP id da5mr31470328wib.30.1363240363324; Wed, 13 Mar 2013 22:52:43 -0700 (PDT) Received: by 10.216.148.193 with HTTP; Wed, 13 Mar 2013 22:52:43 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73375E0B6E@uxcn10-2.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73375E0B6E@uxcn10-2.UoA.auckland.ac.nz> Date: Thu, 14 Mar 2013 00:52:43 -0500 Message-ID: From: Nico Williams To: Peter Gutmann Content-Type: multipart/alternative; boundary=f46d0442694a9981f704d7dc218d Cc: "tls@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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, 14 Mar 2013 05:52:52 -0000 --f46d0442694a9981f704d7dc218d Content-Type: text/plain; charset=UTF-8 On Thursday, March 14, 2013, Peter Gutmann wrote: > Nico Williams writes: > > >Count me as all for this, as long as it's coupled with not leaking that > the > >records following the handshake are also handshake records. We could even > >have a fast second handshake that requires just half a round trip, > something > >like this: > > > > - ClientHello says "I support protecting the the record type" > > - ServerHello says "I support protecting the record type", and "I support > >negotiation of application protocols (optionally: and also these > >applications: X, Y, and Z)" > > - > > It'd have to be quite carefully designed, if a middlebox can tell the > difference between a (short, fixed-length) Finished and a > Finished+Extensions > then they can at least tell that something else is going on. Depends on > whether we're defending against plain interception or interception+traffic > analysis (which is much harder, no matter what we decide to do). The new thing would externally appear to have an application record type and would appear exactly where you expect the first application record (we could even cater to server-speaks-first (or concurrently with the client) by having both the client and server send such a message if need be. We could send both, the extensions message, and any actual app data in one record, thou after decryption we'd have two. Then the only clue for middleboxes would be first app record length, and in many cases this could be handled by fragmentation or tacking on "ignore" data. > In any case though when it was discussed the STARTTLS-style > extensions-before > and extensions-after seemed to make the most send, both in terms of > generality > and being able to re-use existing specs and code. In many cases all we'll need before is both peers to state willingness to use the new thing. If the credentials used in the initial handshake are good enough then a second one isn't needed, just a "I'm using app protocol X" first message and a "OK" and I don't speak protocol X, here's what I speak: ..." replies. Nico -- --f46d0442694a9981f704d7dc218d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thursday, March 14, 2013, Peter Gutmann wrote:
Nico Williams <nico@cryptonector.com> writes:

>Co= unt me as all for this, as long as it's coupled with not leaking that t= he
>records following the handshake are also handshake records. We could ev= en
>have a fast second handshake that requires just half a round trip= , something
>like this:
>
> - ClientHello says "I su= pport protecting the the record type"
> - ServerHello says "I support protecting the record type", a= nd "I support
>negotiation of application protocols (optionally:= and also these
>applications: X, Y, and Z)"
> - <hands= hake continues and finishes>

It'd have to be quite carefully designed, if a middlebox can tell t= he
difference between a (short, fixed-length) Finished and a Finished+Ex= tensions
then they can at least tell that something else is going on. = =C2=A0Depends on
whether we're defending against plain interception or interception+traf= fic
analysis (which is much harder, no matter what we decide to do).

The new thing would externally appear to have a= n application record type and would appear exactly where you expect the fir= st application record (we could even cater to server-speaks-first (or concu= rrently with the client) by having both the client and server send such a m= essage if need be. =C2=A0We could send both,=C2=A0the extensions message, a= nd any actual app data in one record, thou after decryption we'd have t= wo. =C2=A0Then the only clue for middleboxes would be first app record leng= th, and in many cases this could be handled by fragmentation or tacking on = "ignore" data.
=C2=A0
In any case though when it was discussed the STARTTLS-style extensions-b= efore
and extensions-after seemed to make the most send, both in terms o= f generality
and being able to re-use existing specs and code.

In many cases all we'll need b= efore is both peers to state willingness to use the new thing. =C2=A0If the= credentials used in the initial handshake are good enough then a second on= e isn't needed, just a "I'm using app protocol X" first m= essage and a "OK" and=C2=A0I don't speak protocol X, here'= ;s what I speak: ..." replies.

Nico
= --= =C2=A0

--f46d0442694a9981f704d7dc218d-- From juhovh@iki.fi Thu Mar 14 00:29:21 2013 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 8C95B11E80E2 for ; Thu, 14 Mar 2013 00:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] 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 sLL0gAWQ3O-U for ; Thu, 14 Mar 2013 00:29:21 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5A021F8DC0 for ; Thu, 14 Mar 2013 00:29:20 -0700 (PDT) Received: from [10.60.154.138] (188.238.157.138) by kirsi1.inet.fi (8.5.140.03) id 51292B7F0163A1E1; Thu, 14 Mar 2013 09:29:09 +0200 References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> <8EE96183-E8F4-4208-B602-4C308F0515FB@checkpoint.com> Mime-Version: 1.0 (1.0) In-Reply-To: <8EE96183-E8F4-4208-B602-4C308F0515FB@checkpoint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B146) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= Date: Thu, 14 Mar 2013 09:29:03 +0200 To: Yoav Nir Cc: "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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, 14 Mar 2013 07:29:21 -0000 On 14.3.2013, at 3.04, Yoav Nir wrote: > That's why I think we should ignore the threat of firewalls, and concentra= te on what is best for TLS in terms of round-trips, latency and implementati= on convenience vs the alleged security gain from hiding chosen application f= rom Eve. I have to say I agree with this. If there is something in ClientHello extens= ions that needs to be protected, then it should be handled by renegotiation.= If not, then the functionality should be kept as simple as possible. Everything else in TLS works so that the server does not leak information of= its support of ciphers or TLS versions. I don't see why this single case sh= ould work the other way around. If this is considered a problem, we should h= ave a seperate extension that tries to work around firewalls as much as poss= ible. >=20 Juho From ynir@checkpoint.com Thu Mar 14 04:59:47 2013 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 4668B21F8AD8 for ; Thu, 14 Mar 2013 04:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.7 X-Spam-Level: X-Spam-Status: No, score=-7.7 tagged_above=-999 required=5 tests=[MIME_8BIT_HEADER=0.3, 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 qgxUOoU8bK+8 for ; Thu, 14 Mar 2013 04:59:46 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6544C21F8A99 for ; Thu, 14 Mar 2013 04:59:46 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2EBxNg9026641; Thu, 14 Mar 2013 13:59:36 +0200 X-CheckPoint: {5141BAC0-2-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.95]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 13:17:12 +0200 From: Yoav Nir To: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= Thread-Topic: [TLS] ALPN or NPN ? Thread-Index: Ac4fS4/pCw0qsUTCSMOaz+CCsKSG8gAiTGQAAAJpqIAAAki4gAAV58EAAA1rKoAAB/f4gA== Date: Thu, 14 Mar 2013 11:17:11 +0000 Message-ID: <0E5B0F1F-054F-443A-800A-E3AFC95934EE@checkpoint.com> References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> <8EE96183-E8F4-4208-B602-4C308F0515FB@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.4] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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, 14 Mar 2013 11:59:47 -0000 On Mar 14, 2013, at 3:29 AM, Juho V=E4h=E4-Herttua wrote: > On 14.3.2013, at 3.04, Yoav Nir wrote: >> That's why I think we should ignore the threat of firewalls, and concent= rate on what is best for TLS in terms of round-trips, latency and implement= ation convenience vs the alleged security gain from hiding chosen applicati= on from Eve. >=20 > I have to say I agree with this. If there is something in ClientHello ext= ensions that needs to be protected, then it should be handled by renegotiat= ion. If not, then the functionality should be kept as simple as possible. >=20 > Everything else in TLS works so that the server does not leak information= of its support of ciphers or TLS versions. I don't see why this single cas= e should work the other way around. If this is considered a problem, we sho= uld have a seperate extension that tries to work around firewalls as much a= s possible. To be fair, what the server supports is hardly a secret. An attacker can do= like SSL pulse, and attempt multiple handshakes with the server, specifyin= g a single ciphersuite/TLS version/Application each time, and get a compreh= ensive list of everything that the server supports. I still think it's an irrelevant leak, with such a small label space. Yoav From tom@ritter.vg Thu Mar 14 06:47:18 2013 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 94A8E11E8123 for ; Thu, 14 Mar 2013 06:47:18 -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 98Y1piDQgkca for ; Thu, 14 Mar 2013 06:47:14 -0700 (PDT) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id 230D711E8124 for ; Thu, 14 Mar 2013 06:47:14 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id b10so1678945vea.16 for ; Thu, 14 Mar 2013 06:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:content-transfer-encoding; bh=zjhZQH9gXEJhrFd9OMDQGB3rROcTsGuDly5olkTUgw4=; b=FTTu+gMGAtwgoXMelP+0STrqqohUUyUnDBaxAkBMWq/IsXP+bw+XKcFqHl3gCqZ+An 6qZ5TUaw2rivb8cRq8/oQnoQSw3gavOINju3yptaPxt3labmgsizYPM5Y0rgVMDzORhV RJgyDyJPnl/k4vfdBJpFhJ5aPVwcEwdQbCong= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:content-transfer-encoding :x-gm-message-state; bh=zjhZQH9gXEJhrFd9OMDQGB3rROcTsGuDly5olkTUgw4=; b=ZeSQ2ZyyDMvbrZ28yg/6b/04psXi1jaFbTCvm0Q1+EaIuGIwxO9z1Ik6KDqYR3mlTY J2VyAjazRL6Vwj+TLzgjiImBWIoTxbz64x/CMEjyFuTKQ57e6Sfjac0OECXN7NJxGJrR PgMhfsmBGbnFI7knIycRxz4gZg8OMYdJenRktgbsidmjYEy+8LXZH7Iio/a9nfVAa3kc UC2zpd+r/af6vpCPv0yM4akmIfrR9Lk5rCp//cRQXuz3PIa5Kbe91AcYXNjxP2so4MdI Rk0oIOLasR7I979mdj0BPqjFLOVCskLY1VSJw5yHJPKTa8hDpHg3umDh/6tN9tOB9qjm ip3Q== X-Received: by 10.52.230.167 with SMTP id sz7mr1447202vdc.81.1363268833478; Thu, 14 Mar 2013 06:47:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.107.173 with HTTP; Thu, 14 Mar 2013 06:46:52 -0700 (PDT) In-Reply-To: References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> <8EE96183-E8F4-4208-B602-4C308F0515FB@checkpoint.com> From: Tom Ritter Date: Thu, 14 Mar 2013 09:46:52 -0400 Message-ID: To: "TLS@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmmOYGO/1eQn2atX2UR1qDzyHIA6zaDa+V7F91siFfeAuEMIgox0onqaNrCFNq389NpDr7t Subject: Re: [TLS] ALPN or NPN ? 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, 14 Mar 2013 13:47:18 -0000 On 14 March 2013 03:29, Juho V=E4h=E4-Herttua wrote: > If this is considered a problem, we should have a seperate > extension that tries to work around firewalls as much as possible. We do, it's just not in this Working Group. It's over here: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.1.4 I remain convinced that hiding as much information from passive eavesdroppers is a worthwhile goal. The least ambitious at this point would be NPN. Then the suggestion to do a second, encrypted information negotiation came up - again. When we talked about Encrypted Client Certs, we seemed to have punted it to "Encrypted Handshake" (or whatever you want to call it) and now it's coming up again after dying down. Quoting Yoav: > I don't think people would want to block, as long as NPN/ALPN is used onl= y > for distinguishing HTTP/1 from HTTP/2. But I can see this used in the fut= ure > to mark other applications, such as SSL-VPN tunneling client, like > Microsoft's SSTP, Cisco's "SSL VPN client", or my company's SNX. If a fut= ure > firewall has a new feature for blocking tunneling clients, then that feat= ure > is going to work regardless of whether we choose NPN or ALPN. The only > question is whether it's going to require being an SSL proxy or not. But = if > the IT people would like to block tunneling clients, and that requires > activating an SSL proxy, then they will do it. If "They" is corporate IT: of course they will, and it will be easy for them to do so. But "They" is also entities without that control over their users. In the small scale: coffee shops that use a box to break into HTTP streams to add in ads. Why not block VPNs, so I can put in more ads? Or in the large scale: countries (like Iran and China) who block VPNs so they can inspect what their citizens are doing, and look for the activists and reporters. Everything is moving into TLS today, so we have to consider more than just web traffic in a home or corporate network. By being conservative in what we expose (and eventually making a generic encrypted extension mechanism, among other ideas) we will keep TLS more flexible as the general purpose protocol it is, and will result in fewer people hacking and working around it to do what they want. The fact that the label space is small today is not considering where it will go in the future. -tom From rsalz@akamai.com Thu Mar 14 07:06:33 2013 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 8E46B11E8140 for ; Thu, 14 Mar 2013 07:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 W8lIzDl+zRWs for ; Thu, 14 Mar 2013 07:06:33 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [96.6.114.97]) by ietfa.amsl.com (Postfix) with ESMTP id C186E11E8134 for ; Thu, 14 Mar 2013 07:06:30 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4BF1B1C493A; Thu, 14 Mar 2013 14:06:30 +0000 (GMT) Received: from prod-mail-relay04.akamai.com (prod-mail-relay04.akamai.com [172.27.8.27]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 3FA941C492D; Thu, 14 Mar 2013 14:06:30 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub2.dfw01.corp.akamai.com [172.27.25.76]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id 29E0B47BD2; Thu, 14 Mar 2013 14:06:29 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.203]) by ustx2ex-cashub2.dfw01.corp.akamai.com ([172.27.25.76]) with mapi; Thu, 14 Mar 2013 08:06:28 -0600 From: "Salz, Rich" To: Yoav Nir , =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= Date: Thu, 14 Mar 2013 08:06:26 -0600 Thread-Topic: [TLS] ALPN or NPN ? Thread-Index: Ac4fS4/pCw0qsUTCSMOaz+CCsKSG8gAiTGQAAAJpqIAAAki4gAAV58EAAA1rKoAAB/f4gAAJ7NNw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7ABC9B743@USMBX1.msg.corp.akamai.com> References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> <8EE96183-E8F4-4208-B602-4C308F0515FB@checkpoint.com> <0E5B0F1F-054F-443A-800A-E3AFC95934EE@checkpoint.com> In-Reply-To: <0E5B0F1F-054F-443A-800A-E3AFC95934EE@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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, 14 Mar 2013 14:06:33 -0000 In my experiences, particularly in the last half-dozen years at IBM, if an = enterprise cares about security, they terminate SSL/TLS in their DMZ. They = do not allow encrypted connections from the outside to come directly into t= heir internal systems. Am I alone in this view? Has anyone thought about h= ow ALPN/NPN would function in such an environment? /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From ynir@checkpoint.com Thu Mar 14 07:18:45 2013 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 018CE21F8EB0 for ; Thu, 14 Mar 2013 07:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.683 X-Spam-Level: X-Spam-Status: No, score=-9.683 tagged_above=-999 required=5 tests=[AWL=0.916, 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 s6nIpcbaYxiw for ; Thu, 14 Mar 2013 07:18:44 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 25ED521F8EAB for ; Thu, 14 Mar 2013 07:18:43 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2EEIdb3031942; Thu, 14 Mar 2013 16:18:39 +0200 X-CheckPoint: {5141DB63-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 16:18:39 +0200 From: Yoav Nir To: "Salz, Rich" Thread-Topic: [TLS] ALPN or NPN ? Thread-Index: Ac4fS4/pCw0qsUTCSMOaz+CCsKSG8gAiTGQAAAJpqIAAAki4gAAV58EAAA1rKoAAB/f4gAAJ7NNw///jRAA= Date: Thu, 14 Mar 2013 14:18:38 +0000 Message-ID: References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> <8EE96183-E8F4-4208-B602-4C308F0515FB@checkpoint.com> <0E5B0F1F-054F-443A-800A-E3AFC95934EE@checkpoint.com> <2A0EFB9C05D0164E98F19BB0AF3708C7ABC9B743@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7ABC9B743@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.209] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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, 14 Mar 2013 14:18:45 -0000 On Mar 14, 2013, at 10:06 AM, "Salz, Rich" wrote: > In my experiences, particularly in the last half-dozen years at IBM, if a= n enterprise cares about security, they terminate SSL/TLS in their DMZ. The= y do not allow encrypted connections from the outside to come directly into= their internal systems. Am I alone in this view? Has anyone thought about= how ALPN/NPN would function in such an environment? >=20 So if the actual server is in the DMZ, it works as usual. This is often don= e with publicly-facing web servers, and sometimes mail servers. In that cas= e, it doesn't matter whether you use ALPN or NPN. Of course the firewalls t= hat protect DMZs (or internal servers) often have the private keys for the = internal servers, so that they can decrypt the traffic and the handshake. I= n that case, neither ALPN nor NPN hinder them in the least. The other case is when the server is internal, and the DMZ just has a proxy= that translates HTTPS to HTTP (and potentially does some sanity checks). I= don't see why this case is different. Yoav From jsalowey@cisco.com Thu Mar 14 07:26:43 2013 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 1F94321F90C0 for ; Thu, 14 Mar 2013 07:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 DAzv3fWnB5rH for ; Thu, 14 Mar 2013 07:26:39 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8D921F90A2 for ; Thu, 14 Mar 2013 07:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=86; q=dns/txt; s=iport; t=1363271183; x=1364480783; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=ZeBOvixxA6mJfrdilUaBfST+dRmPkjW0drQtbf3wmG8=; b=fdcIWG/LWdkZ+EjL2xRP20Wons+vgf8sshMvDefHcQiRqBXdDeYqSVBO IdHGpsKTIopZoyEIHKshupPEVNXUZknx6uzLdwOIY4kd+QA2KZWvrcD94 wojk2RSpPr8PccFNawsAycUu/V3IkhHwJ4XbW5l+YksucC7GvvW6TIVs9 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMKAGrdQVGtJV2Z/2dsb2JhbABDs22RAwQDAYFiFnSCLAEEOlEBKhRCJwQbiAygDKEjjl+DF2EDp1qDCoIo X-IronPort-AV: E=Sophos;i="4.84,845,1355097600"; d="scan'208";a="184459040" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 14 Mar 2013 14:26:23 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2EEQMI7022254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 14 Mar 2013 14:26:23 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 09:26:22 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Slides for IETF-86 meeting Thread-Index: AQHOIL/m8hHZiTifYEuYzEISFbpvcg== Date: Thu, 14 Mar 2013 14:26:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.223.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <987A96CAE82C6C4A8F69DC26B1739161@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] Slides for IETF-86 meeting 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, 14 Mar 2013 14:26:43 -0000 If you are presenting slides in the TLS session please send them to the cha= irs. = From rsalz@akamai.com Thu Mar 14 07:27:19 2013 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 1FA1421F90D3 for ; Thu, 14 Mar 2013 07:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 ysbF+6EFtTYE for ; Thu, 14 Mar 2013 07:27:17 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id C68A321F90A1 for ; Thu, 14 Mar 2013 07:27:17 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 75546165525; Thu, 14 Mar 2013 14:27:17 +0000 (GMT) Received: from prod-mail-relay04.akamai.com (prod-mail-relay04.akamai.com [172.27.8.27]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 6A61E165524; Thu, 14 Mar 2013 14:27:17 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub2.dfw01.corp.akamai.com [172.27.25.76]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id 656F447BD2; Thu, 14 Mar 2013 14:27:17 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.203]) by ustx2ex-cashub2.dfw01.corp.akamai.com ([172.27.25.76]) with mapi; Thu, 14 Mar 2013 08:27:16 -0600 From: "Salz, Rich" To: Yoav Nir Date: Thu, 14 Mar 2013 08:27:15 -0600 Thread-Topic: [TLS] ALPN or NPN ? Thread-Index: Ac4fS4/pCw0qsUTCSMOaz+CCsKSG8gAiTGQAAAJpqIAAAki4gAAV58EAAA1rKoAAB/f4gAAJ7NNw///jRAD//94DwA== Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7ABC9B781@USMBX1.msg.corp.akamai.com> References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> <8EE96183-E8F4-4208-B602-4C308F0515FB@checkpoint.com> <0E5B0F1F-054F-443A-800A-E3AFC95934EE@checkpoint.com> <2A0EFB9C05D0164E98F19BB0AF3708C7ABC9B743@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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, 14 Mar 2013 14:27:19 -0000 > So if the actual server is in the DMZ, it works as usual. Well, kinda, although it presumably requires more cooperation (configuratio= n) with the true backend services so that the middleman knows what to adver= tise and allow > The other case is when the server is internal, and the DMZ just has a pro= xy that translates HTTPS to HTTP (and potentially does some sanity checks).= I don't see why this case is different. Actually it wouldn't work, would it? How would you convert NPN/ALPN into HT= TP? /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From ynir@checkpoint.com Thu Mar 14 08:07:32 2013 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 F156411E826C for ; Thu, 14 Mar 2013 08:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.206 X-Spam-Level: X-Spam-Status: No, score=-10.206 tagged_above=-999 required=5 tests=[AWL=0.393, 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 7PBXyfJrVcsu for ; Thu, 14 Mar 2013 08:07:28 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3080611E823E for ; Thu, 14 Mar 2013 08:07:14 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2EF7BcQ014404; Thu, 14 Mar 2013 17:07:11 +0200 X-CheckPoint: {5141E6C2-2-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 17:07:11 +0200 From: Yoav Nir To: "Salz, Rich" Thread-Topic: [TLS] ALPN or NPN ? Thread-Index: Ac4fS4/pCw0qsUTCSMOaz+CCsKSG8gAiTGQAAAJpqIAAAki4gAAV58EAAA1rKoAAB/f4gAAJ7NNw///jRAD//94DwIAAL5EA Date: Thu, 14 Mar 2013 15:07:10 +0000 Message-ID: References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> <8EE96183-E8F4-4208-B602-4C308F0515FB@checkpoint.com> <0E5B0F1F-054F-443A-800A-E3AFC95934EE@checkpoint.com> <2A0EFB9C05D0164E98F19BB0AF3708C7ABC9B743@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7ABC9B781@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7ABC9B781@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.209] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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, 14 Mar 2013 15:07:32 -0000 On Mar 14, 2013, at 10:27 AM, "Salz, Rich" wrote: >> So if the actual server is in the DMZ, it works as usual. >=20 > Well, kinda, although it presumably requires more cooperation (configurat= ion) with the true backend services so that the middleman knows what to adv= ertise and allow >=20 >> The other case is when the server is internal, and the DMZ just has a pr= oxy that translates HTTPS to HTTP (and potentially does some sanity checks)= . I don't see why this case is different. >=20 > Actually it wouldn't work, would it? How would you convert NPN/ALPN into = HTTP? NPN or ALPN are TLS features. The clear side would be either HTTP/1 or HTTP= /2. Both will be possible in the clear. The proxy only needs to know which = version of HTTP is supported. From rsalz@akamai.com Thu Mar 14 08:16:36 2013 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 30BA911E827F for ; Thu, 14 Mar 2013 08:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 rTuYuM2N-86g for ; Thu, 14 Mar 2013 08:16:35 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [96.6.114.97]) by ietfa.amsl.com (Postfix) with ESMTP id AA8D211E8171 for ; Thu, 14 Mar 2013 08:16:35 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 521B01C48C7; Thu, 14 Mar 2013 15:16:35 +0000 (GMT) Received: from prod-mail-relay03.akamai.com (prod-mail-relay03.akamai.com [172.27.8.26]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 476541C4808; Thu, 14 Mar 2013 15:16:35 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub7.dfw01.corp.akamai.com [172.27.25.73]) by prod-mail-relay03.akamai.com (Postfix) with ESMTP id 40B242FD51; Thu, 14 Mar 2013 15:16:35 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.203]) by ustx2ex-cashub7.dfw01.corp.akamai.com ([172.27.25.73]) with mapi; Thu, 14 Mar 2013 10:16:34 -0500 From: "Salz, Rich" To: Yoav Nir Date: Thu, 14 Mar 2013 10:16:34 -0500 Thread-Topic: [TLS] ALPN or NPN ? Thread-Index: Ac4fS4/pCw0qsUTCSMOaz+CCsKSG8gAiTGQAAAJpqIAAAki4gAAV58EAAA1rKoAAB/f4gAAJ7NNw///jRAD//94DwIAAL5EA///crQA= Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7ABC9B7EF@USMBX1.msg.corp.akamai.com> References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> <8EE96183-E8F4-4208-B602-4C308F0515FB@checkpoint.com> <0E5B0F1F-054F-443A-800A-E3AFC95934EE@checkpoint.com> <2A0EFB9C05D0164E98F19BB0AF3708C7ABC9B743@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7ABC9B781@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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, 14 Mar 2013 15:16:36 -0000 > NPN or ALPN are TLS features. The clear side would be either HTTP/1 or HT= TP/2. Both will be possible in the clear. The proxy only needs to know whic= h version of HTTP is supported. Only HTTP? Forever? Then why not make the protocol identifier be a small = integer? If the answer is not, then should we define the common X-... convention? /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From mrex@sap.com Thu Mar 14 10:03:27 2013 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 50AF511E8146 for ; Thu, 14 Mar 2013 10:03:27 -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 4hWePK6Tuzm1 for ; Thu, 14 Mar 2013 10:03:26 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9415D11E8126 for ; Thu, 14 Mar 2013 10:03:26 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r2EH3Jco002479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Mar 2013 18:03:19 +0100 (MET) In-Reply-To: <5140CE2B.5020006@fifthhorseman.net> To: Daniel Kahn Gillmor Date: Thu, 14 Mar 2013 18:03:19 +0100 (CET) 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: <20130314170319.C10FB1A635@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "TLS@ietf.org" , Paul Hoffman , Alfredo Pironti Subject: Re: [TLS] ALPN or NPN ? 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: Thu, 14 Mar 2013 17:03:27 -0000 Daniel Kahn Gillmor wrote: > > However, moving the NPN info after the handshake means that the server > won't have an opportunity to select different credentials based on the > NPN info. That is both an obvious hen-and-edd problem: - the server cert goes first in the clear and is a prerequisite for the key exchange - if the server selects a different server credential based on NPN, then the observer could deduce from the server's choice of certificate what the NPN was, even if the NPN was not visible to the observer. -Martin From juhovh@iki.fi Thu Mar 14 11:20:40 2013 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 B67D911E8162 for ; Thu, 14 Mar 2013 11:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] 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 TLJ-bS1lGBZJ for ; Thu, 14 Mar 2013 11:20:40 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id ADA5E11E817A for ; Thu, 14 Mar 2013 11:20:39 -0700 (PDT) Received: from [10.60.154.138] (188.238.157.138) by jenni2.inet.fi (8.5.140.03) id 50871399092910F7; Thu, 14 Mar 2013 20:20:38 +0200 References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> <8EE96183-E8F4-4208-B602-4C308F0515FB@checkpoint.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <86BF0B4B-C169-492F-8572-A3AAAF72FD5B@iki.fi> X-Mailer: iPhone Mail (10B146) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= Date: Thu, 14 Mar 2013 20:20:35 +0200 To: Tom Ritter Cc: "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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, 14 Mar 2013 18:20:40 -0000 On 14.3.2013, at 15.46, Tom Ritter wrote: > If "They" is corporate IT: of course they will, and it will be easy > for them to do so. But "They" is also entities without that control > over their users. In the small scale: coffee shops that use a box to > break into HTTP streams to add in ads. Why not block VPNs, so I can > put in more ads? Or in the large scale: countries (like Iran and > China) who block VPNs so they can inspect what their citizens are > doing, and look for the activists and reporters. Having also lived several years in mainland China I'm more than familiar wit= h these issues. The problem with NPN is that if it's possible to see an undesired protocol (= e.g. VPN) in the Server Hello, as an attacker I would simply sniff for Serve= rHello packets and shut down the connection with a RST from a spoofed source= IP if I don't like the contents. I can do this passively without slowing do= wn the connection at all, which means it's really cheap. This is actually worse than cutting down the connection based on ClientHello= , because of the collateral damage for protocols that are otherwise not bloc= ked at all. And if the server has to fake or omit the list of supported prot= ocols, the whole point of the list becomes questionable. Based on the very good points brought up in this discussion, I would change m= y vote to NPN with the optional list of protocols removed from the server ne= xt_protocol_negotiation extension. I know it makes the protocol selection le= ss flexible, but if we really want to prevent firewall blocking, I don't see= much other options than making the whole NPN negotiation encrypted. The att= acker can still shut down based on the presence of NPN extension in ServerHe= llo, but if it the extension becomes more common in servers that will be dif= ficult. Please give some feedback if I'm on the wrong track here. Juho From nico@cryptonector.com Thu Mar 14 11:30:11 2013 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 C82A911E81F3 for ; Thu, 14 Mar 2013 11:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] 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 vVpPYCWoZ5ca for ; Thu, 14 Mar 2013 11:30:11 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id DC9F611E81B0 for ; Thu, 14 Mar 2013 11:30:10 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 57D8D5940BB for ; Thu, 14 Mar 2013 11:30:10 -0700 (PDT) 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=d5qG7XbmbwoR1yC/pXOuQ5lqui0=; b=nW34axDtoHx dQXnQ8OWpGX/oE2TguIXIWP0Zk7v4KzW4PH4jAsV5NoOsOGznJ9VpYEvZVH3Qyt5 s9TuftHnyYkcC7YT3HC4ad98d9X4Prt4lYYTCfKKADdYclTo4dN8b3jcHxw9lyI7 hdrez+zbUY42z7jBS01W13NSB31pGtXg= Received: from mail-ia0-f174.google.com (mail-ia0-f174.google.com [209.85.210.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id E340559407F for ; Thu, 14 Mar 2013 11:26:56 -0700 (PDT) Received: by mail-ia0-f174.google.com with SMTP id k38so2357785iah.5 for ; Thu, 14 Mar 2013 11:26:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.88.199 with SMTP id bi7mr3216033igb.70.1363285615995; Thu, 14 Mar 2013 11:26:55 -0700 (PDT) Received: by 10.64.252.106 with HTTP; Thu, 14 Mar 2013 11:26:55 -0700 (PDT) In-Reply-To: <86BF0B4B-C169-492F-8572-A3AAAF72FD5B@iki.fi> References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> <8EE96183-E8F4-4208-B602-4C308F0515FB@checkpoint.com> <86BF0B4B-C169-492F-8572-A3AAAF72FD5B@iki.fi> Date: Thu, 14 Mar 2013 13:26:55 -0500 Message-ID: From: Nico Williams To: =?UTF-8?B?SnVobyBWw6Row6QtSGVydHR1YQ==?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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, 14 Mar 2013 18:30:12 -0000 On Thu, Mar 14, 2013 at 1:20 PM, Juho V=C3=A4h=C3=A4-Herttua wrote: > Having also lived several years in mainland China I'm more than familiar = with these issues. > > The problem with NPN is that if it's possible to see an undesired protoco= l (e.g. VPN) in the Server Hello, as an attacker I would simply sniff for S= erverHello packets and shut down the connection with a RST from a spoofed s= ource IP if I don't like the contents. I can do this passively without slow= ing down the connection at all, which means it's really cheap. > > This is actually worse than cutting down the connection based on ClientHe= llo, because of the collateral damage for protocols that are otherwise not = blocked at all. And if the server has to fake or omit the list of supported= protocols, the whole point of the list becomes questionable. But we've also seen that for certain high-value, HTTPS-only sites, the great wall operators end up giving up (gmail, github, ...). Nico -- From juhovh@iki.fi Thu Mar 14 11:41:44 2013 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 3599211E81AC for ; Thu, 14 Mar 2013 11:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] 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 rscwqcig17-L for ; Thu, 14 Mar 2013 11:41:43 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5123D11E81C0 for ; Thu, 14 Mar 2013 11:41:43 -0700 (PDT) Received: from [10.60.154.138] (188.238.157.138) by kirsi1.inet.fi (8.5.140.03) id 51292B7F01712C35; Thu, 14 Mar 2013 20:41:42 +0200 References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> <8EE96183-E8F4-4208-B602-4C308F0515FB@checkpoint.com> <86BF0B4B-C169-492F-8572-A3AAAF72FD5B@iki.fi> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B146) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= Date: Thu, 14 Mar 2013 20:41:40 +0200 To: Nico Williams Cc: "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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, 14 Mar 2013 18:41:44 -0000 On 14.3.2013, at 20.26, Nico Williams wrote: > But we've also seen that for certain high-value, HTTPS-only sites, the > great wall operators end up giving up (gmail, github, ...). Getting slightly off-topic, but I believe HTTPS sites are usually blocked on= ly based on DNS/IP, not based on the actual content. If the concern here is 3= rd parties blocking VPN access and VPNs using NPN (two pretty big assumption= s), I doubt the high-value sites like gmail and github will suddenly start a= dvertising VPN support on their main HTTPS servers. If they do not, blocking= VPN supporting servers is still quite viable. Juho From nico@cryptonector.com Thu Mar 14 11:52:35 2013 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 0A81921F8F07 for ; Thu, 14 Mar 2013 11:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] 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 1gn8LUZv+I9A for ; Thu, 14 Mar 2013 11:52:34 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id CEBA821F8E95 for ; Thu, 14 Mar 2013 11:52:33 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 915B9202054 for ; Thu, 14 Mar 2013 11:52:33 -0700 (PDT) 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=QHlUNTQkkLvq6CTWmBVequoeTYU=; b=BK6SMp6s87t fV26dakGAp7i3T9ltu+VlbaHI1YJMIATDuSy1Lcfc6OcBP70o8Y/qNRymZE7hECb pLw7wu3ACx153HuJ4RAUg24O+TwDEJdjGk+GpGDFLWhzNpr3E+iK8MOey2JVlsHu BNw4zxpJvunedYMOJOW/D2vPGwoQp0Xc= Received: from mail-ia0-f180.google.com (mail-ia0-f180.google.com [209.85.210.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 68F5E202038 for ; Thu, 14 Mar 2013 11:52:33 -0700 (PDT) Received: by mail-ia0-f180.google.com with SMTP id f27so2456410iae.11 for ; Thu, 14 Mar 2013 11:52:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.43.88.134 with SMTP id ba6mr2914065icc.18.1363287152966; Thu, 14 Mar 2013 11:52:32 -0700 (PDT) Received: by 10.64.252.106 with HTTP; Thu, 14 Mar 2013 11:52:32 -0700 (PDT) In-Reply-To: References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> <8EE96183-E8F4-4208-B602-4C308F0515FB@checkpoint.com> <86BF0B4B-C169-492F-8572-A3AAAF72FD5B@iki.fi> Date: Thu, 14 Mar 2013 13:52:32 -0500 Message-ID: From: Nico Williams To: =?UTF-8?B?SnVobyBWw6Row6QtSGVydHR1YQ==?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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, 14 Mar 2013 18:52:35 -0000 On Thu, Mar 14, 2013 at 1:41 PM, Juho V=C3=A4h=C3=A4-Herttua wrote: > On 14.3.2013, at 20.26, Nico Williams wrote: >> But we've also seen that for certain high-value, HTTPS-only sites, the >> great wall operators end up giving up (gmail, github, ...). > > Getting slightly off-topic, but I believe HTTPS sites are usually blocked= only based on DNS/IP, not based on the actual content. If the concern here= is 3rd parties blocking VPN access and VPNs using NPN (two pretty big assu= mptions), I doubt the high-value sites like gmail and github will suddenly = start advertising VPN support on their main HTTPS servers. If they do not, = blocking VPN supporting servers is still quite viable. All they have to do is advertise the ability to negotiate application-layer protocols. That's enough. If a client proceeds past the end of the handshake and tries to start the "VPN" (or whatever) protocol and that fails because the server doesn't support, what's the harm? The harm will only be that the client needed more round trips to _fail_, but that's no big deal considering the benefits when the client succeeds: the client gets what it wants and non-MITM middleboxes don't know what that was. Nico -- From juhovh@iki.fi Thu Mar 14 11:59:22 2013 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 8546321F90D2 for ; Thu, 14 Mar 2013 11:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] 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 8QYjXRii4cao for ; Thu, 14 Mar 2013 11:59:22 -0700 (PDT) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id C144D21F90CE for ; Thu, 14 Mar 2013 11:59:21 -0700 (PDT) Received: from [10.60.154.138] (188.238.157.138) by jenni1.inet.fi (8.5.140.03) id 508712A00927743D; Thu, 14 Mar 2013 20:59:20 +0200 References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> <8EE96183-E8F4-4208-B602-4C308F0515FB@checkpoint.com> <86BF0B4B-C169-492F-8572-A3AAAF72FD5B@iki.fi> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B146) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= Date: Thu, 14 Mar 2013 20:59:17 +0200 To: Nico Williams Cc: "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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, 14 Mar 2013 18:59:22 -0000 On 14.3.2013, at 20.52, Nico Williams wrote: > On Thu, Mar 14, 2013 at 1:41 PM, Juho V=C3=A4h=C3=A4-Herttua wrote: >>=20 >> Getting slightly off-topic, but I believe HTTPS sites are usually blocked= only based on DNS/IP, not based on the actual content. If the concern here i= s 3rd parties blocking VPN access and VPNs using NPN (two pretty big assumpt= ions), I doubt the high-value sites like gmail and github will suddenly star= t advertising VPN support on their main HTTPS servers. If they do not, block= ing VPN supporting servers is still quite viable. >=20 > All they have to do is advertise the ability to negotiate > application-layer protocols. That's enough. If a client proceeds > past the end of the handshake and tries to start the "VPN" (or > whatever) protocol and that fails because the server doesn't support, > what's the harm? The harm will only be that the client needed more > round trips to _fail_, but that's no big deal considering the benefits > when the client succeeds: the client gets what it wants and non-MITM > middleboxes don't know what that was. I guess this is my point. If we want to prevent firewalls from blocking, it w= ould be best if no application-layer protocol information would be transferr= ed in plain text at all. As I understand this is not the case with the curre= nt NPN draft, which includes a plain text (although optional) list of suppor= ted protocols. Juho From nico@cryptonector.com Thu Mar 14 12:11:31 2013 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 209CC21F8E4B for ; Thu, 14 Mar 2013 12:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.727 X-Spam-Level: X-Spam-Status: No, score=-1.727 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] 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 oh9BNVmjqUuD for ; Thu, 14 Mar 2013 12:11:30 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7632221F8CDA for ; Thu, 14 Mar 2013 12:11:30 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 21C33202059 for ; Thu, 14 Mar 2013 12:11:30 -0700 (PDT) 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=LPtC/E1jE6iGay4yaX+cPwFrTW4=; b=w5bYgCtB0Rl 8uBSqYPH0eDNiw95vi2wbLv0pE4aEawHLMwq+evYs/AkRfknPQovLIhbuqjxEnCl 8/X/iEQZHyeV46GmiytXr4MsU2v4cxWdRS3j5iox92TqouC9SXhVWNYdVn1QFK56 DA07E3sQRQ86X3TMdwjwMZ2dU3CsH+Pc= Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id D840E20204C for ; Thu, 14 Mar 2013 12:11:29 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id 16so3466693iea.22 for ; Thu, 14 Mar 2013 12:11:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.45.136 with SMTP id n8mr3484702igm.34.1363288289108; Thu, 14 Mar 2013 12:11:29 -0700 (PDT) Received: by 10.64.252.106 with HTTP; Thu, 14 Mar 2013 12:11:28 -0700 (PDT) In-Reply-To: References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> <8EE96183-E8F4-4208-B602-4C308F0515FB@checkpoint.com> <86BF0B4B-C169-492F-8572-A3AAAF72FD5B@iki.fi> Date: Thu, 14 Mar 2013 14:11:28 -0500 Message-ID: From: Nico Williams To: =?UTF-8?B?SnVobyBWw6Row6QtSGVydHR1YQ==?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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, 14 Mar 2013 19:11:31 -0000 On Thu, Mar 14, 2013 at 1:59 PM, Juho V=C3=A4h=C3=A4-Herttua wrote: > I guess this is my point. If we want to prevent firewalls from blocking, = it would be best if no application-layer protocol information would be tran= sferred in plain text at all. As I understand this is not the case with the= current NPN draft, which includes a plain text (although optional) list of= supported protocols. Before your message I'd have been OK with a server advertising a list of many application protocols in the clear, but it'd have to be OPTIONAL and indeed, NOT RECOMMENDED. You convince me that it's best to not advertise any specific protocols, just the feature. Nico -- From nico@cryptonector.com Thu Mar 14 12:20:22 2013 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 8524A11E81C4 for ; Thu, 14 Mar 2013 12:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=0.112, 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 VGvEpYHxbE8F for ; Thu, 14 Mar 2013 12:20:21 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id D514A11E81C3 for ; Thu, 14 Mar 2013 12:20:21 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 8A55643807F for ; Thu, 14 Mar 2013 12:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=PMMVm8koNgwEJ4H/QA4t0u8TWLs=; b=aSnfyFoYLFw eQ89xiOiOkHnxElYb3dqZECQMR2NCt8BNdHTLlG8jxZH54dL/IjMH3bnLYgTT2gL qjqPkiVsbcfvTY6fgLewE9pLPMozrmpa9QuGThdV4P0JoAqOISa5VJOL6lw70H88 FinKPiXQONI1MjQST3SlK/gHqWAfLeUs= Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 68E6C43806C for ; Thu, 14 Mar 2013 12:20:21 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id c12so3425017ieb.20 for ; Thu, 14 Mar 2013 12:20:21 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.43.88.134 with SMTP id ba6mr2988801icc.18.1363288820988; Thu, 14 Mar 2013 12:20:20 -0700 (PDT) Received: by 10.64.252.106 with HTTP; Thu, 14 Mar 2013 12:20:20 -0700 (PDT) Date: Thu, 14 Mar 2013 14:20:20 -0500 Message-ID: From: Nico Williams To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [TLS] Alternative to ALPN and NPN 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, 14 Mar 2013 19:20:22 -0000 My proposal: - ClientHello and ServerHello to include an extension whose presence indicates two things: a) the record type for all records post-handshake will be application (except for alerts about decryption failures); b) the plaintext (i.e., after decryption) payload of the record will have an actual record type prepended; c) the client MAY send a first post-handshake record that is a new handshake record type whose purpose is to specify which application protocol the client wishes to use (this record will externally appear to be application data, per-(a)); d) if the server doesn't like the client's choice of application protocol it will reply with a new handshake record type (externally this will appear to be an application record, see (a)) indicating what protocols it supports and it will discard any application data from the client until the next application protocol start record from the client (as in (c). Benefits: - eavesdroppers and non-MITM middleboxes get no information about the application protocol (except for record length matters) - in optimistic case no extra round trips are incured Regarding traffic analysis issues (initial record lengths): - we could have a bit in the byte prepended to the plaintext to indicate that it is really a sequence of type-length-value, so we can bundle some actual app data into the first record - we could have a bit in that same byte to indicate padding with random to-be-ignored data - and the sender can fragment the initial record as needed, of course which altogether would allow clients to ensure that first app record lengths match whatever a middlebox might expect. Nico -- From ynir@checkpoint.com Thu Mar 14 13:03:14 2013 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 D527111E81C8 for ; Thu, 14 Mar 2013 13:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.255 X-Spam-Level: X-Spam-Status: No, score=-10.255 tagged_above=-999 required=5 tests=[AWL=0.344, 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 Ueqy8wFpgySP for ; Thu, 14 Mar 2013 13:03:14 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E702411E80D7 for ; Thu, 14 Mar 2013 13:03:13 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2EK2dpE014644; Thu, 14 Mar 2013 22:02:40 +0200 X-CheckPoint: {51422BFF-3-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 22:02:39 +0200 From: Yoav Nir To: Nico Williams Thread-Topic: [TLS] Alternative to ALPN and NPN Thread-Index: AQHOIOkG/MN2Dv29ckuDySHnUOuNV5ilemcA Date: Thu, 14 Mar 2013 20:02:39 +0000 Message-ID: <814B7398-C95E-405B-8E90-51E2BAB11C39@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.209] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [TLS] Alternative to ALPN and NPN 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, 14 Mar 2013 20:03:14 -0000 Drawback: this increases the size of each record (because the type is not p= repended to the actual value). On Mar 14, 2013, at 3:20 PM, Nico Williams wrote: > My proposal: >=20 > - ClientHello and ServerHello to include an extension whose presence > indicates two things: >=20 > a) the record type for all records post-handshake will be > application (except for alerts about decryption failures); > b) the plaintext (i.e., after decryption) payload of the record > will have an actual record type prepended; > c) the client MAY send a first post-handshake record that is a new > handshake record type whose purpose is to specify which application > protocol the client wishes to use (this record will externally appear > to be application data, per-(a)); > d) if the server doesn't like the client's choice of application > protocol it will reply with a new handshake record type (externally > this will appear to be an application record, see (a)) indicating what > protocols it supports and it will discard any application data from > the client until the next application protocol start record from the > client (as in (c). >=20 > Benefits: >=20 > - eavesdroppers and non-MITM middleboxes get no information about the > application protocol (except for record length matters) > - in optimistic case no extra round trips are incured >=20 > Regarding traffic analysis issues (initial record lengths): >=20 > - we could have a bit in the byte prepended to the plaintext to > indicate that it is really a sequence of type-length-value, so we can > bundle some actual app data into the first record >=20 > - we could have a bit in that same byte to indicate padding with > random to-be-ignored data >=20 > - and the sender can fragment the initial record as needed, of course >=20 > which altogether would allow clients to ensure that first app record > lengths match whatever a middlebox might expect. >=20 > Nico > -- > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 > Email secured by Check Point From nico@cryptonector.com Thu Mar 14 13:11:17 2013 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 D5B8E11E8165 for ; Thu, 14 Mar 2013 13:11:17 -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=[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 dmXencw0xTej for ; Thu, 14 Mar 2013 13:11:17 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 36BBF11E8146 for ; Thu, 14 Mar 2013 13:11:17 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id D191877805B for ; Thu, 14 Mar 2013 13:11:16 -0700 (PDT) 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; s=cryptonector.com; bh=mvLewJzSM4OI2HespZwe /6OaISk=; b=uHK06Tb6tShmaw+M1sEc389nzx9FSYK9yew0iGILDpgTVzSl2KX0 6Ud/sqj4pkSjFAX5vuvQoCI7p50DYo+uvYuBFMCNIypVIFDEVBiLC0G/p2Zmsx33 AAiMFhGYpiVxU93i4rkGKhXbfQiE0s1pDlgokfmdju25TSusWiyNzYI= Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 6B537778057 for ; Thu, 14 Mar 2013 13:11:16 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id o45so2674239wer.9 for ; Thu, 14 Mar 2013 13:11:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.94.135 with SMTP id dc7mr36478813wib.11.1363291874763; Thu, 14 Mar 2013 13:11:14 -0700 (PDT) Received: by 10.216.113.68 with HTTP; Thu, 14 Mar 2013 13:11:14 -0700 (PDT) In-Reply-To: <814B7398-C95E-405B-8E90-51E2BAB11C39@checkpoint.com> References: <814B7398-C95E-405B-8E90-51E2BAB11C39@checkpoint.com> Date: Thu, 14 Mar 2013 15:11:14 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [TLS] Alternative to ALPN and NPN 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, 14 Mar 2013 20:11:17 -0000 On Thu, Mar 14, 2013 at 3:02 PM, Yoav Nir wrote: > Drawback: this increases the size of each record (because the type is not prepended to the actual value). By one byte, yes. (And perhaps we'll want more, for alignment. That should be an option though, not a requirement.) Also, we could have a message that says: no records other than application or alert will be send from here on. In that case we could stop prepending the record type to the protected plaintext and send any alerts' record type in the clear. Nico -- From ynir@checkpoint.com Thu Mar 14 13:15:20 2013 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 7B03911E8173 for ; Thu, 14 Mar 2013 13:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.144 X-Spam-Level: X-Spam-Status: No, score=-10.144 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 Qnb6cCnHeURK for ; Thu, 14 Mar 2013 13:15:19 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9D52C21F8E34 for ; Thu, 14 Mar 2013 13:15:06 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2EKEjxC016424; Thu, 14 Mar 2013 22:14:45 +0200 X-CheckPoint: {51422ED5-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 22:14:44 +0200 From: Yoav Nir To: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= Thread-Topic: [TLS] ALPN or NPN ? Thread-Index: Ac4fS4/pCw0qsUTCSMOaz+CCsKSG8gAiTGQAAAJpqIAAAki4gAAV58EAAA1rKoAADTHyAAAJjziAAAP8SAA= Date: Thu, 14 Mar 2013 20:14:43 +0000 Message-ID: <27DAAC9D-7524-4B8D-94E8-5D88AA7A45A5@checkpoint.com> References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> <8EE96183-E8F4-4208-B602-4C308F0515FB@checkpoint.com> <86BF0B4B-C169-492F-8572-A3AAAF72FD5B@iki.fi> In-Reply-To: <86BF0B4B-C169-492F-8572-A3AAAF72FD5B@iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.209] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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, 14 Mar 2013 20:15:20 -0000 On Mar 14, 2013, at 2:20 PM, Juho V=E4h=E4-Herttua wrote: > On 14.3.2013, at 15.46, Tom Ritter wrote: >> If "They" is corporate IT: of course they will, and it will be easy >> for them to do so. But "They" is also entities without that control >> over their users. In the small scale: coffee shops that use a box to >> break into HTTP streams to add in ads. Why not block VPNs, so I can >> put in more ads? Or in the large scale: countries (like Iran and >> China) who block VPNs so they can inspect what their citizens are >> doing, and look for the activists and reporters. >=20 > Having also lived several years in mainland China I'm more than familiar = with these issues. >=20 > The problem with NPN is that if it's possible to see an undesired protoco= l (e.g. VPN) in the Server Hello, as an attacker I would simply sniff for S= erverHello packets and shut down the connection with a RST from a spoofed s= ource IP if I don't like the contents. I can do this passively without slow= ing down the connection at all, which means it's really cheap. >=20 > This is actually worse than cutting down the connection based on ClientHe= llo, because of the collateral damage for protocols that are otherwise not = blocked at all. And if the server has to fake or omit the list of supported= protocols, the whole point of the list becomes questionable. >=20 > Based on the very good points brought up in this discussion, I would chan= ge my vote to NPN with the optional list of protocols removed from the serv= er next_protocol_negotiation extension. I know it makes the protocol select= ion less flexible, but if we really want to prevent firewall blocking, I do= n't see much other options than making the whole NPN negotiation encrypted.= The attacker can still shut down based on the presence of NPN extension in= ServerHello, but if it the extension becomes more common in servers that w= ill be difficult. >=20 > Please give some feedback if I'm on the wrong track here. When clients want to hide their identity, they make an anonymous (or server= -authenticated) handshake, and then perform a second handshake, this time w= ith the client certificate. You could do the same thing with ALPN (or NPN, but in this case NPN has no = advantage). You do a regular handshake without ALPN (or with an indication = that ALPN is supported - ALPN message with no applications). The interior h= andshake can have the ALPN extension with application names. So it would be up to the client to expose the applications in the ClientHel= lo, or go for a second handshake. It's a tradeoff of performance vs secrecy= .=20 I can think of a slight optimization: usually renegotiations are not allowe= d to resume the session. In this case (of empty ALPN) we could allow this. I still think it would be better for browsers at least, to save the roundtr= ip and have the ALPN list in the ClientHello. Tunneling clients may have di= fferent priorities. Yoav= From nico@cryptonector.com Thu Mar 14 13:24:24 2013 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 F19BF11E8106 for ; Thu, 14 Mar 2013 13:24:18 -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=[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 W7+SDPpvlMPC for ; Thu, 14 Mar 2013 13:24:18 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 2452B1F0D0F for ; Thu, 14 Mar 2013 13:24:17 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id A310B2C807F for ; Thu, 14 Mar 2013 13:24:04 -0700 (PDT) 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=m9OANgpn97B4sqT3FwVOa9QFxyQ=; b=ujF80gWPfuc ubbw/8fBZEgRPxMoJSaccjNYAEgNes/5Y+l4AYuC/D2L3jJkwyjFFqrfGZvoAvQi i+BXNwIvGVmqKTTT2c3NfUgqbZqIBP9e+Q9AUdm9tsT2i7Y5sy/bk4DSqQRKskc+ ef3do0n5er9EDHQcvdxT+vVNUekgfFzc= Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id E44F42C808D for ; Thu, 14 Mar 2013 13:23:54 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id t11so2597211wey.14 for ; Thu, 14 Mar 2013 13:23:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.119.68 with SMTP id ks4mr6940244wjb.3.1363292630186; Thu, 14 Mar 2013 13:23:50 -0700 (PDT) Received: by 10.216.113.68 with HTTP; Thu, 14 Mar 2013 13:23:49 -0700 (PDT) In-Reply-To: <27DAAC9D-7524-4B8D-94E8-5D88AA7A45A5@checkpoint.com> References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> <8EE96183-E8F4-4208-B602-4C308F0515FB@checkpoint.com> <86BF0B4B-C169-492F-8572-A3AAAF72FD5B@iki.fi> <27DAAC9D-7524-4B8D-94E8-5D88AA7A45A5@checkpoint.com> Date: Thu, 14 Mar 2013 15:23:49 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "TLS@ietf.org" Subject: Re: [TLS] ALPN or NPN ? 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, 14 Mar 2013 20:24:25 -0000 On Thu, Mar 14, 2013 at 3:14 PM, Yoav Nir wrote: > On Mar 14, 2013, at 2:20 PM, Juho V=C3=A4h=C3=A4-Herttua = wrote: > >> On 14.3.2013, at 15.46, Tom Ritter wrote: >>> If "They" is corporate IT: of course they will, and it will be easy >>> for them to do so. But "They" is also entities without that control >>> over their users. In the small scale: coffee shops that use a box to >>> break into HTTP streams to add in ads. Why not block VPNs, so I can >>> put in more ads? Or in the large scale: countries (like Iran and >>> China) who block VPNs so they can inspect what their citizens are >>> doing, and look for the activists and reporters. >> >> Having also lived several years in mainland China I'm more than familiar= with these issues. >> >> The problem with NPN is that if it's possible to see an undesired protoc= ol (e.g. VPN) in the Server Hello, as an attacker I would simply sniff for = ServerHello packets and shut down the connection with a RST from a spoofed = source IP if I don't like the contents. I can do this passively without slo= wing down the connection at all, which means it's really cheap. >> >> This is actually worse than cutting down the connection based on ClientH= ello, because of the collateral damage for protocols that are otherwise not= blocked at all. And if the server has to fake or omit the list of supporte= d protocols, the whole point of the list becomes questionable. >> >> Based on the very good points brought up in this discussion, I would cha= nge my vote to NPN with the optional list of protocols removed from the ser= ver next_protocol_negotiation extension. I know it makes the protocol selec= tion less flexible, but if we really want to prevent firewall blocking, I d= on't see much other options than making the whole NPN negotiation encrypted= . The attacker can still shut down based on the presence of NPN extension i= n ServerHello, but if it the extension becomes more common in servers that = will be difficult. >> >> Please give some feedback if I'm on the wrong track here. > > When clients want to hide their identity, they make an anonymous (or serv= er-authenticated) handshake, and then perform a second handshake, this time= with the client certificate. Most clients don't use user certs in TLS for authentication anyways, so I'm not sure how this is relevant. Clients that do can re-negotiate, of course, but this is externally evident because of the record type appearing in the clear. IIUC there exist great walls that reset TCP connections where TLS re-nego happens. Clients could re-nego even if they don't use client certs -- just to protect the app protocol negotiation. But this adds more round trips than is absolutely necessary (see my alternative proposal). > I still think it would be better for browsers at least, to save the round= trip and have the ALPN list in the ClientHello. Tunneling clients may have = different priorities. But this will make it trivial for great walls to kill those connections. Nico -- From n.mavrogiannopoulos@gmail.com Thu Mar 14 13:39:34 2013 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 16A2B11E81A6 for ; Thu, 14 Mar 2013 13:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.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 nBubgXKiDYfS for ; Thu, 14 Mar 2013 13:39:33 -0700 (PDT) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id CF83311E819C for ; Thu, 14 Mar 2013 13:39:32 -0700 (PDT) Received: by mail-ea0-f178.google.com with SMTP id g14so1240086eak.23 for ; Thu, 14 Mar 2013 13:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:x-enigmail-version:openpgp :content-type:content-transfer-encoding; bh=NTQoR2fPFFi6RIsdHlnYk04BhWHX6Kv9N/3X/S0GSak=; b=qJnb9agyMSjjERyPfMAACpl8Q7ImqgSEpf+Iv/lbZBXdmrg1W15jIFYdMJgyjb4eMq xt3L4cxD1LeFic4E5fqi5IW9bZI7J4Y98Zh8eJ6/7ETNJYmmfJ5SNRdmSVyQYvmdf5eY bACrEGbcAkDxTuKXGHVbHQrWICdPsvwJa2c4obeHZFfK6OYnB1qXsbXpvqV4ldWChojE KjBfu817yzoMbE88Oa3REoLhGFtnSNJpjqUyJ6tBhTC8uQ8lNfvDvCQUStV4Gydg5QM5 ss4/u3TzYHX4dGWZ3natsH8nYVK/DsGGeXqfe7nv2apDBTZexke1cF77oCyzc4pE5IrN fxHA== X-Received: by 10.14.209.131 with SMTP id s3mr10469459eeo.26.1363293567303; Thu, 14 Mar 2013 13:39:27 -0700 (PDT) Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id q5sm5959966eeo.17.2013.03.14.13.39.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 13:39:26 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <5142357D.6030601@gnutls.org> Date: Thu, 14 Mar 2013 21:39:25 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: tls@ietf.org References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> <8EE96183-E8F4-4208-B602-4C308F0515FB@checkpoint.com> <86BF0B4B-C169-492F-8572-A3AAAF72FD5B@iki.fi> In-Reply-To: X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [TLS] ALPN 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, 14 Mar 2013 20:39:34 -0000 On 03/14/2013 07:41 PM, Juho Vähä-Herttua wrote: > On 14.3.2013, at 20.26, Nico Williams wrote: >> But we've also seen that for certain high-value, HTTPS-only sites, the >> great wall operators end up giving up (gmail, github, ...). > > Getting slightly off-topic, but I believe HTTPS sites are usually blocked only based on DNS/IP, not based on the actual content. If the concern here is 3rd parties blocking VPN access and VPNs using NPN (two pretty big assumptions), I doubt the high-value sites like gmail and github will suddenly start advertising VPN support on their main HTTPS servers. If they do not, blocking VPN supporting servers is still quite viable. I think it is important to decide first what we want from this extension. As I understand ALPN and NPN do exactly the same thing, they negotiate the protocol to be used under TLS, but one proposal offers something more. Some kind of privacy in that negotiation against passive eavesdroppers. The question is, do we need that additional privacy, along with its added complexity (because a totally new negotiation mechanism is added). In my opinion, the added complexity of NPN by not using the standard TLS extension mechanism is a big drawback and I really cannot see the offered privacy as an important advantage. Moreover, I can see the disadvantage of administrators not being able to prioritize bulk from interactive traffic. Do we really need to negotiate the protocol under TLS in a totally hidden way or do we want to negotiate the protocols under TLS similarly to what happens now (e.g. with different port numbers)? People who would like to hide their protocol would do that, and would falsely advertise HTTP as they do now (by using port 443 to transfer arbitrary data). I see no advantage to them from NPN. If the threat on the other hand are misconfigured or misadministered firewalls, I don't know what the TLS WG can do to prevent that, except making a clear specification that firewall makers will understand and not abuse. In short I support the ALPN proposal, because it is cleaner. regards, Nikos From nico@cryptonector.com Thu Mar 14 13:47:04 2013 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 4C74711E81CA for ; Thu, 14 Mar 2013 13:47:04 -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=[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 Nti0CBpJCxKX for ; Thu, 14 Mar 2013 13:47:03 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 8025F11E81C9 for ; Thu, 14 Mar 2013 13:47:03 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 4764E9406B for ; Thu, 14 Mar 2013 13:47:03 -0700 (PDT) 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; s=cryptonector.com; bh=xo6rSgkvw6KADcb8YDfl PdKcs/k=; b=kgi/6b6INXl/2PQOxeqRnTFETTAOp1eMnl+ITSLEl1nzJYZrNKIN MUFElF3fBb0RYLf8mkicmq4WMr32OIgebRt2TgDKqa9dUNhFTF4pYdFCnTlxrmZY ExOArygwfXFFG6YB8NgIttwSJU/hg33KQLiIygpHsPixsqW78VYR7aw= Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id E0C0894065 for ; Thu, 14 Mar 2013 13:47:02 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id fm10so2398490wgb.33 for ; Thu, 14 Mar 2013 13:47:01 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.57.137 with SMTP id i9mr6963164wjq.18.1363294021643; Thu, 14 Mar 2013 13:47:01 -0700 (PDT) Received: by 10.216.113.68 with HTTP; Thu, 14 Mar 2013 13:47:01 -0700 (PDT) In-Reply-To: <5142357D.6030601@gnutls.org> References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> <8EE96183-E8F4-4208-B602-4C308F0515FB@checkpoint.com> <86BF0B4B-C169-492F-8572-A3AAAF72FD5B@iki.fi> <5142357D.6030601@gnutls.org> Date: Thu, 14 Mar 2013 15:47:01 -0500 Message-ID: From: Nico Williams To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] ALPN 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, 14 Mar 2013 20:47:04 -0000 On Thu, Mar 14, 2013 at 3:39 PM, Nikos Mavrogiannopoulos wrote: > I think it is important to decide first what we want from this > extension. As I understand ALPN and NPN do exactly the same thing, they > negotiate the protocol to be used under TLS, but one proposal offers > something more. Some kind of privacy in that negotiation against passive > eavesdroppers. > > The question is, do we need that additional privacy, along with its > added complexity (because a totally new negotiation mechanism is added). We may be able to get that additional privacy without that complexity. We should decide whether we want the additional privacy without concern about the complexity until we then convince ourselves that we cannot obtain such additional privacy without too much additional complication. I just made a third proposal that I think obtains that additional privacy with less complexity. Nico -- From n.mavrogiannopoulos@gmail.com Thu Mar 14 14:10:55 2013 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 33F8C11E822C for ; Thu, 14 Mar 2013 14:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=1.377, 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 COVVMO73n6l8 for ; Thu, 14 Mar 2013 14:10:54 -0700 (PDT) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 775BE11E821A for ; Thu, 14 Mar 2013 14:10:54 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id b47so1258325eek.1 for ; Thu, 14 Mar 2013 14:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received: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=vw8r9a6YX7zoDI2hF6x4wutj4crEbKaueMAe7SMe0Wo=; b=IhOo8gkehhmsPb3SqolNCJJlwhfOWqhyThwji/RIva9zdrdgeeccf23mV8OUd8Pwd7 lC1nrYliRouHH5R00mk+AIKX/BPPFqqdgt4Nv7z6F+48gDOshyVgEU8KCAnIlijwm8Js JQbG6w1JjXHUU1rF6zYl34gkrDujj/QywaUrzht6FG8u3gU98JDko5lAiMDmxZ4JACKM TVACNqyq9Ca/VgMB/dp4nEsjvPhOnV7Vu9d7OWb9YuaaJY27ZDxdzHqI1F6/Tt+73oYj 4UGm2XRi7DZVuMom0uxxMnSYBhGMwoZoCy4Jti+bQyAne3+QaYz/3frlyWB7U8IHYqPO ejSw== X-Received: by 10.14.173.196 with SMTP id v44mr10683675eel.29.1363295453537; Thu, 14 Mar 2013 14:10:53 -0700 (PDT) Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id h5sm6155950eem.1.2013.03.14.14.10.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 14:10:52 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <51423CD6.6070208@gnutls.org> Date: Thu, 14 Mar 2013 22:10:46 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Nico Williams References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> <8EE96183-E8F4-4208-B602-4C308F0515FB@checkpoint.com> <86BF0B4B-C169-492F-8572-A3AAAF72FD5B@iki.fi> <5142357D.6030601@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] ALPN 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, 14 Mar 2013 21:10:55 -0000 On 03/14/2013 09:47 PM, Nico Williams wrote: >> I think it is important to decide first what we want from this >> extension. As I understand ALPN and NPN do exactly the same thing, they >> negotiate the protocol to be used under TLS, but one proposal offers >> something more. Some kind of privacy in that negotiation against passive >> eavesdroppers. >> >> The question is, do we need that additional privacy, along with its >> added complexity (because a totally new negotiation mechanism is added). > We may be able to get that additional privacy without that complexity. > We should decide whether we want the additional privacy without > concern about the complexity until we then convince ourselves that we > cannot obtain such additional privacy without too much additional > complication. > > I just made a third proposal that I think obtains that additional > privacy with less complexity. My main question is whether do we really need that additional privacy? I am not convinced by the current answers to that question, and I see several advantages when that information is disclosed (e.g. networking policies are enforced the same way as they are today). regards, Nikos From nico@cryptonector.com Thu Mar 14 14:20:54 2013 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 CAD3221F8DCB for ; Thu, 14 Mar 2013 14:20:53 -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 xRv8YxIc1hyK for ; Thu, 14 Mar 2013 14:20:53 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id C67E721F8DC2 for ; Thu, 14 Mar 2013 14:20:52 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 86FC9286074 for ; Thu, 14 Mar 2013 14:20:52 -0700 (PDT) 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; s=cryptonector.com; bh=DvSfGIpmwvVCFqQ9GOVB J1JZ7f0=; b=Pc+pmjdj/g0dqK9LQ4iLQxtMZHy8Qv2yMLuLoDQtmSr1eArw8feR RnH38YLrnTyo8YvTJSY3X8fpGoJ+YYyQjkw8MlrRsAGmjpIIDruc0a2Og5xkqC0j qKzUB/DQxYfV1j/bITjish5vH3d6jKUonMMEdzHlEWDDVhdlXNNcNYU= Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id 2BE2E28605B for ; Thu, 14 Mar 2013 14:20:51 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id o45so2565103wer.37 for ; Thu, 14 Mar 2013 14:20:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.89.169 with SMTP id bp9mr6981072wjb.57.1363296050597; Thu, 14 Mar 2013 14:20:50 -0700 (PDT) Received: by 10.216.113.68 with HTTP; Thu, 14 Mar 2013 14:20:50 -0700 (PDT) In-Reply-To: <51423CD6.6070208@gnutls.org> References: <32599_1363111393_513F6DE1_32599_8557_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB90CE2F4@PEXCVZYM14.corporate.adroot.infra.ftgroup> <7C9A0DF1-8BE4-47EF-B3F2-5D1F9E087326@vpnc.org> <9F7DD708-7405-4F94-A935-2A31DE8A9FE5@vpnc.org> <8EE96183-E8F4-4208-B602-4C308F0515FB@checkpoint.com> <86BF0B4B-C169-492F-8572-A3AAAF72FD5B@iki.fi> <5142357D.6030601@gnutls.org> <51423CD6.6070208@gnutls.org> Date: Thu, 14 Mar 2013 16:20:50 -0500 Message-ID: From: Nico Williams To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] ALPN 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, 14 Mar 2013 21:20:54 -0000 On Thu, Mar 14, 2013 at 4:10 PM, Nikos Mavrogiannopoulos wrote: > On 03/14/2013 09:47 PM, Nico Williams wrote: >>> I think it is important to decide first what we want from this >>> extension. As I understand ALPN and NPN do exactly the same thing, they >>> negotiate the protocol to be used under TLS, but one proposal offers >>> something more. Some kind of privacy in that negotiation against passive >>> eavesdroppers. >>> >>> The question is, do we need that additional privacy, along with its >>> added complexity (because a totally new negotiation mechanism is added). >> We may be able to get that additional privacy without that complexity. >> We should decide whether we want the additional privacy without >> concern about the complexity until we then convince ourselves that we >> cannot obtain such additional privacy without too much additional >> complication. >> >> I just made a third proposal that I think obtains that additional >> privacy with less complexity. > > > My main question is whether do we really need that additional privacy? I > am not convinced by the current answers to that question, and I see > several advantages when that information is disclosed (e.g. networking > policies are enforced the same way as they are today). Do we want additional privacy? I believe we *should*. We should always want all the privacy protection that we can get at a low enough price, and so the question is: can we pay a low-enough price for privacy protection of application protocol negotiation? I think it's reasonable to think that NPN is too complex. I don't think it's reasonable to reject this feature without looking at whether there are less complex ways of getting it. I made a proposal that I think is very simple and gets us that privacy protection. Nico -- From jsalowey@cisco.com Thu Mar 14 21:20:23 2013 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 65A0421F8D64 for ; Thu, 14 Mar 2013 21:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 jCKRlNHYuJvP for ; Thu, 14 Mar 2013 21:20:22 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 72B7721F8D60 for ; Thu, 14 Mar 2013 21:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3497; q=dns/txt; s=iport; t=1363321222; x=1364530822; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ptby1B9XgSGy7coLp6WVUjMAvmCMJukWwsSgjuRMiYw=; b=igXVlwnVnN9f6D+VA0+cvPyIuKlXsbWgad3Ew7BNUQj4sp8WCrdEOdGJ 4itzjbrYIXDpYkhcsp7PjD6ZZlxQHSoI24brBBbvAwu1vrM2lFQ9ncjQV 9c/50npcsKFLVS0aC1gmwjrrJWZ9zgWq3WZHFgmVKC1OJzs4t43ph5pnH U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABehQlGtJXG+/2dsb2JhbABDxQWBaRZ0gisBAQEDAQEBATc0CwULAgEIGAoUECcLJQIEDgUIiAYGDMIhBI1ME4EDAjEHgl9hA5MVlEeDCoFqPg X-IronPort-AV: E=Sophos;i="4.84,849,1355097600"; d="scan'208";a="187730238" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 15 Mar 2013 04:20:22 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2F4KLJs024283 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Mar 2013 04:20:21 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 23:20:21 -0500 From: "Joseph Salowey (jsalowey)" To: Sean Turner Thread-Topic: [TLS] AD review of draft-ietf-tls-multiple-cert-status-extension Thread-Index: AQHOH1fJjwNwZgNgfka+RAkAxAep5Jiiyb4AgAO0NoA= Date: Fri, 15 Mar 2013 04:20:21 +0000 Message-ID: References: <51278B81.9070809@ieca.com> <513F861C.2040703@ieca.com> In-Reply-To: <513F861C.2040703@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.223.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [TLS] AD review of draft-ietf-tls-multiple-cert-status-extension 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, 15 Mar 2013 04:20:23 -0000 Looks OK to me.=20 On Mar 12, 2013, at 12:46 PM, Sean Turner wrote: > On 3/12/13 3:28 PM, Yngve N. Pettersen wrote: >> On Fri, 22 Feb 2013 16:15:13 +0100, Sean Turner wrote= : >>=20 >>> Two questions, one comment, and one thing to note: >>>=20 >>> Q1: Is text needed that restricts the number of requests that can go >>> with case ocsp to 1? e.g.,: >>>=20 >>> The list of CertificateStatusRequestItem entries MUST be in >>> order of preference. When used with case ocsp, only one request >>> item is allowed. When used with case ocsp_multi, more than one >>> request is allowed. >>=20 >>=20 >>=20 >> Theoretically, I can envision implementations that signal several >> ResponderID lists, perhaps with different Extensions, where the server >> picks RespondersIDs that it know, possibly with the default as a backup. >> In that case you would want to have several of each type of request. >>=20 >> E.g. >>=20 >> ocsp_multi(Resp1, ext1) >> ocsp(Resp1, ext1) >> ocsp_multi(Resp2, ext2) >> ocsp(Resp2, ext2) >> ocsp_multi() >> ocsp() >>=20 >> I agree it is unlikely that we will see such a scenario, but should we >> explicitly forbid it? The reason for this extension is, after all, that >> the original extension accidentally became too limited. >>=20 >>=20 >>> Q2: Should there be an error if case ocsp is used with multiple >>> requests or when case ocsp_multi is used with only one request? >>=20 >> Given the above, only if we decide to restrict things. >>=20 >> Requiring errors for non-fatal problems could lead to implementation >> differences. Checking for duplicates is also a possible programming issu= e; >> it is implicitly required for the entire extension system, though. >=20 > Okay so on Q1 and Q2 it looks like no. If somebody cares, then they shou= ld say something on Friday otherwise I'll IETF LC it after the session. >=20 >>> C1: CCITT was long ago renamed ITU. How about we change: >>> r/[CCITT.X680.2002]/[X680.2002] >>> r/[CCITT.X690.2002]/[X690.2002] >>>=20 >>> and use the same references from RFC 5246: >>>=20 >>> [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, >>> Information technology - Abstract Syntax Notation One >>> (ASN.1): Specification of basic notation. >>>=20 >>> [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, >>> Information technology - ASN.1 encoding Rules: >>> Specification of Basic Encoding Rules (BER), Canonical >>> Encoding Rules (CER) and Distinguished Encoding Rules >>> (DER). >>=20 >> The main thing about this is that the reference IDs are forced, at least >> in part, by the central bibliography index file, since I am only >> importing those via the XML2RFC file, and there is no entries with >> shorter reference names in the index, and I would rather avoid >> duplicating the entire index entry >=20 > Okay, I'll get the RFC editor to fix this. >=20 >>> N1: OCSP is also about to be in last call so the references will >>> likely be updated to point to it at some point. >>=20 >> We'll handle that if/when it becomes relevant. >=20 > I plan to IETF LC this one at about the same time, but we can always fix = the reference later. This was more of a heads up. >=20 > spt > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From iesg-secretary@ietf.org Fri Mar 15 10:35:59 2013 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 656FB21F891D; Fri, 15 Mar 2013 10:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 n+W2l0qYywmp; Fri, 15 Mar 2013 10:35:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF13621F882F; Fri, 15 Mar 2013 10:35:58 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130315173558.7429.6754.idtracker@ietfa.amsl.com> Date: Fri, 15 Mar 2013 10:35:58 -0700 Cc: tls@ietf.org Subject: [TLS] Last Call: (The TLS Multiple Certificate Status Request Extension) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 17:35:59 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'The TLS Multiple Certificate Status Request Extension' as 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@ietf.org mailing lists by 2013-03-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Fri Mar 15 10:35:59 2013 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 8857321F8922 for ; Fri, 15 Mar 2013 10:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 TsycJbfpfdnN; Fri, 15 Mar 2013 10:35:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C563621F88EA; Fri, 15 Mar 2013 10:35:58 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.43 X-IETF-Draft-string: draft-ietf-tls-multiple-cert-status-extension X-IETF-Draft-revision: 04 Message-ID: <20130315173558.7429.20829.idtracker@ietfa.amsl.com> Date: Fri, 15 Mar 2013 10:35:58 -0700 Cc: tls@ietf.org Subject: [TLS] Last Call: (The TLS Multiple Certificate Status Request Extension) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 17:35:59 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'The TLS Multiple Certificate Status Request Extension' as 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@ietf.org mailing lists by 2013-03-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension/ballot/ No IPR declarations have been submitted directly on this I-D. From ekr@rtfm.com Fri Mar 15 14:46:21 2013 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 E4AC321F8507 for ; Fri, 15 Mar 2013 14:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 Sm606tc1A8II for ; Fri, 15 Mar 2013 14:46:21 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7207221F8493 for ; Fri, 15 Mar 2013 14:46:21 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id d1so344468qca.16 for ; Fri, 15 Mar 2013 14:46:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=Acdq69qGaqqOe6msAGCVg3ViO3/EMexezY8kkZ76LJQ=; b=IetOHuM34WagFWyZ6O8zA6ODoMaam3LkaheYb/hw/+NECCuWO/V7IE/DaJPflaG5FT 6jRiPXzIyxtskshwkRuCvw6wcYPHhCzj+R9s4QNWeu+/lEHMR/wNKSvbofBna4ohE0RC Eamty9NTHamnxYM9Rccr2iJVEtjt5gC8kCqbEZpNmEf+K9ljGuKQuXkvww/s337P1XVV N8ezs9+1Zz7l698i1e3Calys4GU5IUjrehpyh9pPF+XA7oDQx8qUAeFzT3jgoAQaopFF ewec6lxfuBOZIAB7HOq8B4Er7UPpC0g4NPQnltQe6SKMd3zlP8XKGHnNJ4vjfnwEZ/wm 9SaA== X-Received: by 10.49.28.229 with SMTP id e5mr8766362qeh.14.1363383980677; Fri, 15 Mar 2013 14:46:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.84.5 with HTTP; Fri, 15 Mar 2013 14:45:40 -0700 (PDT) X-Originating-IP: [2001:df8:0:16:5a55:caff:fef1:5a11] From: Eric Rescorla Date: Fri, 15 Mar 2013 14:45:40 -0700 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=047d7bdc0aa6dcb7c704d7fd9177 X-Gm-Message-State: ALoCoQk7l7oiyjbh8OHg0UxN+fC/pWgXwPf+R8NPfevzYZuB5JOlElR/OwNnIBXtL9zGbg0/HnqR Subject: [TLS] Confirming consensus for ALPN 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, 15 Mar 2013 21:46:22 -0000 --047d7bdc0aa6dcb7c704d7fd9177 Content-Type: text/plain; charset=ISO-8859-1 At today's TLS WG f2f meeting we had rough consensus to adopt ALPN as the solution to the upper-layer protocol negotiation problem posed to us by the HTTP WG. if you have an opinion on this topic and were not at the meeting, please send a message to the mailing list and/or the chairs by Friday March 29. -Ekr [For the chairs] --047d7bdc0aa6dcb7c704d7fd9177 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable At today's TLS WG f2f meeting we had rough consensus to adopt
ALPN = as the solution to the upper-layer protocol negotiation problem
p= osed to us by the HTTP WG.

if you have an opinion = on this topic and were not at the meeting,
please send a message to the mailing list and/or the chairs by
Friday March 29.

-Ekr
[For the chairs= ]

--047d7bdc0aa6dcb7c704d7fd9177-- From nico@cryptonector.com Fri Mar 15 14:59:53 2013 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 5131A21F8530 for ; Fri, 15 Mar 2013 14:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.090, 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 JI+o-t5QPvCz for ; Fri, 15 Mar 2013 14:59:52 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id BAACF21F852A for ; Fri, 15 Mar 2013 14:59:52 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 75E7D58406A for ; Fri, 15 Mar 2013 14:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=RjKZOxQEDgkZGdhVADq1sQFZw34=; b=ONSrIpWhEo9 aq5oL7Pnxt9WTCw/ea3/oyu0+0aaj6bm3AxM/nffNy8gHBI59m5CWBpchDAkuox7 ujR6GIFiOvBPhU/JTM+tbPuNFLC/RlktuGm3xPM3+8qwcYKTNzBWtDQvpbVe3MWO LOYZ/L7qQ2lqQQqrcx6FxF00Kbw91xao= Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 1F63A584058 for ; Fri, 15 Mar 2013 14:59:51 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id l13so1128519wie.2 for ; Fri, 15 Mar 2013 14:59:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.89.169 with SMTP id bp9mr13660156wjb.57.1363384790555; Fri, 15 Mar 2013 14:59:50 -0700 (PDT) Received: by 10.216.113.68 with HTTP; Fri, 15 Mar 2013 14:59:50 -0700 (PDT) Date: Fri, 15 Mar 2013 16:59:50 -0500 Message-ID: From: Nico Williams To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: [TLS] The consensus is half-mistaken (Re: Confirming consensus for ALPN) 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, 15 Mar 2013 21:59:53 -0000 On Fri, Mar 15, 2013 at 4:45 PM, Eric Rescorla wrote: > At today's TLS WG f2f meeting we had rough consensus to adopt > ALPN as the solution to the upper-layer protocol negotiation problem > posed to us by the HTTP WG. > > if you have an opinion on this topic and were not at the meeting, > please send a message to the mailing list and/or the chairs by > Friday March 29. I believe that privacy protection for as much as possible of the application layer negotiation is highly desirable. In this sense I think the consensus for ALPN is mistaken. I do believe NPN is too complex, and in that sense the consensus for ALPN is correct. Can we find a middle of the road? My compromise proposal is based on providing privacy protection for the record type in TLS (post-CCS, of course) -- a feature that should be desirable anyways and separately (e.g., to hide re-negotiation from non-MITM middleboxes). Such a feature would allow a post-handshake non-application-type record for optimistic application protocol negotiation (zero extra round trips in the optimal case, one more round trip in the pessimal case). Nico -- From mbadra@gmail.com Fri Mar 15 15:10:23 2013 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 0F1D911E80D1 for ; Fri, 15 Mar 2013 15:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 orSUeAlltJeE for ; Fri, 15 Mar 2013 15:10:21 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDDF11E80A5 for ; Fri, 15 Mar 2013 15:10:21 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id ha11so1609565vcb.16 for ; Fri, 15 Mar 2013 15:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=4pl4HI9b4jDaNVXuRJk5QNF9gGXxWmxm4tQL7ehkJTE=; b=zbVpKWlBUCISII/+21G16+4GnABIBMmMTGOXirENs8z7++pjhvngy7wCxSn+WNGvtF 57yKLQozccJmZt/5FEcePcusxBfIzwHJTE8oBQ0MDenvw/qeTo47TTxH9fNP2BWUpgG/ FAXRnd+FFQAT+l5gW6Sr8A0+EU2W/AvpKp3b3EyUyuMiuzfu3UyNco67kiEtA3T7aSo8 Lq4gnYYkU0MkqnSXYpsejH3QSVeOD7hv66iRTP/uu8YtCmTq2U1mFMcxavH53v+Y7SyW 6ABPNLhpHUENY6fkE3k5Xd81FaXWD7ROmxooR9e2eZzU1OWNJikY7xdYsjfMr9TeVDnj MWPA== MIME-Version: 1.0 X-Received: by 10.52.18.235 with SMTP id z11mr8020049vdd.39.1363385417002; Fri, 15 Mar 2013 15:10:17 -0700 (PDT) Received: by 10.220.234.194 with HTTP; Fri, 15 Mar 2013 15:10:16 -0700 (PDT) In-Reply-To: References: Date: Sat, 16 Mar 2013 02:10:16 +0400 Message-ID: From: Mohamad Badra To: Eric Rescorla Content-Type: multipart/alternative; boundary=bcaec502d82878f45e04d7fde7fb Cc: tls@ietf.org Subject: Re: [TLS] Confirming consensus for ALPN 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, 15 Mar 2013 22:10:23 -0000 --bcaec502d82878f45e04d7fde7fb Content-Type: text/plain; charset=ISO-8859-1 Hi, It is still not clear totally clear to me, is ALPN designed to: (a) multiplex several application data over a single TLS session, or (b) negotiate the use of an application level protocol on port 443 (to mainly to avoid firewall)? Best regards, Badra On Sat, Mar 16, 2013 at 1:45 AM, Eric Rescorla wrote: > At today's TLS WG f2f meeting we had rough consensus to adopt > ALPN as the solution to the upper-layer protocol negotiation problem > posed to us by the HTTP WG. > > if you have an opinion on this topic and were not at the meeting, > please send a message to the mailing list and/or the chairs by > Friday March 29. > > -Ekr > [For the chairs] > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --bcaec502d82878f45e04d7fde7fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

It is still not clear totally clear to me,= is ALPN designed to:

(a) multiplex several applic= ation data over a single TLS session, or=A0
(b) negotiate the use= of an application level protocol on=A0port 443 (to mainly to avoid firewal= l)?

Best regards,
Badra


On Sat, Mar 16, 2013 at 1:45 AM, Eric Res= corla <ekr@rtfm.com> wrote:
At today's TLS WG f2f meeting we had rou= gh consensus to adopt
ALPN as the solution to the upper-layer protocol = negotiation problem
posed to us by the HTTP WG.

if you have an op= inion on this topic and were not at the meeting,
please send a message to the mailing list and/or the chairs by
Friday March 29.

-Ekr
[For the chairs= ]


_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls


--bcaec502d82878f45e04d7fde7fb-- From juhovh@iki.fi Fri Mar 15 15:31:33 2013 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 C641421F89E2 for ; Fri, 15 Mar 2013 15:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] 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 2YX7h038WhJH for ; Fri, 15 Mar 2013 15:31:33 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0053B21F87EA for ; Fri, 15 Mar 2013 15:31:32 -0700 (PDT) Received: from [10.48.50.76] (188.238.51.76) by kirsi1.inet.fi (8.5.140.03) id 51292B7F0186BEAA; Sat, 16 Mar 2013 00:31:31 +0200 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-AF1A3563-7A4F-4848-BA71-7839F4DB6E8F Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B146) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= Date: Sat, 16 Mar 2013 00:31:29 +0200 To: Mohamad Badra Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus for ALPN 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, 15 Mar 2013 22:31:33 -0000 --Apple-Mail-AF1A3563-7A4F-4848-BA71-7839F4DB6E8F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On 16.3.2013, at 0.10, Mohamad Badra wrote: > It is still not clear totally clear to me, is ALPN designed to: >=20 > (a) multiplex several application data over a single TLS session, or=20 > (b) negotiate the use of an application level protocol on port 443 (to mai= nly to avoid firewall)? The discussion here might have been a bit misleading recently. My understand= ing is that the main goal of ALPN is the same as with NPN: allowing the use o= f "next-gen" HTTP versions (mainly SPDY and HTTP/2) on the same port as HTTP= S, because they serve the same content anyway. So (b) would be closer. http://tools.ietf.org/html/draft-friedl-tls-applayerprotoneg-02 Juho --Apple-Mail-AF1A3563-7A4F-4848-BA71-7839F4DB6E8F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 16.3.2013, at 0.10, Mohamad Badra &= lt;mbadra@gmail.com> wrote:
=
It is still not clear t= otally clear to me, is ALPN designed to:

(a) multip= lex several application data over a single TLS session, or 
(= b) negotiate the use of an application level protocol on port 443 (to m= ainly to avoid firewall)?

= The discussion here might have been a bit misleading recently. My understand= ing is that the main goal of ALPN is the same as with NPN: allowing the use o= f "next-gen" HTTP versions (mainly SPDY and HTTP/2) on the same port as HTTP= S, because they serve the same content anyway. So (b) would be closer.
=



Juho

= --Apple-Mail-AF1A3563-7A4F-4848-BA71-7839F4DB6E8F-- From mbadra@gmail.com Fri Mar 15 15:41:37 2013 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 7AC1521F8858 for ; Fri, 15 Mar 2013 15:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 W26faIn6dupw for ; Fri, 15 Mar 2013 15:41:37 -0700 (PDT) Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id E827E21F8860 for ; Fri, 15 Mar 2013 15:41:36 -0700 (PDT) Received: by mail-vb0-f41.google.com with SMTP id l22so2229765vbn.28 for ; Fri, 15 Mar 2013 15:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BexF9WsM+1tIjiAx8oFmp6tgfsbLsyIjQBZGbI78HP8=; b=J/aQwkVvr5xc6fhVeXwkiG8lYT4stY8A7eejg5fZ36xZPtNgYOze/floDWMxJuqg2n 408NL+GDTyYoix//BZwvejKUG/GxzfrTu+BdreSJZbpcEZqHrXK/+vYn5wUpen9bfBaC RJU9MndfLccMXY4oj16uHZGH4C0vvuOaNVeXgzlPtQQtXMEAGZo3DlNshX+nXUWzMx54 St5JO+Ye9XOXql9993C/dYGiddNccWlby0UGcQI7WQ+iYtLBAWWittUx6pQTU9W4iMzC usElV1+RT8okCZ1RQ3Fx+v3VgD8ETKrlAbhjX9Xn4rnmZxjfUhw8nrgfzz0ReQRMKqbU rmyw== MIME-Version: 1.0 X-Received: by 10.58.65.2 with SMTP id t2mr9541648ves.28.1363387292262; Fri, 15 Mar 2013 15:41:32 -0700 (PDT) Received: by 10.220.234.194 with HTTP; Fri, 15 Mar 2013 15:41:32 -0700 (PDT) In-Reply-To: References: Date: Sat, 16 Mar 2013 02:41:32 +0400 Message-ID: From: Mohamad Badra To: =?ISO-8859-1?Q?Juho_V=E4h=E4=2DHerttua?= Content-Type: multipart/alternative; boundary=047d7bacbcc83f296a04d7fe5791 Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus for ALPN 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, 15 Mar 2013 22:41:37 -0000 --047d7bacbcc83f296a04d7fe5791 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Mar 16, 2013 at 2:31 AM, Juho V=E4h=E4-Herttua wrot= e: > On 16.3.2013, at 0.10, Mohamad Badra wrote: > > It is still not clear totally clear to me, is ALPN designed to: > > (a) multiplex several application data over a single TLS session, or > (b) negotiate the use of an application level protocol on port 443 (to > mainly to avoid firewall)? > > > The discussion here might have been a bit misleading recently. My > understanding is that the main goal of ALPN is the same as with NPN: > allowing the use of "next-gen" HTTP versions (mainly SPDY and HTTP/2) on > the same port as HTTPS, because they serve the same content anyway. So (b= ) > would be closer. > But HTTP allows version negotiation, why should be this brought to the TLS level? Best regards, Badra --047d7bacbcc83f296a04d7fe5791 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Mar 16, 2013 at 2:31 AM, Juho V=E4h=E4-Herttua <juhov= h@iki.fi> wrote:
On 16.3.2013, at 0.10, Mohamad Bad= ra <mbadra@gmail.c= om> wrote:
It is still not clear totally clear to me, is ALPN designed to:

(a) multiplex several application data over a single TL= S session, or=A0
(b) negotiate the use of an application level pr= otocol on=A0port 443 (to mainly to avoid firewall)?

The discussion here might have been a bit mislead= ing recently. My understanding is that the main goal of ALPN is the same as= with NPN: allowing the use of "next-gen" HTTP versions (mainly S= PDY and HTTP/2) on the same port as HTTPS, because they serve the same cont= ent anyway. So (b) would be closer.


But HTTP allows versi= on negotiation, why should be this brought to the TLS level?

=
Best regards,
Badra
--047d7bacbcc83f296a04d7fe5791-- From nico@cryptonector.com Fri Mar 15 15:46:32 2013 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 185581F0D07 for ; Fri, 15 Mar 2013 15:46:32 -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 wSTDu6-iO4+J for ; Fri, 15 Mar 2013 15:46:31 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 993D61F0D05 for ; Fri, 15 Mar 2013 15:46:31 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 5485F26406A for ; Fri, 15 Mar 2013 15:46:31 -0700 (PDT) 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=x10Z6KaOpE4uJzV//zVMUWk85Xo=; b=MVtQf6kWHe9 SxXnVy0Awh/0oYMZ9MIzmICaVgz2+a3Jl1wpGnb3NgvKMWUE9KXF9HvBjNeJ+5/N o6VhGdZDY8Tu7yW/wE+XvUfkmribUGkEuHK0lOiKA4ONKaEOwWpqFcrqAqS6boG0 11nGQv5pvfiR+hkujxATiYML2iYDLcaE= Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id F23BC264058 for ; Fri, 15 Mar 2013 15:46:30 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id e12so3224005wge.22 for ; Fri, 15 Mar 2013 15:46:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.11.148 with SMTP id q20mr5706172wib.18.1363387589774; Fri, 15 Mar 2013 15:46:29 -0700 (PDT) Received: by 10.216.113.68 with HTTP; Fri, 15 Mar 2013 15:46:29 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Mar 2013 17:46:29 -0500 Message-ID: From: Nico Williams To: Mohamad Badra Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus for ALPN 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, 15 Mar 2013 22:46:32 -0000 On Fri, Mar 15, 2013 at 5:41 PM, Mohamad Badra wrote: > On Sat, Mar 16, 2013 at 2:31 AM, Juho V=C3=A4h=C3=A4-Herttua wrote: >> The discussion here might have been a bit misleading recently. My >> understanding is that the main goal of ALPN is the same as with NPN: >> allowing the use of "next-gen" HTTP versions (mainly SPDY and HTTP/2) on= the >> same port as HTTPS, because they serve the same content anyway. So (b) w= ould >> be closer. > > But HTTP allows version negotiation, why should be this brought to the TL= S > level? To save a round trip? Nico -- From juhovh@iki.fi Fri Mar 15 15:54:48 2013 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 1A76C11E80E9 for ; Fri, 15 Mar 2013 15:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] 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 BxWw1QoJClp0 for ; Fri, 15 Mar 2013 15:54:47 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 61BE511E80BF for ; Fri, 15 Mar 2013 15:54:47 -0700 (PDT) Received: from [10.48.50.76] (188.238.51.76) by kirsi1.inet.fi (8.5.140.03) id 51292B7F018724B7; Sat, 16 Mar 2013 00:54:45 +0200 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7F4E2211-C738-443C-8EEF-1C07B28926CB@iki.fi> X-Mailer: iPhone Mail (10B146) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= Date: Sat, 16 Mar 2013 00:54:43 +0200 To: Nico Williams Cc: "tls@ietf.org" Subject: Re: [TLS] The consensus is half-mistaken (Re: Confirming consensus for ALPN) 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, 15 Mar 2013 22:54:48 -0000 On 15.3.2013, at 23.59, Nico Williams wrote: > I do believe NPN is too > complex, and in that sense the consensus for ALPN is correct. >=20 > Can we find a middle of the road? >=20 > My compromise proposal is based on providing privacy protection for > the record type in TLS (post-CCS, of course) -- a feature that should > be desirable anyways and separately I'm sorry to point this out, but I think your proposal is actually much more= complex to implement than the NPN proposal. No other extension that I can t= hink of have changed the data record format, and mixing data records with ha= ndshake packets would need a rather big refactoring at least in my implement= ation. As I mentioned before, NPN without the plaintext server response would work i= n preventing the most obvious firewall filtering, so if that is desired the d= raft should be reworded more clearly to list only conflicting protocols serv= ing the same content in ServerHello. That being said, I do not object choosing ALPN over NPN. It is the most simp= le and most obvious implementation, and if there's trouble with firewalls on= e can always fake the protocol name or not use ALPN at all. Juho From mbadra@gmail.com Fri Mar 15 16:01:58 2013 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 4F7D121F86BA for ; Fri, 15 Mar 2013 16:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 lYi5UxFmkGMT for ; Fri, 15 Mar 2013 16:01:57 -0700 (PDT) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id A818C21F84A1 for ; Fri, 15 Mar 2013 16:01:57 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id lf10so1660708vcb.1 for ; Fri, 15 Mar 2013 16:01:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xmg7AmMEsAns+Gr+KqQ9kUA2ukn+RfSKBWpNAL8rj1U=; b=X5RoOJ+yHmndEA/gzqcyC2WFvMVBRf7ByjPGpWUT3kHzAQyMJTq8WLsHyXkQJhRANQ As6IbQRpvg/5dOQYIw5nOJ9Wb/24Iaem2TjXvH7fgNyXzQgeC0SymG7fqA/lRrF0EYPL MiVS4SU2i3xN0DDuqkmS77NS6OjV49u2BPiZ4rT+OqrdrCzL6jKMjL8Dvc3DOWo55xq3 hmnD017y6Luq4YOX1a0LxVImEnPNfVbObywAHVHWigYF24SHGejUl1mq0GFU3eBc+i0+ 4HAum0r3RMd2/Fi5xdgLxArpvqpboktLvAFluVoI51M3brK5e76tosXbhRaX1+w4evYI U0Rw== MIME-Version: 1.0 X-Received: by 10.52.18.235 with SMTP id z11mr8149416vdd.39.1363388516930; Fri, 15 Mar 2013 16:01:56 -0700 (PDT) Received: by 10.220.234.194 with HTTP; Fri, 15 Mar 2013 16:01:56 -0700 (PDT) In-Reply-To: References: Date: Sat, 16 Mar 2013 03:01:56 +0400 Message-ID: From: Mohamad Badra To: Nico Williams Content-Type: multipart/alternative; boundary=bcaec502d8283e1df304d7fea0a7 Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus for ALPN 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, 15 Mar 2013 23:01:58 -0000 --bcaec502d8283e1df304d7fea0a7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Mar 16, 2013 at 2:46 AM, Nico Williams wrote= : > On Fri, Mar 15, 2013 at 5:41 PM, Mohamad Badra wrote: > > On Sat, Mar 16, 2013 at 2:31 AM, Juho V=E4h=E4-Herttua > wrote: > >> The discussion here might have been a bit misleading recently. My > >> understanding is that the main goal of ALPN is the same as with NPN: > >> allowing the use of "next-gen" HTTP versions (mainly SPDY and HTTP/2) > on the > >> same port as HTTPS, because they serve the same content anyway. So (b) > would > >> be closer. > > > > But HTTP allows version negotiation, why should be this brought to the > TLS > > level? > > To save a round trip? > > That you want to sacrifice it to avoid traffic analysis :) I don't see how a round trip is saved here: HTTP allows their clients to advertise the major version they support in the first request the client send to the server (e.g. HTTP request). The server replies with the lower of that suggested by the client and the highest supported by the server. This version negotiation is part of HTTP request/response exchange, so where is the saved round trip? Badra --bcaec502d8283e1df304d7fea0a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Mar 16, 2013 at 2:46 AM, Nico Williams <nic= o@cryptonector.com> wrote:
On Fri, Mar 15, 2013 at 5:41 PM, Mohamad Badra <mbadra@gmail.com> wrote:
> On Sat, Mar 16, 2013 at 2:31 AM, Juho V=E4h=E4-Herttua <juhovh@iki.fi> wrote:
>> The discussion here might have been a bit = misleading recently. My
>> understanding is that the main goal of ALPN is the same as with NP= N:
>> allowing the use of "next-gen" HTTP versions (mainly SPD= Y and HTTP/2) on the
>> same port as HTTPS, because they serve the same content anyway. So= (b) would
>> be closer.
>
> But HTTP allows version negotiation, why should be this brought to the= TLS
> level?

To save a round trip?


That you want to sacrifice it to avoid= traffic analysis :)

I don't see how a round t= rip is saved here: HTTP allows their clients to advertise=A0the major versi= on they support in the first request the client send to the server (e.g. HT= TP request). The server replies with the lower of that suggested by the cli= ent and=A0the highest supported by the server. This version negotiation is = part of HTTP request/response exchange, so where is the saved round trip?

Badra
--bcaec502d8283e1df304d7fea0a7-- From juhovh@iki.fi Fri Mar 15 16:02:20 2013 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 6964D21F86EF for ; Fri, 15 Mar 2013 16:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] 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 Hbk8qut1Op1U for ; Fri, 15 Mar 2013 16:02:20 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id A07F621F84A1 for ; Fri, 15 Mar 2013 16:02:18 -0700 (PDT) Received: from [10.48.50.76] (188.238.51.76) by jenni2.inet.fi (8.5.140.03) id 50871399093F4D6F; Sat, 16 Mar 2013 01:02:16 +0200 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-5B788E8C-CB41-4E78-B799-7BF186C62606 Content-Transfer-Encoding: 7bit Message-Id: <11AF66DA-69ED-49E9-8D93-7CCC06AF624D@iki.fi> X-Mailer: iPhone Mail (10B146) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= Date: Sat, 16 Mar 2013 01:02:14 +0200 To: Mohamad Badra Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus for ALPN 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, 15 Mar 2013 23:02:20 -0000 --Apple-Mail-5B788E8C-CB41-4E78-B799-7BF186C62606 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 16.3.2013, at 0.41, Mohamad Badra wrote: > On Sat, Mar 16, 2013 at 2:31 AM, Juho V=C3=A4h=C3=A4-Herttua wrote: >> The discussion here might have been a bit misleading recently. My underst= anding is that the main goal of ALPN is the same as with NPN: allowing the u= se of "next-gen" HTTP versions (mainly SPDY and HTTP/2) on the same port as H= TTPS, because they serve the same content anyway. So (b) would be closer. >=20 > But HTTP allows version negotiation, why should be this brought to the TLS= level? SPDY usually serves HTTP content, but it is not HTTP compatible on the wire.= This means HTTP version negotiation is not relevant in that case. And as Ni= co already said, negotiating the version on TLS level saves one extra round t= rip, which speeds up things. Juho --Apple-Mail-5B788E8C-CB41-4E78-B799-7BF186C62606 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 16.3.2013, at 0.41, Mohamad Badra &= lt;mbadra@gmail.com> wrote:
=
On Sat, Mar 16, 2013 at 2:31= AM, Juho V=C3=A4h=C3=A4-Herttua <juhovh@iki.fi> wrote:
The discu= ssion here might have been a bit misleading recently. My understanding is th= at the main goal of ALPN is the same as with NPN: allowing the use of "next-= gen" HTTP versions (mainly SPDY and HTTP/2) on the same port as HTTPS, becau= se they serve the same content anyway. So (b) would be closer.

But HTTP allows version negotiation, w= hy should be this brought to the TLS level?

SPDY usually serves HTTP content, but it is not HTTP= compatible on the wire. This means HTTP version negotiation is not relevant= in that case. And as Nico already said, negotiating the version on TLS leve= l saves one extra round trip, which speeds up things.


Juho


= --Apple-Mail-5B788E8C-CB41-4E78-B799-7BF186C62606-- From juhovh@iki.fi Fri Mar 15 16:07:53 2013 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 97C2911E80F6 for ; Fri, 15 Mar 2013 16:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] 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 bnJQdKsa7IjS for ; Fri, 15 Mar 2013 16:07:53 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id A2BDF11E80E3 for ; Fri, 15 Mar 2013 16:07:52 -0700 (PDT) Received: from [10.48.50.76] (188.238.51.76) by jenni2.inet.fi (8.5.140.03) id 50871399093F5570; Sat, 16 Mar 2013 01:07:50 +0200 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <18D51C50-E38D-4F34-BEE5-42202FC7219E@iki.fi> X-Mailer: iPhone Mail (10B146) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= Date: Sat, 16 Mar 2013 01:07:48 +0200 To: Mohamad Badra Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus for ALPN 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, 15 Mar 2013 23:07:53 -0000 On 16.3.2013, at 1.01, Mohamad Badra wrote: > I don't see how a round trip is saved here: HTTP allows their clients to a= dvertise the major version they support in the first request the client send= to the server (e.g. HTTP request). The server replies with the lower of tha= t suggested by the client and the highest supported by the server. This vers= ion negotiation is part of HTTP request/response exchange, so where is the s= aved round trip? This negotiation only works if the first request is HTTP/1.0 compliant. If t= he request format changes, the client has to re-send its request data on ver= sion downgrade. Juho From nico@cryptonector.com Fri Mar 15 16:11:27 2013 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 EBB6311E80FC for ; Fri, 15 Mar 2013 16:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] 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 w9At6mdRrYVR for ; Fri, 15 Mar 2013 16:11:27 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 7F75311E80FB for ; Fri, 15 Mar 2013 16:11:23 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 4F78350808C for ; Fri, 15 Mar 2013 16:11:23 -0700 (PDT) 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=Kawt0ykZNlTGEBN1U7nu6dvobb4=; b=dVNw1JzHghG FUtMziwL5TYfTFASBo9fZyWufA5IY+NScFlLBgmZ+GRmpr6Mg740kUXrsZOjwvrL MmbjpnwMkSmQzdm+gVnjP/YpOU01Xh2sczNR3nh6rXyxpkzgtSlv7GyRUvGuZNzo gi97oIOn6498xXXavKz5RDKZ43h0EnHo= Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id EDF64508072 for ; Fri, 15 Mar 2013 16:11:22 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id t57so3732383wey.27 for ; Fri, 15 Mar 2013 16:11:21 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.119.68 with SMTP id ks4mr14020825wjb.3.1363389081727; Fri, 15 Mar 2013 16:11:21 -0700 (PDT) Received: by 10.216.113.68 with HTTP; Fri, 15 Mar 2013 16:11:21 -0700 (PDT) In-Reply-To: <7F4E2211-C738-443C-8EEF-1C07B28926CB@iki.fi> References: <7F4E2211-C738-443C-8EEF-1C07B28926CB@iki.fi> Date: Fri, 15 Mar 2013 18:11:21 -0500 Message-ID: From: Nico Williams To: =?UTF-8?B?SnVobyBWw6Row6QtSGVydHR1YQ==?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] The consensus is half-mistaken (Re: Confirming consensus for ALPN) 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, 15 Mar 2013 23:11:28 -0000 On Fri, Mar 15, 2013 at 5:54 PM, Juho V=C3=A4h=C3=A4-Herttua wrote: > On 15.3.2013, at 23.59, Nico Williams wrote: >> I do believe NPN is too >> complex, and in that sense the consensus for ALPN is correct. >> >> Can we find a middle of the road? >> >> My compromise proposal is based on providing privacy protection for >> the record type in TLS (post-CCS, of course) -- a feature that should >> be desirable anyways and separately > > I'm sorry to point this out, but I think your proposal is actually much m= ore complex to implement than the NPN proposal. No other extension that I c= an think of have changed the data record format, and mixing data records wi= th handshake packets would need a rather big refactoring at least in my imp= lementation. There'd not be any refactoring: there'd still be a record type, just protec= ted. Nico -- From housley@vigilsec.com Fri Mar 15 16:24:06 2013 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 1D1BC21F84EF for ; Fri, 15 Mar 2013 16:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 YhyAssTG1qGZ for ; Fri, 15 Mar 2013 16:24:05 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE5D21F84E6 for ; Fri, 15 Mar 2013 16:24:05 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 016CF9A409A; Fri, 15 Mar 2013 19:24:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id qdKoIFz+FTDR; Fri, 15 Mar 2013 19:23:59 -0400 (EDT) Received: from [130.129.134.239] (unknown [130.129.134.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id AD0759A4096; Fri, 15 Mar 2013 19:24:03 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Fri, 15 Mar 2013 18:08:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Nico Williams X-Mailer: Apple Mail (2.1085) Cc: tls@ietf.org Subject: Re: [TLS] The consensus is half-mistaken (Re: Confirming consensus for ALPN) 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, 15 Mar 2013 23:24:06 -0000 >> At today's TLS WG f2f meeting we had rough consensus to adopt >> ALPN as the solution to the upper-layer protocol negotiation problem >> posed to us by the HTTP WG. >>=20 >> if you have an opinion on this topic and were not at the meeting, >> please send a message to the mailing list and/or the chairs by >> Friday March 29. >=20 > I believe that privacy protection for as much as possible of the > application layer negotiation is highly desirable. In this sense I > think the consensus for ALPN is mistaken. I do believe NPN is too > complex, and in that sense the consensus for ALPN is correct. >=20 > Can we find a middle of the road? >=20 > My compromise proposal is based on providing privacy protection for > the record type in TLS (post-CCS, of course) -- a feature that should > be desirable anyways and separately (e.g., to hide re-negotiation from > non-MITM middleboxes). Such a feature would allow a post-handshake > non-application-type record for optimistic application protocol > negotiation (zero extra round trips in the optimal case, one more > round trip in the pessimal case). I'd prefer a solution that is architected with this goal in addition to = the original goals of SSL/TLS. I'm concerned that an extension to TLS = 1.2 will be an improvement, but it will be far short of a handshake that = was structured to that set of goals. Russ= From nico@cryptonector.com Fri Mar 15 16:41:00 2013 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 B064021F886D for ; Fri, 15 Mar 2013 16:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.025, 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 6RJvMskUDDUh for ; Fri, 15 Mar 2013 16:40:59 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id D62EC21F886C for ; Fri, 15 Mar 2013 16:40:59 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 8CECC1DE060 for ; Fri, 15 Mar 2013 16:40:59 -0700 (PDT) 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; s=cryptonector.com; bh=XBWdOgijqXULw234dBI/ ADlseWc=; b=AC3fAm1wBL/tf8hBFJAAm1k/pMwRwguYoNqTseD6OVgJAEqZXxDo PJUOI0SWUqPaTpUevJlM6Scj6NjX4m7HzqBx/maXtiNtpYbB9Vga7PpCHrL3m92b 3RNjMAauMbwjDcV6Lg3os/aVd4QxU7lVyHL2jMcfKHTr3yu2Fy9F36I= Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 409511DE05D for ; Fri, 15 Mar 2013 16:40:59 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id e12so3206559wge.10 for ; Fri, 15 Mar 2013 16:40:58 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.73.212 with SMTP id n20mr5952400wiv.11.1363390858024; Fri, 15 Mar 2013 16:40:58 -0700 (PDT) Received: by 10.216.113.68 with HTTP; Fri, 15 Mar 2013 16:40:57 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Mar 2013 18:40:57 -0500 Message-ID: From: Nico Williams To: Russ Housley Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] The consensus is half-mistaken (Re: Confirming consensus for ALPN) 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, 15 Mar 2013 23:41:00 -0000 On Fri, Mar 15, 2013 at 5:08 PM, Russ Housley wrote: >>> At today's TLS WG f2f meeting we had rough consensus to adopt >>> ALPN as the solution to the upper-layer protocol negotiation problem >>> posed to us by the HTTP WG. >>> >>> if you have an opinion on this topic and were not at the meeting, >>> please send a message to the mailing list and/or the chairs by >>> Friday March 29. >> >> I believe that privacy protection for as much as possible of the >> application layer negotiation is highly desirable. In this sense I >> think the consensus for ALPN is mistaken. I do believe NPN is too >> complex, and in that sense the consensus for ALPN is correct. >> >> Can we find a middle of the road? >> >> My compromise proposal is based on providing privacy protection for >> the record type in TLS (post-CCS, of course) -- a feature that should >> be desirable anyways and separately (e.g., to hide re-negotiation from >> non-MITM middleboxes). Such a feature would allow a post-handshake >> non-application-type record for optimistic application protocol >> negotiation (zero extra round trips in the optimal case, one more >> round trip in the pessimal case). > > I'd prefer a solution that is architected with this goal in addition to the original goals of SSL/TLS. I'm concerned that an extension to TLS 1.2 will be an improvement, but it will be far short of a handshake that was structured to that set of goals. OK, but ALPN/NPN are the first extensions that negotiate application-layer things[* ah, not really]. TLS has generally (ignoring BEAST/CRIME/...) intended to protect application data. TLS has even been able to protect user certificates' privacy (module re-nego bug) with the caveat that re-nego happens is externally visible. The point is: providing privacy protection for app data *prior* to handshake completion was never really a goal of TLS. It'd be great to make it a goal _now_. If we want to generally send privacy-protected application data before the handshake completes then we definitely need something along the lines of NPN. I think it's worth having such an extension. Count this as more in favor of NPN than ALPN. Nico -- [*] OK, not really true. There's the authz RFC (RFC5878) and the user mapping RFC (RFC4681). And I proposed an extension (draft-williams-tls-app-sasl-opt) once for negotiating application protocol *and* performing the first round trip of SASL authentication in the TLS handshake. From ynir@checkpoint.com Fri Mar 15 16:46:41 2013 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 9055221F88A3 for ; Fri, 15 Mar 2013 16:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.335 X-Spam-Level: X-Spam-Status: No, score=-10.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 iNHezLdK2P1b for ; Fri, 15 Mar 2013 16:46:41 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id DF70E21F888B for ; Fri, 15 Mar 2013 16:46:38 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2FNkaL1016753; Sat, 16 Mar 2013 01:46:37 +0200 X-CheckPoint: {5143B1EB-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Sat, 16 Mar 2013 01:46:36 +0200 From: Yoav Nir To: Eric Rescorla Thread-Topic: Some missing context (was: Confirming consensus for ALPN) Thread-Index: AQHOIddUmC2U+PwnV061JDLgmuI55w== Date: Fri, 15 Mar 2013 23:46:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.24.85] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3D1B9C4D4EF23F48A2D3C0E2F743B1A5@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: [TLS] Some missing context (was: Confirming consensus for ALPN) 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, 15 Mar 2013 23:46:41 -0000 Hi I think some of the people who were not in the room are missing the context= for this decision. Both NPN and ALPN accomplish the same thing. It is to negotiate the applica= tion level protocol that is going to run on top of TLS. Currently such nego= tiation is planned to distinguish between HTTP/1, HTTP/2, and draft version= s of HTTP/2, but future applications may use this for other protocols (such= as SSL-VPN tunneling clients) The difference between them, is that in ALPN the client proposes a list of = applications, and the server chooses - all in the clear. With NPN, the serv= er advertises a list of applications in the clear, while the client picks o= ne after the CCS - in an encrypted handshake record. There is no question that adding NPN to an existing implementation of TLS r= equires more lines of code.=20 Concerns were raised that middleware might block connections when it doesn'= t like the application chosen by the server in ALPN. With NPN, middleware t= hat is not a full TLS proxy won't know just by looking at the handshake whi= ch protocol was chosen. At the meeting there was no rough consensus for either proposal. There was,= however, rough consensus that making either decision is better than not ma= king a decision. As someone (Sean?) put it, "deciding is more important tha= n winning". This was also the position of the proponents of both proposals.= Given this, we went to an alternate means of making the decision (although= one that was not described in RFC 3929) and voted. The result was 25:!2 in= favor of ALPN. There was also some discussion on the need to encrypt significant parts of = the TLS handshake. This was viewed as orthogonal (no need to encrypt this p= articular piece of data, when other, more sensitive things are still sent i= n the clear) and may or may not be taken up by the group separately. I hope this helps those who were not in the room respond to Ekr's call. Yoav On Mar 15, 2013, at 5:45 PM, Eric Rescorla wrote: > At today's TLS WG f2f meeting we had rough consensus to adopt > ALPN as the solution to the upper-layer protocol negotiation problem > posed to us by the HTTP WG. >=20 > if you have an opinion on this topic and were not at the meeting, > please send a message to the mailing list and/or the chairs by > Friday March 29. >=20 > -Ekr > [For the chairs] From pgut001@cs.auckland.ac.nz Fri Mar 15 18:49:02 2013 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 9AC9A11E8109 for ; Fri, 15 Mar 2013 18:49:02 -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 NDSnfomQjA11 for ; Fri, 15 Mar 2013 18:49:00 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 31E9611E80C5 for ; Fri, 15 Mar 2013 18:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1363398540; x=1394934540; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=hGSaL6d3bAsuLna56PsMOa+3LCKZYiXKQNifBMnzxzc=; b=V//PXsSwBqQtJa5lO6X0QHJGxM41/mS/xAgnDmqYeUcpMM/U/d2whTUR 9py0sDDIgr14cPKu2no5lKT0gk6edlhdjpOrVbg8g1mLDZvebGXj4AI9T Ycp8QzH3UFlPYfAEdnECpvMGhKxWJ3iVDasiy66sL0xWt9Zu5pOWXXpo8 Q=; X-IronPort-AV: E=Sophos;i="4.84,855,1355050800"; d="scan'208";a="175704139" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 16 Mar 2013 14:48:58 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.110]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.004; Sat, 16 Mar 2013 14:48:58 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] The consensus is half-mistaken (Re: Confirming consensus for ALPN) Thread-Index: Ac4h6GyCOfac3fAIRpu2AsNQIOIwLw== Date: Sat, 16 Mar 2013 01:48:57 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73375E1C36@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] The consensus is half-mistaken (Re: Confirming consensus for ALPN) 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: Sat, 16 Mar 2013 01:49:02 -0000 Russ Housley writes:=0A= =0A= >I'd prefer a solution that is architected with this goal in addition to th= e=0A= >original goals of SSL/TLS. I'm concerned that an extension to TLS 1.2 wil= l=0A= >be an improvement, but it will be far short of a handshake that was=0A= >structured to that set of goals.=0A= =0A= My objection is somewhat similar, at the moment ALPN is a one-off kludge (a= s=0A= is NPN). The next time we want to do something like this, we'll have to ad= d=0A= another one-off kludge. And then another. And another. Asking the list t= o=0A= choose between kludge #1 and kludge #2 is kind of misleading when there are= =0A= better ways to do this. I'd really prefer to have some sort of general pos= t-=0A= handshake extension mechanism that can be used, like the existing pre-=0A= handshake extensions, to add all the capabilities that people will dream up= in=0A= the future. Then ALPN just becomes a newly-defined extension, and new=0A= capabilities can be easily added by defining a new extension type.=0A= =0A= Peter.=0A= From pgut001@cs.auckland.ac.nz Fri Mar 15 19:00:32 2013 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 AEC5B11E8111 for ; Fri, 15 Mar 2013 19:00:32 -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 YyZQCaPLo2rg for ; Fri, 15 Mar 2013 19:00:32 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id D9EE911E80C5 for ; Fri, 15 Mar 2013 19:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1363399232; x=1394935232; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=+rUDBN+D73Dwb3T7Y2yFELLsz6osymZUMicjVAaVZcs=; b=q1kXG/WSoADfUbfSOQC7yYIp/uZWB4O3dJLDarsPTPhsAng0Y3jDgdVZ VYlCaKRUr6f4n5oOocr4DFTtSeCYc6wkzSwEvXRStMwV9RTB/QkOR0/rb 1UR0dkEfdSj8aa3GiWIMpTz/1RiyctjImgOhITs+LUvlxi7ddnPMHoJJ3 g=; X-IronPort-AV: E=Sophos;i="4.84,855,1355050800"; d="scan'208";a="175704585" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 16 Mar 2013 15:00:31 +1300 Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe2.UoA.auckland.ac.nz (130.216.4.106) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sat, 16 Mar 2013 15:00:30 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.110]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Sat, 16 Mar 2013 15:00:31 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] Some missing context (was: Confirming consensus for ALPN) Thread-Index: Ac4h6gly76FDqRQlQ86PD2w9NTgpMw== Date: Sat, 16 Mar 2013 02:00:30 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73375E1C53@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] Some missing context (was: Confirming consensus for ALPN) 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: Sat, 16 Mar 2013 02:00:32 -0000 Yoav Nir writes:=0A= =0A= >The difference between them, is that in ALPN the client proposes a list of= =0A= >applications, and the server chooses - all in the clear. With NPN, the ser= ver=0A= >advertises a list of applications in the clear, while the client picks one= =0A= >after the CCS - in an encrypted handshake record.=0A= =0A= Thus my earlier comment that I vote for none of the above. Both expose the= =0A= details of the further negotiation that's going on, and neither can be=0A= generalised to server other purposes than protocol-negotiation.=0A= =0A= Peter.=0A= From ynir@checkpoint.com Fri Mar 15 19:05:56 2013 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 D23281F0D2D for ; Fri, 15 Mar 2013 19:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.357 X-Spam-Level: X-Spam-Status: No, score=-10.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 N555TAGLHfCi for ; Fri, 15 Mar 2013 19:05:56 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id EDCD01F0D0E for ; Fri, 15 Mar 2013 19:05:55 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2G25nc2029370; Sat, 16 Mar 2013 04:05:49 +0200 X-CheckPoint: {5143D28A-2-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Sat, 16 Mar 2013 04:05:49 +0200 From: Yoav Nir To: Peter Gutmann Thread-Topic: [TLS] Some missing context (was: Confirming consensus for ALPN) Thread-Index: Ac4h6gly76FDqRQlQ86PD2w9NTgpM///3/KA Date: Sat, 16 Mar 2013 02:05:48 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C73375E1C53@uxcn10-2.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73375E1C53@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.24.138] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <96BBB41D2C83D846B96BA0BD1C138B47@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Some missing context (was: Confirming consensus for ALPN) 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: Sat, 16 Mar 2013 02:05:56 -0000 On Mar 15, 2013, at 10:00 PM, Peter Gutmann wrote: > Yoav Nir writes: >=20 >> The difference between them, is that in ALPN the client proposes a list = of >> applications, and the server chooses - all in the clear. With NPN, the s= erver >> advertises a list of applications in the clear, while the client picks o= ne >> after the CCS - in an encrypted handshake record. >=20 > Thus my earlier comment that I vote for none of the above. Both expose t= he > details of the further negotiation that's going on, and neither can be > generalised to server other purposes than protocol-negotiation. Well, the NPN people think their mechanism can be generalized to other exte= nsions in that post-CCS handshake message. But perhaps this should be left = to TLS 1.3 The one thing we had consensus on in the room was that "none of the above" = was not an option, and neither was anything that would require another roun= d-trip.= From Andrei.Popov@microsoft.com Fri Mar 15 19:39:22 2013 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 31BAA11E80E0 for ; Fri, 15 Mar 2013 19:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.534 X-Spam-Level: X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132] 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 dBBvW7GJHBtP for ; Fri, 15 Mar 2013 19:39:21 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id C724D11E80D3 for ; Fri, 15 Mar 2013 19:39:20 -0700 (PDT) Received: from BL2FFO11FD011.protection.gbl (10.173.161.203) by BL2FFO11HUB007.protection.gbl (10.173.160.227) with Microsoft SMTP Server (TLS) id 15.0.641.9; Sat, 16 Mar 2013 02:33:48 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD011.mail.protection.outlook.com (10.173.161.17) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Sat, 16 Mar 2013 02:33:48 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.318.3; Sat, 16 Mar 2013 02:33:47 +0000 Received: from mail106-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Sat, 16 Mar 2013 02:33:46 +0000 Received: from mail106-ch1 (localhost [127.0.0.1]) by mail106-ch1-R.bigfish.com (Postfix) with ESMTP id CE885140124 for ; Sat, 16 Mar 2013 02:33:45 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -20 X-BigFish: PS-20(zzbb2dI9371Ic85fhzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dh18c673h8275bhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah9a9j1155h) Received-SPF: softfail (mail106-ch1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=Andrei.Popov@microsoft.com; helo=BL2PRD0310HT001.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BN1PR03MB072; H:BN1PR03MB072.namprd03.prod.outlook.com; LANG:en; Received: from mail106-ch1 (localhost.localdomain [127.0.0.1]) by mail106-ch1 (MessageSwitch) id 1363401189913259_3971; Sat, 16 Mar 2013 02:33:09 +0000 (UTC) Received: from CH1EHSMHS031.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.239]) by mail106-ch1.bigfish.com (Postfix) with ESMTP id CB51C2400C2; Sat, 16 Mar 2013 02:33:07 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS031.bigfish.com (10.43.70.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 16 Mar 2013 02:33:02 +0000 Received: from BN1PR03MB072.namprd03.prod.outlook.com (10.255.225.156) by BL2PRD0310HT001.namprd03.prod.outlook.com (10.255.97.36) with Microsoft SMTP Server (TLS) id 14.16.287.2; Sat, 16 Mar 2013 02:33:01 +0000 Received: from BN1PR03MB072.namprd03.prod.outlook.com (10.255.225.156) by BN1PR03MB072.namprd03.prod.outlook.com (10.255.225.156) with Microsoft SMTP Server (TLS) id 15.0.620.20; Sat, 16 Mar 2013 02:33:00 +0000 Received: from BN1PR03MB072.namprd03.prod.outlook.com ([169.254.7.102]) by BN1PR03MB072.namprd03.prod.outlook.com ([169.254.7.102]) with mapi id 15.00.0620.020; Sat, 16 Mar 2013 02:33:00 +0000 From: Andrei Popov To: Peter Gutmann , "tls@ietf.org" Thread-Topic: [TLS] The consensus is half-mistaken (Re: Confirming consensus for ALPN) Thread-Index: Ac4h6GyC3yD66VskgEuQrQQ/bmCs4QABibZv Date: Sat, 16 Mar 2013 02:32:59 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C73375E1C36@uxcn10-2.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73375E1C36@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [32.165.144.38] Content-Type: multipart/alternative; boundary="_000_e670321c6c4142babbf1e4acf570e152BN1PR03MB072namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BN1PR03MB072.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CS.AUCKLAND.AC.NZ$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC104.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(479174001)(189002)(377454001)(47446002)(50986001)(51856001)(63696002)(20776003)(66066001)(74502001)(80022001)(512954001)(16676001)(53806001)(74662001)(76482001)(54316002)(44976002)(49866001)(47976001)(69226001)(54356001)(6806001)(33646001)(46102001)(59766001)(65816001)(4396001)(56816002)(77982001)(5343635001)(16236675001)(79102001)(47736001)(56776001)(31966008)(5343655001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB007; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0787459938 Subject: Re: [TLS] The consensus is half-mistaken (Re: Confirming consensus for ALPN) 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: Sat, 16 Mar 2013 02:39:22 -0000 --_000_e670321c6c4142babbf1e4acf570e152BN1PR03MB072namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't think ALPN or NPN should be general extension mechanisms. Instead w= e can define a general mechanism for TLS handshake confidentiality (which w= ould also cover ALPN). Cheers, Andrei Sent from my Windows Phone ________________________________ From: Peter Gutmann Sent: 3/15/2013 8:49 PM To: tls@ietf.org Subject: Re: [TLS] The consensus is half-mistaken (Re: Confirming consensus= for ALPN) Russ Housley writes: >I'd prefer a solution that is architected with this goal in addition to th= e >original goals of SSL/TLS. I'm concerned that an extension to TLS 1.2 wil= l >be an improvement, but it will be far short of a handshake that was >structured to that set of goals. My objection is somewhat similar, at the moment ALPN is a one-off kludge (a= s is NPN). The next time we want to do something like this, we'll have to ad= d another one-off kludge. And then another. And another. Asking the list t= o choose between kludge #1 and kludge #2 is kind of misleading when there are better ways to do this. I'd really prefer to have some sort of general pos= t- handshake extension mechanism that can be used, like the existing pre- handshake extensions, to add all the capabilities that people will dream up= in the future. Then ALPN just becomes a newly-defined extension, and new capabilities can be easily added by defining a new extension type. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_e670321c6c4142babbf1e4acf570e152BN1PR03MB072namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I don't think= ALPN or NPN should be general extension mechanisms. Instead we can define = a general mechanism for TLS handshake confidentiality (which would also cov= er ALPN).

Cheers,

Andrei

Sent from my Windows Phone
From: Peter = Gutmann
Sent: 3/15/2= 013 8:49 PM
To: tls@ie= tf.org
Subject: Re: [T= LS] The consensus is half-mistaken (Re: Confirming consensus for ALPN)

Russ Housley <housley@vigilsec.com> writes:<= br>
>I'd prefer a solution that is architected with this goal in addition to= the
>original goals of SSL/TLS.  I'm concerned that an extension to TLS= 1.2 will
>be an improvement, but it will be far short of a handshake that was
>structured to that set of goals.

My objection is somewhat similar, at the moment ALPN is a one-off kludge (a= s
is NPN).  The next time we want to do something like this, we'll have = to add
another one-off kludge.  And then another.  And another.  As= king the list to
choose between kludge #1 and kludge #2 is kind of misleading when there are=
better ways to do this.  I'd really prefer to have some sort of genera= l post-
handshake extension mechanism that can be used, like the existing pre-
handshake extensions, to add all the capabilities that people will dream up= in
the future.  Then ALPN just becomes a newly-defined extension, and new=
capabilities can be easily added by defining a new extension type.

Peter.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/= mailman/listinfo/tls


 --_000_e670321c6c4142babbf1e4acf570e152BN1PR03MB072namprd03pro_-- From tom@ritter.vg Sat Mar 16 08:47:57 2013 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 7729621F89C3 for ; Sat, 16 Mar 2013 08:47: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 CE02K5+402lO for ; Sat, 16 Mar 2013 08:47:56 -0700 (PDT) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id A092F21F89BA for ; Sat, 16 Mar 2013 08:47:56 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id uo15so5101987pbc.19 for ; Sat, 16 Mar 2013 08:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=ndIATEnJCN82Cnm6jSGiePol/zly2NT5tgapwk23IlY=; b=TsVSOs10iQezQl58MqjTiz4+4BKbfcf7rMnBEWZi5AzQjITsnfLCaLtPBQuls3X8C6 /ilZXAUzEWu42JDLOUtGpYYe1hKyCiW0ygb0S4cQaZOIxj+7QJbv8aZbgk4KbRJKx7SV L3qjPr4SzJD0W82HR8PkKOI5whhroL0P/JN8w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=ndIATEnJCN82Cnm6jSGiePol/zly2NT5tgapwk23IlY=; b=Ve2+x2eWLQMpz12VPvKdjyg4HB0wy0TE60pBXZOqOQYmNLaNs0DY2E4L6zvMm+gyNR fP4CAxbe3OuEv0V14prWlcCjW3pI39nrEndkQqVR6jHUeE1FXKmmMjsSzEn0ALw+PVdu yVP3PnukjhVoO07cUg3ht1zZhjegzg46TtTQ/a7+/+1lslCOwEWgwWwUVYeP/9sfqBdO nnTN+zY/d9K3nq+Ph6eNL8z2KJBKUo7NhbAUw+tcaULPtozf7G0UtMXQL86FtzJ7zZ93 LoJfMM+IQ/qJ18phtQTFSBS4Z+T5n/dGAZe5DkoMMad1MmsAvVgTI8YFRQu3Bn0CSKSt FuwQ== X-Received: by 10.69.3.97 with SMTP id bv1mr24996557pbd.73.1363448876360; Sat, 16 Mar 2013 08:47:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.201 with HTTP; Sat, 16 Mar 2013 08:47:36 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73375E1C36@uxcn10-2.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73375E1C36@uxcn10-2.UoA.auckland.ac.nz> From: Tom Ritter Date: Sat, 16 Mar 2013 11:47:36 -0400 Message-ID: To: Peter Gutmann Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkdap4lBTToXmmNu+ysJLlPNfnqJASj7hHShZ5QpcX1Y/Qvk2UTRjp9F8CpHd0iS6khtoMh Cc: "tls@ietf.org" Subject: Re: [TLS] The consensus is half-mistaken (Re: Confirming consensus for ALPN) 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: Sat, 16 Mar 2013 15:47:57 -0000 On 15 March 2013 21:48, Peter Gutmann wrote: > My objection is somewhat similar, at the moment ALPN is a one-off kludge (as > is NPN). The next time we want to do something like this, we'll have to add > another one-off kludge. And then another. And another. Asking the list to > choose between kludge #1 and kludge #2 is kind of misleading when there are > better ways to do this. I'd really prefer to have some sort of general post- > handshake extension mechanism that can be used, like the existing pre- > handshake extensions, to add all the capabilities that people will dream up in > the future. Then ALPN just becomes a newly-defined extension, and new > capabilities can be easily added by defining a new extension type. I register my agreement. -tom From turners@ieca.com Sun Mar 17 14:44:41 2013 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 38B6D21F8AC8 for ; Sun, 17 Mar 2013 14:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.745 X-Spam-Level: X-Spam-Status: No, score=-101.745 tagged_above=-999 required=5 tests=[AWL=0.520, 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 TKj1sSk7Q1a8 for ; Sun, 17 Mar 2013 14:44:36 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.206.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBA421F8821 for ; Sun, 17 Mar 2013 14:44:35 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 091048B5E7CF4; Sun, 17 Mar 2013 16:44:12 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id ECFC18B5E7CAD for ; Sun, 17 Mar 2013 16:44:11 -0500 (CDT) Received: from [198.180.150.142] (port=54194 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UHLNa-0000fc-SS; Sun, 17 Mar 2013 16:44:34 -0500 Message-ID: <51463941.5040903@ieca.com> Date: Sun, 17 Mar 2013 17:44:33 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Yoav Nir References: In-Reply-To: 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) [198.180.150.142]:54194 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "" Subject: Re: [TLS] Some missing context 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: Sun, 17 Mar 2013 21:44:41 -0000 Hums were taken on ALPN or NPN. After everybody chuckled about it being close. I agreed with Joe that there was a discernible preference for ALPN. I guess the next bit is where we differ. I think a show of hands is just another method the WG chairs can use to determine rough consensus, as documented in RFC 2818. Sure I counted 'em but just standing there looking at the room it was a clear 2/1 ratio for ALPN and that I'd argue that was rough consensus in the room. Then, the chairs took it to the list to confirm it on the list. spt On 3/15/13 7:46 PM, Yoav Nir wrote: > Hi > > I think some of the people who were not in the room are missing the context for this decision. > > Both NPN and ALPN accomplish the same thing. It is to negotiate the application level protocol that is going to run on top of TLS. Currently such negotiation is planned to distinguish between HTTP/1, HTTP/2, and draft versions of HTTP/2, but future applications may use this for other protocols (such as SSL-VPN tunneling clients) > > The difference between them, is that in ALPN the client proposes a list of applications, and the server chooses - all in the clear. With NPN, the server advertises a list of applications in the clear, while the client picks one after the CCS - in an encrypted handshake record. > > There is no question that adding NPN to an existing implementation of TLS requires more lines of code. > > Concerns were raised that middleware might block connections when it doesn't like the application chosen by the server in ALPN. With NPN, middleware that is not a full TLS proxy won't know just by looking at the handshake which protocol was chosen. > > At the meeting there was no rough consensus for either proposal. There was, however, rough consensus that making either decision is better than not making a decision. As someone (Sean?) put it, "deciding is more important than winning". This was also the position of the proponents of both proposals. Given this, we went to an alternate means of making the decision (although one that was not described in RFC 3929) and voted. The result was 25:!2 in favor of ALPN. > > There was also some discussion on the need to encrypt significant parts of the TLS handshake. This was viewed as orthogonal (no need to encrypt this particular piece of data, when other, more sensitive things are still sent in the clear) and may or may not be taken up by the group separately. > > I hope this helps those who were not in the room respond to Ekr's call. > > Yoav > > On Mar 15, 2013, at 5:45 PM, Eric Rescorla wrote: > >> At today's TLS WG f2f meeting we had rough consensus to adopt >> ALPN as the solution to the upper-layer protocol negotiation problem >> posed to us by the HTTP WG. >> >> if you have an opinion on this topic and were not at the meeting, >> please send a message to the mailing list and/or the chairs by >> Friday March 29. >> >> -Ekr >> [For the chairs] > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From simon@josefsson.org Sun Mar 17 15:52:09 2013 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 B882221F874F for ; Sun, 17 Mar 2013 15:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, 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 0xFA43uupiwf for ; Sun, 17 Mar 2013 15:52:08 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4365B21F8801 for ; Sun, 17 Mar 2013 15:52:06 -0700 (PDT) Received: from latte.josefsson.org (host-95-192-103-177.mobileonline.telia.com [95.192.103.177]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r2HMpsDw016861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 17 Mar 2013 23:51:56 +0100 X-Hashcash: 1:22:130317:tls@ietf.org::1xhQVf0XqbSFqu9s:d3LL X-Hashcash: 1:22:130317:joachim@secworks.se::oJPDICZ6Hl0+I6FK:3MTH X-Hashcash: 1:22:130317:nmav@gnutls.org::2d9BU0ro0cTG6/kh:1wcl From: Simon Josefsson To: tls@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Sun, 17 Mar 2013 23:51:49 +0100 Message-ID: <87ppyxhc6y.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: joachim@secworks.se Subject: [TLS] Salsa20 stream cipher in TLS 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: Sun, 17 Mar 2013 22:52:09 -0000 All, FYI, we have published -00 of a draft that describes how the Salsa20 stream cipher can be added to TLS and DTLS, see: http://tools.ietf.org/html/draft-josefsson-salsa20-tls While we are not asking for WG adoption of this draft now, we are at a point where we would like to invite external review and solicit feedback. Some elements of the draft is still in flux. For example, initial performance benchmarks suggests HMAC-SHA256 was a poor choice for the MAC so we are looking into UMAC and HMAC-SHA1 as alternatives. Still, all comments are appreciated. /Simon From rob.stradling@comodo.com Mon Mar 18 06:06:16 2013 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 51F2C21F8DA2 for ; Mon, 18 Mar 2013 06:06:16 -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 TFM+twlda39G for ; Mon, 18 Mar 2013 06:06:15 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0E19321F8DAB for ; Mon, 18 Mar 2013 06:06:14 -0700 (PDT) Received: (qmail 12917 invoked from network); 18 Mar 2013 13:06:05 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 18 Mar 2013 13:06:05 -0000 Received: (qmail 24239 invoked by uid 1000); 18 Mar 2013 13:06:05 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Mon, 18 Mar 2013 13:06:05 +0000 Message-ID: <5147113D.2070304@comodo.com> Date: Mon, 18 Mar 2013 13:06:05 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: tls@ietf.org References: <4EF84292.50201@gmx.net> <4F2FC5AA.5070600@comodo.com> <7E329BCB-EFA1-423B-8F20-F6EA382D2901@gmx.net> In-Reply-To: <7E329BCB-EFA1-423B-8F20-F6EA382D2901@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [TLS] cached-info and multiple-ocsp 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, 18 Mar 2013 13:06:16 -0000 Hannes, Stefan, I see that draft-ietf-tls-cached-info-13 expired a couple of days ago. Does this WG still intend to progress cached-info to RFC status? On 13/07/12 10:40, Hannes Tschofenig wrote: >> Or, is it your explicit intention to restrict cached-info so that it only supports the "standard" TLS handshake objects (e.g. Certificate, Trusted CAs list). >> (I can see that such a restriction could help to ensure that client-side code can be implemented entirely within the network layer rather than bleeding into the application layer). > > There is no intention to restrict the functionality to certain extensions. > > I do, however, believe that new documents should add a description to their document how this document could be used in combination with the TLS cached information extension. > > I don't think it makes sense to add text about, for example, draft-pettersen-tls-ext-multiple-ocsp when that work is still in progress. Since multiple-ocsp is currently in IESG call, it seems likely that multiple-ocsp will reach RFC status before cached-info. Therefore, please could text be added to cached-info to specify its use with both of the CertificateStatus extensions (RFC6066 and multiple-ocsp) ? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From jsalowey@cisco.com Mon Mar 18 08:18:24 2013 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 0759821F8EE7 for ; Mon, 18 Mar 2013 08:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 T+5P86bOs0SC for ; Mon, 18 Mar 2013 08:18:23 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5C721F8C8F for ; Mon, 18 Mar 2013 08:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1836; q=dns/txt; s=iport; t=1363619903; x=1364829503; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pLt69oSesEtYAszrCdX+P0QyXBM9qLT+7y/M2m6ROkw=; b=iHHdY60/IZNRDro4SsqegPECNL1OPawN7HhJ8CJim7sZ6WVP7eL1h8Fl hFGIMuTGfGX4zWAw36TViJg1TpxAymWyurifjLhd+Gm96OX/O3cfcZohQ lEbCfUNhGQbBq8FIEg1OXrLunNgLf0u8s9ZO36zxEmAD3uiOfZbS5TbVq Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABEwR1GtJV2d/2dsb2JhbABDxR2BUhZ0giQBAQEDAQEBATc0CwULAgEIGAoUECcLJQIEDgUIiAYGDMIPBI5iAjEHgl9hA6BYhwiDCoIo X-IronPort-AV: E=Sophos;i="4.84,865,1355097600"; d="scan'208";a="188661344" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 18 Mar 2013 15:18:15 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2IFIEUp032082 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Mar 2013 15:18:14 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 10:18:14 -0500 From: "Joseph Salowey (jsalowey)" To: Rob Stradling Thread-Topic: [TLS] cached-info and multiple-ocsp Thread-Index: AQHOI9li+Sa2vzndl0GpVHcsZQF55Zir470A Date: Mon, 18 Mar 2013 15:18:14 +0000 Message-ID: References: <4EF84292.50201@gmx.net> <4F2FC5AA.5070600@comodo.com> <7E329BCB-EFA1-423B-8F20-F6EA382D2901@gmx.net> <5147113D.2070304@comodo.com> In-Reply-To: <5147113D.2070304@comodo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.151] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [TLS] cached-info and multiple-ocsp 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, 18 Mar 2013 15:18:24 -0000 Hi Rob, We still plan on moving this draft forward. A revision is in the works. P= lease work with the authors to define some candidate text for multi-OCSP. Thanks, Joe On Mar 18, 2013, at 6:06 AM, Rob Stradling wrote= : > Hannes, Stefan, >=20 > I see that draft-ietf-tls-cached-info-13 expired a couple of days ago. >=20 > Does this WG still intend to progress cached-info to RFC status? >=20 > On 13/07/12 10:40, Hannes Tschofenig wrote: > >>> Or, is it your explicit intention to restrict cached-info so that it on= ly supports the "standard" TLS handshake objects (e.g. Certificate, Trusted= CAs list). >>> (I can see that such a restriction could help to ensure that client-sid= e code can be implemented entirely within the network layer rather than ble= eding into the application layer). >>=20 >> There is no intention to restrict the functionality to certain extension= s. >>=20 >> I do, however, believe that new documents should add a description to th= eir document how this document could be used in combination with the TLS ca= ched information extension. >>=20 >> I don't think it makes sense to add text about, for example, draft-pette= rsen-tls-ext-multiple-ocsp when that work is still in progress. >=20 > Since multiple-ocsp is currently in IESG call, it seems likely that multi= ple-ocsp will reach RFC status before cached-info. >=20 > Therefore, please could text be added to cached-info to specify its use w= ith both of the CertificateStatus extensions (RFC6066 and multiple-ocsp) ? >=20 > --=20 > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mcgrew@cisco.com Mon Mar 18 12:25:10 2013 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 568DB21F8606 for ; Mon, 18 Mar 2013 12:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 hNDhspyt+YR6 for ; Mon, 18 Mar 2013 12:25:00 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1451521F86B2 for ; Mon, 18 Mar 2013 12:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2652; q=dns/txt; s=iport; t=1363634630; x=1364844230; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8vehR51qWhLI+badoKnlpXr05HUhctN0m30MFDYIVLc=; b=R62FaZ29XH2yLiJn/MJJdaVkDMkhpXhdCiVM0HTId6oMCYOogjqwCCZM rgdBVr6mvwF8f20tpsRlBamNREhkDaOqFEIvzmKCWbBqHoJ9TGosFP6cB 0mH1UAaOe+CpBYU2O8T1LCdRfTpuLaRkNaMD+WBE0JvV163H9MEDtwCrZ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFABFpR1GtJXG+/2dsb2JhbABDxSGBVhZ0giYBBAEBATc0CxIBCCIUNwslAgQOBQgMiAAMwhaOZDEHgl9hA5d9j2ODCoIo X-IronPort-AV: E=Sophos;i="4.84,865,1355097600"; d="scan'208";a="188805962" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 18 Mar 2013 19:23:42 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2IJNg9u029822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Mar 2013 19:23:42 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 14:23:42 -0500 From: "David McGrew (mcgrew)" To: Simon Josefsson Thread-Topic: [TLS] Salsa20 stream cipher in TLS Thread-Index: AQHOI2IRfwT9uKfaFUuf1DQlms1pvpir5i+A Date: Mon, 18 Mar 2013 19:23:41 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B183EB8AD@xmb-rcd-x04.cisco.com> In-Reply-To: <87ppyxhc6y.fsf@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [TLS] Salsa20 stream cipher in TLS 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, 18 Mar 2013 19:25:10 -0000 Hi Simon, On 3/17/13 6:51 PM, "Simon Josefsson" wrote: >All, > >FYI, we have published -00 of a draft that describes how the Salsa20 >stream cipher can be added to TLS and DTLS, see: > >http://tools.ietf.org/html/draft-josefsson-salsa20-tls > >While we are not asking for WG adoption of this draft now, we are at a >point where we would like to invite external review and solicit >feedback. =20 Some early feedback; copied CFRG. It would be good to have review from that community. It is not exactly clear what problem is being addressed by this work. Would be good to add a problem statement section. In addition, it would be good to provide the currently-unmet requirements to CAESAR (Competition for Authenticated Encryption: Security, Applicability, and Robustness) http://competitions.cr.yp.to/ Some more detailed comments, quoting from the draft: Recent attacks has indicated problems with CBC-mode cipher suites in TLS/DTLS and problems with the only supported stream cipher (RC4) in TLS has been known for a long time. While AEAD cipher suites address these issues, concerns about performance are sometimes raised. What are the performance concerns? I suggest citing some relevant performance data. Because the GenericStreamCipher definition in TLS does not provide any way to transport the Salsa20 nonce that is required for functionality and needed to provide the random access property, we let the output from the stream cipher operation be the concatenation of the IV and the encrypted data. Please, define a Salsa20-based AEAD mechanism instead of a new TLS format! =20 >Some elements of the draft is still in flux. For example, >initial performance benchmarks suggests HMAC-SHA256 was a poor choice >for the MAC so we are looking into UMAC and HMAC-SHA1 as alternatives. >Still, all comments are appreciated. If anything other than HMAC-SHA1 is used, that would underscore the value of defining an AEAD algorithm. If the main motivation for this work is encryption that is computationally cheap, then it makes sense to pair the algorithm with an authentication method with the same characteristics. For security considerations, I suggest citing the analysis of Salsa20, and adding a sentence or paragraph summarizing the best-known attacks. Something like "Salsa20 has been analyzed by X independent teams, and the best known attack breaks 8 of 20 rounds." David > >/Simon >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From wtc@google.com Mon Mar 18 12:49:13 2013 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 B860E21F904B for ; Mon, 18 Mar 2013 12:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, 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 isVjVdicPj1a for ; Mon, 18 Mar 2013 12:49:05 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id C7A3221F8FAC for ; Mon, 18 Mar 2013 12:48:51 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id k11so7442274iea.38 for ; Mon, 18 Mar 2013 12:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ptXySJh+gW1crGcIb+mifuN/1RadHY9lXYZg31IxYpo=; b=hZdsJ/UBS+kKMG/Rz7oVxGnlkp9mI2+nlSn74jDNq7nEHVgurYtnpsHbD+W/GE24W3 dSJz6wKakT1iN1mWkt82zHG2OCGqUAbeVSaTU2mZeJENrg9ESbx6oKaYaBB8TTp+uKXr 5LR1riMjgS3jK2IKbVUWLl8MadCurXnrrCSAdEwmyKVaUWtN1vRq3CBZcqR+OJsYVf9K ufUZa6lMnCDlbcPbWL9XB22FQBPiFt8O3xdN9H0NI62weXptEc2G/FBy02fAV6JnnBmv eM8ukZp7SvSxohyleQ+Qn/b+HW8cc1B9BBN8cVhSLDc0GQ3MPmUKjpV20KX6exWDgiX1 kPKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=ptXySJh+gW1crGcIb+mifuN/1RadHY9lXYZg31IxYpo=; b=Uqk0dixlC9nzjv+kVEQ7FZZjPSI/AasMJpfL647CyFpBZXm/T5cxf0/IChlfbtUEI2 l3kR9kEQgd6RvfpiLrej/+wHlHDzzrXg+/1ItJXQM+asIGI//NA90nQWZV61Ou9Ga6xy R6xFyNu3oWcPUqwsNKGnRKfIW7xmfY30eXW37Vpc6Lc9izNWKmhr1UiLj7P/s2zoy3Qb ERfzsXJnegYXlao2gJ7hT8KU8a16huDYeJNo9dgpIOPV5BavYyAMor9MSK5A/URU8T9o pu1wLH9t+4ply3zVOUsdaqhlcNhWs73BU1/XAmS4DN3AR3SkvWxpUTmOC6rO7DkUuD5Z jWjQ== MIME-Version: 1.0 X-Received: by 10.50.152.229 with SMTP id vb5mr125374igb.56.1363636131204; Mon, 18 Mar 2013 12:48:51 -0700 (PDT) Received: by 10.231.112.2 with HTTP; Mon, 18 Mar 2013 12:48:51 -0700 (PDT) In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B183EB8AD@xmb-rcd-x04.cisco.com> References: <87ppyxhc6y.fsf@latte.josefsson.org> <747787E65E3FBD4E93F0EB2F14DB556B183EB8AD@xmb-rcd-x04.cisco.com> Date: Mon, 18 Mar 2013 12:48:51 -0700 Message-ID: From: Wan-Teh Chang To: "David McGrew (mcgrew)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnHVS/ffbVpMxgAAUD6fGyWHO4b4jJ7R0Jvux4NOZC7yv4UpHZ78FB/TD7Tfr434UFlrCvWxPD0u2syQKmvm3X1HCdOogAy0WkBwfuokbgx6jj6wwmnJXYQc00BdsZYNag3wx3uLuBY39dYJWxxnXLmaFh37Ver9fV4FyesdDL/F9enL6ZZXJrwwkb5zGxafxAsj4Vb Cc: Simon Josefsson , "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [TLS] Salsa20 stream cipher in TLS 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, 18 Mar 2013 19:49:13 -0000 On Sun, Mar 17, 2013 at 3:51 PM, Simon Josefsson wrote: > All, > > FYI, we have published -00 of a draft that describes how the Salsa20 > stream cipher can be added to TLS and DTLS, see: > > http://tools.ietf.org/html/draft-josefsson-salsa20-tls Hi Simon, I am interested in this work. I am especially interested in your plan to allow the salsa20 cipher suites to be used in TLS 1.0 and TLS 1.1, which you stated in the first paragraph of the Introduction section. Since all of the new cipher suite names end in _SHA256, I infer the MAC algorithm is hmac_sha256. (The fact is not explicitly stated in the -00 draft.) It is important to clarify how hmac_sha256 can be used in TLS 1.0 and TLS 1.1, because a naive implementor would see the old definition of MACAlgorithm in TLS 1.0 and 1.1: enum { null, md5, sha } MACAlgorithm; and conclude that hmac_sha256 can't be used in TLS 1.0 and 1.1. I'm also interested in figuring out if these cipher suites can be used in SSL 3.0. The only difficulty I see is extending the SSL 3.0 MAC algorithm to hash=sha256 (see the definition of the SSL 3.0 MAC in Section 5.2.3.1 of RFC 6101) -- it is not clear what should be the size of pad_1 and pad_2 for hash=sha256. The reason I'm interested in SSL 3.0 is that web browsers, when talking to Google servers, which implement TLS/SSL version negotiation correctly, are still downgraded to SSL 3.0 by network errors injected by certain network devices. Wan-Teh From n.mavrogiannopoulos@gmail.com Mon Mar 18 13:02:33 2013 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 C7CA321F8F87 for ; Mon, 18 Mar 2013 13:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.681 X-Spam-Level: X-Spam-Status: No, score=-2.681 tagged_above=-999 required=5 tests=[AWL=0.918, 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 ZXNhzB51DfXO for ; Mon, 18 Mar 2013 13:02:30 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC5521F8F0C for ; Mon, 18 Mar 2013 13:02:30 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id dr13so5418915wgb.14 for ; Mon, 18 Mar 2013 13:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received: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=jvrNs2o5ggiKHKlWRUDJxDxPG3viPK242oqH3+MMnaA=; b=WRjaDBLKYfIPIf+nk4M++7XbLknSWYAdjHFpJC2rdiVPe6VLwd1ZwQfPo8LufRyZLT 7TZscKZkpW0HsLlYVmGDpEPQs8d3BEnCngcZi4H7PE2lkf9a0mUk00GV2Rc3wy3v0JyK E4X5BDd+8y2U2igeCpJr+WmSv26mW3BUB0UOIZhDZpDB3zOuPotmLBaGEjVGOOMK0+id iiREGKDoC79DevwlmGvjlRZPg6M54xIw0Sw81/q1L5tdp+U3J6Ak5J2bODwg2gnJBrOQ 5yYRlKUjcfCHOAJ+GZdaQgBAMKdtqW2kzvcxuEzx00Ys+wNn8QieC4gH3lkNAiWTlFQi LLPA== X-Received: by 10.194.57.137 with SMTP id i9mr27754481wjq.18.1363636949297; Mon, 18 Mar 2013 13:02:29 -0700 (PDT) Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id f1sm15621675wib.0.2013.03.18.13.02.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Mar 2013 13:02:28 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <514772CE.4060300@gnutls.org> Date: Mon, 18 Mar 2013 21:02:22 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: "David McGrew (mcgrew)" References: <747787E65E3FBD4E93F0EB2F14DB556B183EB8AD@xmb-rcd-x04.cisco.com> In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B183EB8AD@xmb-rcd-x04.cisco.com> X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Simon Josefsson , "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [TLS] Salsa20 stream cipher in TLS 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, 18 Mar 2013 20:02:34 -0000 On 03/18/2013 08:23 PM, David McGrew (mcgrew) wrote: > Hi Simon, > > On 3/17/13 6:51 PM, "Simon Josefsson" wrote: > >> All, >> >> FYI, we have published -00 of a draft that describes how the Salsa20 >> stream cipher can be added to TLS and DTLS, see: >> >> http://tools.ietf.org/html/draft-josefsson-salsa20-tls >> >> While we are not asking for WG adoption of this draft now, we are at a >> point where we would like to invite external review and solicit >> feedback. > > Some early feedback; copied CFRG. It would be good to have review from > that community. > It is not exactly clear what problem is being addressed by this work. As I understand, the requirement, is a fast stream cipher that can be used for TLS and DTLS, and doesn't have the issues RC4 has [0]. [0]. http://home.hiroshima-u.ac.jp/ohigashi/rc4/index.html > Some more detailed comments, quoting from the draft: > What are the performance concerns? I suggest citing some relevant > performance data. The GCM mode does require special instructions to achieve performance close (but often not better) to RC4 in general purpose CPUs. The stream ciphers from the eStream competition outperform RC4 without any hw assistance. > Because the GenericStreamCipher definition in TLS does not provide > any way to transport the Salsa20 nonce that is required for > functionality and needed to provide the random access property, we > let the output from the stream cipher operation be the concatenation > of the IV and the encrypted data. > Please, define a Salsa20-based AEAD mechanism instead of a new TLS format! The GenericStreamCipher mode is sufficient for this mode. It just requires to define how to set the nonce. I think using the AEAD would complicate things rather than provide any practical advantage. regards, Nikos From simon@josefsson.org Mon Mar 18 13:42:33 2013 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 F3C1C11E80CC; Mon, 18 Mar 2013 13:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, 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 PXsO-wceCunr; Mon, 18 Mar 2013 13:42:32 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id EF48E11E80BA; Mon, 18 Mar 2013 13:42:30 -0700 (PDT) Received: from latte.josefsson.org (host-95-192-103-177.mobileonline.telia.com [95.192.103.177]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r2IKgIXx008663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Mar 2013 21:42:21 +0100 From: Simon Josefsson To: "David McGrew \(mcgrew\)" References: <87ppyxhc6y.fsf@latte.josefsson.org> <747787E65E3FBD4E93F0EB2F14DB556B183EB8AD@xmb-rcd-x04.cisco.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130318:joachim@secworks.se::gtcs30S7ApbT29ps:1XE5 X-Hashcash: 1:22:130318:cfrg@irtf.org::aYH0KGdGpFBKoqaG:9He X-Hashcash: 1:22:130318:mcgrew@cisco.com::McJDm8ulb7NLZpDl:Ole7 X-Hashcash: 1:22:130318:tls@ietf.org::Ce9zQZZ6LXhKXWtE:gpfN Date: Mon, 18 Mar 2013 21:42:13 +0100 In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B183EB8AD@xmb-rcd-x04.cisco.com> (David McGrew's message of "Mon, 18 Mar 2013 19:23:41 +0000") Message-ID: <87ehfc784a.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [TLS] Salsa20 stream cipher in TLS 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, 18 Mar 2013 20:42:33 -0000 "David McGrew (mcgrew)" writes: > Hi Simon, Hi David. Thanks for quick review. > It is not exactly clear what problem is being addressed by this work. > Would be good to add a problem statement section. Good idea, the document now contains this paragraph: The purpose of this document is to provide an alternative stream cipher for both TLS and DTLS that is comparable to RC4 in speed on a wide range of platforms. There are other soft factors too. In general the goal is to offer something that can replace use of RC4 in TLS. I'm guessing speed is one reason people use RC4 in TLS today. > Some more detailed comments, quoting from the draft: > > Recent attacks has indicated problems with CBC-mode cipher suites in > TLS/DTLS and problems with the only supported stream cipher (RC4) in > TLS has been known for a long time. While AEAD cipher suites address > these issues, concerns about performance are sometimes raised. > > > What are the performance concerns? I suggest citing some relevant > performance data. If there are implementations of this, we can benchmark them and compare them against other cipher suites and include some numbers or pointers to comparisons. I believe Salsa20 is faster than for example AES GCM on most platforms. > Because the GenericStreamCipher definition in TLS does not provide > any way to transport the Salsa20 nonce that is required for > functionality and needed to provide the random access property, we > let the output from the stream cipher operation be the concatenation > of the IV and the encrypted data. > > > Please, define a Salsa20-based AEAD mechanism instead of a new TLS format! That paragraph has been removed from the current work in progress, it was incorrect (the record sequence number will be used as nonce instead). I don't believe the AEAD mechanism works: there is no field to put the MAC in it. >>Some elements of the draft is still in flux. For example, >>initial performance benchmarks suggests HMAC-SHA256 was a poor choice >>for the MAC so we are looking into UMAC and HMAC-SHA1 as alternatives. >>Still, all comments are appreciated. > > If anything other than HMAC-SHA1 is used, that would underscore the value > of defining an AEAD algorithm. If the main motivation for this work is > encryption that is computationally cheap, then it makes sense to pair the > algorithm with an authentication method with the same characteristics. Yes -- only specifying HMAC-SHA256 was a mistake, and we have included a HMAC-SHA1 variant in the working copy. It is not clear to me whether keeping HMAC-SHA256 is useful. > For security considerations, I suggest citing the analysis of Salsa20, and > adding a sentence or paragraph summarizing the best-known attacks. > Something like "Salsa20 has been analyzed by X independent teams, and the > best known attack breaks 8 of 20 rounds." Good idea, the first paragraph of the security considerations is now: The security of Salsa20 is discussed in the Salsa20 security [SALSA20-SECURITY] paper. The reader must consult cryptographic research to find out the current security status of Salsa20. At the time of writing this document, there are no known significant security problems with Salsa20/12 or Salsa20/20. As of early 2013, the best cryptanalysis breaks 8 out of 20 rounds to recover the 256- bit secret key in 2^251 operations, using 2^31 keystream pairs (see [SALSA20-ATTACK]). For more background, see the eSTREAM report [ESTREAM]. /Simon From agl@google.com Mon Mar 18 13:45:53 2013 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 0C5A521F912A for ; Mon, 18 Mar 2013 13:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, 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 gjndX9cXWRQw for ; Mon, 18 Mar 2013 13:45:52 -0700 (PDT) Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 8822921F9129 for ; Mon, 18 Mar 2013 13:45:52 -0700 (PDT) Received: by mail-ia0-f180.google.com with SMTP id f27so5587755iae.25 for ; Mon, 18 Mar 2013 13:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+ScDC+urbkRqPRWsp1BFthDON7Z2ZWJ/gEuXZM/2R7Y=; b=nKeT6WffHOmf5hVJD/Cojl/n9xjm2VhAIl8vvad537cM7bPzM8KGaEl0ENOSXQE+20 9f7pp0kMcV3a0yN09HHt4sIcGISHybKH8CxAnWlnlohrSmNG8ro0PZPWNJdWbiChLZ47 2PT6QX5ZHwybe2AsiAI8Yl5q8VyE672NeiFdo8Lq3kEWGhdHB2m3nbPmJPWCDVZhqVFs WVsRDPIVKb9gn/UmrbdGw9WfbG7saXqn2wAIe+dMm9vBaLqRT4R+oNZ4nvodcgwmfvyA idt+O9gajeoyXAlotxLYEvMT+D2oRYySLL0iVXQ+T3nGmyqk4JXhFXNs/buQ/gNRORcT rkUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=+ScDC+urbkRqPRWsp1BFthDON7Z2ZWJ/gEuXZM/2R7Y=; b=gAtYWYvP8A3pw7drAUkNFQxGC+9hm41Eag3H2+VpFpZnKdYGrV09eqW6A/pqyC9wrV R/L3yDWTok3hpOzzSSbj3CEh4RBluS5NXaekSPM/m6JkbqG9+oKjrw73ORUCkmA7nY1E plVhvI9xQ4VKIyPxmGXz/KKB9tPm704wLmqix9WLxZqMJAfWkousidzAJa9wztGfopfG VU6CS+UgqixSufJdxbye/4uXgIvBDh5wiWA8zY8ZlHC+x7bcIDnqA4XmVdGG6utkKAMH cXnYi0Z6GVEh8V90DH1KYBY0mkSGizgmkTsE4mwRgOzybL5sSD2DVF+iJ3tG+ibnoE44 G80A== MIME-Version: 1.0 X-Received: by 10.43.134.8 with SMTP id ia8mr9365233icc.42.1363639552052; Mon, 18 Mar 2013 13:45:52 -0700 (PDT) Received: by 10.231.229.135 with HTTP; Mon, 18 Mar 2013 13:45:51 -0700 (PDT) In-Reply-To: <87ehfc784a.fsf@latte.josefsson.org> References: <87ppyxhc6y.fsf@latte.josefsson.org> <747787E65E3FBD4E93F0EB2F14DB556B183EB8AD@xmb-rcd-x04.cisco.com> <87ehfc784a.fsf@latte.josefsson.org> Date: Mon, 18 Mar 2013 16:45:51 -0400 Message-ID: From: Adam Langley To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnTwBBjmAtqWPyXsh2jKGlT7RL7w0QiZ0oHK+ZdaszODX5NgYX4thXVdi769rsuBJYPazHPywYv1vDrBb6j2Wir8aWHItAVzNtWUc/SZCwOBIt6XiyU4IOT7oYprEwsaUWtPRvG4lgoI3hhWAO4/R/YF7I1Xe+tecZX03XV2pP126kC9tqKG6WatpjSNmT78zAW1Q3T Cc: "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [TLS] Salsa20 stream cipher in TLS 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, 18 Mar 2013 20:45:53 -0000 On Mon, Mar 18, 2013 at 4:42 PM, Simon Josefsson wrote: > instead). I don't believe the AEAD mechanism works: there is no field > to put the MAC in it. There's no field for the GHASH tag for AES-GCM either: the construction of the authentication is opaque to the user of the AEAD algorithm. If you were to define an AEAD for this then you could decide where you would like the MAC to know, but it's a property of the AEAD, not of TLS. > Yes -- only specifying HMAC-SHA256 was a mistake, and we have included a > HMAC-SHA1 variant in the working copy. It is not clear to me whether > keeping HMAC-SHA256 is useful. I'm curious why you wouldn't pair Salsa20 with Poly1305, which is the typical combination. Cheers AGL From simon@josefsson.org Mon Mar 18 13:55:54 2013 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 8398D21F916C; Mon, 18 Mar 2013 13:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, 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 nMK4lbi3Z+4x; Mon, 18 Mar 2013 13:55:54 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id A29D121F914F; Mon, 18 Mar 2013 13:55:53 -0700 (PDT) Received: from latte.josefsson.org (host-95-192-103-177.mobileonline.telia.com [95.192.103.177]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r2IKthCd009249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Mar 2013 21:55:45 +0100 From: Simon Josefsson To: Wan-Teh Chang References: <87ppyxhc6y.fsf@latte.josefsson.org> <747787E65E3FBD4E93F0EB2F14DB556B183EB8AD@xmb-rcd-x04.cisco.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130318:tls@ietf.org::K8nk1fUrLw1piW/7:3bnc X-Hashcash: 1:22:130318:cfrg@irtf.org::+Ps6paRixAR8yNrV:Bek3 X-Hashcash: 1:22:130318:wtc@google.com::gE+KLXI0W4qEv3OR:GDSS X-Hashcash: 1:22:130318:joachim@secworks.se::f3lrVB5nPrZ37699:IqUe X-Hashcash: 1:22:130318:mcgrew@cisco.com::Ua0cWHXJYLWnHsCl:UOB+ Date: Mon, 18 Mar 2013 21:55:38 +0100 In-Reply-To: (Wan-Teh Chang's message of "Mon, 18 Mar 2013 12:48:51 -0700") Message-ID: <87620o77hx.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [TLS] Salsa20 stream cipher in TLS 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, 18 Mar 2013 20:55:54 -0000 Wan-Teh Chang writes: > On Sun, Mar 17, 2013 at 3:51 PM, Simon Josefsson wrote: >> All, >> >> FYI, we have published -00 of a draft that describes how the Salsa20 >> stream cipher can be added to TLS and DTLS, see: >> >> http://tools.ietf.org/html/draft-josefsson-salsa20-tls > > Hi Simon, > > I am interested in this work. I am especially interested in your plan > to allow the salsa20 cipher suites to be used in TLS 1.0 and TLS > 1.1, which you stated in the first paragraph of the Introduction > section. > > Since all of the new cipher suite names end in _SHA256, I > infer the MAC algorithm is hmac_sha256. (The fact is > not explicitly stated in the -00 draft.) Hi Wan-Teh and thank you for the review. Good catch, I have added a paragraph explaining what the MAC algorithm should be. > It is important to clarify how hmac_sha256 can be used in TLS 1.0 and > TLS 1.1, because a naive implementor would see the old definition of > MACAlgorithm in TLS 1.0 and 1.1: > > enum { null, md5, sha } MACAlgorithm; > > and conclude that hmac_sha256 can't be used in TLS > 1.0 and 1.1. Right. Would adding a set of cipher suites that use HMAC-SHA1 resolve this? We have added them already in our working copy for performance reasons. It is not clear whether there is any point in also having HMAC-SHA256, it destroys the performance properties. > I'm also interested in figuring out if these cipher suites > can be used in SSL 3.0. The only difficulty I see is > extending the SSL 3.0 MAC algorithm to hash=sha256 > (see the definition of the SSL 3.0 MAC in Section 5.2.3.1 > of RFC 6101) -- it is not clear what should be the size of > pad_1 and pad_2 for hash=sha256. I'm hoping that using HMAC-SHA1 here would solve this too, right? > The reason I'm interested in SSL 3.0 is that web browsers, > when talking to Google servers, which implement TLS/SSL > version negotiation correctly, are still downgraded to SSL 3.0 > by network errors injected by certain network devices. Having compability with SSL 3.0 would be nice. The next version will mention SSL 3.0 compatibility too. /Simon From wtc@google.com Mon Mar 18 14:01:19 2013 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 BF74721F917E for ; Mon, 18 Mar 2013 14:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, 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 jx7pWPOEsNOW for ; Mon, 18 Mar 2013 14:01:19 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 56B0121F917A for ; Mon, 18 Mar 2013 14:01:19 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id qd14so1719184ieb.25 for ; Mon, 18 Mar 2013 14:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6rP1bJi2iG5oWd5OcbuYQkH7G2o25wqs2nhDvZsK/No=; b=K7/O0fHdFORKOuiPuvDbvxkW0QubzjntI6nl7cYCEjBlZNRC1yP8o6CFrZHpK23fMv mQKpERvnG5oHVexNSP8iIJUUOlekMsY75bmfHhFEoNea8OY9ywlMMfZ8d0qp2sLh2gm3 C3totGsEeWHAW3WncMLgs2oRLdzfgW1lMoeOzAAXg0FsWU4VG7xPBuscRfu/FyhvBeu6 SlZxVI799bZ8QYoqj8COp3EGmP4DM/1MV0tCSlJjL6YggkCVPsgp688kXztx6p/+6PoE ML+vCCAEP0sdkSGKFCnpVQ8vqZq033rlNqy2UJEr73TPuP0VIKU2ZOxvm2nj4ntqcOoB Neew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=6rP1bJi2iG5oWd5OcbuYQkH7G2o25wqs2nhDvZsK/No=; b=cXCWiUowa+fM5aKOk6en7IVEhAM6Qt6xX5QBg9aZkUIy0Y+NoyYs44ZSdn1hmad2KL GEglgVRuJgWTeQYqYh31+2RUEpiPe7K2x1fCjAR3YO5qmaRpWAXTq//4xSgeFWzMY2mD m9yCHmNEAEx3pvUmHnXwQTqLY1peCU7cyD38FcHWBdq+ByQX6LZ6eVpA/uQG2xuKTdac 7m1DN156fQUXxFhGgNd1bT3Uo5mKOjcQzLYzu6s4TxdcVS2aCVEZqa/wjRA7+3Aq1mui jUYd76GExC0GOLBs+4zdOZZ79RNs9oDTZiqlEbN1dP0DvX0QQagzldyBjMV0a4uSCzwd a85Q== MIME-Version: 1.0 X-Received: by 10.50.36.199 with SMTP id s7mr228062igj.56.1363640478914; Mon, 18 Mar 2013 14:01:18 -0700 (PDT) Received: by 10.231.112.2 with HTTP; Mon, 18 Mar 2013 14:01:18 -0700 (PDT) In-Reply-To: <87620o77hx.fsf@latte.josefsson.org> References: <87ppyxhc6y.fsf@latte.josefsson.org> <747787E65E3FBD4E93F0EB2F14DB556B183EB8AD@xmb-rcd-x04.cisco.com> <87620o77hx.fsf@latte.josefsson.org> Date: Mon, 18 Mar 2013 14:01:18 -0700 Message-ID: From: Wan-Teh Chang To: Simon Josefsson Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmzv4uuzbxviWfcdIDh5qWCaWLpvqfz0D2Ymna+zhaOkHmKCHI0rtiMgdfoNDr0jZB4i11IspbfygoVEl7OLkj18PR2U0U5SlV5jaGH4be2AHA0iRUeza7NZx8Ryit5VUOQHATdxr/wXQI89dpKM4De4XQGKOoe2GHQ2DhzOOj5XC4+bUarglwY+t8SN/3IUTaihVKe Cc: "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [TLS] Salsa20 stream cipher in TLS 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, 18 Mar 2013 21:01:19 -0000 On Mon, Mar 18, 2013 at 1:55 PM, Simon Josefsson wrote: > > Would adding a set of cipher suites that use HMAC-SHA1 resolve this? We > have added them already in our working copy for performance reasons. Yes, using HMAC-SHA1 would solve both of the problems I asked about (TLS 1.0-1.1 support, and SSL 3.0 MAC compatibility). If the goal is to provide an alternative to the existing RC4 cipher suites (most of which use SHA-1), then using HMAC-SHA1 would be the best. Wan-Teh From mcgrew@cisco.com Mon Mar 18 14:12:04 2013 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 A7E8D21F9148 for ; Mon, 18 Mar 2013 14:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 HcEHOviOoLcI for ; Mon, 18 Mar 2013 14:12:03 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A86AE21F9142 for ; Mon, 18 Mar 2013 14:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4226; q=dns/txt; s=iport; t=1363641123; x=1364850723; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YHFhIrKFdBhAXh/7aHgA1Pr31JADzxXnkwFK6nSfbxg=; b=D7UxWsI+WkcEkdFmERdv0xZn/gVhBfaQKY0lav+oA8QesmajbLmQ+R4b c/gtl47/yquy7ZvmdxqV2QVkzLHy8If7niIe8YMfgCqbTrFiYwGguuvUw m6NRu2dfaenHJpH8GOK7LzjrXOGXQbO07wzLSRM0zrf35GO7exPGziVAi s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIeAR1GtJXG8/2dsb2JhbABDxS6BVhZ0giQBAQEDATo/EgEIIhRCJQIEDgUIiAYGwieOXzEHgl9hA4t6kVOKE4MKgig X-IronPort-AV: E=Sophos;i="4.84,867,1355097600"; d="scan'208";a="188840993" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 18 Mar 2013 21:11:58 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2ILBwih014374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Mar 2013 21:11:58 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 16:11:57 -0500 From: "David McGrew (mcgrew)" To: Simon Josefsson Thread-Topic: Salsa20 stream cipher in TLS Thread-Index: AQHOJBkcOgV0xxTq40yuP+6jbt08QpisAv8A Date: Mon, 18 Mar 2013 21:11:57 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B183EB9C5@xmb-rcd-x04.cisco.com> In-Reply-To: <87ehfc784a.fsf@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [TLS] Salsa20 stream cipher in TLS 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, 18 Mar 2013 21:12:04 -0000 Hi Simon, On 3/18/13 4:42 PM, "Simon Josefsson" wrote: >"David McGrew (mcgrew)" writes: > >> Hi Simon, > >Hi David. Thanks for quick review. Thanks for the quick response, more inline: > >> It is not exactly clear what problem is being addressed by this work. >> Would be good to add a problem statement section. > >Good idea, the document now contains this paragraph: > > The purpose of this document is to provide an alternative stream > cipher for both TLS and DTLS that is comparable to RC4 in speed on a > wide range of platforms. > >There are other soft factors too. In general the goal is to offer >something that can replace use of RC4 in TLS. I'm guessing speed is one >reason people use RC4 in TLS today. > >> Some more detailed comments, quoting from the draft: >> >> Recent attacks has indicated problems with CBC-mode cipher suites in >> TLS/DTLS and problems with the only supported stream cipher (RC4) in >> TLS has been known for a long time. While AEAD cipher suites address >> these issues, concerns about performance are sometimes raised. >> >> >> What are the performance concerns? I suggest citing some relevant >> performance data. > >If there are implementations of this, we can benchmark them and compare >them against other cipher suites and include some numbers or pointers to >comparisons. I believe Salsa20 is faster than for example AES GCM on >most platforms. > >> Because the GenericStreamCipher definition in TLS does not provide >> any way to transport the Salsa20 nonce that is required for >> functionality and needed to provide the random access property, we >> let the output from the stream cipher operation be the concatenation >> of the IV and the encrypted data. >> >> >> Please, define a Salsa20-based AEAD mechanism instead of a new TLS >>format! > >That paragraph has been removed from the current work in progress, it >was incorrect (the record sequence number will be used as nonce >instead). I don't believe the AEAD mechanism works: there is no field >to put the MAC in it. I'm not sure what you mean about the lack of a MAC field. It would not be hard to define an AEAD algorithm based on Salsa20; I would be surprised if there is not a submission to CAESAR using that cipher. And using the AEAD in TLSv1.2 is straightforward. (Is the issue a desire to use Salsa20 in older versions?) > >>>Some elements of the draft is still in flux. For example, >>>initial performance benchmarks suggests HMAC-SHA256 was a poor choice >>>for the MAC so we are looking into UMAC and HMAC-SHA1 as alternatives. >>>Still, all comments are appreciated. >> >> If anything other than HMAC-SHA1 is used, that would underscore the >>value >> of defining an AEAD algorithm. If the main motivation for this work is >> encryption that is computationally cheap, then it makes sense to pair >>the >> algorithm with an authentication method with the same characteristics. > >Yes -- only specifying HMAC-SHA256 was a mistake, and we have included a >HMAC-SHA1 variant in the working copy. It is not clear to me whether >keeping HMAC-SHA256 is useful. > >> For security considerations, I suggest citing the analysis of Salsa20, >>and >> adding a sentence or paragraph summarizing the best-known attacks. >> Something like "Salsa20 has been analyzed by X independent teams, and >>the >> best known attack breaks 8 of 20 rounds." > >Good idea, the first paragraph of the security considerations is now: > > The security of Salsa20 is discussed in the Salsa20 security > [SALSA20-SECURITY] paper. The reader must consult cryptographic > research to find out the current security status of Salsa20. At the > time of writing this document, there are no known significant > security problems with Salsa20/12 or Salsa20/20. As of early 2013, > the best cryptanalysis breaks 8 out of 20 rounds to recover the 256- > bit secret key in 2^251 operations, using 2^31 keystream pairs (see > [SALSA20-ATTACK]). For more background, see the eSTREAM report > [ESTREAM]. Looks good. David > >/Simon From simon@josefsson.org Mon Mar 18 14:17:25 2013 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 E36A321F8FFD; Mon, 18 Mar 2013 14:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, 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 8-OU-zyTgi-2; Mon, 18 Mar 2013 14:17:25 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id BE7C421F897A; Mon, 18 Mar 2013 14:17:24 -0700 (PDT) Received: from latte.josefsson.org (host-95-192-103-177.mobileonline.telia.com [95.192.103.177]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r2ILHIBr010090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Mar 2013 22:17:20 +0100 From: Simon Josefsson To: Adam Langley References: <87ppyxhc6y.fsf@latte.josefsson.org> <747787E65E3FBD4E93F0EB2F14DB556B183EB8AD@xmb-rcd-x04.cisco.com> <87ehfc784a.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130318:agl@google.com::xSV2JNAmIvHd9ZVy:04e4 X-Hashcash: 1:22:130318:tls@ietf.org::GTrw17Fe8VdYV7+F:3GPG X-Hashcash: 1:22:130318:joachim@secworks.se::IYmT3Ten/6vcIFhL:6Q7u X-Hashcash: 1:22:130318:cfrg@irtf.org::fbVVFNdpH4psAGGb:INax Date: Mon, 18 Mar 2013 22:17:12 +0100 In-Reply-To: (Adam Langley's message of "Mon, 18 Mar 2013 16:45:51 -0400") Message-ID: <87r4jc5rxj.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [TLS] Salsa20 stream cipher in TLS 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, 18 Mar 2013 21:17:26 -0000 Adam Langley writes: > On Mon, Mar 18, 2013 at 4:42 PM, Simon Josefsson wrote: >> instead). I don't believe the AEAD mechanism works: there is no field >> to put the MAC in it. > > There's no field for the GHASH tag for AES-GCM either: the > construction of the authentication is opaque to the user of the AEAD > algorithm. If you were to define an AEAD for this then you could > decide where you would like the MAC to know, but it's a property of > the AEAD, not of TLS. Right, agreed. Equally, the content of the ciphertext for a GenericStreamCipher is opaque to TLS, so we could put a nonce in there if that was necessary (but we don't need to). Having stream ciphers expand data is a bit unorthodox, but from a TLS protocol point of view it may work. Some implementation assume there is no message expansion for stream ciphers, but I haven't seen anything in the specification that assumes or require that. >> Yes -- only specifying HMAC-SHA256 was a mistake, and we have included a >> HMAC-SHA1 variant in the working copy. It is not clear to me whether >> keeping HMAC-SHA256 is useful. > > I'm curious why you wouldn't pair Salsa20 with Poly1305, which is the > typical combination. That could be another option. The only reason is that I haven't worked with any implementation of Poly1305, so I'm not that familiar with it. /Simon From mcgrew@cisco.com Mon Mar 18 14:23:57 2013 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 9975021F8576 for ; Mon, 18 Mar 2013 14:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 WmHN2FRu3Vl2 for ; Mon, 18 Mar 2013 14:23:56 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D9EDE21F85CB for ; Mon, 18 Mar 2013 14:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2379; q=dns/txt; s=iport; t=1363641836; x=1364851436; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=78zxLcE7EmVZ3fRwkyZGFsGvor0zwiDRbXmd2OD+xsw=; b=MTt8wU2JY7CXEV/17OJdA/RGPSpzwutfqw4iWH2O1m2GbhDC4TNoisrd fWUddMbwiZOfyazDTcHYQU7R9E/Z5Kp2kpo6GZ7nFGp3UZhim7acVgJau 13VLfdVR5Pc4rGqZurcJh4Pzgrgh3ce2lCR0iBidXARKzzbS3GPdweND4 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHOFR1GtJV2b/2dsb2JhbABDxTSBWxZ0giQBAQEDATo/EgEIGAoUQiUCBA4FCAyHegYMwiWOXzECBYJfYQOXfY9jgwqCKA X-IronPort-AV: E=Sophos;i="4.84,867,1355097600"; d="scan'208";a="188811719" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 18 Mar 2013 21:23:55 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2ILNtug021336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Mar 2013 21:23:55 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 16:23:55 -0500 From: "David McGrew (mcgrew)" To: Nikos Mavrogiannopoulos Thread-Topic: [TLS] Salsa20 stream cipher in TLS Thread-Index: AQHOI2IRfwT9uKfaFUuf1DQlms1pvpir5i+AgABN3wD//9O3AA== Date: Mon, 18 Mar 2013 21:23:54 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B183EB9F6@xmb-rcd-x04.cisco.com> In-Reply-To: <514772CE.4060300@gnutls.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: text/plain; charset="us-ascii" Content-ID: <49DA04091F6369498BEF1352C3192BA4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simon Josefsson , "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [TLS] Salsa20 stream cipher in TLS 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, 18 Mar 2013 21:23:57 -0000 Hi Nikos, On 3/18/13 4:02 PM, "Nikos Mavrogiannopoulos" wrote: >On 03/18/2013 08:23 PM, David McGrew (mcgrew) wrote: > >> Hi Simon, >>=20 >> On 3/17/13 6:51 PM, "Simon Josefsson" wrote: >>=20 >>> All, >>> >>> FYI, we have published -00 of a draft that describes how the Salsa20 >>> stream cipher can be added to TLS and DTLS, see: >>> >>> http://tools.ietf.org/html/draft-josefsson-salsa20-tls >>> >>> While we are not asking for WG adoption of this draft now, we are at a >>> point where we would like to invite external review and solicit >>> feedback. =20 >>=20 >> Some early feedback; copied CFRG. It would be good to have review from >> that community. >> It is not exactly clear what problem is being addressed by this work. > > >As I understand, the requirement, is a fast stream cipher that can be >used for TLS and DTLS, and doesn't have the issues RC4 has [0]. > >[0]. http://home.hiroshima-u.ac.jp/ohigashi/rc4/index.html Yes, I'm well aware of the RC4 issues and I support its deprecation. > >> Some more detailed comments, quoting from the draft: > >> What are the performance concerns? I suggest citing some relevant >> performance data. > > >The GCM mode does require special instructions to achieve performance >close (but often not better) to RC4 in general purpose CPUs. The stream >ciphers from the eStream competition outperform RC4 without any hw >assistance. The appropriate comparison would include both authentication and encryption, so comparisons to "naked" stream ciphers are misleading. And I strongly encourage actual performance comparisons on target platforms. > >> Because the GenericStreamCipher definition in TLS does not provide >> any way to transport the Salsa20 nonce that is required for >> functionality and needed to provide the random access property, we >> let the output from the stream cipher operation be the concatenation >> of the IV and the encrypted data. >> Please, define a Salsa20-based AEAD mechanism instead of a new TLS >>format! > > >The GenericStreamCipher mode is sufficient for this mode. It just >requires to define how to set the nonce. I think using the AEAD would >complicate things rather than provide any practical advantage. I respectfully disagree. David > >regards, >Nikos From simon@josefsson.org Mon Mar 18 14:47:52 2013 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 D7AB621F85DF; Mon, 18 Mar 2013 14:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, 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 VGQGfux+dIBC; Mon, 18 Mar 2013 14:47:52 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 118B021F8A09; Mon, 18 Mar 2013 14:47:51 -0700 (PDT) Received: from latte.josefsson.org (host-95-192-103-177.mobileonline.telia.com [95.192.103.177]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r2ILliI7011347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Mar 2013 22:47:47 +0100 From: Simon Josefsson To: "David McGrew \(mcgrew\)" References: <87ehfc784a.fsf@latte.josefsson.org> <747787E65E3FBD4E93F0EB2F14DB556B183EB9C5@xmb-rcd-x04.cisco.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130318:tls@ietf.org::yfSRUt/OfKmL9Tdb:4my2 X-Hashcash: 1:22:130318:cfrg@irtf.org::xeQWpLRwOeKJ09rB:7Kla X-Hashcash: 1:22:130318:mcgrew@cisco.com::nrEdyeYix5MZ7Jmu:3i40 X-Hashcash: 1:22:130318:joachim@secworks.se::5GPrf/oDr6ZRN7S7:JQ7k Date: Mon, 18 Mar 2013 22:47:39 +0100 In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B183EB9C5@xmb-rcd-x04.cisco.com> (David McGrew's message of "Mon, 18 Mar 2013 21:11:57 +0000") Message-ID: <87ip4o5qis.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [TLS] Salsa20 stream cipher in TLS 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, 18 Mar 2013 21:47:53 -0000 "David McGrew (mcgrew)" writes: > I'm not sure what you mean about the lack of a MAC field. It would not be > hard to define an AEAD algorithm based on Salsa20; I would be surprised if > there is not a submission to CAESAR using that cipher. And using the AEAD > in TLSv1.2 is straightforward. (Is the issue a desire to use Salsa20 in > older versions?) Yes. If it is not possible to implement Salsa20 as a GenericStreamCipher we'll reconsider. Right now to me it seems Salsa20 is more similar to RC4 than to AES-GCM or other AEAD ciphers and there is no advantage in specifying it as a GenericAEADCipher while the advantage for GenericStreamCipher is potential compatibility with older TLS versions. /Simon From simon@josefsson.org Mon Mar 18 14:50:07 2013 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 3EB5D21F8994 for ; Mon, 18 Mar 2013 14:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, 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 EseYBsO1oBOj for ; Mon, 18 Mar 2013 14:50:05 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2FA21F8928 for ; Mon, 18 Mar 2013 14:50:03 -0700 (PDT) Received: from latte.josefsson.org (host-95-192-103-177.mobileonline.telia.com [95.192.103.177]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r2ILo0E7011355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 18 Mar 2013 22:50:02 +0100 From: Simon Josefsson To: tls@ietf.org References: <87ppyxhc6y.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130318:joachim@secworks.se::DTy7HSr6QQnh730g:ipFz X-Hashcash: 1:22:130318:tls@ietf.org::CFHrz9BB1Mi4H475:0AJSB Date: Mon, 18 Mar 2013 22:49:55 +0100 In-Reply-To: <87ppyxhc6y.fsf@latte.josefsson.org> (Simon Josefsson's message of "Sun, 17 Mar 2013 23:51:49 +0100") Message-ID: <87ehfc5qf0.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [TLS] Salsa20 stream cipher in TLS 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, 18 Mar 2013 21:50:08 -0000 We pushed out a -01 to address the feedback we got so far. http://tools.ietf.org/html/draft-josefsson-salsa20-tls Refresh the page in your browser if you still see the -00 version. Thanks, /Simon Simon Josefsson writes: > All, > > FYI, we have published -00 of a draft that describes how the Salsa20 > stream cipher can be added to TLS and DTLS, see: > > http://tools.ietf.org/html/draft-josefsson-salsa20-tls > > While we are not asking for WG adoption of this draft now, we are at a > point where we would like to invite external review and solicit > feedback. Some elements of the draft is still in flux. For example, > initial performance benchmarks suggests HMAC-SHA256 was a poor choice > for the MAC so we are looking into UMAC and HMAC-SHA1 as alternatives. > Still, all comments are appreciated. > > /Simon From n.mavrogiannopoulos@gmail.com Mon Mar 18 15:42:32 2013 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 25E9221F8BA4 for ; Mon, 18 Mar 2013 15:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.534 X-Spam-Level: X-Spam-Status: No, score=-1.534 tagged_above=-999 required=5 tests=[AWL=-0.688, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.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 o3fIyziibBrD for ; Mon, 18 Mar 2013 15:42:31 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4CD21F8B6D for ; Mon, 18 Mar 2013 15:42:31 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id d7so5345403wer.22 for ; Mon, 18 Mar 2013 15:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:x-enigmail-version:openpgp :content-type:content-transfer-encoding; bh=v4ZZI6zaG+d/nDRnGsHivT9khgXvvJhHX8knKMnmTWk=; b=F/BsKTcBSqwkLQyOmx37DOgvnFhjlGjsbm5aVfKdzhWfjxDd2cD70p/cJEhWx7y5Lp hePeIJlv1X2zBgawAdDJG1kEiTpyu/D0nFlTIqEbJ5AQMI3zeYVavBppU4AS0vdC6kUA vJqDBZ0T43jqsTC7CKDKANXKQQD3kH4Y/x/HiRZq6IlrCgMrBTaEeZamhqgthvd/5JRp NXUk25fdop881s2WKsAbTkkthTpoYc70CKnk8YUACsUYBxTXuJR20N2Sjgy1rATsZDf7 BCzXwzSVsfUCRIx/YdqcbQEGa92IkQlEE1fCBrlP/NAkEKQ1wNZzOhwks4932niePrI5 N0bg== X-Received: by 10.194.242.197 with SMTP id ws5mr28247416wjc.44.1363646550595; Mon, 18 Mar 2013 15:42:30 -0700 (PDT) Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id f1sm16346237wib.0.2013.03.18.15.42.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Mar 2013 15:42:29 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <51479854.6020101@gnutls.org> Date: Mon, 18 Mar 2013 23:42:28 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: tls@ietf.org References: <87ppyxhc6y.fsf@latte.josefsson.org> <747787E65E3FBD4E93F0EB2F14DB556B183EB8AD@xmb-rcd-x04.cisco.com> <87ehfc784a.fsf@latte.josefsson.org> In-Reply-To: X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Salsa20 stream cipher in TLS 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, 18 Mar 2013 22:42:32 -0000 On 03/18/2013 09:45 PM, Adam Langley wrote: > I'm curious why you wouldn't pair Salsa20 with Poly1305, which is the > typical combination. We are considering UMAC which is an older MAC, similar to the poly thing, and already published in RFC4418. Performance-wise UMAC-AES-96 is around 2x the speed of sha1 and 5x the speed of sha256. The small tag also means more savings in DTLS datagrams which are typically small (without sacrificing security - remember the finished message MAC is also 96-bits). regards, Nikos From alexey.melnikov@isode.com Mon Mar 18 19:28:50 2013 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 C81A121F89AA; Mon, 18 Mar 2013 19:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 c7fGJBLp8Ezj; Mon, 18 Mar 2013 19:28:50 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 22A4821F89A5; Mon, 18 Mar 2013 19:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1363660128; d=isode.com; s=selector; i=@isode.com; bh=NO01FN0jrRjdOdFdu+fnNNLLFvo4zNK2xPWHHNV2dqA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=GZt6PCQXNURMdnCjdM+vaWYIDdqQOGjbq63jXIM4m/QVfYtGVXROriSPC+7GY2ROfbWBdm 5Q99f5hcXf3RxKKrn1rv4J6dwG5WZhuIdkdQhWWk7UZagzKKV+diKfS08Hj46+10f6cSpx K3WNgJ1W8iq0H4Kq0b/oGPhPGN3hib8=; Received: from [10.8.38.166] (173-14-120-161-richmond.hfc.comcastbusiness.net [173.14.120.161]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 19 Mar 2013 02:28:48 +0000 References: <20130315173558.7429.20829.idtracker@ietfa.amsl.com> In-Reply-To: <20130315173558.7429.20829.idtracker@ietfa.amsl.com> Message-Id: X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Mon, 18 Mar 2013 22:30:20 -0400 To: "ietf@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] Last Call: (The TLS Multiple Certificate Status Request Extension) 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: Tue, 19 Mar 2013 02:28:50 -0000 On 15 Mar 2013, at 13:35, The IESG wrote: > The IESG has received a request from the Transport Layer Security WG > (tls) to consider the following document: > - 'The TLS Multiple Certificate Status Request Extension' > as Proposed > Standard >=20 > 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@ietf.org mailing lists by 2013-03-29. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > 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. I read the document. I think it adds important functionality. It is clearly w= ritten, so I support its publication. From n.mavrogiannopoulos@gmail.com Tue Mar 19 00:10:31 2013 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 C92AD21F8548 for ; Tue, 19 Mar 2013 00:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.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 zXhIlyks6kkp for ; Tue, 19 Mar 2013 00:10:31 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0C53B21F84F9 for ; Tue, 19 Mar 2013 00:10:30 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id ds1so3136178wgb.4 for ; Tue, 19 Mar 2013 00:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:x-enigmail-version:openpgp :content-type:content-transfer-encoding; bh=c6qfwBd9T5/5l92bn+iWCloKpp0S/ijydmZGy0sHKZE=; b=oSVI4gafx3NgtEyDcCAfTsu7ALoyGD4rU4V4IXdPKkM5MtwWhjezOWA5qNXu9o7g3e dGtV7K5cErR9g8MdeRo6ySmQyX/ONUHzKtk3T+7zW4hVSThwzyRW75PclXmpZgK7fE45 rosu8B+jqF3/zYum6ohLGj9qsRVOd4CqVa91+pF6bqcHXrrBoVS2B7hTXPHEJADYFMJy mwKabR+/0LsXQ047yOOu9+T6GXf2GflQDOWv77EjgG7SjCJ251YUkZP491Bx3OZYCAi0 udjdrrPqJUOg7SEnjenIXg+GwarqviY6JI7PMRKpQ5IZ8wOHeMYJ5c6FRZlwm8Yq00zR hGpQ== X-Received: by 10.194.59.100 with SMTP id y4mr1031828wjq.51.1363677030241; Tue, 19 Mar 2013 00:10:30 -0700 (PDT) Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id fx5sm19411974wib.11.2013.03.19.00.10.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Mar 2013 00:10:29 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <51480F5F.30408@gnutls.org> Date: Tue, 19 Mar 2013 08:10:23 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: tls@ietf.org References: <87ppyxhc6y.fsf@latte.josefsson.org> <747787E65E3FBD4E93F0EB2F14DB556B183EB8AD@xmb-rcd-x04.cisco.com> <87ehfc784a.fsf@latte.josefsson.org> In-Reply-To: <87ehfc784a.fsf@latte.josefsson.org> X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Salsa20 stream cipher in TLS 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, 19 Mar 2013 07:10:31 -0000 On 03/18/2013 09:42 PM, Simon Josefsson wrote: >> What are the performance concerns? I suggest citing some relevant >> performance data. > > If there are implementations of this, we can benchmark them and compare > them against other cipher suites and include some numbers or pointers to > comparisons. I believe Salsa20 is faster than for example AES GCM on > most platforms. Hello, I've done some throughput comparisons on my amd64 (no hw acceleration of AES) and gnutls. * with a 1400-byte packet size: RSA_WITH_SALSA20R20_256_UMAC_96: 46.88 MB/sec RSA_WITH_SALSA20R20_256_SHA1: 40.00 MB/sec RSA_ARCFOUR_SHA1: 39.34 MB/sec RSA_ARCFOUR_MD5: 40.35 MB/sec RSA_AES_128_GCM_SHA256: 29.88 MB/sec * with a 15360 packet size: RSA_WITH_SALSA20R20_256_UMAC_96: 59.53 MB/sec RSA_WITH_SALSA20R20_256_SHA1: 48.66 MB/sec RSA_ARCFOUR_SHA1: 46.64 MB/sec RSA_ARCFOUR_MD5: 47.78 RSA_AES_128_GCM_SHA256: 33.64 MB/sec (the umac-96 is implemented in plain C using the reference code) regards, Nikos From mcgrew@cisco.com Tue Mar 19 06:36:08 2013 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 D6E5021F8A3F for ; Tue, 19 Mar 2013 06:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 nsty9Y7svs-s for ; Tue, 19 Mar 2013 06:36:07 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C83D521F8A35 for ; Tue, 19 Mar 2013 06:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2494; q=dns/txt; s=iport; t=1363700167; x=1364909767; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jijjCFzkWEvgUJ1ArkwuLuvh/hoCLM7YDvmm6QNb7og=; b=Jsp0PFo7y7HfpwG+jtw8jThJ2kphwggBMQbtwegnuTsCsDRudKggk6oh x2QC9hVBHMMuDlEIqDDOBn4SPJP9LRp8koRPB3oybv1NWZoxUQlAxbIU2 C1n1dChmRXYptn6OfuxnPPaGb/eXMleNgqDN7eUzMJQgO9wu+2uy48lPg g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOBoSFGtJV2a/2dsb2JhbABDxSCBXhZ0giQBAQEEeRIBCBgKViUCBAENBQiIDLI9kB2NX3wCMQeCX2EDiD+PP49jgwqCKA X-IronPort-AV: E=Sophos;i="4.84,872,1355097600"; d="scan'208";a="188845794" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 19 Mar 2013 13:36:07 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2JDa7fN004556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Mar 2013 13:36:07 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 08:36:07 -0500 From: "David McGrew (mcgrew)" To: "joachim@secworks.se" , Adam Langley Thread-Topic: [TLS] Salsa20 stream cipher in TLS Thread-Index: AQHOJBkcOgV0xxTq40yuP+6jbt08QpisPsaAgAER6wD//8VGgA== Date: Tue, 19 Mar 2013 13:36:06 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B183EBFA6@xmb-rcd-x04.cisco.com> In-Reply-To: <514862C6.4070809@secworks.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simon Josefsson , "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] Salsa20 stream cipher in TLS 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, 19 Mar 2013 13:36:09 -0000 Hi Joachim, On 3/19/13 9:06 AM, "Joachim Str=F6mbergson" wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Aloha! > >On 2013-03-18 21:45 , Adam Langley wrote: >> I'm curious why you wouldn't pair Salsa20 with Poly1305, which is >> the typical combination. > >Is poly1305 widely used? I think that's the wrong question to ask when considering a MAC based on universal hashing, since the security of such constructs is well understood. =20 >Would it be advantageous for adoption and >approval of Salsa20 in TLS to also introduce poly1305? If one of the motivations for adopting Salsa20 is that it is computationally cheap (fast in software, small circuit, low power consumption) then it definitely makes sense to pair it with an authenticator with the same properties. It will be important to make sure that the performance is adequate on all of the processors under consideration. Many universal hash functions have a performance that is closely linked to that of the 32,64, or 128-bit multiplication operation, which varies widely across CPUs. > >My gut feeling is/was that trying to just provide a really good >alternative to RC4 would be easiest to do and get adoption for. Well, AES-GCM is certainly a good alternative to RC4 and CBC. It is security-conservative, already specified in TLSv1.2 and implemented in many places, performs very well on dedicated hardware and performs adequately otherwise, and is approved for use in FIPS-140. David > >- --=20 >Med v=E4nlig h=E4lsning, Yours > >Joachim Str=F6mbergson - Alltid i harmonisk sv=E4ngning. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Joachim Str=F6mbergson Secworks AB joachim@secworks.se >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >-----BEGIN PGP SIGNATURE----- >Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >Comment: GPGTools - http://gpgtools.org >Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > >iEYEARECAAYFAlFIYsYACgkQZoPr8HT30QEavwCg04uHLG2XSgTRHt2fL9NZdMft >FM4AoIlRvzHPPzwnjHe4yKkYOjm9q6Bo >=3DddOd >-----END PGP SIGNATURE----- From joachim@secworks.se Tue Mar 19 06:06:12 2013 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 7657F21F86D8 for ; Tue, 19 Mar 2013 06:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 VeTBFB+ggdqZ for ; Tue, 19 Mar 2013 06:06:11 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 9523721F86D3 for ; Tue, 19 Mar 2013 06:06:11 -0700 (PDT) Received: from tunnis.local (2.67.227.87.static.g-sn.siw.siwnet.net [87.227.67.2]) by mail.frobbit.se (Postfix) with ESMTPSA id 784FD21904; Tue, 19 Mar 2013 14:06:10 +0100 (CET) Message-ID: <514862C6.4070809@secworks.se> Date: Tue, 19 Mar 2013 14:06:14 +0100 From: =?UTF-8?B?Sm9hY2hpbSBTdHLDtm1iZXJnc29u?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Adam Langley References: <87ppyxhc6y.fsf@latte.josefsson.org> <747787E65E3FBD4E93F0EB2F14DB556B183EB8AD@xmb-rcd-x04.cisco.com> <87ehfc784a.fsf@latte.josefsson.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 19 Mar 2013 07:15:35 -0700 Cc: Simon Josefsson , "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] Salsa20 stream cipher in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: joachim@secworks.se 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, 19 Mar 2013 13:06:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! On 2013-03-18 21:45 , Adam Langley wrote: > I'm curious why you wouldn't pair Salsa20 with Poly1305, which is > the typical combination. Is poly1305 widely used? Would it be advantageous for adoption and approval of Salsa20 in TLS to also introduce poly1305? My gut feeling is/was that trying to just provide a really good alternative to RC4 would be easiest to do and get adoption for. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim@secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFIYsYACgkQZoPr8HT30QEavwCg04uHLG2XSgTRHt2fL9NZdMft FM4AoIlRvzHPPzwnjHe4yKkYOjm9q6Bo =ddOd -----END PGP SIGNATURE----- From agl@google.com Tue Mar 19 08:10:01 2013 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 C2B1121F8CD7 for ; Tue, 19 Mar 2013 08:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, 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 PU4yLZRv86g4 for ; Tue, 19 Mar 2013 08:10:01 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id E218E21F866F for ; Tue, 19 Mar 2013 08:10:00 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id c13so724116ieb.9 for ; Tue, 19 Mar 2013 08:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=L/bOqxuJPC4vbmqPmR4zMg99pHpQh56O3tWqM0YDDrQ=; b=n1rjuKz04KDfDqfzUn64gubJCH0MFNgO85myTo1WU4VEQRWHBj0ei6hn0wFpKD4Gh/ XEWXMvq06a0TseuLxDxJ7lzubU4DYkBbG3Gh74dV3rUVCvMvQheydSIyjCL3nvxyEgCD 3Hh6IPnrv7iN1enKvjcVH4MD829w4U30hqkabZm/vcb69om/475ajOgBI9lH0wNSem86 EGmRDQZSmZfpJ6tbyijSuzE9FdlTgeZDXNPOwU/AcebXqETrSX9ThZaTnRG9+32fua2x CRFJLzbjlCSXpqPQISEkcA66VGqLi4T3ZyGsxPNQIE4NR2Jezsdq/DyLZfRe6KkLTeVf cF1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=L/bOqxuJPC4vbmqPmR4zMg99pHpQh56O3tWqM0YDDrQ=; b=TnO/rYKv2zalPpb4yp0m+muS46Ww2qmoHyXV0w8qGUuaoZ/+6j/IOsOSlKy32CVQl8 hL1ezHR4DuLHO43zsVR4IvnhyUbZOYKHiZMJ5aGYmDCIsZc4WBtjvRhG+sYFUfYabkhf IKoWyZFqSqTwma8lYx3uQho/pNwPbSIyjywskhOur7SZMiHoVp2D9lvnSptv/cgn3abR 5CuEI4qxj63USER8/EYstQ3bAMNOwf8XHj47LNSFZ1iXO8JpIHClpWm/zrbEdADZ94so p5S85pinIrd9qQ4BRThco5pmJ43rxaMcJvBAcpGfHhUy/ZF6j8vGcb+fClfR7NvKye5l 7A/A== MIME-Version: 1.0 X-Received: by 10.50.152.169 with SMTP id uz9mr1696623igb.15.1363705800249; Tue, 19 Mar 2013 08:10:00 -0700 (PDT) Received: by 10.231.229.135 with HTTP; Tue, 19 Mar 2013 08:10:00 -0700 (PDT) In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B183EBFA6@xmb-rcd-x04.cisco.com> References: <514862C6.4070809@secworks.se> <747787E65E3FBD4E93F0EB2F14DB556B183EBFA6@xmb-rcd-x04.cisco.com> Date: Tue, 19 Mar 2013 11:10:00 -0400 Message-ID: From: Adam Langley To: "David McGrew (mcgrew)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnFywaEBLWp70500XDhtnDmJzWZTK8RHCIEOkg/IxB2fJl1F3yWKSKT4ZiKVivjqZ5oPPyhg5WH3fj/nXSuAem2v8zL7iHWkObtlLJEGUZ06d4aYfjkHGp9vWZ+OjkFB0fpYD2wXPbG3G/2If6tkl2mo0Pa0LXeFpuSqOOWgC3R+4oRPnoDEKKIryIVw95Rf0LoczHN Cc: Simon Josefsson , "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [TLS] Salsa20 stream cipher in TLS 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, 19 Mar 2013 15:10:02 -0000 On Tue, Mar 19, 2013 at 9:36 AM, David McGrew (mcgrew) wrote: > Well, AES-GCM is certainly a good alternative to RC4 and CBC. It is > security-conservative, already specified in TLSv1.2 and implemented in > many places, performs very well on dedicated hardware and performs > adequately otherwise, and is approved for use in FIPS-140. AES-GCM is great on dedicated hardware but, if I may be somewhat deliberately contradictory :) On common, low(ish)-end hardware (Cortex A15) Salsa20 is 2x faster than AES. Additionally, AES and GHASH both use binary fields which, in order to have an efficient implementation, are often implemented as table lookups in software. These table lookups cause timing side-channels[1] and also cache pressure, which isn't accounted for in benchmarks which run the function in a loop. (There has been some great work on implementing AES in a side-channel free manner, and that work is found in OpenSSL and some other places, but it's very complex and there are lots of much simpler, much more vulnerable, AES and GHASH implementations out there.) Salsa20, however, is naturally free of timing side channels. Even a novice implementation will be secure. In short, I'm implementing AES-GCM at the moment because we need the option and there's already a fair amount of deployment. However, I'd be happy to see a Salsa20 option too. Without it, AES-GCM would be the only reasonable ciphersuite in TLS for the future. [1] http://cs.tau.ac.il/~tromer/papers/cache.pdf Cheers AGL From wtc@google.com Tue Mar 19 11:23:41 2013 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 3DC5621F8EF1 for ; Tue, 19 Mar 2013 11:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, 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 upATM2q3mewf for ; Tue, 19 Mar 2013 11:23:40 -0700 (PDT) Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4628821F8EEA for ; Tue, 19 Mar 2013 11:23:40 -0700 (PDT) Received: by mail-ia0-f178.google.com with SMTP id y10so694018iak.9 for ; Tue, 19 Mar 2013 11:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=puiYDpr2uFVgjWENY8yY9duilzup/lbDNcwyZcDcheo=; b=gmNS2iRAMi7iwKh5zsmLVBwH2FrgSKXUkPqEkBhAyMzc21l8/cTWPwb5GCnPr2KBBD RMvme+ZdkQ92TCwds1IsX0v5dKk33AS4UpLZHCsV8fiEAD3wrzrKIkeh8velngcUd0hW IIJq5APTMKQrMyAdmNBdqATliOB4wjvgFeLjVIzxEGrGvshgv2+s7tCCBmAjC2x+6sx3 IOFZuSFd/D+V6ozgGPG7O8QAbJs0T7Q+TjTyU6PQP/v7MGqvsizYn1Nthop6/JMs64nj MtQFDKiunw0mpsT1ItsEnzsN5aqfj2yvqxpj9/VbYuyJehcKaUfe0xw9+Wu9P3UDAEn2 3dnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=puiYDpr2uFVgjWENY8yY9duilzup/lbDNcwyZcDcheo=; b=QG6LukQOyJnzBcf0DtiFvA+bMoBeTqbCf0lZ+NHSHvg3RQYXRdXBzyrrN3P3G9gSb9 XQJ0xwoMR3P3EZ1X6TdmKPtbaMtcKT/gM9808jQpJkuilEdC5YYx8IouC3hDzvU/bqQO HYRHTm8LCn96XcVYmHCvESNxu+Hyr17PWqlDke0BLSg08TenQ4KZYQ7gwAdGZBDFMQvP dEXVjmL5jF4cdJeV9/1SVREQz8gUqTKMKjibYV/L89/r2bjCX+p2WVEPq4ebiWVaNKS/ U2+R0pdyPq0Wiggp+EYVIa+gOV6JmwX0uPu7LQRKvxhd1Sx9MnlzqH05Su5s18768TCC cw4Q== MIME-Version: 1.0 X-Received: by 10.42.126.133 with SMTP id e5mr11695555ics.17.1363717419807; Tue, 19 Mar 2013 11:23:39 -0700 (PDT) Received: by 10.231.112.2 with HTTP; Tue, 19 Mar 2013 11:23:39 -0700 (PDT) In-Reply-To: References: <514862C6.4070809@secworks.se> <747787E65E3FBD4E93F0EB2F14DB556B183EBFA6@xmb-rcd-x04.cisco.com> Date: Tue, 19 Mar 2013 11:23:39 -0700 Message-ID: From: Wan-Teh Chang To: Adam Langley Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmE8Wi2YyEH5YiZ2ANbIHAawHL0nlgv4x0H5nYWYeP2X/+Lon4E0g0u2QYzTycVt6eHZJ28iKp3tt9hrA1XX24AuDOqmr3HVl4Gzz6oWn94GTYUtP2/zKd49LAGoDsP3cph/pih2hEu1L0Qnk1B0Co+2j5lek3m36AkqOHXTQhfJn3650E8cYWXbqYvMw5Y8NRjwi1S Cc: Simon Josefsson , "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [TLS] Salsa20 stream cipher in TLS 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, 19 Mar 2013 18:23:42 -0000 On Tue, Mar 19, 2013 at 8:10 AM, Adam Langley wrote: > > In short, I'm implementing AES-GCM at the moment because we need the > option and there's already a fair amount of deployment. However, I'd > be happy to see a Salsa20 option too. Without it, AES-GCM would be the > only reasonable ciphersuite in TLS for the future. Another problem with the AES-GCM cipher suites they can't be used with older versions of TLS. The most obvious problem is that the GenericAEADCipher struct is only defined in the TLS 1.2 RFC. (Key expansion also needs to generate client_write_IV and server_write_IV.) Although it may be possible to retrofit GenericAEADCipher into TLS 1.0 and 1.1, the existing implementations of the AES-GCM cipher suites restrict them to TLS 1.2, so there will still be interoperability problems. Assuming we can solve the problems of using GenericAEADCipher and updating key expansion in TLS 1.0 and 1.1, new AEAD cipher suites can describe how they will be used in older versions of TLS from day one. So it still seems worthwhile to solve the problem of using AEAD cipher suites in TLS 1.0 and 1.1. Wan-Teh From simon@josefsson.org Tue Mar 19 13:41:40 2013 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 3A7FD21F8F29; Tue, 19 Mar 2013 13:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, 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 r1GqV0Pf7P86; Tue, 19 Mar 2013 13:41:39 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 30FF221F8F35; Tue, 19 Mar 2013 13:41:38 -0700 (PDT) Received: from latte.josefsson.org (host-95-192-103-177.mobileonline.telia.com [95.192.103.177]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r2JKfMM7009797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Mar 2013 21:41:24 +0100 From: Simon Josefsson To: Wan-Teh Chang References: <514862C6.4070809@secworks.se> <747787E65E3FBD4E93F0EB2F14DB556B183EBFA6@xmb-rcd-x04.cisco.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130319:joachim@secworks.se::dxc0gSCGfbu+z/Zk:0VfY X-Hashcash: 1:22:130319:cfrg@irtf.org::C0oV06b/PWJtk+mu:2lj X-Hashcash: 1:22:130319:tls@ietf.org::jQ6n40INzvdPyq9Q:35oy X-Hashcash: 1:22:130319:agl@google.com::mSitBaG3KYHSk7bU:HxoV X-Hashcash: 1:22:130319:wtc@google.com::fW1tmDJk5QKNqjFy:Jl6J Date: Tue, 19 Mar 2013 21:41:16 +0100 In-Reply-To: (Wan-Teh Chang's message of "Tue, 19 Mar 2013 11:23:39 -0700") Message-ID: <87fvzrktqr.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [TLS] Salsa20 stream cipher in TLS 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, 19 Mar 2013 20:41:40 -0000 Wan-Teh Chang writes: > Although it may be possible to retrofit GenericAEADCipher into TLS 1.0 and > 1.1, the existing implementations of the AES-GCM cipher suites restrict them > to TLS 1.2, so there will still be interoperability problems. Implementations could be fixed here, if we want to. There may still be interop problems, but there will always be interop problems so implementations need to handle them anyway. > Assuming we can solve the problems of using GenericAEADCipher and > updating key expansion in TLS 1.0 and 1.1, new AEAD cipher suites can > describe how they will be used in older versions of TLS from day one. > So it still seems worthwhile to solve the problem of using AEAD cipher > suites in TLS 1.0 and 1.1. That may be useful, and would likely have helped adoption of AEAD ciphers in TLS if it was done from the start. I'm not sure why TLS 1.2 isn't negotiated more often by browsers. If it is an implementation issue, I'm not convinced specifying AEAD ciphers for TLS 1.0 and TLS 1.1 will help: they just get another implementation issue to implement that instead. Admittedly, it is a different implementation task, so it may be fixed earlier than the other issue, but that is difficult to predict. Generally, it might be better to push browsers vendors to switch to TLS 1.2 more quickly, then the problem is also solved. /Simon From jon@callas.org Tue Mar 19 16:30:59 2013 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 E85C521F8DE1 for ; Tue, 19 Mar 2013 16:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 4A40kUzukhEc for ; Tue, 19 Mar 2013 16:30:59 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 828BB21F8DB7 for ; Tue, 19 Mar 2013 16:30:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id AB8AA24C3678; Tue, 19 Mar 2013 16:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fwWOFAPUpCB; Tue, 19 Mar 2013 16:30:49 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 5EAB924C365A; Tue, 19 Mar 2013 16:30:49 -0700 (PDT) Received: from [192.168.66.100] ([207.239.114.206]) by keys.merrymeet.com (PGP Universal service); Tue, 19 Mar 2013 16:30:49 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 19 Mar 2013 16:30:49 -0700 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jon Callas In-Reply-To: <87fvzrktqr.fsf@latte.josefsson.org> Date: Tue, 19 Mar 2013 16:30:16 -0700 Message-Id: References: <514862C6.4070809@secworks.se> <747787E65E3FBD4E93F0EB2F14DB556B183EBFA6@xmb-rcd-x04.cisco.com> <87fvzrktqr.fsf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.1503) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Jon Callas , "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Salsa20 stream cipher in TLS 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, 19 Mar 2013 23:31:00 -0000 On Mar 19, 2013, at 1:41 PM, Simon Josefsson = wrote: > I'm not sure why TLS 1.2 isn't negotiated more often by browsers. If = it > is an implementation issue, I'm not convinced specifying AEAD ciphers > for TLS 1.0 and TLS 1.1 will help: they just get another = implementation > issue to implement that instead. Admittedly, it is a different > implementation task, so it may be fixed earlier than the other issue, > but that is difficult to predict. Generally, it might be better to = push > browsers vendors to switch to TLS 1.2 more quickly, then the problem = is > also solved. There are two reasons. Uncertainty about ECC, and uncertainty about GCM. We can debate how much the ECC uncertainty is warranted, but lots of = people have it. We can also debate the GCM issues, but GCM is tetchy to = use properly. And yes, you could always use CCM instead. But most people = don't know that CCM is part of TLS 1.2. I didn't know it I discovered it = while writing this note. The general opinion about TLS 1.2 is that that's the version for Suite = B. That's not precisely true. I had that opinion for a while until I = learned I was mistaken. However, if you have concerns about either ECC = or GCM, then you have concerns about TLS 1.2. I don't know if you can do = 1.2 without ECC or GCM. Jon From juhovh@iki.fi Wed Mar 20 00:02:39 2013 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 B424A21F8D76 for ; Wed, 20 Mar 2013 00:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] 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 dcGmwp1xpQJo for ; Wed, 20 Mar 2013 00:02:39 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB0521F8C0C for ; Wed, 20 Mar 2013 00:02:39 -0700 (PDT) Received: from [10.60.40.2] (188.238.169.2) by kirsi1.inet.fi (8.5.140.03) id 51292B7F01CD1698; Wed, 20 Mar 2013 09:02:24 +0200 References: <514862C6.4070809@secworks.se> <747787E65E3FBD4E93F0EB2F14DB556B183EBFA6@xmb-rcd-x04.cisco.com> <87fvzrktqr.fsf@latte.josefsson.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B146) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= Date: Wed, 20 Mar 2013 09:02:21 +0200 To: Jon Callas Cc: Simon Josefsson , "cfrg@irtf.org" , Jon Callas , "tls@ietf.org" , "joachim@secworks.se" Subject: Re: [TLS] [Cfrg] Salsa20 stream cipher in TLS 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 Mar 2013 07:02:39 -0000 On 20.3.2013, at 1.30, Jon Callas wrote: > On Mar 19, 2013, at 1:41 PM, Simon Josefsson wrote: >=20 >> Generally, it might be better to push >> browsers vendors to switch to TLS 1.2 more quickly, then the problem is >> also solved. >=20 > There are two reasons. Uncertainty about ECC, and uncertainty about GCM. I don't believe I'm alone in this when I think TLS 1.2 and ECC are not relat= ed at all, ECC is specified to work on TLS 1.0 or later. And GCM is related o= nly because AEAD is not specified before 1.2, but it is not part of the spec= . > We can debate how much the ECC uncertainty is warranted, but lots of peopl= e have it. We can also debate the GCM issues, but GCM is tetchy to use prope= rly. And yes, you could always use CCM instead. But most people don't know t= hat CCM is part of TLS 1.2. I didn't know it I discovered it while writing t= his note. Well, neither GCM nor CCM are part of TLS 1.2 itself, but both can be used w= ith it as additional cipher suites. > The general opinion about TLS 1.2 is that that's the version for Suite B. T= hat's not precisely true. I had that I don't think that's true at all, TLS 1.2 is just a new version of TLS, and S= uite B compatibility comes as a nice plus. > opinion for a while until I learned I was mistaken. However, if you have c= oncerns about either ECC or GCM, then you have concerns about TLS 1.2. I don= 't know if you can do 1.2 without ECC or GCM. This was the first time I've heard this kind of comments. 1.2 is just a new v= ersion of TLS, and it is perfectly fine to continue using the old TLS 1.0 ci= pher suites on TLS 1.2 without touching ECC or GCM at all. I always thought people don't want to implement TLS 1.2 because it brings to= o many changes that are difficult to test properly (selectable hashes etc). B= ut if someone thinks ECC and GCM/CCM are somehow compulsory, I think that sh= ould be clarified. And personally I think defining AEAD for TLS1.0+ might be a good idea. It wo= uld be really easy to implement compared to the full TLS1.2 specification. Juho From mcgrew@cisco.com Wed Mar 20 02:55:51 2013 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 B31FC21F8A41 for ; Wed, 20 Mar 2013 02:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 YDLFxvyJeLNR for ; Wed, 20 Mar 2013 02:55:51 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id ED29621F8A47 for ; Wed, 20 Mar 2013 02:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2952; q=dns/txt; s=iport; t=1363773351; x=1364982951; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=m5Nr3Z/zGLgaPY+jnDMdm0bpXh4VW79Nn6qE5aBkRkc=; b=I4+vcYKoEgsXis0l5emvcwwUCeYAv+veDS8qPEPoyxZorertpqpjkLcl ioWrKrA+nU/01/TqjhgKyKd2PyjOta6WTIsyW5bZJXrie9UWgnHQDKU8B D+mee1866UBgYV4h1QdrkL4qePjcY9aJHmTLIFbN2r4aFYLcsYfRb/Fej E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGCHSVGtJXG+/2dsb2JhbABDxRKBSBZ0giQBAQEDAQEBATc0CxIBCBgKFDcLJQIEAQ0FCAGIBQYMwhAXjDyCIjEHgl9hA6digwqCKA X-IronPort-AV: E=Sophos;i="4.84,876,1355097600"; d="scan'208";a="186440167" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 20 Mar 2013 09:55:28 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2K9tRAZ008319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Mar 2013 09:55:27 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 20 Mar 2013 04:55:27 -0500 From: "David McGrew (mcgrew)" To: Jon Callas , Simon Josefsson Thread-Topic: [Cfrg] Salsa20 stream cipher in TLS Thread-Index: AQHOJOIar3FapCbYoEGyY4Iqyk/e/pit/XkAgABrnQA= Date: Wed, 20 Mar 2013 09:55:26 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B183EC751@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Salsa20 stream cipher in TLS 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 Mar 2013 09:55:51 -0000 Hi Jon, On 3/19/13 7:30 PM, "Jon Callas" wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Mar 19, 2013, at 1:41 PM, Simon Josefsson wrote: > >> I'm not sure why TLS 1.2 isn't negotiated more often by browsers. If it >> is an implementation issue, I'm not convinced specifying AEAD ciphers >> for TLS 1.0 and TLS 1.1 will help: they just get another implementation >> issue to implement that instead. Admittedly, it is a different >> implementation task, so it may be fixed earlier than the other issue, >> but that is difficult to predict. Generally, it might be better to push >> browsers vendors to switch to TLS 1.2 more quickly, then the problem is >> also solved. > >There are two reasons. Uncertainty about ECC, and uncertainty about GCM. > >We can debate how much the ECC uncertainty is warranted, but lots of >people have it. We can also debate the GCM issues, but GCM is tetchy to >use properly. >And yes, you could always use CCM instead. But most people don't know >that CCM is part of TLS 1.2. I didn't know it I discovered it while >writing this note. > >The general opinion about TLS 1.2 is that that's the version for Suite B. >That's not precisely true. I had that opinion for a while until I learned >I was mistaken. However, if you have concerns about either ECC or GCM, >then you have concerns about TLS 1.2. I don't know if you can do 1.2 >without ECC or GCM. TLSv1.2 barely mentions either GCM or ECC, much less requires their use. RFC 5246 says: in the absence of an application profile standard specifying otherwise, a TLSv1.2-compliant application MUST implement the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA. No ECC or GCM ciphersuites are mentioned in that RFC. On the flip side, there are benefits in using that version; v1.2 allows to use SHA256 in key derivation (PRF) and message authentication (HMAC), allows the use of AEAD, and adds other fixes. GCM does require a distinct nonce for each encryption operation, which makes it vulnerable to "nonce misuse", or makes it tetchy as you say. However, this property is a non-issue in TLS, since it is easy to use a sequence number as a nonce, and session keys don't persist between sessions. For comparison, Salsa20 and UMAC, both recently mentioned on this thread, would also have exactly the same distinct-nonce requirement, and essentially RC4 does as well (in the sense that an application that mis-manages the RC4 state would likely cause a loss of confidentiality). David > > Jon > > >-----BEGIN PGP SIGNATURE----- >Version: PGP Universal 3.2.0 (Build 1672) >Charset: us-ascii > >wj8DBQFRSPUpsTedWZOD3gYRAimEAJ0V1eXYxUqRHxWWNaX1GzZJIIz0ZgCfRBXF >48rWFyQymJ1znyyvWCKO4MY=3D >=3DJh5v >-----END PGP SIGNATURE----- >_______________________________________________ >Cfrg mailing list >Cfrg@irtf.org >http://www.irtf.org/mailman/listinfo/cfrg From mrex@sap.com Wed Mar 20 10:59:01 2013 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 5060621F84F8; Wed, 20 Mar 2013 10:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.332 X-Spam-Level: X-Spam-Status: No, score=-10.332 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 WvU3krwvzdgv; Wed, 20 Mar 2013 10:59:00 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6AABE21F84E9; Wed, 20 Mar 2013 10:59:00 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r2KHwuhH028353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Mar 2013 18:58:56 +0100 (MET) In-Reply-To: To: Wan-Teh Chang Date: Wed, 20 Mar 2013 18:58:56 +0100 (CET) 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: <20130320175856.80A7A1A652@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Simon Josefsson , "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [TLS] Salsa20 stream cipher in TLS 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, 20 Mar 2013 17:59:01 -0000 Wan-Teh Chang wrote: > On Tue, Mar 19, 2013 at 8:10 AM, Adam Langley wrote: > > > > In short, I'm implementing AES-GCM at the moment because we need the > > option and there's already a fair amount of deployment. However, I'd > > be happy to see a Salsa20 option too. Without it, AES-GCM would be the > > only reasonable ciphersuite in TLS for the future. > > Another problem with the AES-GCM cipher suites they can't be used with > older versions of TLS. The most obvious problem is that the GenericAEADCipher > struct is only defined in the TLS 1.2 RFC. (Key expansion also needs to > generate client_write_IV and server_write_IV.) > > Although it may be possible to retrofit GenericAEADCipher into TLS 1.0 and > 1.1, the existing implementations of the AES-GCM cipher suites restrict them > to TLS 1.2, so there will still be interoperability problems. Technically, it would be simple, sensible and straightforward to offer AES-GCM for TLSv1.0 and TLSv1.1. The Definition of the GenericAEADCipher PDU is a non-issue, that'll work just fine with TLSv1.1 and TLSv1.0. The most significant problem is the gossip/nonsense in rfc5288 section 4 and rfc6655 section 5; and then there is the desired use of a SHA-256 PRF (implied by rfc6655, explicit in rfc5288) or SHA-384 PRF (for the _SHA384 cipher suites in rfc5288). It is an urban myth that changing the PRF would be easier in TLSv1.2 than it is in TLSv1.0 or TLSv1.1. There is actually *ZERO* difference. It is at most unusual to do it in TLSv1.0 and TLSv1.1, because very few existing cipher suites require it. Being able to plug-n-play the TLS PRF for specific cipher suites was already an explicit design goal in TLSv1.0, see: http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0218.html http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0230.html For example: while there is no support for TLS extensions (rfc3546) in Microsoft Windows SChannel of Windows 2000 and XP, replacing the PRF in Microsoft SChannel with third-party crypto plugins has always been possible, see CryptCreateHash() and CryptDeriveKey() functions and the ALGID parameters CALG_TLS1_MASTER, CALG_SCHANNEL_*, which were already defined in the Visual Studio 98 "wincrypt.h" header file from 23-Apr-1998. There exist third-party plugins that provide TLS GOST cipher suites for use with Microsoft SChannel (and therefore all of its callers, such as MSIE) on Windows 2000&XP, and they change all relevant things --TLS PRF, asymmetric, symmetric and hash algs, the contents of the KexExchange and "digitally signed struct", as well as the content of the "Finished" handshake messages. > > Assuming we can solve the problems of using GenericAEADCipher and > updating key expansion in TLS 1.0 and 1.1, new AEAD cipher suites can > describe how they will be used in older versions of TLS from day one. > So it still seems worthwhile to solve the problem of using AEAD cipher > suites in TLS 1.0 and 1.1. My personal problem with TLSv1.2 (which causes me to completely ignore it) is the fouled up "SignatureAlgorithms" extensions and the braindead semantics rfc5246 defines how that flawed extension is supposed to interfere with signatures on certificates. The way it is currently defined, TLSv1.2 interferes VERY BADLY with interop of scenarios that work just fine with TLSv1.0 and TLSv1.1. It is also currently impossible to support GOST cipher suites _and_ offer TLSv1.2 (whereas GOST works just fine with TLSv1.0 and TLSv1.1). -Martin From mrex@sap.com Wed Mar 20 16:54:12 2013 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 DEC5C21F866F for ; Wed, 20 Mar 2013 16:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.014 X-Spam-Level: X-Spam-Status: No, score=-10.014 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_38=0.6, 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 EQztoD1ts7h1 for ; Wed, 20 Mar 2013 16:54:11 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E0EC421F8620 for ; Wed, 20 Mar 2013 16:54:10 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r2KNs1AQ009525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Mar 2013 00:54:01 +0100 (MET) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73375E1C36@uxcn10-2.UoA.auckland.ac.nz> To: Peter Gutmann Date: Thu, 21 Mar 2013 00:54:01 +0100 (CET) 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: <20130320235401.208911A653@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] The consensus is half-mistaken (Re: Confirming consensus for ALPN) 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, 20 Mar 2013 23:54:12 -0000 Peter Gutmann wrote: > Russ Housley writes: > > >I'd prefer a solution that is architected with this goal in addition to the > >original goals of SSL/TLS. I'm concerned that an extension to TLS 1.2 will > >be an improvement, but it will be far short of a handshake that was > >structured to that set of goals. > > My objection is somewhat similar, at the moment ALPN is a one-off kludge (as > is NPN). The next time we want to do something like this, we'll have to add > another one-off kludge. And then another. And another. Asking the list to > choose between kludge #1 and kludge #2 is kind of misleading when there are > better ways to do this. I'd really prefer to have some sort of general post- > handshake extension mechanism that can be used, like the existing pre- > handshake extensions, to add all the capabilities that people will dream up in > the future. Then ALPN just becomes a newly-defined extension, and new > capabilities can be easily added by defining a new extension type. You mean something like a TLS protected extensions handshake message that is inserted between the CCS and the Finished handshake message on both directions, becoming the first protected message and still being covered/authenticated by the handshake message hash? Only for the initial aka "full" TLS handshake (because on the abbreviated aka "session resume" handshake, the sequence of the CCS&Finished is reversed, i.e. the Server sends the first Finished handshake message and the Client confirms it), or on both handshake types? Or are you thinking of exchanging protected extensions _after_ the Finished handshake message(s)? -Martin PS: Different to Nico, I strongly prefer to keep handshake message types clearly recognizable in the cleartext part of the TLS record protocol, including renegotiation. I do *not* see this as a problem. I'm actively using that data for preprocessing incoming SSL records on my network wrapper for non-blocking operation, because having to dive through the entire TLS protocol engine for record reassembly is ugly, complex and a significant waste of resources. Btw., I'm not a fan of client-side SSL proxies that MitM HTTPS with fake server certs. I wished, that such activities would be a felony criminal offense in more countries than just in Germany. And yes, this is undoubtely illegal in Germany for employers doing that on HTTPS traffic of employees, no matter what some clueless lawyers claim. From jon@callas.org Wed Mar 20 16:54:19 2013 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 833AF11E80F2 for ; Wed, 20 Mar 2013 16:54:18 -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 cEAQULi8XbQ6 for ; Wed, 20 Mar 2013 16:54:17 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1E15C11E80F9 for ; Wed, 20 Mar 2013 16:54:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id CFB0424EDA70; Wed, 20 Mar 2013 16:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nl7KBUqcwMea; Wed, 20 Mar 2013 16:54:05 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 7A79F24EDA4A; Wed, 20 Mar 2013 16:54:05 -0700 (PDT) Received: from mab.hardwired ([66.241.70.254]) by keys.merrymeet.com (PGP Universal service); Wed, 20 Mar 2013 16:54:05 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 20 Mar 2013 16:54:05 -0700 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jon Callas In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B183EC751@xmb-rcd-x04.cisco.com> Date: Wed, 20 Mar 2013 16:53:55 -0700 Message-Id: References: <747787E65E3FBD4E93F0EB2F14DB556B183EC751@xmb-rcd-x04.cisco.com> To: David McGrew (mcgrew) X-Mailer: Apple Mail (2.1503) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Simon Josefsson , Jon Callas , "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Salsa20 stream cipher in TLS 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 Mar 2013 23:54:19 -0000 On Mar 20, 2013, at 2:55 AM, David McGrew (mcgrew) = wrote: > TLSv1.2 barely mentions either GCM or ECC, much less requires their = use. > RFC 5246 says: in the absence of an application profile standard > specifying otherwise, a TLSv1.2-compliant application MUST implement = the > cipher suite TLS_RSA_WITH_AES_128_CBC_SHA. No ECC or GCM ciphersuites = are > mentioned in that RFC. On the flip side, there are benefits in using = that > version; v1.2 allows to use SHA256 in key derivation (PRF) and message > authentication (HMAC), allows the use of AEAD, and adds other fixes. >=20 > GCM does require a distinct nonce for each encryption operation, which > makes it vulnerable to "nonce misuse", or makes it tetchy as you say. > However, this property is a non-issue in TLS, since it is easy to use = a > sequence number as a nonce, and session keys don't persist between > sessions. For comparison, Salsa20 and UMAC, both recently mentioned = on > this thread, would also have exactly the same distinct-nonce = requirement, > and essentially RC4 does as well (in the sense that an application = that > mis-manages the RC4 state would likely cause a loss of = confidentiality). I apologize for note being organized in my typing. Let me try again. Rightly or wrongly, there's a perception both on the implementation end = and the deployment end that TLS 1.2 is the "Suite B" version of TLS, = that it's mandatory to implement and mandatory to deploy. That this is a = misperception is in fact what part of the problem is. I've held many of = these misperceptions myself, and if someone as expert as I doesn't grok = TLS 1.2, then how is the average developer or sysadmin going to = understand? TLS 1.2 needs some marketing that explains why people want it, and that = needs to include reassurance that it doesn't require you to commit to = ECC and GCM. Many people out there believe precisely this. Jon From agl@google.com Wed Mar 20 17:04:54 2013 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 E24D811E8109 for ; Wed, 20 Mar 2013 17:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, 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 fZv0g0hYnZFQ for ; Wed, 20 Mar 2013 17:04:54 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6311311E80F2 for ; Wed, 20 Mar 2013 17:04:47 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id a11so2684796iee.11 for ; Wed, 20 Mar 2013 17:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uhmlFDDrgvu//LHMNaQ8hFgdEeaE3IsZ3o7nj/IHQ/s=; b=fWtN1ZyMA9TYLqpdgrGeHratWXBmXmOrQgojqvTWCLDalzXsX93Ob+YR5xt4/5qgVp nBtvmlSj552hF/2KIovbwt6N21qW42zJkQgikccyWsP+tM9GSNIq4P/AHnwpHROR87eT RbjR9g3maU3IRkqrtyFvuKozSfGIQPP2Z0WSswQSKazarxoJlYz263Cuu2NOx7Vtw11H Apw8n/Tai7SGCF/X52/zVU2pFucL4wJtFLbKfQAIY83c7h88zvq92v0BEdONDYY7dhJE i1Qzaj5UVlj3RTmaQOEqe0u7Br6qQeojaqj8dihWv+gY7+DNT6v/jGaUxiBLyHZ0MNmn ZKcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=uhmlFDDrgvu//LHMNaQ8hFgdEeaE3IsZ3o7nj/IHQ/s=; b=pIoAXBJOvIdsEKECrBUvlknYnbNFiJxqUBlgsLAIhOmRjlePWwKGCqKvsLyQlyFpNU /5c6XRfhUytBaaw4fH99XY6yjAbdbIPv0JEvX3x1IPOloPvUEi8V9HQubIoYo+WE91oM QuThuWdc8jGJ4vrj8N2EFBpnDeDDiwQWY4ujrR9MYFCWp1gLIb9c9GcExBhhRQxlWsoc 8vwwY2UKddfISQkUCa4BXJv1zNtH87lkJB6yH3tkrWBNWztk3jXWyv7xJnnrBwY5c3wo WrZiv7GLMB3Wrpdva/0GB1hTmZm/5l6Galn+OfEoRei3M38Ryr7xnclRbZshrkylniNm /VMQ== MIME-Version: 1.0 X-Received: by 10.50.30.69 with SMTP id q5mr857150igh.1.1363824286906; Wed, 20 Mar 2013 17:04:46 -0700 (PDT) Received: by 10.231.229.135 with HTTP; Wed, 20 Mar 2013 17:04:46 -0700 (PDT) In-Reply-To: References: <747787E65E3FBD4E93F0EB2F14DB556B183EC751@xmb-rcd-x04.cisco.com> Date: Wed, 20 Mar 2013 20:04:46 -0400 Message-ID: From: Adam Langley To: Jon Callas Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQn4typEXPpZjYz3c1SiPtpGIs6K/BWrU+f5/dWgLwwZH2nyURXIUvrbjy5KL6xv3TrxxX3wN6ford5wIP1nUU9sbSX1k+jnMS3IYpdNZLPi6A0iMtEa+NusruydcaVxDj5iBxpkA1cgpeYP/kbd2LQw2XtFAXhzD2Zrwxj7HscpGCvaT90xvgho80ui2aqHXPEK+wAw Cc: Simon Josefsson , "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Salsa20 stream cipher in TLS 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, 21 Mar 2013 00:04:55 -0000 On Wed, Mar 20, 2013 at 7:53 PM, Jon Callas wrote: > TLS 1.2 needs some marketing that explains why people want it, and that needs to include reassurance that it doesn't require you to commit to ECC and GCM. Many people out there believe precisely this. I believe that the reason that TLS 1.2 hasn't seen wider deployment is that it causes compatibility issues and the motivation hasn't previously been strong enough. Microsoft, for example, have had TLS 1.2 support in SChannel for a while, but IE doesn't send TLS 1.2 ClientHellos because they break some sites. When Chrome enabled TLS 1.1 support, we had to add a fairly promiscuous fallback to TLS 1.0 (on top of the fallback to SSLv3) to address these problems. NSS doesn't have TLS 1.2 support (yet; it's coming) because there are, in general, more people talking about TLS than working on the underlying libraries :) Those that do have many other things that they can be working on and spending time on TLS 1.2 support hasn't had the best cost/benefit tradeoff yet. I don't think that ECC or GCM fear plays a part. There may be people who have that fear, but I don't think they are deciding, for the most part, what gets implemented in browsers and many servers. (And, as noted, the ECC part is nonsense: Google has been using ECDHE with TLS 1.0, 1.1 and 1.2 for a while now.) Cheers AGL From nico@cryptonector.com Wed Mar 20 17:52:35 2013 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 CCBFB11E8121 for ; Wed, 20 Mar 2013 17:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.955 X-Spam-Level: X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 oFvC1dDPoC3V for ; Wed, 20 Mar 2013 17:52:35 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4748A11E8119 for ; Wed, 20 Mar 2013 17:52:35 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id AD1743B805C for ; Wed, 20 Mar 2013 17:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=wA0HnROG/UkXiW6Q9n/cGTPhff0=; b=F4MRwt34IEu wg4pdb/wCpGSgXP2+Zlx4zwXfSyQZddEmfu2nSd8YdpHxiIh5BHvRXkeJDialLqI stKxQ+BS3J8GyKpzrPWKCallFQiORjx4gw3TrxnAHbK9qwXP+4rL7K74jO/xHZlY OURPg1GslQFpYvhVZ9slf4mANGJWQluo= Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 525303B800B for ; Wed, 20 Mar 2013 17:52:34 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id 16so70354wgi.15 for ; Wed, 20 Mar 2013 17:52:33 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.158.161 with SMTP id wv1mr13901894wjb.38.1363827153057; Wed, 20 Mar 2013 17:52:33 -0700 (PDT) Received: by 10.217.105.195 with HTTP; Wed, 20 Mar 2013 17:52:32 -0700 (PDT) Date: Wed, 20 Mar 2013 19:52:32 -0500 Message-ID: From: Nico Williams To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e013c6ab0fe42cf04d864c023 Subject: [TLS] Missing cipher: anon ephemeral ECDH w/ SHA-2 nor AEAD modes 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, 21 Mar 2013 00:52:36 -0000 --089e013c6ab0fe42cf04d864c023 Content-Type: text/plain; charset=UTF-8 Note that anon cipher suites are useful for: - SMTP - apps that want to use tls-unique channel bindings This is bad because ECDH is faster, has smaller public keys, but lacking these cipher suites we're stuck with using either TLS_ECDH_anon w/ SHA-1 suites or TLS_DH_anon suites. Please fix :) Nico -- --089e013c6ab0fe42cf04d864c023 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Note that anon cipher suites are useful for:

=C2=A0- SMT= P
=C2=A0- apps that want to use tls-unique channel bindings
=

This is bad because ECDH is faster, has smaller public = keys, but lacking these cipher suites we're stuck with using either TLS= _ECDH_anon w/ SHA-1 suites or TLS_DH_anon suites.

Please fix :)

Nico
-= -=C2=A0

--089e013c6ab0fe42cf04d864c023-- From mrex@sap.com Wed Mar 20 18:06:37 2013 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 B4CF911E810D for ; Wed, 20 Mar 2013 18:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.22 X-Spam-Level: X-Spam-Status: No, score=-10.22 tagged_above=-999 required=5 tests=[AWL=0.029, 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 p1pUa8Ism-UA for ; Wed, 20 Mar 2013 18:06:37 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1E711E80FD for ; Wed, 20 Mar 2013 18:06:35 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r2L16W7T016698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Mar 2013 02:06:32 +0100 (MET) In-Reply-To: To: Nico Williams Date: Thu, 21 Mar 2013 02:06:31 +0100 (CET) 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: <20130321010631.F1A651A653@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Missing cipher: anon ephemeral ECDH w/ SHA-2 nor AEAD modes 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: Thu, 21 Mar 2013 01:06:38 -0000 Nico Williams wrote: > > Note that anon cipher suites are useful for: > > - SMTP > - apps that want to use tls-unique channel bindings > > This is bad because ECDH is faster, has smaller public keys, but lacking > these cipher suites we're stuck with using either TLS_ECDH_anon w/ SHA-1 > suites or TLS_DH_anon suites. > > Please fix :) http://tools.ietf.org/html/rfc5246#appendix-D.3 A proper implementation will probably not support many cipher suites. For instance, anonymous Diffie-Hellman is strongly discouraged because it cannot prevent man- in-the-middle attacks. Our TLS implementation does not contain anonymous cipher suites, and I stronly doubt that anyone could provide a convincing rationale to change that. For SMTP(STARTTLS), I consider the lack of authentication in the original SMTP infrastructure as well as most of the STARTTLS installed base to part of the _problem_space_. And while I'm not particularly enthusiastic about misleading DANE band-aids to SMTP-STARTTLS, I consider that approach preferable to anonymous TLS cipher suites by a huge margin. -Martin From pgut001@cs.auckland.ac.nz Wed Mar 20 21:41:52 2013 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 C994611E80EE for ; Wed, 20 Mar 2013 21:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_38=0.6] 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 hdTXavHrkD+3 for ; Wed, 20 Mar 2013 21:41:50 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id AB60D11E80BA for ; Wed, 20 Mar 2013 21:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1363840909; x=1395376909; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=JxtrwGsOAHA3dfbmuQNsAGHgsJ7xqR3FjqMc9aBsQHM=; b=dcBdJbdEyXw22zxtBQAt8Je58kh8PImVlYTIc2PTqo4qLXZRiVi29GGe gjNDCiNovwcOolgZE7qpXucRM1hxblsTn7sOBfg3GHwvzn/oAe4UZ9aOc FrW2KAiqeE4kjAmTJgCJ974nhPukmOt3a9k+dxgFumJ15cyaEQSsJPpYp k=; X-IronPort-AV: E=Sophos;i="4.84,883,1355050800"; d="scan'208";a="176956637" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Mar 2013 17:41:48 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.115]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 17:41:47 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] The consensus is half-mistaken (Re: Confirming consensus for ALPN) Thread-Index: Ac4l7mVDy9HF9SLdSFqDp0gyz61wBg== Date: Thu, 21 Mar 2013 04:41:47 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D245B5@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] The consensus is half-mistaken (Re: Confirming consensus for ALPN) 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, 21 Mar 2013 04:41:53 -0000 Martin Rex writes:=0A= =0A= >You mean something like a TLS protected extensions handshake message that = is=0A= >inserted between the CCS and the Finished handshake message on both=0A= >directions, becoming the first protected message and still being=0A= >covered/authenticated by the handshake message hash?=0A= >=0A= >Only for the initial aka "full" TLS handshake (because on the abbreviated = aka=0A= >"session resume" handshake, the sequence of the CCS&Finished is reversed, = i.e.=0A= >the Server sends the first Finished handshake message and the Client confi= rms=0A= >it), or on both handshake types?=0A= >=0A= >Or are you thinking of exchanging protected extensions _after_ the Finishe= d=0A= >handshake message(s)?=0A= =0A= Yes.=0A= =0A= (I'm happy to be persuaded that either is better, but if I said I wanted #1= =0A= and not #2 it'd split things even further. At the moment I'd just like to = get=0A= away from the idea that we're required to choose between kludge A and kludg= e=0A= B, and then have to revisit the whole thing every few months when someone= =0A= wants another new extension added.=0A= =0A= If I have to express a preference I'd go for option #2, mirroring how START= TLS=0A= et al work).=0A= =0A= Peter.= From pgut001@cs.auckland.ac.nz Wed Mar 20 21:49:57 2013 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 6A79421F8D68 for ; Wed, 20 Mar 2013 21:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 euz2n9Qs9xVp for ; Wed, 20 Mar 2013 21:49:55 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 451AA21F8D59 for ; Wed, 20 Mar 2013 21:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1363841395; x=1395377395; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=wkZh4t/qPcRXenaABR0IebEVphdl/qvVVl9qXjs66z8=; b=byVF16zZxbanlPIA7GA1mM/52grUOQRlpdqajwmvQqLCYCo8ZxTZqrOW BlO6BqS7+iqmWmQGdZBNfGAj+7XTTF9xVfl1UCEoJis+qoZXimTyzOS3s 3RIgCi1wjqA/k8M22ZWt5qVmIoI5BfZKw7dcfACkF0diA4vLKaOYU6H2y w=; X-IronPort-AV: E=Sophos;i="4.84,883,1355050800"; d="scan'208";a="176957505" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Mar 2013 17:49:54 +1300 Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe1.UoA.auckland.ac.nz (130.216.4.112) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 21 Mar 2013 17:49:53 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.115]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 17:49:53 +1300 From: Peter Gutmann To: "cfrg@irtf.org" , "tls@ietf.org" Thread-Topic: [TLS] [Cfrg] Salsa20 stream cipher in TLS Thread-Index: Ac4l74bCx0Msako7Rh2/1VlfqG02AA== Date: Thu, 21 Mar 2013 04:49:52 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D245C7@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] [Cfrg] Salsa20 stream cipher in TLS 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, 21 Mar 2013 04:49:57 -0000 Adam Langley writes:=0A= >On Wed, Mar 20, 2013 at 7:53 PM, Jon Callas wrote:=0A= > TLS 1.2 needs some marketing that explains why people want it, and that= =0A= > needs to include reassurance that it doesn't require you to commit to ECC= =0A= > and GCM. Many people out there believe precisely this.=0A= >=0A= >I believe that the reason that TLS 1.2 hasn't seen wider deployment is tha= t=0A= >it causes compatibility issues and the motivation hasn't previously been= =0A= >strong enough.=0A= =0A= Exactly. Getting back to Jon's point that "it needs some marketing that=0A= explains why people want it", I can't think of any reason why you'd want it= .=0A= It causes compatibility problems, but I can't think of any pressing issue t= hat=0A= it solves apart from "we need to do Suite B". This is why it's seen as "TL= S=0A= with Suite B", because that's it's sole marketing point.=0A= =0A= Look at OCSP pinning as a counterexample. Virtually every major site deplo= yed=0A= this as quickly as they could, because the site owners recognised that if t= hey=0A= didn't do it, they'd take a significant performace hit or even complete OCS= P-=0A= induced site outages (on hard fail).=0A= =0A= If you don't deploy TLS 1.2 OTOH, nothing happens. You're no slower, no le= ss=0A= available, no less secure... the only thing you don't have is Suite B. I= =0A= implemented it some time ago and so far the sole users have been (a) a smal= l=0A= number of users who wanted Suite B and (b) an even smaller number of users,= =0A= mostly in Europe, who insisted on having the largest version number of TLS= =0A= they could get. Most of the latter went back to 1.1 when they started runn= ing=0A= into problems with interoperability.=0A= =0A= Peter.= From pgut001@cs.auckland.ac.nz Wed Mar 20 21:54:00 2013 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 E151921F855C for ; Wed, 20 Mar 2013 21:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 S7oT3+Y1kR-c for ; Wed, 20 Mar 2013 21:53:58 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id B30E921F8558 for ; Wed, 20 Mar 2013 21:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1363841638; x=1395377638; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=s/OyeklOnLpiKtTzUwNgt9gv052BameKikB6/FeO9Sk=; b=uLfgA835YVa3EkFng2UM4BbqSUbMer5ffyweEI44o2TrxMnUGaSqBLuI AyiKEbnCQ9fIdphgZLMGQIPOfGUoRpDHLEfyuTnUk03XVbcRAhXzOTpUm 43C3V0K1Zmnme1+khYUqQdmXG36BNVZB9Mr2fdkQfso+LjqfUeSkXj/hq g=; X-IronPort-AV: E=Sophos;i="4.84,883,1355050800"; d="scan'208";a="176959034" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Mar 2013 17:53:57 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.115]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 17:53:56 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] Missing cipher: anon ephemeral ECDH w/ SHA-2 nor AEAD modes Thread-Index: Ac4l8BguyiTHv7MdQh2QjBPZqaAIOg== Date: Thu, 21 Mar 2013 04:53:56 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D245D6@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Missing cipher: anon ephemeral ECDH w/ SHA-2 nor AEAD modes 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, 21 Mar 2013 04:54:00 -0000 Martin Rex writes:=0A= =0A= >Our TLS implementation does not contain anonymous cipher suites, and I=0A= >stronly doubt that anyone could provide a convincing rationale to change= =0A= >that.=0A= =0A= Just a small technical nit here, if your implementation provides a means of= =0A= clicking past certificate mismatches then it provides effective anon-DH eve= n=0A= if it's not directly implemented as such. A lot of deployment of bulk-traf= fic=0A= TLS (e.g. for STMP via STARTTLS, and many VPNs) is also effective anon-DH.= =0A= Since it uses RSA for this, it's effective anon-DH without any of its=0A= advantages.=0A= =0A= Peter.=0A= From geoffk@geoffk.org Wed Mar 20 22:07:04 2013 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 3D50D21F8F07 for ; Wed, 20 Mar 2013 22:07:03 -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 qGN0ZbfkyUba for ; Wed, 20 Mar 2013 22:07:01 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id CE5D321F8F06 for ; Wed, 20 Mar 2013 22:07:00 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id B189733D025; Thu, 21 Mar 2013 05:06:56 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Peter Gutmann References: <9A043F3CF02CD34C8E74AC1594475C7343D245C7@uxcn10-2.UoA.auckland.ac.nz> From: Geoffrey Keating Date: 20 Mar 2013 22:06:56 -0700 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7343D245C7@uxcn10-2.UoA.auckland.ac.nz> Message-ID: Lines: 23 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Salsa20 stream cipher in TLS 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, 21 Mar 2013 05:07:04 -0000 Peter Gutmann writes: > Adam Langley writes: > >On Wed, Mar 20, 2013 at 7:53 PM, Jon Callas wrote: > >I believe that the reason that TLS 1.2 hasn't seen wider deployment is that > >it causes compatibility issues and the motivation hasn't previously been > >strong enough. ... > It causes compatibility problems, but I can't think > of any pressing issue that it solves apart from "we need to do Suite > B". ... It also lets you do GCM, which has performance benefits over AES+SHA1. Part of the reason TLS 1.2 doesn't solve issues is because people were willing to go to great lengths to avoid going to a higher TLS version, even in cases where a new version would be the obvious and simplest choice, the zero-size record hack and renegotiation cipher suite/extension being two examples that come to mind. So are we now in a catch-22 where no-one will upgrade because they don't need to because all the fixes are shoehorned into the current version because no-one will upgrade? From pgut001@cs.auckland.ac.nz Wed Mar 20 22:36:32 2013 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 B903C21F8F83 for ; Wed, 20 Mar 2013 22:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 GJ0JiCj7mgN4 for ; Wed, 20 Mar 2013 22:36:31 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 2596521F9002 for ; Wed, 20 Mar 2013 22:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1363844190; x=1395380190; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=yL3K2zCGuCVNgX4B36InR2hI3vfUey74JCNmHghsabk=; b=T0gUzhPTnBNSJnXXunRbGSBG0n+/dDPGUSj61fX+vOBEfzjKSJaQ40+K G2YtaGwfsTj7hN/atxGGP2pywyu41TE2CZwjedX7w0wGnBOxPxmGmkm3O ZaCbTKkkNNDnqNUbBbCpvPYytEwr7t9axwjINjSF00s1RDPsxDxJ/AGtX E=; X-IronPort-AV: E=Sophos;i="4.84,883,1355050800"; d="scan'208";a="176963893" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Mar 2013 18:36:25 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.115]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 18:36:25 +1300 From: Peter Gutmann To: "cfrg@irtf.org" , "tls@ietf.org" Thread-Topic: [Cfrg] Salsa20 stream cipher in TLS Thread-Index: Ac4l9gauvD7G5gucTheQ1FuELorOyg== Date: Thu, 21 Mar 2013 05:36:24 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D25628@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] [Cfrg] Salsa20 stream cipher in TLS 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, 21 Mar 2013 05:36:33 -0000 Geoffrey Keating =0A= =0A= >It also lets you do GCM, which has performance benefits over AES+SHA1.=0A= =0A= It does? GMAC is kind of a pig unless you've got hardware assist... and=0A= speaking of hardware, if you're using an ASIC for it you don't have much=0A= choice, it's mostly HMAC-SHA1 only. Even with that aside, anyone who's rea= lly=0A= worried about performance seems to be using RC4.=0A= =0A= >So are we now in a catch-22 where no-one will upgrade because they don't n= eed=0A= >to because all the fixes are shoehorned into the current version because n= o-=0A= >one will upgrade?=0A= =0A= I'm not sure I'd characterise it as "shoehorned", a better view would be th= at=0A= the existing versions fix pretty much everything that needs fixing except t= he=0A= MAC-then-encrypt problem, and given that 1.2 is such a huge change that it'= s=0A= almost a new protocol in parts (the change from 1.1 to 1.2 is much bigger t= han=0A= the change from SSL to TLS), it's not surprising that there's no great rush= to=0A= move to it.=0A= =0A= It's also a killer roadblock to any new changes in 1.3. Since even the mos= t=0A= trivial change (to get to 1.3) will involve implementing and deploying all = of=0A= 1.2, people will keep adding stuff to 1.1 rather than have to go through th= e=0A= pain of 1.2 in order to add new features. So in that sense you're right,= =0A= we're going to keep seeing changes to 1.1 rather than having them added in= =0A= 1.3. 1.2 is too big a hurdle for too small a gain.=0A= =0A= Kinda scary when you look at it like that...=0A= =0A= Peter.= From pgut001@cs.auckland.ac.nz Wed Mar 20 23:16:08 2013 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 F0C2621F8D65 for ; Wed, 20 Mar 2013 23:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 TtACW0IYpzF8 for ; Wed, 20 Mar 2013 23:16:08 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id C2C1521F84DF for ; Wed, 20 Mar 2013 23:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1363846568; x=1395382568; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=e5ul2HlfcKZeDIgIMbs4D0N1s0myQlaswu6Ykf3ZgXM=; b=uLq9TCCEIQxuaYZ1ZOMw6l9yRgcoWtQhOx/CYMAMqlqhn3rfy79L/mWn FjVHdkHsNxN8ebf9WP5fvuE+sPNw2QuueH8J/xDBsFvO1skyDrmOgEhe7 XZcidm6k+h+2ajoLjakxA5QETMZ+ZD6Jjk8PepLyCWvvtNI6hWYwpaY2X c=; X-IronPort-AV: E=Sophos;i="4.84,884,1355050800"; d="scan'208";a="176967000" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Mar 2013 19:16:07 +1300 Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe1.UoA.auckland.ac.nz (130.216.4.112) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 21 Mar 2013 19:16:06 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.115]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 19:16:06 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: Updated TLS drafts uploaded Thread-Index: Ac4l+5HTUPPm9QB9QD2q1YQ+ZucqOA== Date: Thu, 21 Mar 2013 06:16:05 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D256B7@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] Updated TLS drafts uploaded 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, 21 Mar 2013 06:16:09 -0000 I've just uploaded the updated versions of two TLS drafts, "Standardised EC= C=0A= Cipher Suites for TLS",=0A= http://www.ietf.org/id/draft-gutmann-tls-eccsuites-04.txt, and "Encrypt-the= n-=0A= MAC for TLS", http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac= -01.=0A= Note for the encrypt-then-MAC draft:=0A= =0A= [Implementation note: There is currently a test server=0A= available for interop testing at https://eid.vx4.net:443/.=0A= This uses the "extension_type" value 0x10, which is the=0A= first currently unassigned TLS extension value. This=0A= server has been tested successfully with several different=0A= implementations].=0A= =0A= Since we now have interoperable implementations, and since there seems to b= e=0A= some demand for this (one vendor's response was "this should have been done= =0A= ten years ago"), I'd like to see this moved forward reasonably quickly, alo= ng=0A= with the ECC draft, which has now been around, and stable, for some time.= =0A= =0A= Peter.=0A= From simon@josefsson.org Thu Mar 21 03:27:17 2013 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 D7BF321F8DE5; Thu, 21 Mar 2013 03:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, 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 HHS2cYP-hdFw; Thu, 21 Mar 2013 03:27:17 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6892221F883E; Thu, 21 Mar 2013 03:27:15 -0700 (PDT) Received: from latte.josefsson.org (host-95-192-103-177.mobileonline.telia.com [95.192.103.177]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r2LAQalv018265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 21 Mar 2013 11:26:42 +0100 From: Simon Josefsson To: Peter Gutmann References: <9A043F3CF02CD34C8E74AC1594475C7343D25628@uxcn10-2.UoA.auckland.ac.nz> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130321:cfrg@irtf.org::AXEYTUj7t32Jh4bg:HU7E X-Hashcash: 1:22:130321:tls@ietf.org::zxMPnT91mWG2m9Xz:PrUv X-Hashcash: 1:22:130321:pgut001@cs.auckland.ac.nz::dvlkWYeuAD6jsyyj:K/Jt Date: Thu, 21 Mar 2013 11:26:31 +0100 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7343D25628@uxcn10-2.UoA.auckland.ac.nz> (Peter Gutmann's message of "Thu, 21 Mar 2013 05:36:24 +0000") Message-ID: <87ppytqca0.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] Salsa20 stream cipher in TLS 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, 21 Mar 2013 10:27:18 -0000 Peter Gutmann writes: > It's also a killer roadblock to any new changes in 1.3. Since even the most > trivial change (to get to 1.3) will involve implementing and deploying all of > 1.2, people will keep adding stuff to 1.1 rather than have to go through the > pain of 1.2 in order to add new features. So in that sense you're right, > we're going to keep seeing changes to 1.1 rather than having them added in > 1.3. 1.2 is too big a hurdle for too small a gain. Are people adding stuff to 1.1? My impression is that all serious problems (including renegotiation and the explicit IV problem) are solved in TLS 1.0 too. The problems are solved through specification (think renegotiation) or through implementation fixes (think empty fragments to mimic explicit IVs). For TLS 1.0 and SSL 3.0 to go away, there needs to be a serious enough security problem that is not fixable in TLS 1.0 implementations. I'm not convinced that will happen. We have seen that people will try hard to resolve protocol security problems within TLS 1.0. Thinking about this, perhaps we need a document explaining how to implement TLS 1.0 securely. TLS 1.0 as implemented by RFC 2246 is not secure. The document could say that you need to send bad_record_mac in case of MAC verification failures, and to send empty fragments to combat CBC attacks, and implement renegotiation, and discuss how to combat CBC timing attacks, and something about RC4. And other things I may have forgotten. Right now it seems the knowledge about fixing TLS 1.0 are found in TLS implementations and not discussed in IETF documents. /Simon From agl@google.com Thu Mar 21 03:55:48 2013 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 A679121F9029 for ; Thu, 21 Mar 2013 03:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, 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 iI-McbyhCCfb for ; Thu, 21 Mar 2013 03:55:48 -0700 (PDT) Received: from mail-ia0-x236.google.com (mail-ia0-x236.google.com [IPv6:2607:f8b0:4001:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 37B7C21F9027 for ; Thu, 21 Mar 2013 03:55:48 -0700 (PDT) Received: by mail-ia0-f182.google.com with SMTP id u8so2290384iag.27 for ; Thu, 21 Mar 2013 03:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wDaxG9RJ2nBvyJFxcHcyc/Zeo9D64pTOOr7Wsrwl2VU=; b=Bo4L/EkUEzGWIkIMyHCNpwFbgno0g/j0KAFheigLgQ89ifMvisoHMNaLIYji0pbRAP LjCK928/fLySsTjMOLnWWqRRGURVpj2D/E2KW/tqULapgIruHe468wNiQASs/G9iLJra TwtQm4ohUlv1op2/KwQapMP8dG9K6kN3MU+yYtTTK8Qy+DF8K2pUkwEOiu5/1RBmaa2s je8SkPF4FqDSDsZDnBBcU5j8Qk6zzw7jYQMjaSNCDsa1vcBmVYItEUrDyIJwkak08/Gy odsli1vOYEOKQyF4Yj6ubQq+vQjSg9Jkk48pHvrGliOggt3G+ulvDDGFtfSrSLZoT9e0 rJ8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=wDaxG9RJ2nBvyJFxcHcyc/Zeo9D64pTOOr7Wsrwl2VU=; b=NSUEfBP+4CUdbU5iiblcY0hVBTwDiG+QLyP6lxcWTjg7p7BSTCx+ZQn3hI8fW6y+D8 gquSsSqYPcdkMsCN9vJYkwcfpYbhjO6vjaaS/7QNtA1j5W3q81LgqeP6EIyKXWLwNDRx Z1YyuzjYT+dzJlRntYwCLAlCjJAbIKUVMjyQk9KvR5z2KE5H6NedZqIZ775EXrLdj5Po oZcSGXf4CBqM2wOlZlYPMc2Jac+pEiMOTiTVNc78C3Wq8zKTgSfIFNCC5rIBI6Am3p64 v15FgayCFxlcRwPjpXWL8kRfSis9IRaymJFg6EM+y5IlEUdPqxj7psWUAYSRrbROsatQ gPzg== MIME-Version: 1.0 X-Received: by 10.50.77.233 with SMTP id v9mr1751734igw.74.1363863347779; Thu, 21 Mar 2013 03:55:47 -0700 (PDT) Received: by 10.231.229.135 with HTTP; Thu, 21 Mar 2013 03:55:47 -0700 (PDT) In-Reply-To: <87ppytqca0.fsf@latte.josefsson.org> References: <9A043F3CF02CD34C8E74AC1594475C7343D25628@uxcn10-2.UoA.auckland.ac.nz> <87ppytqca0.fsf@latte.josefsson.org> Date: Thu, 21 Mar 2013 06:55:47 -0400 Message-ID: From: Adam Langley To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmzo12AHDnowo5cQgCS9oXOQlv1lnvwD3/lqsQ1PSjxSYxjEODMb9tLdRUVzf/x1xvYT/8oLbeiPGqMk5EgK59qSzfQNQ49xBw4kYL3aLKdfyvcxz7+IyyPMf8/upIFDyZ0q+RdEqX1b/NH1rIEAhHoUpp2cCA19vRzf1AKeFAOyFjTduDLBRqRrZJrsCV46sUTJGRc Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] Salsa20 stream cipher in TLS 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, 21 Mar 2013 10:55:48 -0000 On Thu, Mar 21, 2013 at 6:26 AM, Simon Josefsson wrote: > Right now it seems the knowledge about fixing TLS 1.0 are found in TLS > implementations and not discussed in IETF documents. I believe that it'll be one of the documents from wpkops, which is chartered to document the current state of the "Web PKI" - including certificate processing and TLS stack operation. The first draft is pending me getting around to writing it. Cheers AGL From ynir@checkpoint.com Thu Mar 21 05:10:09 2013 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 C3FAE21F8E1D; Thu, 21 Mar 2013 05:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.418 X-Spam-Level: X-Spam-Status: No, score=-10.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 AZVdPnKby3TL; Thu, 21 Mar 2013 05:10:09 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 83BBE21F86CB; Thu, 21 Mar 2013 05:09:54 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2LC9PbZ023958; Thu, 21 Mar 2013 14:09:29 +0200 X-CheckPoint: {514AF733-1-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Thu, 21 Mar 2013 14:09:25 +0200 From: Yoav Nir To: Peter Gutmann Thread-Topic: [TLS] [Cfrg] Salsa20 stream cipher in TLS Thread-Index: Ac4l74bCPkc5tmAbHkmmrTIC4WvxcwALKVEA Date: Thu, 21 Mar 2013 12:09:25 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C7343D245C7@uxcn10-2.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7343D245C7@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.171] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <5B1650FD24FEE74E8D627E91ABDB4656@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Salsa20 stream cipher in TLS 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, 21 Mar 2013 12:10:10 -0000 On Mar 21, 2013, at 12:49 AM, Peter Gutmann wro= te: > If you don't deploy TLS 1.2 OTOH, nothing happens. You're no slower, no = less > available, no less secure... the only thing you don't have is Suite B. I > implemented it some time ago and so far the sole users have been (a) a sm= all > number of users who wanted Suite B and (b) an even smaller number of user= s, > mostly in Europe, who insisted on having the largest version number of TL= S > they could get. Most of the latter went back to 1.1 when they started ru= nning > into problems with interoperability. Actually, we turned on TLS 1.2 by default for the speed advantage. iOS begi= ns a TLS handshake with version 1.2, both in ClientHello and in the record = layer. Only when the (shocked and flabbergasted) server closes the connecti= on, does the iPhone try with something more sane like 1.0, and then even ca= ches this for a short while. This takes two extra round-trips. The bug report said "iPhone x is slow to connect" (I don't remember if at t= he time x was 5 or 6. Yoav From agl@google.com Thu Mar 21 05:18:12 2013 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 63AF021F8FB3 for ; Thu, 21 Mar 2013 05:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, 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 Q4uduRC9Qrnq for ; Thu, 21 Mar 2013 05:18:12 -0700 (PDT) Received: from mail-ia0-x22c.google.com (mail-ia0-x22c.google.com [IPv6:2607:f8b0:4001:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E4F6921F8D68 for ; Thu, 21 Mar 2013 05:18:11 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id l29so2381791iag.3 for ; Thu, 21 Mar 2013 05:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=MypFymk4QieoA1rH9jqvXhuymNOmPE3yWiImN1Mjec8=; b=Jg4N29Uf+NZhxRLt/mUqQBDCAoPCy3oI4fQhcJn3i3IeUDB5hRV9ioLnBBx1mOff1m 3JQnPYBlJouD07Wcdbz6lGTWaLWXlGvghbOg1sZwYcUIKg1BI7c5FeaWRqEvb8i0UA8s RgBMbPflKq5u2eqSs8ExjDNscSRWYdJB2K7D0pKuPf3eSzSr8sEiNWmVDST60Dg0bY1g tDsLIOvu6Hn5jcOCAoDg+WaN9idmW6Xnfh2j0vxqL4Qrjx58ECF/w6MHZxO2EXH+vVpA lhb/rCQMeBHp65b/l8DDOy69C1OJqVpph7vFLYGiePzM9Ok3/QJvtkT5KdjnYdCxiwkH V7QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=MypFymk4QieoA1rH9jqvXhuymNOmPE3yWiImN1Mjec8=; b=a/E3NWjCDjn+klyZ54Wv4iSY/b9pe5IAra+t1fzumEHcekxmXsn/hB4bSHv0KyooyP V5VhP+IjBUKWToyBDkyuslErxUk65GkfZRaNqpA3lV2Lq9XRXy2vWD+SmOqVc2vcFM0/ yK/MhW5Nz76rvODNmkuzEHMmpfDaIADRMbLfiT8wfAV5lOONqUvjmTw3K8ASoEiGEAbF NEcC3cNqTP2/T5L9gGNYXgddogyJveYKD+PZeyYHRMJ2mZSPLrSa1cjzUOy7I2tloGX0 16Qud30C5y0mGlnaFS0TZtJLGJcGaYKTVmVpYhps9+l0QcG0Cz+3iVl2R1/TQSwABGcw q98Q== MIME-Version: 1.0 X-Received: by 10.42.145.137 with SMTP id f9mr15924512icv.52.1363868291429; Thu, 21 Mar 2013 05:18:11 -0700 (PDT) Received: by 10.231.229.135 with HTTP; Thu, 21 Mar 2013 05:18:11 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C7343D245C7@uxcn10-2.UoA.auckland.ac.nz> Date: Thu, 21 Mar 2013 08:18:11 -0400 Message-ID: From: Adam Langley To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmv4Oub4kbWw+dnO2sV78+2GfRc+3ZZT73dyjBd9yM51Tvk3nJ8PufYT3fuzM4bAw2uUkE+ciCamPhztN++u9xcsQ5yUYnxR+QW2vmSJHsoH4YM9kIsMYPciwHaCGBe6gYqmhqb9B/4tF73I7CKaxhMkKSnojiH8V2pS+qaR5OhXMks5G24shad+K4QZQc875I9hV8u Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Salsa20 stream cipher in TLS 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, 21 Mar 2013 12:18:12 -0000 On Thu, Mar 21, 2013 at 8:09 AM, Yoav Nir wrote: > Actually, we turned on TLS 1.2 by default for the speed advantage. iOS be= gins a TLS handshake with version 1.2, both in ClientHello and in the recor= d layer. Only when the (shocked and flabbergasted) server closes the connec= tion, does the iPhone try with something more sane like 1.0, and then even = caches this for a short while. But you don't need to switch on TLS 1.2 to fix this, right? The server just needs to implement version negotiation correctly. (On the flip side, this /is/ a problem for clients since the incentives are aligned for clients to stop trying TLS 1.2 since they can't (directly) fix the server.) Cheers AGL From nico@cryptonector.com Thu Mar 21 11:44:24 2013 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 747A321F9109 for ; Thu, 21 Mar 2013 11:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 5AiT-eemtVxL for ; Thu, 21 Mar 2013 11:44:23 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 927CC21F90AF for ; Thu, 21 Mar 2013 11:44:23 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 6379567C06E for ; Thu, 21 Mar 2013 11:44:23 -0700 (PDT) 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; s=cryptonector.com; bh=+fvJNks/C2FPzlVALMgb iBs6Fl8=; b=u1w1Wm69oeAZizV9PKTgEXrp28JGZQuzkfRkk2mWEDpXmY7bcYY/ ocn19sYXMy6pdGhw99jy8Xml1oyMfVfkRc/Z4fCa0oEKeOcQ7Ms5k1YN88+j+oEg Qey0HF6H2HKDiJyVkYN40+cOY1ghjulw31ItGqMYDr614X393u8H+nQ= Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id E436867C073 for ; Thu, 21 Mar 2013 11:44:22 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id dt14so788149wgb.14 for ; Thu, 21 Mar 2013 11:44:21 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.11.70 with SMTP id o6mr19221773wjb.29.1363891461704; Thu, 21 Mar 2013 11:44:21 -0700 (PDT) Received: by 10.217.105.195 with HTTP; Thu, 21 Mar 2013 11:44:21 -0700 (PDT) In-Reply-To: <20130321010631.F1A651A653@ld9781.wdf.sap.corp> References: <20130321010631.F1A651A653@ld9781.wdf.sap.corp> Date: Thu, 21 Mar 2013 13:44:21 -0500 Message-ID: From: Nico Williams To: "mrex@sap.com" Content-Type: multipart/alternative; boundary=047d7b5d456c165db604d873baf6 Cc: "tls@ietf.org" Subject: Re: [TLS] Missing cipher: anon ephemeral ECDH w/ SHA-2 nor AEAD modes 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, 21 Mar 2013 18:44:24 -0000 --047d7b5d456c165db604d873baf6 Content-Type: text/plain; charset=UTF-8 On Wednesday, March 20, 2013, Martin Rex wrote: > Nico Williams wrote: > > > > Note that anon cipher suites are useful for: > > > > - SMTP > > - apps that want to use tls-unique channel bindings > > > > This is bad because ECDH is faster, has smaller public keys, but lacking > > these cipher suites we're stuck with using either TLS_ECDH_anon w/ SHA-1 > > suites or TLS_DH_anon suites. > > > > Please fix :) > > http://tools.ietf.org/html/rfc5246#appendix-D.3 > > A proper implementation will > probably not support many cipher suites. For instance, anonymous > Diffie-Hellman is strongly discouraged because it cannot prevent man- > in-the-middle attacks. That's not relevant. I'm not asking why your implementation is missing some cipher suite: I'm asking why some cipher suites are missing from the registry. Our TLS implementation does not contain anonymous cipher suites, > and I stronly doubt that anyone could provide a convincing rationale > to change that. > > For SMTP(STARTTLS), I consider the lack of authentication in the original > SMTP infrastructure as well as most of the STARTTLS installed base to > part of the _problem_space_. And while I'm not particularly enthusiastic > about misleading DANE band-aids to SMTP-STARTTLS, I consider that approach > preferable to anonymous TLS cipher suites by a huge margin. > TLS has anon cipher suites. I have a need for anon cipher suites with a) decent confidentiality and integrity protection algorithms, b) fast ephemeral-ephemeral + small public key key agreement. That is, I need *modern* anon cipher suites. Your value judgement is noted, and rejected: it does not change my need, a need that is acknowledged by TLS given that it provides anon cipher suites at all. If nothing else we should have consistency, and we should define all modern cipher suites that make sense (e.g., we'd not define suites for stream ciphers w/ block cipher modes). We might leave some out (e.g., why bother with old non-AEAD modes for new block ciphers?), but we should not leave out modern suites providing important functionality that TLS has generally offered before (again, anon cipher suites with modern algorithms). Please argue (or accept) this, not that anon suites are a bad idea. [Yes, this means we're stuck having lots of cipher suites registrations, but we already have lots, and the commitment to having lots was made long ago. I'd propose, once more, that we begin to aim for a la carte negotiation, but that's really a separate thread (and please change the Subject: if you want to take this chance to discuss that idea).] Also, +1 to Peter G.'s response. You might hate anon cipher suites, but I can always get the same effect by ignoring cert validation failures (or even not attempting to validate them in the first place). Nico -- --047d7b5d456c165db604d873baf6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, March 20, 2013, Martin Rex wrote:
Nico Williams wrote:
>
> Note that anon cipher suites are useful for:
>
> =C2=A0- SMTP
> =C2=A0- apps that want to use tls-unique channel bindings
>
> This is bad because ECDH is faster, has smaller public keys, but lacki= ng
> these cipher suites we're stuck with using either TLS_ECDH_anon w/= SHA-1
> suites or TLS_DH_anon suites.
>
> Please fix :)

=C2=A0 =C2=A0http://tools.ietf.org/html/rfc5246#appendix-D.3

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A= proper implementation will
=C2=A0 =C2=A0probably not support many cipher suites. =C2=A0For instance, a= nonymous
=C2=A0 =C2=A0Diffie-Hellman is strongly discouraged because it cannot preve= nt man-
=C2=A0 =C2=A0in-the-middle attacks.

That= 9;s not relevant. =C2=A0I'm not asking why your implementation is missi= ng some cipher suite:=C2=A0I'm asking why some cipher suites are missin= g from the registry.


Our TLS implementation does not contain anonymous cipher suites,
and I stronly doubt that anyone could provide a convincing rationale
to change that.

For SMTP(STARTTLS), I consider the lack of authentication in the original SMTP infrastructure as well as most of the STARTTLS installed base to
part of the _problem_space_. =C2=A0And while I'm not particularly enthu= siastic
about misleading DANE band-aids to SMTP-STARTTLS, I consider that approach<= br> preferable to anonymous TLS cipher suites by a huge margin.

TLS has anon cipher suites. =C2=A0I have a= need=C2=A0for anon cipher suites with a) decent confidentiality and=C2=A0i= ntegrity protection algorithms, b) fast ephemeral-ephemeral + small public = key=C2=A0key agreement. =C2=A0That is, I need *modern* anon cipher suites. = =C2=A0Your value judgement is noted, and rejected: it does not change my ne= ed, a need that is acknowledged by=C2=A0TLS given that it provides anon cip= her suites at all.

If nothing else we should have consistency, and we shou= ld define all=C2=A0modern=C2=A0cipher suites that make sense=C2=A0(e.g., we= 'd not define suites for stream ciphers=C2=A0w/ block cipher modes). = =C2=A0We might leave some out (e.g., why bother with old=C2=A0non-AEAD mode= s for new block ciphers?), but we should not leave out modern suites=C2=A0p= roviding=C2=A0important functionality that TLS has generally offered before= (again, anon cipher suites with modern algorithms). =C2=A0Please argue (or= accept)=C2=A0this, not that anon suites are a bad idea.

[Yes, this means we're stuck having lots of cipher = suites registrations, but we already have lots, and the commitment to havin= g lots=C2=A0was made long ago. =C2=A0I'd=C2=A0propose, once more, that = we begin to aim for a la carte negotiation, but that's really a separat= e=C2=A0thread (and=C2=A0please=C2=A0change the Subject: if you want to take= this chance to discuss that idea).]

Also, +1 to Peter G.'s response. =C2=A0You might ha= te anon cipher suites, but I can always get the same effect by ignoring cer= t validation failures=C2=A0(or even not attempting to validate them in the = first place).

Nico
--=C2=A0
--047d7b5d456c165db604d873baf6-- From ynir@checkpoint.com Thu Mar 21 13:26:43 2013 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 6E70021F8C04; Thu, 21 Mar 2013 13:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.428 X-Spam-Level: X-Spam-Status: No, score=-10.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 1Ik3BoivcIYZ; Thu, 21 Mar 2013 13:26:43 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 81E5D21F8C00; Thu, 21 Mar 2013 13:26:39 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2LKQMrY013187; Thu, 21 Mar 2013 22:26:22 +0200 X-CheckPoint: {514B6BA7-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Thu, 21 Mar 2013 22:26:22 +0200 From: Yoav Nir To: Adam Langley Thread-Topic: [TLS] [Cfrg] Salsa20 stream cipher in TLS Thread-Index: Ac4l74bCPkc5tmAbHkmmrTIC4WvxcwALKVEAAABN74AAEQ1ygA== Date: Thu, 21 Mar 2013 20:26:21 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C7343D245C7@uxcn10-2.UoA.auckland.ac.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.41] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <3828286181568D44A23D649A5DADC6EB@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Salsa20 stream cipher in TLS 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, 21 Mar 2013 20:26:43 -0000 On Mar 21, 2013, at 8:18 AM, Adam Langley wrote: > On Thu, Mar 21, 2013 at 8:09 AM, Yoav Nir wrote: >> Actually, we turned on TLS 1.2 by default for the speed advantage. iOS b= egins a TLS handshake with version 1.2, both in ClientHello and in the reco= rd layer. Only when the (shocked and flabbergasted) server closes the conne= ction, does the iPhone try with something more sane like 1.0, and then even= caches this for a short while. >=20 > But you don't need to switch on TLS 1.2 to fix this, right? The server > just needs to implement version negotiation correctly. We consider the record layer version to be the minimum version supported by= the client, and the version in the ClientHello to be the maximum version s= upported by the client. Since both were 1.2, our code concludes that TLS 1.= 2 is the only supported version. We tried replying in TLS 1.0, and we got a= TCP reset or an alert (I forget which). So without TLS 1.2 support, the fi= rst connection would always fail. In practice this wouldn't be a problem, b= ecause the phone would get the penalty once, and then cache the information= that our server doesn't support 1.2. Still, we preferred to add support fo= r TLS 1.2 (which I wanted to do anyway) > (On the flip side, this /is/ a problem for clients since the > incentives are aligned for clients to stop trying TLS 1.2 since they > can't (directly) fix the server.) >=20 >=20 > Cheers >=20 > AGL >=20 > Email secured by Check Point From bhill@paypal-inc.com Thu Mar 21 14:41:35 2013 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 AAE4321F8E49 for ; Thu, 21 Mar 2013 14:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 BV9BAHRSJ87U for ; Thu, 21 Mar 2013 14:41:34 -0700 (PDT) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by ietfa.amsl.com (Postfix) with ESMTP id 2611621F8E48 for ; Thu, 21 Mar 2013 14:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=@paypal-inc.com; q=dns/txt; s=paypalcorp; t=1363902094; x=1395438094; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=PoQ1LiG1iMrdlYlmlEfPVxwGUkp0zoEKMNQDCsdK7SE=; b=kLNPw6VEHskifz0Q1XQ6txv85mQqKEjp/Kk6Otl5snqwaxb8L3Ed73oV 4SU+x6/64PYHVBfIXlq7IfaBpr6Gos6ChQ1Sjhj2dBbyT11dXAnF+TFRB ApHC1+OD7tsbRQmRvB279VUJZzAIqeHl0Me6My7F0zojfgZa7jU1+3D6L s=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.84,888,1355126400"; d="scan'208,217";a="13913721" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-EXMHT-004.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 21 Mar 2013 14:41:34 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-004.corp.ebay.com ([fe80::a487:c570:9abc:bb59%14]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 15:41:33 -0600 From: "Hill, Brad" To: Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] Confirming consensus for ALPN Thread-Index: AQHOIcagV5WYe8sQck6Vhye6hmriPJiws+bg Date: Thu, 21 Mar 2013 21:41:32 +0000 Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E2796E492@DEN-EXDDA-S12.corp.ebay.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.245.27.241] Content-Type: multipart/alternative; boundary="_000_370C9BEB4DD6154FA963E2F79ADC6F2E2796E492DENEXDDAS12corp_" MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [TLS] Confirming consensus for ALPN 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, 21 Mar 2013 21:41:35 -0000 --_000_370C9BEB4DD6154FA963E2F79ADC6F2E2796E492DENEXDDAS12corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was at the meeting, but didn't speak up. I expected the "running code" pa= rt of the IETF motto would carry more weight in the vote. NPN is here today and is right at the point where large web properties (tha= t aren't Google) can start deploying it. As it is linked with SPDY, it is = now available in major browsers representing ~50% of market share, supporte= d in several web servers, on at least one major web accelerator appliance, = and CDNs are rolling out experimental support. If we start over with ALPN, it will take years for the "supply chain" to ge= t us back to the point of viability that NPN is at today. Going forward I don't have a strong preference, but if the consensus is str= ong that ALPN is the technically correct way to do this, I would prefer tha= t we do NPN as informational and make ALPN-style negotiation part of TLS 1.= 3, since that is the deployment timeframe most of us would realistically be= facing anyway. -Brad Hill From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Eric = Rescorla Sent: Friday, March 15, 2013 2:46 PM To: tls@ietf.org Subject: [TLS] Confirming consensus for ALPN At today's TLS WG f2f meeting we had rough consensus to adopt ALPN as the solution to the upper-layer protocol negotiation problem posed to us by the HTTP WG. if you have an opinion on this topic and were not at the meeting, please send a message to the mailing list and/or the chairs by Friday March 29. -Ekr [For the chairs] --_000_370C9BEB4DD6154FA963E2F79ADC6F2E2796E492DENEXDDAS12corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was at the meeting, but= didn’t speak up. I expected the “running code” part of t= he IETF motto would carry more weight in the vote.

 <= /p>

NPN is here today and is = right at the point where large web properties (that aren’t Google) ca= n start deploying it.  As it is linked with SPDY, it is now available in major browsers representing ~50% of market share, supported in several = web servers, on at least one major web accelerator appliance, and CDNs are = rolling out experimental support.

 <= /p>

If we start over with ALP= N, it will take years for the “supply chain” to get us back to = the point of viability that NPN is at today.

 <= /p>

Going forward I don’= ;t have a strong preference, but if the consensus is strong that ALPN is th= e technically correct way to do this, I would prefer that we do NPN as informational and make ALPN-style negotiation part of TLS 1.3, sinc= e that is the deployment timeframe most of us would realistically be facing= anyway.

 <= /p>

-Brad Hill

 <= /p>

From: tls-boun= ces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Friday, March 15, 2013 2:46 PM
To: tls@ietf.org
Subject: [TLS] Confirming consensus for ALPN

 

At today's TLS WG f2f meeting we had rough consensus= to adopt

ALPN as the solution to the upper-layer protocol neg= otiation problem

posed to us by the HTTP WG.

 

if you have an opinion on this topic and were not at= the meeting,

please send a message to the mailing list and/or the= chairs by

Friday March 29.

 

-Ekr

[For the chairs]

 

--_000_370C9BEB4DD6154FA963E2F79ADC6F2E2796E492DENEXDDAS12corp_-- From alangley@gmail.com Thu Mar 21 16:58:58 2013 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 6DFA221F8F2E for ; Thu, 21 Mar 2013 16:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 haoqnbdR1iFw for ; Thu, 21 Mar 2013 16:58:58 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A348721F8E6A for ; Thu, 21 Mar 2013 16:58:57 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id fq12so6279969lab.33 for ; Thu, 21 Mar 2013 16:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SrFgwQb7Eh7rTG+RsBM8bAEuZnyoP8ANHOdNea9Iz/o=; b=gZ9BmW9XxfjWRRlfaEvkEefl0cLBRPWKkVbDGWWTvtCHJUgkOFMWPogDL48gtc/xcU XpNT4sP6FKM78aEC2EX7IbKfzZhjvRiP0BQ2ymtCNKrJj32stXJt9mUeeWs7pyuC5jeP 3Oh/TXttSUGaGrp+A6MuHb3cqxzjZu1DMmrvc5pkb3ZqfA9xV1gSwsZ58msptG8xADps UWYoWWBybtlLPY7aQUGuUird3RD2t0uEOCTp/eN8pdUqwtqw9lJQ67L2KvyXjmGMg8c6 LznC0+lup/t63yZ5BVE2ThVbtlZCXmppa38WkSdfGkN3VvCqzqBdZ/vxgjvG1/4dZZWi z3cg== MIME-Version: 1.0 X-Received: by 10.112.42.162 with SMTP id p2mr52144lbl.103.1363910336595; Thu, 21 Mar 2013 16:58:56 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.42.230 with HTTP; Thu, 21 Mar 2013 16:58:56 -0700 (PDT) In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E2796E492@DEN-EXDDA-S12.corp.ebay.com> References: <370C9BEB4DD6154FA963E2F79ADC6F2E2796E492@DEN-EXDDA-S12.corp.ebay.com> Date: Thu, 21 Mar 2013 19:58:56 -0400 X-Google-Sender-Auth: F8_MR3B0tLgqgjRxid0UHvs9K_k Message-ID: From: Adam Langley To: "Hill, Brad" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus for ALPN 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, 21 Mar 2013 23:58:58 -0000 On Thu, Mar 21, 2013 at 5:41 PM, Hill, Brad wrote: > If we start over with ALPN, it will take years for the =E2=80=9Csupply ch= ain=E2=80=9D to get > us back to the point of viability that NPN is at today. Note that the existing NPN wasn't what I was advocating: the NPN draft differs from the current code. The NextProtocol message changed into an EncryptedExtensions message for one in order to be more general etc. Cheers AGL From Jeff.Hodges@KingsMountain.com Thu Mar 21 22:13:03 2013 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 779C721F8AD4 for ; Thu, 21 Mar 2013 22:13:03 -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 VJeV3UU1dLLT for ; Thu, 21 Mar 2013 22:13:02 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id B4D7F21F8AD1 for ; Thu, 21 Mar 2013 22:13:02 -0700 (PDT) Received: (qmail 6785 invoked by uid 0); 22 Mar 2013 05:12:37 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com with SMTP; 22 Mar 2013 05:12:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=TAKy0uMhkmTOs2SeKEC1+PAjLUQLBYCelJbtEJKqS6o=; b=6U7CdC4h+gKF+OB1wUvqAWdRM8Io+tYxdev+WLPF0O/o2CBq1qePmmeBBS5Bqb+auMchMzZ8D7L64NbGBmN/YKs5deinN7pqLndQ6rf8VeGoRM9czSu1V+xmz/LqJxRk; Received: from [24.4.122.173] (port=43703 helo=[192.168.11.12]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UIuHM-0003rq-Se; Thu, 21 Mar 2013 23:12:36 -0600 Message-ID: <514BE843.3040808@KingsMountain.com> Date: Thu, 21 Mar 2013 22:12:35 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Adam Langley Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: IETF TLS WG Subject: Re: [TLS] Confirming consensus for ALPN 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, 22 Mar 2013 05:13:03 -0000 AGL replied.. > > On Thu, Mar 21, 2013 at 5:41 PM, Hill, Brad wro= te: > >> If we start over with ALPN, it will take years for the =93supply chai= n=94 to get >> us back to the point of viability that NPN is at today. > > Note that the existing NPN wasn't what I was advocating: the NPN draft= > differs from the current code. Ok, but it's not clear from the above what you were advocating --=20 draft-agl-tls-nextprotoneg-04 or "current code" ? > The NextProtocol message changed into > an EncryptedExtensions message for one in order to be more general > etc. Was the aforementioned transformation in the currently shipping code (eg = Chrome=20 Version 25 or thereabouts) or in draft-agl-tls-nextprotoneg-04 ? thanks, =3DJeffH From mrex@sap.com Thu Mar 21 22:23:33 2013 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 EE70621F8648; Thu, 21 Mar 2013 22:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.225 X-Spam-Level: X-Spam-Status: No, score=-10.225 tagged_above=-999 required=5 tests=[AWL=0.024, 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 gzXu6zHVxp5a; Thu, 21 Mar 2013 22:23:33 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8E07321F8DB2; Thu, 21 Mar 2013 22:23:29 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r2M5NK1a019069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Mar 2013 06:23:20 +0100 (MET) In-Reply-To: To: Adam Langley Date: Fri, 22 Mar 2013 06:23:12 +0100 (CET) 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: <20130322052312.1ADD51A65B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Salsa20 stream cipher in TLS 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, 22 Mar 2013 05:23:34 -0000 Adam Langley wrote: > On Thu, Mar 21, 2013 at 8:09 AM, Yoav Nir wrote: > > > > Actually, we turned on TLS 1.2 by default for the speed advantage. > > iOS begins a TLS handshake with version 1.2, both in ClientHello > > and in the record layer. Only when the (shocked and flabbergasted) > > server closes the connection, does the iPhone try with something > > more sane like 1.0, and then even caches this for a short while. Are you sure? It would clearly be stupid behaviour on part of iPhone to send an initial ClientHello with { 0x03, 0x03 } at the record layer. It should be sending this version in ClientHello.client_version alone. > > But you don't need to switch on TLS 1.2 to fix this, right? The server > just needs to implement version negotiation correctly. The servers typically implement it correctly. If iPhone is willing to talk a protocol version < TLSv1.2, then using TLSv1.2 on the Record Layer on the first ClientHello is a stupid bug. Only(!!) TLSv1.2 servers will ignore the record layer PDU version on the initial ClientHello (but for them this is currently entirely irrelevant, since there is no TLSv1.3 and no borked TLSv1.3 clients that tag PDUs incorrectly). -Martin From ynir@checkpoint.com Thu Mar 21 23:06:50 2013 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 C7BDE21F8AB2; Thu, 21 Mar 2013 23:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.438 X-Spam-Level: X-Spam-Status: No, score=-10.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 DTey7ZyY3NTY; Thu, 21 Mar 2013 23:06:50 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8201221F8AA8; Thu, 21 Mar 2013 23:06:49 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2M66j7a021418; Fri, 22 Mar 2013 08:06:45 +0200 X-CheckPoint: {514BF3A9-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Fri, 22 Mar 2013 08:06:45 +0200 From: Yoav Nir To: "" Thread-Topic: [TLS] [Cfrg] Salsa20 stream cipher in TLS Thread-Index: Ac4l74bCPkc5tmAbHkmmrTIC4WvxcwALKVEAAABN74AAI8xdAAABhmkA Date: Fri, 22 Mar 2013 06:06:44 +0000 Message-ID: References: <20130322052312.1ADD51A65B@ld9781.wdf.sap.corp> In-Reply-To: <20130322052312.1ADD51A65B@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.114] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <08E8563364190C43B399CE274F5E21E5@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Salsa20 stream cipher in TLS 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, 22 Mar 2013 06:06:51 -0000 On Mar 22, 2013, at 1:23 AM, Martin Rex wrote: > Adam Langley wrote: >> On Thu, Mar 21, 2013 at 8:09 AM, Yoav Nir wrote: >>>=20 >>> Actually, we turned on TLS 1.2 by default for the speed advantage. >>> iOS begins a TLS handshake with version 1.2, both in ClientHello >>> and in the record layer. Only when the (shocked and flabbergasted) >>> server closes the connection, does the iPhone try with something >>> more sane like 1.0, and then even caches this for a short while. >=20 > Are you sure? >=20 > It would clearly be stupid behaviour on part of iPhone to send an > initial ClientHello with { 0x03, 0x03 } at the record layer. It would be, and it was. This was long ago, so it may have been fixed in iO= S 6. >=20 > It should be sending this version in ClientHello.client_version alone. >=20 >>=20 >> But you don't need to switch on TLS 1.2 to fix this, right? The server >> just needs to implement version negotiation correctly. >=20 > The servers typically implement it correctly. If iPhone is willing > to talk a protocol version < TLSv1.2, then using TLSv1.2 on the > Record Layer on the first ClientHello is a stupid bug.=20 >=20 > Only(!!) TLSv1.2 servers will ignore the record layer PDU version > on the initial ClientHello (but for them this is currently entirely > irrelevant, since there is no TLSv1.3 and no borked TLSv1.3 clients > that tag PDUs incorrectly). >=20 >=20 > -Martin >=20 > Email secured by Check Point From nick.lewis@usa.g4s.com Fri Mar 22 02:24:54 2013 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 C5AA921F902A for ; Fri, 22 Mar 2013 02:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 WeN7YJbXIm2u for ; Fri, 22 Mar 2013 02:24:54 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.109]) by ietfa.amsl.com (Postfix) with ESMTP id ABC5421F903C for ; Fri, 22 Mar 2013 02:24:53 -0700 (PDT) Received: from [85.158.140.195:55310] by server-5.bemta-14.messagelabs.com id 3F/41-09030-4632C415; Fri, 22 Mar 2013 09:24:52 +0000 X-Env-Sender: nick.lewis@usa.g4s.com X-Msg-Ref: server-5.tower-193.messagelabs.com!1363944292!5337448!1 X-Originating-IP: [89.206.228.155] X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32187 invoked from network); 22 Mar 2013 09:24:52 -0000 Received: from unallocated.star.net.uk (HELO gbtwk10s037.Technology.local) (89.206.228.155) by server-5.tower-193.messagelabs.com with RC4-SHA encrypted SMTP; 22 Mar 2013 09:24:52 -0000 Received: from GBTWK10E001.Technology.local ([10.234.1.29]) by gbtwk10s037.Technology.local ([10.234.1.39]) with mapi; Fri, 22 Mar 2013 09:24:52 +0000 From: "Lewis, Nick" To: "'tls@ietf.org'" Date: Fri, 22 Mar 2013 09:24:51 +0000 Thread-Topic: Re: [TLS] Missing cipher: anon ephemeral ECDH w/ SHA-2 nor Thread-Index: Ac4m3zchiO7MlN0ySduaVC79QvXo5w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [TLS] Missing cipher: anon ephemeral ECDH w/ SHA-2 nor 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, 22 Mar 2013 09:24:54 -0000 PklmIG5vdGhpbmcgZWxzZSB3ZSBzaG91bGQgaGF2ZSBjb25zaXN0ZW5jeSwgYW5kIHdlIHNob3Vs ZCBkZWZpbmUgYWxsIG1vZGVybiBjaXBoZXIgc3VpdGVzDQo+dGhhdCBtYWtlIHNlbnNlIChlLmcu LCB3ZSdkIG5vdCBkZWZpbmUgc3VpdGVzIGZvciBzdHJlYW0gY2lwaGVycyB3LyBibG9jayBjaXBo ZXIgbW9kZXMpLg0KPldlIG1pZ2h0IGxlYXZlIHNvbWUgb3V0IChlLmcuLCB3aHkgYm90aGVyIHdp dGggb2xkIG5vbi1BRUFEIG1vZGVzIGZvciBuZXcgYmxvY2sgY2lwaGVycz8pLA0KPmJ1dCB3ZSBz aG91bGQgbm90IGxlYXZlIG91dCBtb2Rlcm4gc3VpdGVzIHByb3ZpZGluZyBpbXBvcnRhbnQgZnVu Y3Rpb25hbGl0eSB0aGF0IFRMUyBoYXMNCj5nZW5lcmFsbHkgb2ZmZXJlZCBiZWZvcmUgKGFnYWlu LCBhbm9uIGNpcGhlciBzdWl0ZXMgd2l0aCBtb2Rlcm4gYWxnb3JpdGhtcykuDQoNCk5pY28NCg0K SXQgaXMgZ29vZCB0byBoZWFyIGZyb20gc29tZW9uZSB3aXRoIHN1Y2ggaGlnaCBsZXZlbHMgb2Yg bW90aXZhdGlvbg0KDQpJIHByaXZhdGVseSB1c2UgY2lwaGVyIHN1aXRlcyB0aGF0IEkgaGF2ZSBu ZXZlciBhdHRlbXB0ZWQgdG8gcmVnaXN0ZXIgb3Igd3JpdGUgYW4gUkZDIGZvci4NCklmIHlvdSBk byB3cml0ZSBhbiBSRkMgdG8gYWRkIHNvbWUgY2lwaGVyIHN1aXRlcyB0byB0aGUgcmVnaXN0cnkg Y291bGQgeW91IHBsZWFzZSBjb25zaWRlcg0KaW5jbHVkaW5nIHRoZXNlIHRvbzoNCiAtIFRMU19F Q0RIX0VDRFNBX1dJVEhfTlVMTF9TSEEyNTYNCiAtIFRMU19FQ0RIX0VDRFNBX1dJVEhfTlVMTF9T SEEzODQNCiAtIFRMU19FQ0RIRV9FQ0RTQV9XSVRIX05VTExfU0hBMjU2DQogLSBUTFNfRUNESEVf RUNEU0FfV0lUSF9OVUxMX1NIQTM4NA0KIC0gVExTX0VDREhfUlNBX1dJVEhfTlVMTF9TSEEyNTYN CiAtIFRMU19FQ0RIX1JTQV9XSVRIX05VTExfU0hBMzg0DQogLSBUTFNfRUNESEVfUlNBX1dJVEhf TlVMTF9TSEEyNTYNCiAtIFRMU19FQ0RIRV9SU0FfV0lUSF9OVUxMX1NIQTM4NA0KDQoNCi0tDQpO aWNrDQoNCg0KVGhlIGRldGFpbHMgb2YgdGhpcyBjb21wYW55IGFyZSBhcyBmb2xsb3dzOg0KRzRT IFRlY2hub2xvZ3kgTGltaXRlZCwgUmVnaXN0ZXJlZCBPZmZpY2U6IENoYWxsZW5nZSBIb3VzZSwg SW50ZXJuYXRpb25hbCBEcml2ZSwgVGV3a2VzYnVyeSwgR2xvdWNlc3RlcnNoaXJlIEdMMjAgOFVR LCBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgTm8uIDIzODIzMzguDQoNClRoaXMgY29tbXVuaWNhdGlv biBtYXkgY29udGFpbiBpbmZvcm1hdGlvbiB3aGljaCBpcyBjb25maWRlbnRpYWwsIHBlcnNvbmFs IGFuZC9vciBwcml2aWxlZ2VkLg0KDQpJdCBpcyBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhl IGludGVuZGVkIHJlY2lwaWVudChzKS4NCklmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQocyksIHBsZWFzZSBub3RlIHRoYXQgYW55IGRpc3RyaWJ1dGlvbiwgZm9yd2FyZGluZywg Y29weWluZyBvciB1c2Ugb2YgdGhpcyBjb21tdW5pY2F0aW9uIG9yIHRoZSBpbmZvcm1hdGlvbiBp biBpdCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLg0KDQpBbnkgcGVyc29uYWwgdmlld3MgZXhwcmVz c2VkIGluIHRoaXMgZS1tYWlsIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIgYW5k IHRoZSBjb21wYW55IGRvZXMgbm90IGVuZG9yc2Ugb3IgYWNjZXB0IHJlc3BvbnNpYmlsaXR5IGZv ciB0aGVtLg0KDQpQcmlvciB0byB0YWtpbmcgYW55IGFjdGlvbiBiYXNlZCB1cG9uIHRoaXMgZS1t YWlsIG1lc3NhZ2UsIHlvdSBzaG91bGQgc2VlayBhcHByb3ByaWF0ZSBjb25maXJtYXRpb24gb2Yg aXRzIGF1dGhlbnRpY2l0eS4NCg0KVGhpcyBlLW1haWwgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgYWxs IHZpcnVzZXMgYnkgTWVzc2FnZUxhYnMuDQo= From alangley@gmail.com Fri Mar 22 04:38:32 2013 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 B08EF21F896C for ; Fri, 22 Mar 2013 04:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 iNq8OjVmTAZK for ; Fri, 22 Mar 2013 04:38:32 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 89EE221F8511 for ; Fri, 22 Mar 2013 04:38:31 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id fq12so7082753lab.33 for ; Fri, 22 Mar 2013 04:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=c850e4S/xMJQbvvMucSJzgZQoXWQS/hDIHWQXrcWbuA=; b=v0GNPrnuk78j+Kx+JNi67jtMaBXBmyKAE7Lar7y8PQuG1crij6AD5CTYeErNGTRiNZ lCW/zkdfXTaq72WnBQtn06SZoWiqonIHajt1U1FF0t/hM/rIr4ffjzC6EECQJtooQuwT e36A4eaoo20PgUTvUW1tMXcmpNVcNwX6vGm9LPXZ4BTB2A1LKY1ktYfhB+zux/D00X0q FuREgKdo+glffiYJS3/ld0nHM8Tbxvm04auD83n7hQ1EMVnJAGLnxhlX55ownnxtHIeS yiZwPDxJIYtbWIAEZZBs5j3BwinaKyvRd0X3i6jHp0iNUj6G1e/IwgHqxXpfkoZ9r7/C cV8w== MIME-Version: 1.0 X-Received: by 10.112.42.162 with SMTP id p2mr925501lbl.103.1363952310486; Fri, 22 Mar 2013 04:38:30 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.61.7 with HTTP; Fri, 22 Mar 2013 04:38:29 -0700 (PDT) In-Reply-To: <514BE843.3040808@KingsMountain.com> References: <514BE843.3040808@KingsMountain.com> Date: Fri, 22 Mar 2013 07:38:29 -0400 X-Google-Sender-Auth: y1hPC7GkW8BUu-yD1QvU9M3qBbc Message-ID: From: Adam Langley To: "=JeffH" Content-Type: text/plain; charset=UTF-8 Cc: IETF TLS WG Subject: Re: [TLS] Confirming consensus for ALPN 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, 22 Mar 2013 11:38:32 -0000 On Fri, Mar 22, 2013 at 1:12 AM, =JeffH wrote: > Ok, but it's not clear from the above what you were advocating -- > draft-agl-tls-nextprotoneg-04 or "current code" ? I was advocating draft-agl-tls-nextprotoneg-04 > Was the aforementioned transformation in the currently shipping code (eg > Chrome Version 25 or thereabouts) or in draft-agl-tls-nextprotoneg-04 ? The latter. The currently shipping code was always going to change, if nothing else because of a change of extension number. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From n.mavrogiannopoulos@gmail.com Fri Mar 22 10:27:55 2013 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 52A6521F8DF0 for ; Fri, 22 Mar 2013 10:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.305 X-Spam-Level: X-Spam-Status: No, score=-1.305 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.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 Ikh9ntLy+L5p for ; Fri, 22 Mar 2013 10:27:54 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7977021F87D1 for ; Fri, 22 Mar 2013 10:27:54 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hm11so8892947wib.1 for ; Fri, 22 Mar 2013 10:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:x-enigmail-version:openpgp :content-type:content-transfer-encoding; bh=oXprxYgOb05f/3pA5vnR5asycpIdeHDJ7hpRabx0KaY=; b=tswHvjKCNBdM6Jc/guBLvPAMuhkS5yw1kY1V/1NlWytwI9DSeipKj+ksgXOT0S0m1x ahcQ2cdcp8wpON9uhCs2QoJvSOrr7r2d3ya69ynslcr4pgeB5qjcAq3RoaHijS7cj+xp n7fKlUncE/WZUNOQwWAT9VGrTo32C8DZEwwamMLKu55iAJgM/7RE2lP0iEhQKzprvKRJ n+HesFkzjrw+Y12g22+sg0vtABInZhAwkcqB84GlNwTf7ntgeBwIykTs/dVC9Ae6zdE4 p28hYLajEDEIPTZzyQwofUfp3D1CAN7Vgh6xOxfV4puPhKHE0Th/w/myOjcK+lgv4AAQ s6Jg== X-Received: by 10.180.185.44 with SMTP id ez12mr12657489wic.33.1363973273694; Fri, 22 Mar 2013 10:27:53 -0700 (PDT) Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id g4sm4881480wib.11.2013.03.22.10.27.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Mar 2013 10:27:52 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <514C9492.5080209@gnutls.org> Date: Fri, 22 Mar 2013 18:27:46 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: tls@ietf.org References: <20130321010631.F1A651A653@ld9781.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Missing cipher: anon ephemeral ECDH w/ SHA-2 nor AEAD modes 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, 22 Mar 2013 17:27:55 -0000 On 03/21/2013 07:44 PM, Nico Williams wrote: >> A proper implementation will >> probably not support many cipher suites. For instance, anonymous >> Diffie-Hellman is strongly discouraged because it cannot prevent man- >> in-the-middle attacks. > > That's not relevant. I'm not asking why your implementation is missing > some cipher suite: I'm asking why some cipher suites are missing from the > registry. Indeed, but as a comment I'd say that the anon ciphersuites have a big disadvantage comparing to using the certificate based ones for anonymous authentication, and that is they cannot support key continuity. With the certificate based ciphersuites you may use the certificates only as container to send the public key of each party (or even use the raw key proposed extension of TLS), and store the party's key for future sessions. That way you limit the anon authentication only on the first session and subsequent sessions are properly authenticated (you are assured it is the same party you talked before). With the anon ciphersuites unfortunately you cannot not do that, meaning you are always going to have anonymous authentication, even if you have seen that party before. regards, Nikos From mike-list@pobox.com Fri Mar 22 10:30:38 2013 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 58FE921F8DE5 for ; Fri, 22 Mar 2013 10:30:38 -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 F-TAgapPNujo for ; Fri, 22 Mar 2013 10:30:37 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id A2F9C21F8533 for ; Fri, 22 Mar 2013 10:30:35 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 84EB1BF07 for ; Fri, 22 Mar 2013 13:30:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=N/58ogKuH4+d RqMr8om/VhMpKmw=; b=GPm/nn7JdJuUKzM8OnYx6V1xURKsWcGJWnGupQ5k+8md yUv9uvT4ODH4sadmPCu0nNMdFfKkeK8FjCrsWorFv3M8Banucv0TBUBjZCY86HFu Ctu/x5QcJJfJPD7r7B4YSDbjy2Ig+ZnS4zaXzBpb+Feu7uEw2cLDr+/78JZ8hFo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=v3C4GX XGsnEMOFgGkRuhlVkODzhAkpIxIqh6qQi8avVpbTpaa4SQk8A+pbexbTve1CQXIh LEP028XBAsTnmmCGQKy9/m+dsy7s8I27QEJsLYNIufRsfhIyABMyf+aekMMr36vv exASjkSyotQMOJUefE0bnJdUYbjP14jvK7BUU= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 7DFD3BF06 for ; Fri, 22 Mar 2013 13:30:34 -0400 (EDT) Received: from iMac.local (unknown [68.224.235.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id D10C0BF05 for ; Fri, 22 Mar 2013 13:30:33 -0400 (EDT) Message-ID: <514C9538.7030401@pobox.com> Date: Fri, 22 Mar 2013 10:30:32 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "tls@ietf.org" References: <20130322052312.1ADD51A65B@ld9781.wdf.sap.corp> In-Reply-To: <20130322052312.1ADD51A65B@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 33A4D3B2-9316-11E2-9694-B7660E5B5709-38729857!a-pb-sasl-quonix.pobox.com Subject: [TLS] Record version (was Re: Salsa20 stream cipher in TLS) 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, 22 Mar 2013 17:30:38 -0000 Martin Rex wrote: > Adam Langley wrote: >> On Thu, Mar 21, 2013 at 8:09 AM, Yoav Nir wrote: >>> Actually, we turned on TLS 1.2 by default for the speed advantage. >>> iOS begins a TLS handshake with version 1.2, both in ClientHello >>> and in the record layer. Only when the (shocked and flabbergasted) >>> server closes the connection, does the iPhone try with something >>> more sane like 1.0, and then even caches this for a short while. > > Are you sure? > > It would clearly be stupid behaviour on part of iPhone to send an > initial ClientHello with { 0x03, 0x03 } at the record layer. > > It should be sending this version in ClientHello.client_version alone. The TLS 1.2 spec. clearly allows for this 'stupid' behavior. Here's an excerpt from RFC 5246 Appendix E (Backward Compatibility): Earlier versions of the TLS specification were not fully clear on what the record layer version number (TLSPlaintext.version) should contain when sending ClientHello (i.e., before it is known which version of the protocol will be employed). Thus, TLS servers compliant with this specification MUST accept any value {03,XX} as the record layer version number for ClientHello. TLS clients that wish to negotiate with older servers MAY send any value {03,XX} as the record layer version number. Typical values would be {03,00}, the lowest version number supported by the client, and the value of ClientHello.client_version. No single value will guarantee interoperability with all old servers, but this is a complex topic beyond the scope of this document. Perhaps some better advice should be added next time ("use the client's lowest supported version") and placed in the main document instead of an appendix.... Mike From wtc@google.com Fri Mar 22 10:49:55 2013 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 D278D21F8F9F for ; Fri, 22 Mar 2013 10:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, 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 5iVaXWolXOGR for ; Fri, 22 Mar 2013 10:49:55 -0700 (PDT) Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2B57221F8F81 for ; Fri, 22 Mar 2013 10:49:55 -0700 (PDT) Received: by mail-ia0-f171.google.com with SMTP id z13so3801909iaz.30 for ; Fri, 22 Mar 2013 10:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=VdzcTG5b350k70Vhefu5NOL8q8F/srC4OX1Tx3jKsuI=; b=Ps+snFkXEmaULm9jfcQxcASI/a1BYMDM47NsR0DIYmg4yPl3RU0sIUnoWfClQmb98C Z99LWAxf6xXulPolEy1RbqTFXLEyLs3HFpsGHBDc6FBkYnhRUiRaBVY5bTkwTa5Ss5mv TGHY5ms1Y0hV48ZjQXGeDbpqac7mJpJeOtEm1bPdNrEl0e9XGTkmqwh2aA3ADr6RBld5 nbG0HHjbduK5g5jOwNJUnYvcp09+7kjgHWscFmfTlWqbFUD4e4kIuiN5YwwsRj5Q1BEG uGh6GFPOoqKLZxuoHjgO5JIm/LeqR/pd9EDnAGTp9hmNACPVpgbVd1NJmqGJcONFIZrZ 9pnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=VdzcTG5b350k70Vhefu5NOL8q8F/srC4OX1Tx3jKsuI=; b=g0Am2jOQg3sE923NEZN5wWCaojLLWGMwH9X4nEGrgbMGYXppaECT040O6T/bLukdxn Bb1Mx0ig4iffGVLEnATyke/NbVt0+JOvroSXhsLSAQ9s1KkE4Jx2Eu8nCWl3xVCgp42c q3B0SSlDJanOPFmR9tTvGVKekctV/aOIRc8MnkXzpeyYp0+ZH5VvLwUocUQZxxPypRCO rR5PqZUCfNzjjuQxKpH8xqqIABUhn76aAv7ZzAR/X+G4LMR9v4bMqvsCwFznLs831XWi edgf4Tbo3DEwl1r1Og6B+0eoegwF/12BSGentQmvI6Ulh8iAW3pUpc4TENXOr4y4ldmf Eorg== MIME-Version: 1.0 X-Received: by 10.50.70.34 with SMTP id j2mr1822820igu.7.1363974594799; Fri, 22 Mar 2013 10:49:54 -0700 (PDT) Received: by 10.231.112.2 with HTTP; Fri, 22 Mar 2013 10:49:54 -0700 (PDT) In-Reply-To: <514C9538.7030401@pobox.com> References: <20130322052312.1ADD51A65B@ld9781.wdf.sap.corp> <514C9538.7030401@pobox.com> Date: Fri, 22 Mar 2013 10:49:54 -0700 Message-ID: From: Wan-Teh Chang To: "Michael D'Errico" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkd/P77iWDE5+V95IzkfNyDSELPc3RTXaF9MkKSzlW3tcYkMxri+oOBNbha1uHVKBXMHFjqCzTRt3nYViykDcYOsBGaaPh0woAhBngRDELnnz/m8+POEcFX5XeHkGLJHPBJAFxJ8f/tP/nKASP6L7/QKFR/7SjUTOhDqHOTgwl0h48H5Bzzuof0r7FxaxBRR1VPREhU Cc: "tls@ietf.org" Subject: Re: [TLS] Record version (was Re: Salsa20 stream cipher in TLS) 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, 22 Mar 2013 17:49:56 -0000 On Fri, Mar 22, 2013 at 10:30 AM, Michael D'Errico wrote: > > Perhaps some better advice should be added next time ("use the client's > lowest supported version") and placed in the main document instead of > an appendix.... As RFC 5246 Appendix E says, this is a complex topic. We encountered one server that supports SSL 3.0 and TLS 1.0 and chooses the version in the record layer, ignoring ClientHello.client_version: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ssl/ssl3con.c&rev=1.207&mark=2379-2386#2379 If you put the lowest version number supported by the client, which is typically SSL 3.0 {03, 00}, in the record layer, this server will pick SSL 3.0, even though it can also do TLS 1.0. In our experience with the Google Chrome browser, putting TLS 1.0 {03, 01} in the record layer of the initial ClientHello has worked well. (ClientHello.client_version is TLS 1.1 {03, 02} for Google Chrome.) Wan-Teh From mrex@sap.com Fri Mar 22 12:51:54 2013 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 AD35B21F912D for ; Fri, 22 Mar 2013 12:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.226 X-Spam-Level: X-Spam-Status: No, score=-10.226 tagged_above=-999 required=5 tests=[AWL=0.023, 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 T7HfdEckSEcH for ; Fri, 22 Mar 2013 12:51:53 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1D25321F912A for ; Fri, 22 Mar 2013 12:51:52 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r2MJpm0M029915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Mar 2013 20:51:48 +0100 (MET) In-Reply-To: To: Nico Williams Date: Fri, 22 Mar 2013 20:51:48 +0100 (CET) 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: <20130322195148.110A11A654@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Missing cipher: anon ephemeral ECDH w/ SHA-2 nor AEAD modes 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, 22 Mar 2013 19:51:54 -0000 Nico Williams wrote: > Martin Rex wrote: > > > Nico Williams wrote: > > > > > > Note that anon cipher suites are useful for: > > > > > > - SMTP > > > - apps that want to use tls-unique channel bindings > > > > > > This is bad because ECDH is faster, has smaller public keys, but lacking > > > these cipher suites we're stuck with using either TLS_ECDH_anon w/ SHA-1 > > > suites or TLS_DH_anon suites. > > > > > > Please fix :) > > > > http://tools.ietf.org/html/rfc5246#appendix-D.3 > > > > A proper implementation will > > probably not support many cipher suites. For instance, anonymous > > Diffie-Hellman is strongly discouraged because it cannot prevent man- > > in-the-middle attacks. > > > That's not relevant. I'm not asking why your implementation is missing > some cipher suite: I'm asking why some cipher suites are missing from the > registry. I believe you're too fast in dismissing the security problems associated with anon cipher suites. http://tools.ietf.org/html/rfc5246#page-76 The following cipher suites are used for completely anonymous Diffie-Hellman communications in which neither party is authenticated. Note that this mode is vulnerable to man-in-the- *> middle attacks. Using this mode therefore is of limited use: These *> cipher suites MUST NOT be used by TLS 1.2 implementations unless the *> application layer has specifically requested to allow anonymous key exchange. (Anonymous key exchange may sometimes be acceptable, for example, to support opportunistic encryption when no set-up for authentication is in place, or when TLS is used as part of more complex security protocols that have other means to ensure authentication.) CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 }; CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A }; CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00,0x6C }; CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00,0x6D }; Note that using non-anonymous key exchange without actually verifying the key exchange is essentially equivalent to anonymous key exchange, and the same precautions apply. While non-anonymous key exchange will generally involve a higher computational and communicational cost than anonymous key exchange, it may be in the interest of interoperability not to disable non-anonymous key exchange when the application layer is allowing anonymous key exchange. One of the problem is, that with some SSL Stacks, authentication of the server is performed in an event-based callback fashion on receipt of the Server Certfiicate handshake message. Myself, I haven't used any such implementation, but I would not be surprised if, when an anon cipher suite is enabled and used, there simply wouldn't be any callback performed, and the application caller typically wouldn't care, and the user would silently assume that authentication happend, because he was not shown an error. The other problem is, that when a Server certificate is required, at least a self-signed one for local/test scenarios, that the relevant interfaces and configuration options will be available in the application caller code. If anonymous ciphersuites were available by default, you start finding application callers that either "forgot" to offer a configuration option for certs, or where that option is only theoretically available but doesn't work, because it was never tested (by the developer). Using a regular TLS cipher suite, and ignoring the server certificate chain is always a possibility for an application caller that desires to skip authentication consciously. > > [Yes, this means we're stuck having lots of cipher suites registrations, > but we already have lots, and the commitment to having lots was made long > ago. Now you're confusing two things. While its true that there are lots of cipher suites _registrations_, that doesn't mean that there are lots of cipher suites to choose from. And performance seems to not be a concern for everybody, because there are some TLS implementations that put RSA-AES256-SHA1 before RSA-AES128-SHA1 in their preference order, rather than the more reasonable RSA-AES128-SHA1 before RSA-AES256-SHA1 default ordering. -Martin From nico@cryptonector.com Fri Mar 22 13:07:54 2013 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 C61C221F8D20 for ; Fri, 22 Mar 2013 13:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 KuJWYiR+t4Lz for ; Fri, 22 Mar 2013 13:07:53 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id A699621F8CAA for ; Fri, 22 Mar 2013 13:07:53 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 528931E07C for ; Fri, 22 Mar 2013 13:07:53 -0700 (PDT) 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; s=cryptonector.com; bh=Op2lvHU3flWXnQvqrfk4 Zn770yw=; b=rbwvxdsIagKnJtRQjP8FBoXqqOmzay7oo2lQ686JKoTZEq/jw99a WoGb/Z/3mhAVVcxz6Bum8XFKtO43iiteyKmYp6J9hu4oIbglqUAxb1dwvqgUvSMe 5OIJMUfraMfQF1LdkGc4GbY3AaRTc8suJ1KtKXSqVOCd4yJM3jeSP1w= Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id D29C31E076 for ; Fri, 22 Mar 2013 13:07:52 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id 8so3550400wgl.30 for ; Fri, 22 Mar 2013 13:07:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.158.161 with SMTP id wv1mr5433650wjb.38.1363982871428; Fri, 22 Mar 2013 13:07:51 -0700 (PDT) Received: by 10.217.105.195 with HTTP; Fri, 22 Mar 2013 13:07:51 -0700 (PDT) In-Reply-To: <514C9492.5080209@gnutls.org> References: <20130321010631.F1A651A653@ld9781.wdf.sap.corp> <514C9492.5080209@gnutls.org> Date: Fri, 22 Mar 2013 15:07:51 -0500 Message-ID: From: Nico Williams To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=089e013c6ab0880bed04d88902d4 Cc: "tls@ietf.org" Subject: Re: [TLS] Missing cipher: anon ephemeral ECDH w/ SHA-2 nor AEAD modes 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, 22 Mar 2013 20:07:54 -0000 --089e013c6ab0880bed04d88902d4 Content-Type: text/plain; charset=UTF-8 On Friday, March 22, 2013, Nikos Mavrogiannopoulos wrote: > On 03/21/2013 07:44 PM, Nico Williams wrote: > > >> A proper implementation will > >> probably not support many cipher suites. For instance, anonymous > >> Diffie-Hellman is strongly discouraged because it cannot prevent man- > >> in-the-middle attacks. > > > > That's not relevant. I'm not asking why your implementation is missing > > some cipher suite: I'm asking why some cipher suites are missing from the > > registry. > > Indeed, but as a comment I'd say that the anon ciphersuites have a big > disadvantage comparing to using the certificate based ones for anonymous > authentication, and that is they cannot support key continuity. An interesting argument... that fails to address the use cases I gave. Also, it's not responsive to the issue at hand... unless you want to argue for removal of the existing anon cipher suites, and even then it'd not be responsive. I might not mind having a debate about the utility of anon cipher suites -in a separate thread- but I kinda need to know what to do about the missing cipher suites. I want to know a) why these cipher suites are missing (presumably from RFC5289) and b) what I should do to get them added (submit an individual submission I-D? ask the chairs to adopt a new WG work item for adding these?). The registry has Specification Required allocation a range but merely submitting an I-D is still not enough, and if there's some reason for these cipher suites being missing other than "oversight", well, why get myself blindsided by it? Better ask is what I thought. If no one answers by Monday I'll assume this was an oversight and submit an I-D. Nico -- --089e013c6ab0880bed04d88902d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Friday, March 22, 2013, Nikos Mavrogiannopoulos wrote:
On 03/21/2013 07:44 PM, Nico Williams wrote:

>> =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A proper imp= lementation will
>> =C2=A0 =C2=A0probably not support many cipher = suites. =C2=A0For instance, anonymous
>> =C2=A0 =C2=A0Diffie-Hellman is strongly discouraged because it can= not prevent man-
>> =C2=A0 =C2=A0in-the-middle attacks.
>> That's not relevant. =C2=A0I'm not asking why your implementa= tion is missing
> some cipher suite: I'm asking why some cipher s= uites are missing from the
> registry.

Indeed, but as a comment I'd say that the anon ci= phersuites have a big
disadvantage comparing to using the certificate ba= sed ones for anonymous
authentication, and that is they cannot support k= ey continuity.

An interesting argument... that fai= ls to address the use cases I gave. =C2=A0Also, it's not responsive to = the issue at hand...=C2=A0unless you want to argue for removal of the exist= ing anon cipher suites, and even then it'd not be responsive. =C2=A0I m= ight not mind having a debate about the utility of anon cipher suites=C2=A0= -in a separate thread-=C2=A0but I kinda need to know what to do about the m= issing cipher suites.

I want to know a) why these cipher = suites are missing (presumably from RFC5289)=C2=A0and b) what I should do t= o get them added (submit an individual submission I-D? =C2=A0ask the chairs= to adopt a new WG work item for adding these?). =C2=A0The registry has Spe= cification Required allocation a=C2=A0range but merely submitting an I-D is= still not enough, and if there's some reason for these cipher suites b= eing missing other than "oversight", well, why get myself blindsi= ded by it? =C2=A0Better ask is what I thought. =C2=A0If no one answers by M= onday I'll assume this was an oversight and submit an I-D.=

Nico
--=C2=A0
--089e013c6ab0880bed04d88902d4-- From mrex@sap.com Fri Mar 22 13:13:11 2013 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 4256321F88F7 for ; Fri, 22 Mar 2013 13:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.228 X-Spam-Level: X-Spam-Status: No, score=-10.228 tagged_above=-999 required=5 tests=[AWL=0.021, 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 7t53AP-0DJcM for ; Fri, 22 Mar 2013 13:13:10 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3485B21F8489 for ; Fri, 22 Mar 2013 13:13:10 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r2MKD7P6016895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Mar 2013 21:13:07 +0100 (MET) In-Reply-To: To: Wan-Teh Chang Date: Fri, 22 Mar 2013 21:13:07 +0100 (CET) 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: <20130322201307.0E2C21A65C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Record version (was Re: Salsa20 stream cipher in TLS) 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, 22 Mar 2013 20:13:11 -0000 Wan-Teh Chang wrote: > > Michael D'Errico wrote: > > > > Perhaps some better advice should be added next time ("use the client's > > lowest supported version") and placed in the main document instead of > > an appendix.... > > As RFC 5246 Appendix E says, this is a complex topic. > > We encountered one server that supports SSL 3.0 and TLS 1.0 and > chooses the version in the record layer, ignoring ClientHello.client_version: > http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ssl/ssl3con.c&rev=1.207&mark=2379-2386#2379 > > If you put the lowest version number supported by the client, > which is typically SSL 3.0 {03, 00}, in the record layer, this > server will pick SSL 3.0, even though it can also do TLS 1.0. > > In our experience with the Google Chrome browser, putting > TLS 1.0 {03, 01} in the record layer of the initial ClientHello > has worked well. (ClientHello.client_version is TLS 1.1 {03, 02} {03, 01} should be interoperable with any server that implements TLSv1.0, plus those SSLv3 servers where this was retroactively relaxed. The exact wording rfc5246 is a silly excuse for stupid behaviour based on a minor typo in rfc2246 that should have been obvious to every careful implementor. http://tools.ietf.org/html/rfc2246#appendix-E TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both is easy. TLS clients who wish to negotiate with SSL 3.0 servers should send client hello messages using the SSL 3.0 record format and client hello structure, sending {3, 1} for the version field to note that they support TLS 1.0. If the server supports only SSL 3.0, it will respond with an SSL 3.0 server hello; if it supports TLS, with a TLS server hello. The negotiation then proceeds as appropriate for the negotiated protocol. Question: what is the difference between "SSL 3.0 record format" and "TLS 1.0 record format"? If they had meant to use the the TLSv1.0 record format for a backwards compatible ClientHello, this text wouldn't have been there. 2nd Question: what is the version field of the client hello structure? The protocol version field at the Record Layer declares the version of the protocol PDU. An implementation of a particular protocol version should not make any flawed assumptions about future protocol versions which it does not implement and simply reject them. For example, an implementation of SSLv3 or TLSv1.0 will typically not be able to parse a TLSv1.1 "GenericBlockCipher" PDU or TLSv1.2 CertificateRequest or TLSv1.2 ServerKeyExchange or TLSv1.2 CertificateVerify PDUs, because these differ from earlier protocol versions. -Martin From n.mavrogiannopoulos@gmail.com Fri Mar 22 13:37:10 2013 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 7F4D221F9425 for ; Fri, 22 Mar 2013 13:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.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 0QZvB6Kxz9Pr for ; Fri, 22 Mar 2013 13:37:10 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id C71A821F9423 for ; Fri, 22 Mar 2013 13:37:09 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id k14so760100wer.13 for ; Fri, 22 Mar 2013 13:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received: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=Mf8vKW+y0xNBWUS247RGqwbjuV+o7YZbeampuBZZU8o=; b=AaUMymoh1uwwFly0RCGdNvBH7zMTju9/wuOAcyiec3Yhrl1c7hVVuazyuHsYQbUJHz soq4dQiry68bfswLcrtB6yG2a89a06UIKqI2MlaClJYJ0PlLSO3a0QAtwqby5JaU4Onh W7YAe+3eOIeXETv2BbeJ4J6vVy36zuKY6BIAzmlHdk0IJhY8XU3OfeP3PnOBVoKkvrFi +BzwuniqR/+gOdCQ9cA74J8P9lCWXiBm3A59iAUhmCXHmlwc+WVtpVAae5qRFPrnSHMf x9IhWo8rlpCXeqSy3+61vv1/JSxOs9xftc818qbGyyROKmzHU9dq2D+3/dnX52nBmFWC rWHQ== X-Received: by 10.180.100.10 with SMTP id eu10mr13783203wib.4.1363984628726; Fri, 22 Mar 2013 13:37:08 -0700 (PDT) Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id ed6sm5941662wib.9.2013.03.22.13.37.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Mar 2013 13:37:07 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <514CC0ED.9050502@gnutls.org> Date: Fri, 22 Mar 2013 21:37:01 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Nico Williams References: <20130321010631.F1A651A653@ld9781.wdf.sap.corp> <514C9492.5080209@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] Missing cipher: anon ephemeral ECDH w/ SHA-2 nor AEAD modes 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, 22 Mar 2013 20:37:10 -0000 On 03/22/2013 09:05 PM, Nico Williams wrote: >>> >>> That's not relevant. I'm not asking why your implementation is missing >>> some cipher suite: I'm asking why some cipher suites are missing from the >>> registry. >> >> Indeed, but as a comment I'd say that the anon ciphersuites have a big >> disadvantage comparing to using the certificate based ones for anonymous >> authentication, and that is they cannot support key continuity. > > > An interesting argument... that fails to address the use cases I gave. > Also, it's not responsive to the issue at hand... unless you want to argue > for removal of the existing anon cipher suites, and even then it'd not be > responsive. I might not mind having a debate about the utility of anon > cipher suites -in a separate thread- but I kinda need to know what to do > about the missing cipher suites. No I didn't say that to challenge the utility of the anon ciphersuites in your use case. Since they are defined, it is good to have all possible variants, as you suggest. > The registry has Specification Required allocation a range but > merely submitting an I-D is still not enough, and if there's some reason > for these cipher suites being missing other than "oversight", well, why get > myself blindsided by it? Better ask is what I thought. What if submitting an independent informational rfc? Wouldn't that count as a specification? regards, Nikos From mrex@sap.com Fri Mar 22 14:25:51 2013 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 5384121F9436 for ; Fri, 22 Mar 2013 14:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.229 X-Spam-Level: X-Spam-Status: No, score=-10.229 tagged_above=-999 required=5 tests=[AWL=0.020, 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 tCrmPzaPy-a6 for ; Fri, 22 Mar 2013 14:25:50 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6C75321F9435 for ; Fri, 22 Mar 2013 14:25:50 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r2MLPiaV025476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Mar 2013 22:25:44 +0100 (MET) In-Reply-To: <514CC0ED.9050502@gnutls.org> To: Nikos Mavrogiannopoulos Date: Fri, 22 Mar 2013 22:25:43 +0100 (CET) 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: <20130322212544.036931A65A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Nico Williams , "tls@ietf.org" Subject: Re: [TLS] Missing cipher: anon ephemeral ECDH w/ SHA-2 nor AEAD modes 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, 22 Mar 2013 21:25:51 -0000 Nikos Mavrogiannopoulos wrote: > > Nico Williams wrote: > > > > The registry has Specification Required allocation a range but > > merely submitting an I-D is still not enough, and if there's some reason > > for these cipher suites being missing other than "oversight", well, why get > > myself blindsided by it? Better ask is what I thought. > > What if submitting an independent informational rfc? Wouldn't that count > as a specification? To meet "Specification Required" an Informational RFC is OK. But it is actually a lesser Requirement than "RFC Required", so having it permanently documented elsewhere (outside of the IETF), would also be OK. An I-D typically needs to have at least been approved by the IESG to meet the "documented in a permanent and readily available specification", since I-Ds are officially "temporary, work in progress", carrying the explicit "warning" label: It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". For the exact definition, see: http://tools.ietf.org/html/rfc5226#page-10 Specification Required - Values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. When used, Specification Required also implies use of a Designated Expert, who will review the public specification and evaluate whether it is sufficiently clear to allow interoperable implementations. The intention behind "permanent and readily available" is that a document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value. Publication of an RFC is an ideal means of achieving this requirement, but Specification Required is intended to also cover the case of a document published outside of the RFC path. For RFC publication, the normal RFC review process is expected to provide the necessary review for interoperability, though the Designated Expert may be a particularly well-qualified person to perform such a review. Examples: Diffserv-aware TE Bandwidth Constraints Model Identifiers [RFC4124], TLS ClientCertificateType Identifiers [RFC4346], ROHC Profile Identifiers [RFC4995]. -Martin From mrex@sap.com Fri Mar 22 18:46:45 2013 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 E543321F8FE2 for ; Fri, 22 Mar 2013 18:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.23 X-Spam-Level: X-Spam-Status: No, score=-10.23 tagged_above=-999 required=5 tests=[AWL=0.019, 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 mNgQfSKW1HD0 for ; Fri, 22 Mar 2013 18:46:45 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id CF2B421F8FA5 for ; Fri, 22 Mar 2013 18:46:44 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r2N1kecl019157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 23 Mar 2013 02:46:40 +0100 (MET) In-Reply-To: <514C9538.7030401@pobox.com> To: "Michael D'Errico" Date: Sat, 23 Mar 2013 02:46:40 +0100 (CET) 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: <20130323014640.5086F1A65A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Record version (was Re: Salsa20 stream cipher in TLS) 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: Sat, 23 Mar 2013 01:46:46 -0000 Michael D'Errico wrote: > Martin Rex wrote: > > Adam Langley wrote: > >> On Thu, Mar 21, 2013 at 8:09 AM, Yoav Nir wrote: > >>> Actually, we turned on TLS 1.2 by default for the speed advantage. > >>> iOS begins a TLS handshake with version 1.2, both in ClientHello > >>> and in the record layer. Only when the (shocked and flabbergasted) > >>> server closes the connection, does the iPhone try with something > >>> more sane like 1.0, and then even caches this for a short while. > > > > Are you sure? > > > > It would clearly be stupid behaviour on part of iPhone to send an > > initial ClientHello with { 0x03, 0x03 } at the record layer. > > > > It should be sending this version in ClientHello.client_version alone. > > The TLS 1.2 spec. clearly allows for this 'stupid' behavior. Here's an > excerpt from RFC 5246 Appendix E (Backward Compatibility): Yes, I know. The text in rfc5246 (TLSv1.2) is a poor solution, trying to make broken TLS implementation look less broken than they really are. Since TLSv1.2 servers(!) are finally required to accept any {03,XX} record version for the initial ClientHello, it is UNREASONABLE for a client to use TLSv1.2 {03,03} at the record layer _unless_ the client is not willing to talk any lower protocol versions. And this is what the text in rfc5246 fails to point out! We had the discussion in 2006. I started a discussion thread about it here: http://www.ietf.org/mail-archive/web/tls/current/msg00677.html One of Pasi's later replies: http://www.ietf.org/mail-archive/web/tls/current/msg00684.html rfc2246(TLSv1.0) says that you should use SSLv3 record format for a handshake with a SSLv3 server, and TLSv1.0 in the ClientHello structure. rfc4346(TLSv1.1) says that you should use SSLv3 record format for a handshake with a TLSv1.0 or SSLv3 server and a TLSv1.1 in the ClientHello structure. Bodo is reading the spec correctly (excerpt): http://www.ietf.org/mail-archive/web/tls/current/msg00681.html The specification specifically demands the "SSL 3.0 record format and client hello structure", which is essentially the same as the TLS 1.0 record format and client hello structure, with the notable exception of the version number field. So it's quite clear that you should put {03,00} into the record header version field, since this is the only way you can actually avoid the "TLS 1.0 record format" and use the "SSL 3.0 record format". On the other hand, this could trigger some bugs in thoughtlessly done server implementations, which are avoided by sending {03,01} in the record version field. Robert Dugal's comment is also reading the spec correctly: http://www.ietf.org/mail-archive/web/tls/current/msg00683.html Bodo Moeller wrote on 07/04/2006 05:41:06 AM: > Pasi.Eronen at nokia.com wrote: > > > A quick and totally unscientific survey of what some widely used > > SSL/TLS implementations do: > > > > - OpenSSL (0.9.8) > > - When configured in "both SSLv3 and TLSv10 allowed" mode, > > sends V2 ClientHello. > > This is the behavior of OpenSSL versions up to 0.9.7g. Versions > 0.9.7h and later, including 0.9.8, will actually send a TLS/SSL3 > format Client Hello message with version number {03,01} in both > fields. The 0.9.8 behavior doesn't make sense to me. I think the correct behaviour would be to encode the minimum protocol {03,00} in the record's protocol field and the highest protocol {03,01} in the client_hello message's protocol field. A server that understands only SSLv3 could reject a client hello message that uses a record protocol of TLSv1. To negotiate with an SSLv2 server the client must send an SSLv2 client hello so why would the situation be any different for SSLv3/TLSv1? -Martin From pgut001@cs.auckland.ac.nz Sun Mar 24 21:52:10 2013 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 5DC2821F8E42 for ; Sun, 24 Mar 2013 21:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 tTu74d6NJc3W for ; Sun, 24 Mar 2013 21:52:09 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 4A34821F8DF1 for ; Sun, 24 Mar 2013 21:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1364187129; x=1395723129; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=/xnxbqjQ6ZPVTicgpqgdSU6AXWW8IqwVM/apNIMIgeY=; b=WYZ6+qxEqj3eNPijpmXZRQS548A4ov+Y2TlhgrscY2HN4GDdQ7GAy6+o i20wYe2G4v4SeAS0rrgEXb1t2PivXJ52OtgoBVGvFxd350pAVrAG+acmD LqIpdjBd0LxKiWqV4h2IztdiGjOEOlSKw4IEX2vSrpOeVlFKJ9oOrX2XM 4=; X-IronPort-AV: E=Sophos;i="4.87,343,1363086000"; d="scan'208";a="177660963" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 25 Mar 2013 17:52:04 +1300 Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe1.UoA.auckland.ac.nz (130.216.4.112) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 25 Mar 2013 17:52:03 +1300 Received: from UXCN10-TDC02.UoA.auckland.ac.nz ([169.254.8.212]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Mon, 25 Mar 2013 17:52:03 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] Missing cipher: anon ephemeral ECDH w/ SHA-2 nor AEAD modes Thread-Index: Ac4pFH3mkIgYtXpbSUOthpH09cmM9w== Date: Mon, 25 Mar 2013 04:52:02 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D2C9EF@uxcn10-tdc02.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Missing cipher: anon ephemeral ECDH w/ SHA-2 nor AEAD modes 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, 25 Mar 2013 04:52:10 -0000 Nikos Mavrogiannopoulos writes:=0A= =0A= >Indeed, but as a comment I'd say that the anon ciphersuites have a big=0A= >disadvantage comparing to using the certificate based ones for anonymous= =0A= >authentication, and that is they cannot support key continuity.=0A= =0A= This is a good point, but then they can support key continuity, you just mi= x=0A= in secret info from session n-1 into the premaster secret for session n. I= t's=0A= even simpler than using certs.=0A= =0A= Peter.= From pgut001@cs.auckland.ac.nz Sun Mar 24 21:59:03 2013 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 AEDF421F8CE9 for ; Sun, 24 Mar 2013 21:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 FozcAwsrfa2n for ; Sun, 24 Mar 2013 21:59:03 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9C621F8CE8 for ; Sun, 24 Mar 2013 21:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1364187543; x=1395723543; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=GzvDG7C58eRbVNcd/lcnlhTIrTxNgi1HyLx8tyNjlCY=; b=SnFwjHLa9T6FbwMvblYZW11CCOoBaCuBvNL5QHulX73iREgJNcjpCkiK tWYIPzoA+kTYMcvO87CoNqyTKkA+qbcwwr4XZR5NBxRYDBsl6UbXLLI+c KfKOiyAyRnLvZZ6IfYspCP9eETX/nu52tA4LjHTdDTb84LBtYHrmFtRkt c=; X-IronPort-AV: E=Sophos;i="4.87,343,1363086000"; d="scan'208";a="177661658" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 25 Mar 2013 17:59:02 +1300 Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe1.UoA.auckland.ac.nz (130.216.4.112) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 25 Mar 2013 17:59:01 +1300 Received: from UXCN10-TDC02.UoA.auckland.ac.nz ([169.254.8.212]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Mon, 25 Mar 2013 17:59:01 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] Missing cipher: anon ephemeral ECDH w/ SHA-2 nor AEAD modes Thread-Index: Ac4pFXa7/8iFSxodRjulmQhk9DS3lQ== Date: Mon, 25 Mar 2013 04:59:00 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D2C9FC@uxcn10-tdc02.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Missing cipher: anon ephemeral ECDH w/ SHA-2 nor AEAD modes 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, 25 Mar 2013 04:59:03 -0000 Martin Rex writes:=0A= =0A= >One of the problem is, that with some SSL Stacks, authentication of the=0A= >server is performed in an event-based callback fashion on receipt of the= =0A= >Server Certfiicate handshake message.=0A= >=0A= >Myself, I haven't used any such implementation, but I would not be surpris= ed=0A= >if, when an anon cipher suite is enabled and used, there simply wouldn't b= e=0A= >any callback performed, and the application caller typically wouldn't care= ,=0A= >and the user would silently assume that authentication happend, because he= =0A= >was not shown an error.=0A= =0A= There's a (reasonably) widely-deployed implementation that reports successf= ul=0A= cert verification if an anon or NULL suite is used (!!). Both are enabled = by=0A= default, this was discovered by chance by some implementers who carefully= =0A= checked that the cert the other side presented had verified, for some reaso= n=0A= the other enabled use of a NULL suite and the implementation happily comple= ted=0A= the handshake with a NULL suite while reporting that everything was OK and = the=0A= certificate had verified.=0A= =0A= Having said that:=0A= =0A= >Myself, I haven't used any such implementation, but I would not be surpris= ed=0A= >if, when an anon cipher suite is enabled and used, there simply wouldn't b= e=0A= >any callback performed=0A= =0A= ... as opposed to implementation where a callback does happen and the=0A= developers hardcode it to 'return true' because certificate verification is= =0A= hard (too many cases of this to enumerate, see the CCS'12 papers on cert-= =0A= verification problems in apps for some examples).=0A= =0A= Peter.=0A= From nico@cryptonector.com Mon Mar 25 09:46:47 2013 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 2EE7821F92BD for ; Mon, 25 Mar 2013 09:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_BACKHAIR_33=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 SzfnDoQnX+o3 for ; Mon, 25 Mar 2013 09:46:46 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE4B21F92BA for ; Mon, 25 Mar 2013 09:46:46 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 3A33859805F for ; Mon, 25 Mar 2013 09:46:46 -0700 (PDT) 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; s=cryptonector.com; bh=zmqNxBX2txuLURRaJow/ Kf9LlLo=; b=Xfcn/ZMG9vUGRpRfdu5MI2RUPjxtf9UjfZvh7mWlof6hAsKszmpV clhOHDJcenpawb4+B1mKvk+ZI775vzmP3J9NLSWcl8SD7mr8Lad/b4lb0QXxj6yS DLgQHWxgfxFTJIHwfk8ooz461CNrm1papg414FQRssKE/vhCeNpitLM= Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id D6D6F598057 for ; Mon, 25 Mar 2013 09:46:45 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id r5so2712780wey.11 for ; Mon, 25 Mar 2013 09:46:44 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.39.207 with SMTP id r15mr6427322wik.16.1364230004226; Mon, 25 Mar 2013 09:46:44 -0700 (PDT) Received: by 10.217.105.195 with HTTP; Mon, 25 Mar 2013 09:46:43 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7343D2C9FC@uxcn10-tdc02.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C7343D2C9FC@uxcn10-tdc02.UoA.auckland.ac.nz> Date: Mon, 25 Mar 2013 11:46:43 -0500 Message-ID: From: Nico Williams To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Missing cipher: anon ephemeral ECDH w/ SHA-2 nor AEAD modes 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, 25 Mar 2013 16:46:47 -0000 One of the applications where use of anon DH suites is useful is Postfix, and, really, all MTAs. *Eventually* we'll have a world where DANE has been widely (and properly) deployed, and then we can use that an no anon DH suites. In the meantime, the ability to negotiate an anon DH cipher suite obtains a) protection from passive attackers (which, well, whatever, in this day and age of NSLs and such), and b) decent integrity protection relative to plain transmission errors. In the world of e-mail hop-by-hop authentication has much lower priority than delivery, and if you want end-to-end authentication then you'll layer that on top (either PGP or S/MIME, or settle for DKIM). But we should still want to be able to upgrade to stronger hop-by-hop security some day, and starting with being able to do TLS in *all* MTA<->MTA connections helps us get there. I will submit an I-D shortly. I will assume that the missing ciphersuites are missing due to oversight. Nico -- From hannes.tschofenig@gmx.net Tue Mar 26 07:16:59 2013 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 618A621F8A0C for ; Tue, 26 Mar 2013 07:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.141 X-Spam-Level: X-Spam-Status: No, score=-102.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 TqMRIo4-ktk5 for ; Tue, 26 Mar 2013 07:16:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id BAC9D21F888C for ; Tue, 26 Mar 2013 07:16:49 -0700 (PDT) Received: from 3capp-gmx-bs15.server.lan ([172.19.170.67]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M1TnD-1UdwEl1GEj-00tRar; Tue, 26 Mar 2013 15:16:42 +0100 Received: from [194.251.119.198] by 3capp-gmx-bs15.server.lan with HTTP; Tue Mar 26 15:16:42 CET 2013 MIME-Version: 1.0 Message-ID: From: "Hannes Tschofenig" To: "Joseph Salowey (jsalowey)" Content-Type: text/html; charset=UTF-8 Date: Tue, 26 Mar 2013 15:16:42 +0100 (CET) Importance: normal Sensitivity: Normal In-Reply-To: References: <4EF84292.50201@gmx.net> <4F2FC5AA.5070600@comodo.com> <7E329BCB-EFA1-423B-8F20-F6EA382D2901@gmx.net> <5147113D.2070304@comodo.com>, X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:OA376BG/dDlmRav9j54+M17AtmgROFr4h1eF6DpKuxv yukSG3Iw5jZf0jJNt2pxaAveT1q/lY27QFMTaeF1t6PE1qVrxK ywQ9GC940DL5KgKDJVBjZTy3xUBhkKjLxFSx1UDuRGPG6rYb2Q dVpmUoB7oafWG8PjjMMi3Z4QIOmx0smVQqg34MjJnxMSkniA3f bbrhT4TWyGw4BARRutaU2LEHkpMi1Tfejl2vz5b38xufoD82Z+ u+Qhs5zDriKwukXZODgRGTJeqdsC1q1TENYqg4EnzCXPVxSmcO Ikh7ys= Cc: "" Subject: Re: [TLS] cached-info and multiple-ocsp 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, 26 Mar 2013 14:16:59 -0000
Hi Rob,
 
thanks for your comments. (In all the Salsa mail traffic I overlooked your mail.)
 
We are indeed working on the update and a most recent snapshot of the work in progress document is available here:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-14.txt
 
Regarding RFC 6066: It includes a number of features but I guess you are interested in allowing to omit send the OCSP response from the server to the client. 
 
Regarding multiple-ocsp: I guess you refer to http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-04 rather than http://tools.ietf.org/html/draft-pettersen-tls-ext-multiple-ocsp-03.
In draft-ietf-tls-multiple-cert-status-extension-04 I guess you are interested in omitting the multiple OCSP responses (which is an extension to RFC 6066).
 
Just want to confirm that I am looking at the right documents/functionality.
 
To ask you further questions have a look at RFC 6066. The OCSP response is defined as follows:
      struct {
          CertificateStatusType status_type;
          select (status_type) {
              case ocsp: OCSPResponse;
          } response;
      } CertificateStatus;

      opaque OCSPResponse<1..2^24-1>;
Would you expect that the entire "CertificateStatus" message is omitted, which RFC 6066 seems to allow?
 
Ciao
Hannes
 
Gesendet: Montag, 18. März 2013 um 16:18 Uhr
Von: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
An: "Rob Stradling" <rob.stradling@comodo.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Betreff: Re: [TLS] cached-info and multiple-ocsp
Hi Rob,

We still plan on moving this draft forward. A revision is in the works. Please work with the authors to define some candidate text for multi-OCSP.

Thanks,

Joe
On Mar 18, 2013, at 6:06 AM, Rob Stradling <rob.stradling@comodo.com> wrote:

> Hannes, Stefan,
>
> I see that draft-ietf-tls-cached-info-13 expired a couple of days ago.
>
> Does this WG still intend to progress cached-info to RFC status?
>
> On 13/07/12 10:40, Hannes Tschofenig wrote:
> <snip>
>>> Or, is it your explicit intention to restrict cached-info so that it only supports the "standard" TLS handshake objects (e.g. Certificate, Trusted CAs list).
>>> (I can see that such a restriction could help to ensure that client-side code can be implemented entirely within the network layer rather than bleeding into the application layer).
>>
>> There is no intention to restrict the functionality to certain extensions.
>>
>> I do, however, believe that new documents should add a description to their document how this document could be used in combination with the TLS cached information extension.
>>
>> I don't think it makes sense to add text about, for example, draft-pettersen-tls-ext-multiple-ocsp when that work is still in progress.
>
> Since multiple-ocsp is currently in IESG call, it seems likely that multiple-ocsp will reach RFC status before cached-info.
>
> Therefore, please could text be added to cached-info to specify its use with both of the CertificateStatus extensions (RFC6066 and multiple-ocsp) ?
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
From mrex@sap.com Tue Mar 26 07:43:28 2013 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 7A0DA21F8B6D for ; Tue, 26 Mar 2013 07:43:28 -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=[AWL=0.000, 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 9z+mECpf5QXm for ; Tue, 26 Mar 2013 07:43:24 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 23F9821F8B35 for ; Tue, 26 Mar 2013 07:43:23 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r2QEhCLa013963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Mar 2013 15:43:22 +0100 (MET) In-Reply-To: To: Wan-Teh Chang Date: Tue, 26 Mar 2013 15:43:11 +0100 (CET) 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: <20130326144312.02CD41A668@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Record version (was Re: Salsa20 stream cipher in TLS) 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: Tue, 26 Mar 2013 14:43:28 -0000 Wan-Teh Chang wrote: > Michael D'Errico wrote: > > > > Perhaps some better advice should be added next time ("use the client's > > lowest supported version") and placed in the main document instead of > > an appendix.... > > As RFC 5246 Appendix E says, this is a complex topic. > > If you put the lowest version number supported by the client, > which is typically SSL 3.0 {03, 00}, in the record layer, this > server will pick SSL 3.0, even though it can also do TLS 1.0. > > In our experience with the Google Chrome browser, putting > TLS 1.0 {03, 01} in the record layer of the initial ClientHello > has worked well. (ClientHello.client_version is TLS 1.1 {03, 02} > for Google Chrome.) When we discussed that issue on the TLS WG mailing list in 2006, there was already quite some variation around, and there was a significant amount of implementations in the installed base sending TLSv1.0 in record layer and ClientHello.client_version, and this specific combination had at least the same interoperability as SSLv3 in record layer and TLSv1.0 in ClientHello.client_version. I can understand that one does not want to retroactively patch a change of behaviour of the installed base unless there are interop benefits (which there were not apparent for {03,00}+{03,01} over {03,01}+{03,01}. But what should have been obvious is that it would be a bad idea to make the situation any worse going into the future. Google Chrome (25) improved, sending {03,01}+{03,02} OpenSSL-1.0.1c improved, sending {03,01}+{03,03}, Microsoft Windows 7 is worse than 2006, sending {03,03}+{03,03}, similar to iPhone... -Martin From rob.stradling@comodo.com Tue Mar 26 14:40:25 2013 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 1FA7521F8CAE for ; Tue, 26 Mar 2013 14:40:25 -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 tmvRDq9k+i0b for ; Tue, 26 Mar 2013 14:40:23 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 91F9D21F8C8F for ; Tue, 26 Mar 2013 14:40:17 -0700 (PDT) Received: (qmail 13443 invoked from network); 26 Mar 2013 21:40:16 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 26 Mar 2013 21:40:16 -0000 Received: (qmail 5425 invoked by uid 1000); 26 Mar 2013 21:40:16 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Tue, 26 Mar 2013 21:40:16 +0000 Message-ID: <515215BF.2060303@comodo.com> Date: Tue, 26 Mar 2013 21:40:15 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Hannes Tschofenig References: <4EF84292.50201@gmx.net> <4F2FC5AA.5070600@comodo.com> <7E329BCB-EFA1-423B-8F20-F6EA382D2901@gmx.net> <5147113D.2070304@comodo.com>, In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [TLS] cached-info and multiple-ocsp 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, 26 Mar 2013 21:40:25 -0000 On 26/03/13 14:16, Hannes Tschofenig wrote: > Hi Rob, Hi Hannes. > Regarding RFC 6066: It includes a number of features but I guess you are > interested in allowing to omit send the OCSP response from the server to > the client. Yes. > Regarding multiple-ocsp: I guess you refer to > http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-04 > rather than > http://tools.ietf.org/html/draft-pettersen-tls-ext-multiple-ocsp-03. Yes. > In draft-ietf-tls-multiple-cert-status-extension-04 I guess you are > interested in omitting the multiple OCSP responses (which is an > extension to RFC 6066). Yes. > Just want to confirm that I am looking at the right documents/functionality. > To ask you further questions have a look at RFC 6066. The OCSP response > is defined as follows: > > struct { > CertificateStatusType status_type; > select (status_type) { > case ocsp: OCSPResponse; > } response; > } CertificateStatus; > > opaque OCSPResponse<1..2^24-1>; > > Would you expect that the entire "CertificateStatus" message is omitted, > which RFC 6066 seems to allow? Yes. > Ciao > Hannes > *Gesendet:* Montag, 18. März 2013 um 16:18 Uhr > *Von:* "Joseph Salowey (jsalowey)" > *An:* "Rob Stradling" > *Cc:* "" > *Betreff:* Re: [TLS] cached-info and multiple-ocsp > Hi Rob, > > We still plan on moving this draft forward. A revision is in the works. > Please work with the authors to define some candidate text for multi-OCSP. > > Thanks, > > Joe > On Mar 18, 2013, at 6:06 AM, Rob Stradling wrote: > > > Hannes, Stefan, > > > > I see that draft-ietf-tls-cached-info-13 expired a couple of days ago. > > > > Does this WG still intend to progress cached-info to RFC status? > > > > On 13/07/12 10:40, Hannes Tschofenig wrote: > > > >>> Or, is it your explicit intention to restrict cached-info so that > it only supports the "standard" TLS handshake objects (e.g. Certificate, > Trusted CAs list). > >>> (I can see that such a restriction could help to ensure that > client-side code can be implemented entirely within the network layer > rather than bleeding into the application layer). > >> > >> There is no intention to restrict the functionality to certain > extensions. > >> > >> I do, however, believe that new documents should add a description > to their document how this document could be used in combination with > the TLS cached information extension. > >> > >> I don't think it makes sense to add text about, for example, > draft-pettersen-tls-ext-multiple-ocsp when that work is still in progress. > > > > Since multiple-ocsp is currently in IESG call, it seems likely that > multiple-ocsp will reach RFC status before cached-info. > > > > Therefore, please could text be added to cached-info to specify its > use with both of the CertificateStatus extensions (RFC6066 and > multiple-ocsp) ? > > > > -- > > Rob Stradling > > Senior Research & Development Scientist > > COMODO - Creating Trust Online > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From fabrice.gautier@gmail.com Tue Mar 26 16:29:18 2013 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 28DF221F89AA for ; Tue, 26 Mar 2013 16:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 nkbgO4Kfxpi2 for ; Tue, 26 Mar 2013 16:29:17 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7E621F894D for ; Tue, 26 Mar 2013 16:29:17 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id b40so3391911qcq.38 for ; Tue, 26 Mar 2013 16:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=ALV56lZSe22wEOOcG5IS2talkLb7SE5ibXcjBDB4BxU=; b=FhR6V969HCrR0rLoOeREhj0aPJPngwmuR0R47U5y9wuHqKDfPkT+HF0ENETygz49fA Xqm69vFF6bf1ar4S4WMAVA64boB+PwbPEqyHfQKocuSCiBGg4RJ6B6jV3cKN0RTIbhTG VBo+Ml+rBs3NwjyXtsloMpRRrP8WhpWIR0ZFk8rR28yT+qKQ+M09gL6FYwo0n7wQ2UUf O5RLffnMjqgIC5Ca4KE8zxQmG5pp11GbKpVFqRaNkskQdbt1DiBetFcyh3fiFlDGOz/r JuZcyK5/mfGUIYb0YZQ62Ats+SK8npHUei9mJWjYVAN8ShJzCkXfLDH/KLos8pvbcImz PBcg== X-Received: by 10.224.147.65 with SMTP id k1mr8030128qav.26.1364340130387; Tue, 26 Mar 2013 16:22:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.1.18 with HTTP; Tue, 26 Mar 2013 16:21:50 -0700 (PDT) From: Fabrice Gautier Date: Tue, 26 Mar 2013 16:21:50 -0700 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [TLS] Client Hello version during renegotiation. 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, 26 Mar 2013 23:29:18 -0000 Hi all, If I'm reading the RFC 5746 correctly, a TLS 1.2 client that initially negotiated a TLS 1.0 connection with a server should subsequently set their ClientHello.version to TLS 1.0 in any subsequent renegotiation. Also, when generating the premaster secret in the RSA key exchange, the client should use the protocol version sent in its ClientHello.version, although using the negotiated version may be acceptable. As it turns out, it looks like Exchange 2010 servers are not paying nice with this. Those servers do not support TLS 1.2 and will downgrade to 1.0. They will properly accept the 1.2 version in the premaster secret during the initial handshake. But when the client send a TLS 1.0 client hello during a renegotiation, the handshake will fail if a TLS 1.0 version is used in the premaster secret. It will succeed if a TLS 1.2 version is used in the premaster secret during the renegotiation. On the other hand, using a TLS 1.2 version in the premaster secret, while sending a TLS 1.0 client hello will break openssl and gnutls servers. It looks like this is worked around in OpenSSL (1.0.1) by sending a TLS 1.2 client hello during the renegotiation, even if the server indicated that they only supported 1.0. Gnutls clients (3.0.8) will fail as explained above. So two questions: - Is gnutls doing the right thing and Exchange just buggy ? - Is the OpenSSL workaround a sane thing to do ? Relevant OpenSSL ChangeLog: Changes between 1.0.0h and 1.0.1 [14 Mar 2012] [...] *) Some servers which support TLS 1.0 can choke if we initially indicate support for TLS 1.2 and later renegotiate using TLS 1.0 in the RSA encrypted premaster secret. As a workaround use the maximum pemitted client version in client hello, this should keep such servers happy and still work with previous versions of OpenSSL. [Steve Henson] -- Fabrice From ryan-ietftls@sleevi.com Tue Mar 26 16:44:24 2013 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 964B521F863B for ; Tue, 26 Mar 2013 16:44:24 -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 H0EJ9ei68O4R for ; Tue, 26 Mar 2013 16:44:23 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5FE21F85DB for ; Tue, 26 Mar 2013 16:44:23 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 611B5286057; Tue, 26 Mar 2013 16:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=VCGo6AN+ZEBBYuWMFfv4Kll/k34=; b=wkBUEsBRz7vjO9aZB +thmeWwbtao25AbQn/7d+LGGRVRxzovczMFjWqxOhkQPVNLhKz5i1QRjpLmw8omm kl80P9q+ObHeoaww3Iu8Sw3TeksJcMvfc8AO4Y//mAQ6t/EyrciD/qAyql6zK+6b slb3Th1t9IwAuCNYb8DaQFYkmg= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPA id DAA3E286055; Tue, 26 Mar 2013 16:44:22 -0700 (PDT) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Tue, 26 Mar 2013 16:44:23 -0700 Message-ID: <7f3a1490eb9ac441353d74865592c3e8.squirrel@webmail.dreamhost.com> In-Reply-To: References: Date: Tue, 26 Mar 2013 16:44:23 -0700 From: "Ryan Sleevi" To: "Fabrice Gautier" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Client Hello version during renegotiation. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietftls@sleevi.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: Tue, 26 Mar 2013 23:44:24 -0000 On Tue, March 26, 2013 4:21 pm, Fabrice Gautier wrote: > Hi all, > > If I'm reading the RFC 5746 correctly, a TLS 1.2 client that initially > negotiated a TLS 1.0 connection with a server should subsequently set > their ClientHello.version to TLS 1.0 in any subsequent renegotiation. > > Also, when generating the premaster secret in the RSA key exchange, > the client should use the protocol version sent in its > ClientHello.version, although using the negotiated version may be > acceptable. > > > As it turns out, it looks like Exchange 2010 servers are not paying > nice with this. > > Those servers do not support TLS 1.2 and will downgrade to 1.0. > They will properly accept the 1.2 version in the premaster secret > during the initial handshake. > But when the client send a TLS 1.0 client hello during a > renegotiation, the handshake will fail if a TLS 1.0 version is used in > the premaster secret. > It will succeed if a TLS 1.2 version is used in the premaster secret > during the renegotiation. > > On the other hand, using a TLS 1.2 version in the premaster secret, > while sending a TLS 1.0 client hello will break openssl and gnutls > servers. > > It looks like this is worked around in OpenSSL (1.0.1) by sending a > TLS 1.2 client hello during the renegotiation, even if the server > indicated that they only supported 1.0. > > Gnutls clients (3.0.8) will fail as explained above. > > > So two questions: > - Is gnutls doing the right thing and Exchange just buggy ? > - Is the OpenSSL workaround a sane thing to do ? > > > Relevant OpenSSL ChangeLog: > > Changes between 1.0.0h and 1.0.1 [14 Mar 2012] > [...] > *) Some servers which support TLS 1.0 can choke if we initially indi= cate > support for TLS 1.2 and later renegotiate using TLS 1.0 in the RS= A > encrypted premaster secret. As a workaround use the maximum pemit= ted > client version in client hello, this should keep such servers hap= py > and still work with previous versions of OpenSSL. > [Steve Henson] > > > > -- Fabrice Hi Fabrice, For better or worse, when we were implementing support for TLS 1.1 within Chrome/Chromium, we ran into the same issue. Because of the many sites it affected (namely, sites that use SChannel for SSL/TLS), we adopted the workaround you've described, and as similar to OpenSSL. This was captured in the NSS bug https://bugzilla.mozilla.org/show_bug.cgi?id=3D783448 - which is the same underlying cryptographic library used by Firefox and Chrome. As such, consider this one of the many pieces of TLS lore that gets passe= d around for how clients "really" behave. Cheers, Ryan From turners@ieca.com Tue Mar 26 17:41:52 2013 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 8604C21F89CC for ; Tue, 26 Mar 2013 17:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.286 X-Spam-Level: X-Spam-Status: No, score=-102.286 tagged_above=-999 required=5 tests=[AWL=-0.021, 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 U51RSQd6z+oo for ; Tue, 26 Mar 2013 17:41:52 -0700 (PDT) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.56.142.29]) by ietfa.amsl.com (Postfix) with ESMTP id 1F37221F89AE for ; Tue, 26 Mar 2013 17:41:52 -0700 (PDT) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id 85A9BBF023A42; Tue, 26 Mar 2013 19:41:51 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway08.websitewelcome.com (Postfix) with ESMTP id 79C68BF023A06 for ; Tue, 26 Mar 2013 19:41:51 -0500 (CDT) Received: from [108.45.16.214] (port=60236 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UKeR5-0006Wz-AX for tls@ietf.org; Tue, 26 Mar 2013 19:41:51 -0500 Message-ID: <5152404E.2010702@ieca.com> Date: Tue, 26 Mar 2013 20:41:50 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: tls@ietf.org 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) [108.45.16.214]:60236 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [TLS] request for early IANA assignment for ALPN 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, 27 Mar 2013 00:41:52 -0000 I received a verbal request for an early IANA assignment for ALPN in the TLS extension type registry from Adrei P, Stephan F, and Adam L at the meeting in Orlando. I've double checked with them and the WG chairs to make sure that's still desired. Not so shocking the answer was yes. The TLS extension type registry is eligible for early assignment if approved by the IESG (I double checked). I asked a couple of folks whether they thought the format, semantics, processing, etc were adequately described and they said they were. It's a pretty simple extension so it's probably not going to change much, and there's definitely interest in pre-RFC implementation. Based on the WG adopting the TLS-based upper-layer protocol negotiation mechanism working item in Atlanta, what looks like consensus to me on using ALPN, and the fact that we're not exactly running out of code points I'm going to request that the IESG approve an early assignment. But, there's no guarantee it'll happen Thursday. spt From n.mavrogiannopoulos@gmail.com Wed Mar 27 00:16:42 2013 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 DCE2B21F90A6 for ; Wed, 27 Mar 2013 00:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.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 cWt6Ri9k8itq for ; Wed, 27 Mar 2013 00:16:42 -0700 (PDT) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 35ABC21F8ECD for ; Wed, 27 Mar 2013 00:16:42 -0700 (PDT) Received: by mail-ea0-f171.google.com with SMTP id b15so1202823eae.2 for ; Wed, 27 Mar 2013 00:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:x-enigmail-version:openpgp :content-type:content-transfer-encoding; bh=D/9IO1jVtf4wr/b6lqKzDgjFIOEkmlZiraJ91CjFwKM=; b=ol+1CRunGA+1M8c7lsrUjSkXSksghRtV9FuI59zDQQFT7MfihQJ8yMFXKP5rJrUINQ fl048A71IymjmxCBF4BbDETy1LISEQyJX5txd2b5LOrJOATvk8sHY5SvRZ+HQ5T4Fj+1 JIOoYK2k42x1VfAHV64CEkJK9lM0NgVPDNfSA00JSnlAZQHQB8NZysc+0uJhB9Gr1y+z 9IPQjTBMcb7hQaoHDmXQ1damLiccW74BbrYxy99PoaObp4yOeYObwBrSH9u66raXQRiN uosITCrCIgo3Bc6PxZrX22nksochVGSDqlgUiuEICA0yf20Ib/U3ZgWugVwwZ9XVCfK8 6u2w== X-Received: by 10.15.21.1 with SMTP id c1mr4316200eeu.36.1364368598686; Wed, 27 Mar 2013 00:16:38 -0700 (PDT) Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id a1sm29341192eep.2.2013.03.27.00.16.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Mar 2013 00:16:37 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <51529CCE.5070302@gnutls.org> Date: Wed, 27 Mar 2013 08:16:30 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: tls@ietf.org References: <5152404E.2010702@ieca.com> In-Reply-To: <5152404E.2010702@ieca.com> X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] request for early IANA assignment for ALPN 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, 27 Mar 2013 07:16:43 -0000 On 03/27/2013 01:41 AM, Sean Turner wrote: > Based on the WG adopting the TLS-based upper-layer protocol negotiation > mechanism working item in Atlanta, what looks like consensus to me on > using ALPN, and the fact that we're not exactly running out of code The advantage of no point registration during draft stage is that contributors are not limited by arguments like "this is now implemented and deployed - too difficult to change". The disadvantage is no interoperability testing. However, I'd find it nice to easily reserve points for ciphersuites or other TLS IANA managed points at an early stage of a draft for interoperability testing. Those points could be reserved for a limited time and kept if the RFC is identical to the draft. So I think that such process should be generalized, if possible, rather than applied only for ALPN. regards, Nikos From yngve@spec-work.net Wed Mar 27 01:43:41 2013 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 AD23A21F90DE for ; Wed, 27 Mar 2013 01:43: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 2fZV7xHKJSZJ for ; Wed, 27 Mar 2013 01:43:41 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB8321F90DB for ; Wed, 27 Mar 2013 01:43:40 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:50809 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UKlxK-0002aJ-6z for tls@ietf.org; Wed, 27 Mar 2013 09:43:38 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org References: <5152404E.2010702@ieca.com> Date: Wed, 27 Mar 2013 09:43:30 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <5152404E.2010702@ieca.com> User-Agent: Opera Mail/12.14 (Win32) Subject: Re: [TLS] request for early IANA assignment for ALPN 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, 27 Mar 2013 08:43:41 -0000 As Nikos said, there are advantages and disadvantages with an early assignment. In my opinion, the risk of changes to the format should mean that a permanent assignment should not be done at this stage. After all, the format of my multistapling draft did change once I had some implementation experience, although that was before it became a WG item. If the change had happened after several test implementations had been deployed with a reserved number, we might have had a problem, particularly if the extension had been deployed in final versions of products. Instead, I would suggest that a temporary number from a (reusable) range that is allocated to testing is used. A permanent number can be assigned once development is complete. The temporary number means that everybody are on notice that the spec is still under development and subject to change, and should only be deployed in test-versions of products, not final versions. On Wed, 27 Mar 2013 01:41:50 +0100, Sean Turner wrote: > I received a verbal request for an early IANA assignment for ALPN in the > TLS extension type registry from Adrei P, Stephan F, and Adam L at the > meeting in Orlando. I've double checked with them and the WG chairs to > make sure that's still desired. Not so shocking the answer was yes. > > The TLS extension type registry is eligible for early assignment if > approved by the IESG (I double checked). I asked a couple of folks > whether they thought the format, semantics, processing, etc were > adequately described and they said they were. It's a pretty simple > extension so it's probably not going to change much, and there's > definitely interest in pre-RFC implementation. > > Based on the WG adopting the TLS-based upper-layer protocol negotiation > mechanism working item in Atlanta, what looks like consensus to me on > using ALPN, and the fact that we're not exactly running out of code > points I'm going to request that the IESG approve an early assignment. > But, there's no guarantee it'll happen Thursday. > > spt > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From mrex@sap.com Wed Mar 27 06:52:07 2013 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 8145B21F9096 for ; Wed, 27 Mar 2013 06:52:07 -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 s7z7c4aSNFdo for ; Wed, 27 Mar 2013 06:52:06 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 01B3D21F90DE for ; Wed, 27 Mar 2013 06:52:05 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r2RDq3bm001016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Mar 2013 14:52:03 +0100 (MET) In-Reply-To: To: Fabrice Gautier Date: Wed, 27 Mar 2013 14:52:02 +0100 (CET) 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: <20130327135202.E868A1A672@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Client Hello version during renegotiation. 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, 27 Mar 2013 13:52:07 -0000 Fabrice Gautier wrote: > > If I'm reading the RFC 5746 correctly, a TLS 1.2 client that initially > negotiated a TLS 1.0 connection with a server should subsequently set > their ClientHello.version to TLS 1.0 in any subsequent renegotiation. No, not really. (rfc5746 says it is merely reiterating rfc5246) Admittedly, the original text in rfc2246->rfc4346->rfc5246 is slightly weird: 7.4.1.2. Client Hello http://tools.ietf.org/html/rfc5246#page-41 client_version The version of the TLS protocol by which the client wishes to communicate during this session. This SHOULD be the latest (highest valued) version supported by the client. For this version of the specification, the version will be 3.3 (see Appendix E for details about backward compatibility). If you look closely, the first sentence contradicts the second sentence. But only the second sentence uses "requirements" language, and that requirement is unconditional. The rule of thumb is: if the server asks you for renegotiation, do NOT pull any stunts -- send EXACTLY the same ClientHello as on the initial handshake, i.e. the exact same ClientHello.client_version as on the initial handshake, and that should unconditionally contain the highest version the implementation supports (or more accurately the highest version that the implementation is configured to offer. Adding Extensions, removing extensions or playing with TLS version numbers may cause the reneogtiation handshake to fail, so HANDS OFF. > > Also, when generating the premaster secret in the RSA key exchange, > the client should use the protocol version sent in its > ClientHello.version, although using the negotiated version may be > acceptable. The client MUST send the ClientHello.client_version of the **CURRENT** handshake in the RSA premaster secret. This is the part that Microsoft > > As it turns out, it looks like Exchange 2010 servers are not paying > nice with this. This is the part that Microsoft completely goofed in Win7 SChannel -- they're comparing the RSA premaster secret client_version with the ClientHello.client_version of the initial handshake of the connection. I'm puzzled what takes them so long to patch this bug. They know about this goof for quite some time. http://www.ietf.org/mail-archive/web/tls/current/msg08139.html -Martin From fabrice.gautier@gmail.com Wed Mar 27 09:35:03 2013 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 5F4FF21F9181 for ; Wed, 27 Mar 2013 09:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 ZeryrDuAnX0r for ; Wed, 27 Mar 2013 09:35:02 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id 52FD521F91BD for ; Wed, 27 Mar 2013 09:35:02 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id b4so4633132qen.18 for ; Wed, 27 Mar 2013 09:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=+MRJD5OD8vZBURt3zwp8ge1PzmFJoPvxSsubQHoj6pA=; b=Pw4ypT9L5QGYh+7LYW3QaM2DS3E4/S8FenHYZqKJpAfuGbTMd7bv2JdInMsjorQFCK /aJZzWI6eUl8lk70x2BOBSFZj2tLg89sjCWHDtqZGbdqh2sEAO0dsbIId79vjVvfdWuL +N9f+oBy3dRz0OuhRAvpfT2YMSw5Zclo6+CoQy+kDtGKavSfOiMdt1eHLoP/1CGJ48GX 8EOqQC6pQ9r9YJf69K3c2wRKyp4eT9M+Sract5VF6dBunrOS+YqfMrSorGC8nrpXjWE7 Nf59rJoLm41ZacYoPFrL2mnQa6gC5g1uP9aU9VHPIFCwccyX5l/bzXY3gJBdEoAFWWkw RbCQ== X-Received: by 10.49.96.201 with SMTP id du9mr16004931qeb.47.1364402101766; Wed, 27 Mar 2013 09:35:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.1.18 with HTTP; Wed, 27 Mar 2013 09:34:41 -0700 (PDT) In-Reply-To: <20130327135202.E868A1A672@ld9781.wdf.sap.corp> References: <20130327135202.E868A1A672@ld9781.wdf.sap.corp> From: Fabrice Gautier Date: Wed, 27 Mar 2013 09:34:41 -0700 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Cc: tls@ietf.org Subject: Re: [TLS] Client Hello version during renegotiation. 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, 27 Mar 2013 16:35:03 -0000 On Wed, Mar 27, 2013 at 6:52 AM, Martin Rex wrote: > Fabrice Gautier wrote: >> >> If I'm reading the RFC 5746 correctly, a TLS 1.2 client that initially >> negotiated a TLS 1.0 connection with a server should subsequently set >> their ClientHello.version to TLS 1.0 in any subsequent renegotiation. > > No, not really. (rfc5746 says it is merely reiterating rfc5246) > Sorry, I meant 5246. Specifically, I was referring to: E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 [...] Whenever a client already knows the highest protocol version known to a server (for example, when resuming a session), it SHOULD initiate the connection in that native protocol. Arguably, this could be only meant to apply to new connections and resumed connections, rather than renegotiation handshakes, since it otherwise contradicts the part you quoted. > Admittedly, the original text in rfc2246->rfc4346->rfc5246 is > slightly weird: > > 7.4.1.2. Client Hello > > http://tools.ietf.org/html/rfc5246#page-41 > > client_version > The version of the TLS protocol by which the client wishes to > communicate during this session. This SHOULD be the latest > (highest valued) version supported by the client. For this > version of the specification, the version will be 3.3 (see > Appendix E for details about backward compatibility). > > If you look closely, the first sentence contradicts the second sentence. > But only the second sentence uses "requirements" language, and that > requirement is unconditional. > > The rule of thumb is: if the server asks you for renegotiation, > do NOT pull any stunts -- send EXACTLY the same ClientHello as on > the initial handshake, i.e. the exact same ClientHello.client_version > as on the initial handshake, and that should unconditionally contain > the highest version the implementation supports (or more accurately > the highest version that the implementation is configured to offer. > > Adding Extensions, removing extensions or playing with TLS version > numbers may cause the reneogtiation handshake to fail, so HANDS OFF. > > >> >> Also, when generating the premaster secret in the RSA key exchange, >> the client should use the protocol version sent in its >> ClientHello.version, although using the negotiated version may be >> acceptable. > > > The client MUST send the ClientHello.client_version of the **CURRENT** > handshake in the RSA premaster secret. This is the part that Microsoft > > >> >> As it turns out, it looks like Exchange 2010 servers are not paying >> nice with this. > > This is the part that Microsoft completely goofed in Win7 SChannel -- > they're comparing the RSA premaster secret client_version with the > ClientHello.client_version of the initial handshake of the connection. > I'm puzzled what takes them so long to patch this bug. They know about > this goof for quite some time. > > http://www.ietf.org/mail-archive/web/tls/current/msg08139.html > > > -Martin From mrex@sap.com Wed Mar 27 10:25:41 2013 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 BC41B21F8AE3 for ; Wed, 27 Mar 2013 10:25: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 zHCoUWvGWxPQ for ; Wed, 27 Mar 2013 10:25:41 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5160321F8A40 for ; Wed, 27 Mar 2013 10:25:23 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r2RHPLml008327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Mar 2013 18:25:21 +0100 (MET) In-Reply-To: To: Fabrice Gautier Date: Wed, 27 Mar 2013 18:25:21 +0100 (CET) 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: <20130327172521.0C39E1A677@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Client Hello version during renegotiation. 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, 27 Mar 2013 17:25:41 -0000 Fabrice Gautier wrote: > On Wed, Mar 27, 2013 at 6:52 AM, Martin Rex wrote: > > Fabrice Gautier wrote: > >> > >> If I'm reading the RFC 5746 correctly, a TLS 1.2 client that initially > >> negotiated a TLS 1.0 connection with a server should subsequently set > >> their ClientHello.version to TLS 1.0 in any subsequent renegotiation. > > > > No, not really. (rfc5746 says it is merely reiterating rfc5246) > > > > Sorry, I meant 5246. > > Specifically, I was referring to: > > E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 > [...] > Whenever a client already knows the highest protocol version known to > a server (for example, when resuming a session), it SHOULD initiate > the connection in that native protocol. > > Arguably, this could be only meant to apply to new connections and > resumed connections, rather than renegotiation handshakes, since it > otherwise contradicts the part you quoted. There is a subtle difference between a mere proposal of a protocol version, as represented by "ClientHello.client_version", and the actual use of a protocol version, as represented by the "ProtocolVersion" field of the record layer. So the above "it SHOULD initiate the connection in that native protocol" technically applies only to the "protocol being employed". http://tools.ietf.org/html/rfc5246#section-6.2.1 struct { ContentType type; ProtocolVersion version; uint16 length; opaque fragment[TLSPlaintext.length]; } TLSPlaintext; version The version of the protocol being employed. In case you're wondering whether it is possible to change the protocol version during renegotiation -- not that is currently impossible, because it is unspecified. (Unfortunately, the TLS spec does not mention this). For cryptographic properties that are negotiated with the cipher suite, it is well-defined when to switch from the current ciphersuite and the current properties to the new cipher suite and the new properties (->ChangeCipherSpec). For cryptographic properties that are negotiated through TLS version or through TLS extensions, it is currently undefined when they take effect. -Martin From trevp@trevp.net Wed Mar 27 10:33:00 2013 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 A343E21F9227 for ; Wed, 27 Mar 2013 10:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.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 FFk8ERhrO17z for ; Wed, 27 Mar 2013 10:33:00 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C15E921F9222 for ; Wed, 27 Mar 2013 10:32:59 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id d46so5681321wer.30 for ; Wed, 27 Mar 2013 10:32:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=T/S/KNyoFfVy8Vwcz1+AClPswZIyXbE4Z79sWvehVJ4=; b=VQZZtd4ES3cMT9Qyz1MzQc0RxKUv1+x3WBHJyUkBAnKxOiclw3UlXnvOoV9TIjp2w3 btW8gKUBCdsaVSuy/WnytqB0iWe2/3Ij9w4RQe7NXoppGj8zBGOGxpDuuFZnVBRqNLN+ NltSuPrzxGgsVXoZ9bZBz638x5rhk4OT7Ft7M4bPn2EQybsjWOdWGssNrgPbSdOjAspq Gk4oONUZDVktRUsQ3drOqE3nW9EWLiIVUWLSmVzaus2VJpFyAOSH2gTX7TxA8upXlpUM A/juEAINhkLJys16QOyS+CxafGjzzuGZKNdobKpE6skfrb4E0uJ5mrxdqNIwklRZopUM fjww== MIME-Version: 1.0 X-Received: by 10.180.72.228 with SMTP id g4mr11325733wiv.22.1364405578776; Wed, 27 Mar 2013 10:32:58 -0700 (PDT) Received: by 10.216.111.1 with HTTP; Wed, 27 Mar 2013 10:32:58 -0700 (PDT) X-Originating-IP: [66.127.230.131] In-Reply-To: References: <5152404E.2010702@ieca.com> Date: Wed, 27 Mar 2013 10:32:58 -0700 Message-ID: From: Trevor Perrin To: "Yngve N. Pettersen" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlcGXrQaxczaWVO9VNPqC7LcItnp6i14U64kG4CESJYAIUrNZdX0uQsvbKqoFuuzlmOM8og Cc: tls@ietf.org Subject: Re: [TLS] request for early IANA assignment for ALPN 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, 27 Mar 2013 17:33:00 -0000 On Wed, Mar 27, 2013 at 1:43 AM, Yngve N. Pettersen wrote: > > As Nikos said, there are advantages and disadvantages with an early > assignment. > > In my opinion, the risk of changes to the format should mean that a > permanent assignment should not be done at this stage. I don't believe Nikos was suggesting early "permanent assignment" as a general process. I believe he was suggesting that TLS should have a process for temporarily reserving ExtensionType (and perhaps CipherSuite?) numbers. I think this is a great idea. This would allow new proposals to document what numbers they're using for interop testing and experiments, avoiding the sorts of collisions that occurred around the time of TLS-SRP (several proposals were using the "next" ExtensionType, so software changes were needed after RFC issuance, solely for the final IANA numbers). Another example is TACK: we are using an ExtensionType number for testing, and will be increasingly using it for test and trial deployments. It would be great if there was some process for documenting / deconflicting this with other Internet-Drafts. > Instead, I would suggest that a temporary number from a (reusable) range > that is allocated to testing is used. A permanent number can be assigned > once development is complete. The boundaries between experimental and actual deployments aren't always clear-cut. You're proposing a "flag day" on RFC issuance, where all existing depoyments of a TLS technology must cut-over to a new number. A "temporary reservation" process based on rough WG consensus (which the WG would periodically review) seems much better to me. Trevor From mike-list@pobox.com Wed Mar 27 11:09:56 2013 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 6EA0921F8EA5 for ; Wed, 27 Mar 2013 11:09:56 -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 OlR0V3dbDRi2 for ; Wed, 27 Mar 2013 11:09:55 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1FC21F8A51 for ; Wed, 27 Mar 2013 11:09:53 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 97914C5EA for ; Wed, 27 Mar 2013 14:09:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=T6ldKq2K88AQ 9Bx0AqoeDEvD+IE=; b=NUTS1aPPVUu1MmdkayPW5R1aHgenXMk1Wjc1K050Phku Qv8Q0Q2/K/mScXtrFz4AKbV0Ls6Y0mGdFtpqkTaxIGa6Ts5vFOYo0VCdbWn/Ohyk ayuvS+7HOFnZsKz89QBaIvIwaEtCBHgzTRkYItpv7UyGiBpgJzMp26Pk0Ta+bSI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=Oukazr e8PBEUQh+AiMCpKrYtIOcDD/W1BpXa4UWWywH/FcWX3c6pSXpWGqywJn2lFkfzbi ujkouBZ/CUM1n11dmqHbJ6dz7FAajcZafFvDrGJR3q94yIdq0ulDHUwa62Nb7IxF oOcSFp1Oegz7zOM5c7UZ38Zg93YQ7/PPdVAUo= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 90B98C5E9 for ; Wed, 27 Mar 2013 14:09:52 -0400 (EDT) Received: from iMac.local (unknown [68.224.235.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 25EBAC5E8 for ; Wed, 27 Mar 2013 14:09:52 -0400 (EDT) Message-ID: <515335EF.70607@pobox.com> Date: Wed, 27 Mar 2013 11:09:51 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: tls@ietf.org References: <5152404E.2010702@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 855C6C5A-9709-11E2-8AE1-782E0E5B5709-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] request for early IANA assignment for ALPN 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, 27 Mar 2013 18:09:56 -0000 Trevor Perrin wrote: > On Wed, Mar 27, 2013 at 1:43 AM, Yngve N. Pettersen wrote: >> As Nikos said, there are advantages and disadvantages with an early >> assignment. >> >> In my opinion, the risk of changes to the format should mean that a >> permanent assignment should not be done at this stage. > > I don't believe Nikos was suggesting early "permanent assignment" as a > general process. I believe he was suggesting that TLS should have a > process for temporarily reserving ExtensionType (and perhaps > CipherSuite?) numbers. We could assign a single extension number for experimental use and then pack it with (a list of) experimental extensions: struct { opaque extension_name<1..255>; opaque extension_data<0..2^16-1>; } ExperimentalExtension; ExperimentalExtension experimental_extensions<4..65535>; So then ALPN would look like: 0x04 'A' 'L' 'P' 'N' followed by the same extension data that would appear once ALPN becomes a numbered extension. The added complexity for parsing this structure only affects code that is working on experimental extensions; normal clients and servers will simply ignore the extension. Mike From trevp@trevp.net Wed Mar 27 11:58:00 2013 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 AEA0321F9168 for ; Wed, 27 Mar 2013 11:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.356 X-Spam-Level: * X-Spam-Status: No, score=1.356 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.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 8IP5xOhHlNZ9 for ; Wed, 27 Mar 2013 11:57:59 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 46CB621F84A8 for ; Wed, 27 Mar 2013 11:57:59 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so2681156wiw.2 for ; Wed, 27 Mar 2013 11:57:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=k4Z1kXQNrlr5uqbFEYtz4kxgH24RSMx6KgGFr6RKhQc=; b=peBt0NR9Q76bIyNK8Z9z7poo/fqd+jDrp5i91mP4h9TL8w7sfb/wBnG0mRPCAoDtMH BcQ/dGzg2+6mJSjLTfX5OcB6Xd/Ycsdja6ObOi4d0iecaAASW+jXjOmaxp/C3D02Gw2e jN/wKPXr42NmYii+RNBccBxAh6Tlh8NPoFl0c/XFsqsv3/q66qzuulVW9OGVUx9EIK+J Ya+Vr6/1fSdnhScA2b3AwaQJqcB8kYXvvPjMIsd1eVez1CuadkU2ajY6rpiC5wYFqQ7v uzpWfltZlfKFuXleDQYCMACo4Fs7IeubsfdkuQBSpXVTJkeZCLD09zHduRiCpRgKdstj wVkg== MIME-Version: 1.0 X-Received: by 10.194.121.6 with SMTP id lg6mr33509604wjb.22.1364410678503; Wed, 27 Mar 2013 11:57:58 -0700 (PDT) Received: by 10.216.111.1 with HTTP; Wed, 27 Mar 2013 11:57:58 -0700 (PDT) X-Originating-IP: [64.134.153.179] In-Reply-To: <515335EF.70607@pobox.com> References: <5152404E.2010702@ieca.com> <515335EF.70607@pobox.com> Date: Wed, 27 Mar 2013 11:57:58 -0700 Message-ID: From: Trevor Perrin To: "Michael D'Errico" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnEgTQpLctaIzxf6QegEfM8tIZ6z2MeeiP2tqB3kFi1Nb76lwhJxrFTmIwpH26kagzqZc+0 Cc: tls@ietf.org Subject: Re: [TLS] request for early IANA assignment for ALPN 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, 27 Mar 2013 18:58:00 -0000 On Wed, Mar 27, 2013 at 11:09 AM, Michael D'Errico wrote: > > We could assign a single extension number for experimental use and then > pack it with (a list of) experimental extensions: > > struct { > opaque extension_name<1..255>; > opaque extension_data<0..2^16-1>; > } ExperimentalExtension; > > ExperimentalExtension experimental_extensions<4..65535>; Hmm.... so we'd have to do all interop testing and trial deployments based on an "ExperimentalExtension". Then - once everything is working and RFCs are assigned - make a major incompatible protocol change to a different extension format. I see the costs and risks here, but not the benefit. What does this solve that is not solved by having someone maintain a wiki listing temporary ExtensionType assignments (based on, say, WG rough consensus, re-confirmed at each IETF meeting)? This is essentially just formalizing / documenting existing practice, and provides a smooth path between I-D and RFC deployments without needing a "flag day" protocol change. Trevor From mike-list@pobox.com Wed Mar 27 15:24:02 2013 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 62CEC21F888B for ; Wed, 27 Mar 2013 15:24:02 -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 bLk+f17h+M3x for ; Wed, 27 Mar 2013 15:24:01 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9A07121F86DC for ; Wed, 27 Mar 2013 15:24:00 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 1BDEDB671 for ; Wed, 27 Mar 2013 18:23:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=rm/hNeurcwC+ UFX7Gq+UGujBYSw=; b=UjDYepGQk2G3zJDuJELmLSM0huJb8qPv5oGkHChJEF7g pcqapw6YjKCkeSB8IxtJluz/wjWQgyb9CVQeK81I0Ju+Z0DBc1tEv1F2Pja6jVV1 vfQoAcjTZg6/8GEsMdzQyZnPP3AbPd44rDi9LhXhyNPcqVtD8cZJxiQsTU6x0Hk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=TvWruo rCleEz9d29DV42zVuOiWg1yXY93l9gUHZ5e/tExf4jasDZH/UjNWmrWSXSErPFp2 d8Ekrmdh67H1McPesJkt5amLMm/dWh92K61BiOjjiH1OOReEnwOWKWhaRn7Gt2Hh WiX+Rnh1x1SET/YKkcQP21R7/LWhPSEDL0Olg= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 1342BB670 for ; Wed, 27 Mar 2013 18:23:58 -0400 (EDT) Received: from iMac.local (unknown [68.224.235.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 70B66B66F for ; Wed, 27 Mar 2013 18:23:57 -0400 (EDT) Message-ID: <5153717C.4070707@pobox.com> Date: Wed, 27 Mar 2013 15:23:56 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: tls@ietf.org References: <5152404E.2010702@ieca.com> <515335EF.70607@pobox.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 044535EC-972D-11E2-8A8E-D36F0E5B5709-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] request for early IANA assignment for ALPN 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, 27 Mar 2013 22:24:02 -0000 Trevor Perrin wrote: > On Wed, Mar 27, 2013 at 11:09 AM, Michael D'Errico wrote: >> We could assign a single extension number for experimental use and then >> pack it with (a list of) experimental extensions: >> >> struct { >> opaque extension_name<1..255>; >> opaque extension_data<0..2^16-1>; >> } ExperimentalExtension; >> >> ExperimentalExtension experimental_extensions<4..65535>; > > Hmm.... so we'd have to do all interop testing and trial deployments > based on an "ExperimentalExtension". Then - once everything is > working and RFCs are assigned - make a major incompatible protocol > change to a different extension format. The extension_data would not change. The only difference would be in locating it. > I see the costs and risks here, but not the benefit. The problem with using a range of temporary extension numbers comes when you run out and have to reuse one. Somewhere a server that hasn't been updated in years will be running code like this: switch (extension_number) { case 0x0000: process_sni_extension(); break; case 0xABCD: // experimental ALPN extension number - REMOVE! case 0x00xx: // IANA-assigned ALPN extension number process_alpn_extension(); break; } If 0xABCD is ever used for any other experimental extension, it could cause this server to start acting funny. Using names for experimental extensions avoids this problem. > What does this solve that is not solved by having someone maintain a > wiki listing temporary ExtensionType assignments (based on, say, WG > rough consensus, re-confirmed at each IETF meeting)? The problem outlined above, plus it allows for non-IETF-sanctioned experiments such as NPN/SPDY. The wire format of an extension could change during the experiment - simply add "v2" to the name instead of requiring a new number assignment via rough consensus at the next IETF meeting resulting in a wiki update. Mike From rsalz@akamai.com Wed Mar 27 15:54:14 2013 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 CA26921F9098 for ; Wed, 27 Mar 2013 15:54:08 -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 a8o6L89a1dpE for ; Wed, 27 Mar 2013 15:54:08 -0700 (PDT) Received: from prod-mail-xrelay01.akamai.com (prod-mail-xrelay01.akamai.com [72.246.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 118A221F9060 for ; Wed, 27 Mar 2013 15:53:57 -0700 (PDT) Received: from prod-mail-xrelay01.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CE737D0407; Wed, 27 Mar 2013 22:53:56 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay01.akamai.com (Postfix) with ESMTP id BC897D0400; Wed, 27 Mar 2013 22:53:56 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub1.dfw01.corp.akamai.com [172.27.25.75]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id A4494204C; Wed, 27 Mar 2013 22:53:56 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.203]) by ustx2ex-cashub1.dfw01.corp.akamai.com ([172.27.25.75]) with mapi; Wed, 27 Mar 2013 17:53:56 -0500 From: "Salz, Rich" To: Michael D'Errico , "tls@ietf.org" Date: Wed, 27 Mar 2013 17:53:55 -0500 Thread-Topic: [TLS] request for early IANA assignment for ALPN Thread-Index: Ac4rOcwOGFpVijdESs21LbziJTZJywAA37rA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7AC44C32A@USMBX1.msg.corp.akamai.com> References: <5152404E.2010702@ieca.com> <515335EF.70607@pobox.com> <5153717C.4070707@pobox.com> In-Reply-To: <5153717C.4070707@pobox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] request for early IANA assignment for ALPN 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, 27 Mar 2013 22:54:18 -0000 You could put (year-2000) as the top two bytes of the extension number, and= promise that no temporary assignment lasts more than two years. That way i= t could be made obvious when your counter-party is using an outdated tempor= ary identifier. And I wouldn't worry about round-off or encoding the month. /r$, who apparently pines for the pre-CIDR days -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From trevp@trevp.net Wed Mar 27 16:29:16 2013 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 39AB121F85DA for ; Wed, 27 Mar 2013 16:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.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 H6WQSqzkg8ZR for ; Wed, 27 Mar 2013 16:29:15 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5411721F8ECD for ; Wed, 27 Mar 2013 16:29:15 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id z53so2934612wey.23 for ; Wed, 27 Mar 2013 16:29:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=FpsOJGUJvrDZj4qYLH+DqmhbvR0jf0lek0E8/j7WSb0=; b=KZMI4HRzxJ9Ql5HftRlJ4udSkiDIzxD/fFloJtkaJB+XLSlB4dT7X/qnOlr3gq3SQ8 fbb6nS5FvsfbtST/di8s/+0EqBp0sSOO1/fFuy2wAYuHbEMR80rZ+QoIfnjfkrQeiXlp NFw93fO/CyA6T5/n51D8E+hKrLSXJcosd1NTIYtnm5QFYBjgUZUc8da43KNwJdacmvnT IU1BWPG4wYKqypWBhtnNsjTQF94D7/SICt/byWPbO4YBL3OJ2V02T902AJOjHkxXmFMu 0DtmzvzTDXW0gMj5tbaIhpXfc2ZxFIzv5p3yveHbHzB+5iJT6Nvcb3+myJL+lNO5iXUV FuRg== MIME-Version: 1.0 X-Received: by 10.180.105.99 with SMTP id gl3mr12870071wib.22.1364426954527; Wed, 27 Mar 2013 16:29:14 -0700 (PDT) Received: by 10.216.111.1 with HTTP; Wed, 27 Mar 2013 16:29:14 -0700 (PDT) X-Originating-IP: [173.11.71.218] In-Reply-To: <5153717C.4070707@pobox.com> References: <5152404E.2010702@ieca.com> <515335EF.70607@pobox.com> <5153717C.4070707@pobox.com> Date: Wed, 27 Mar 2013 16:29:14 -0700 Message-ID: From: Trevor Perrin To: "Michael D'Errico" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmk3MfdYVNRBgTDrJfCzyrDaVVrFI2EZei2qNYzF6t9JBcbdtX0tsQERl3fO2r2dXjeRKDU Cc: tls@ietf.org Subject: Re: [TLS] request for early IANA assignment for ALPN 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, 27 Mar 2013 23:29:16 -0000 On Wed, Mar 27, 2013 at 3:23 PM, Michael D'Errico wrote: > Trevor Perrin wrote: >> >> Hmm.... so we'd have to do all interop testing and trial deployments >> based on an "ExperimentalExtension". Then - once everything is >> working and RFCs are assigned - make a major incompatible protocol >> change to a different extension format. > > > The extension_data would not change. The only difference would be in > locating it. Sure. But it's still a code change *after* all the testing and deployment that went into the Internet-Draft. >> I see the costs and risks here, but not the benefit. > > > The problem with using a range of temporary extension numbers comes when > you run out and have to reuse one. I wasn't proposing a separate range of temporary extension numbers. I was seconding Nikos' proposal that there should be an easy way for implementors of an Internet-Draft to temporarily reserve "real" numbers while doing testing and trial deployment. If the Internet-Draft advances to RFC, those numbers can be enshrined by IANA. Otherwise, they're recycled. > Somewhere a server that hasn't been > updated in years will be running code like this: > > switch (extension_number) { > case 0x0000: process_sni_extension(); break; > > case 0xABCD: // experimental ALPN extension number - REMOVE! > case 0x00xx: // IANA-assigned ALPN extension number > process_alpn_extension(); break; > } > > If 0xABCD is ever used for any other experimental extension, it could > cause this server to start acting funny. We're proposing the opposite of this - instead of having different code paths for I-D vs RFC, there should be one code path (i.e the IANA should have assigned 0xABCD, above). > The problem outlined above, plus it allows for non-IETF-sanctioned > experiments such as NPN/SPDY. The wire format of an extension could > change during the experiment - simply add "v2" to the name instead of > requiring a new number assignment via rough consensus at the next IETF > meeting resulting in a wiki update. If early implementors of an I-D need to make a wire format change, I think they should upgrade their implementations and keep using the same temporarily-reserved extension number. Trevor From internet-drafts@ietf.org Thu Mar 28 00:17:36 2013 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 C0D1B21F903E; Thu, 28 Mar 2013 00:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 v9WJc9SFfwFj; Thu, 28 Mar 2013 00:17:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 520C821F8FF8; Thu, 28 Mar 2013 00:17:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130328071736.30641.44362.idtracker@ietfa.amsl.com> Date: Thu, 28 Mar 2013 00:17:36 -0700 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-cached-info-14.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: Thu, 28 Mar 2013 07:17:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Group of= the IETF. Title : Transport Layer Security (TLS) Cached Information Extens= ion Author(s) : Stefan Santesson Hannes Tschofenig Filename : draft-ietf-tls-cached-info-14.txt Pages : 15 Date : 2013-03-28 Abstract: Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted Certification Authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate path (including all intermediary certificates up to the trust anchor public key). This document defines an extension that omits the exchange of already available information. The TLS client informs a server of cached information, for example from a previous TLS handshake, allowing the server to omit the already available information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-cached-info-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-cached-info-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Thu Mar 28 00:30:02 2013 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 CD41A21F8AA8 for ; Thu, 28 Mar 2013 00:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.224 X-Spam-Level: X-Spam-Status: No, score=-103.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, 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 Z0FSLVmrLALP for ; Thu, 28 Mar 2013 00:30:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9395421F8A85 for ; Thu, 28 Mar 2013 00:30:00 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MYqSb-1U6yMm2fzP-00VjeE for ; Thu, 28 Mar 2013 08:29:59 +0100 Received: (qmail invoked by alias); 28 Mar 2013 07:29:59 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.103]) [88.115.219.140] by mail.gmx.net (mp027) with SMTP; 28 Mar 2013 08:29:59 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/MZ6dVAkXMM5mJbM+lcyNWOgI4MPMuSU4q8QWfou JkGbxpbXCIZYUb From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Mar 2013 09:29:58 +0200 Message-Id: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [TLS] draft-ietf-tls-cached-info-14 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, 28 Mar 2013 07:30:03 -0000 Hi all,=20 I just submitted an updated version of the TLS cached info document to = incorporate the suggestions initially raised by Stefan in = http://www.ietf.org/mail-archive/web/tls/current/msg09038.html, later = discussed on the mailing list at = http://www.ietf.org/mail-archive/web/tls/current/msg09253.html and also = presented during the IETF#86 meeting.=20 The updated document does not yet include the recently raised issue by = Rob (see = http://www.ietf.org/mail-archive/web/tls/current/msg09352.html). Ciao Hannes From hannes.tschofenig@gmx.net Thu Mar 28 05:51:06 2013 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 CBA9121F8775 for ; Thu, 28 Mar 2013 05:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.038 X-Spam-Level: X-Spam-Status: No, score=-101.038 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 XByvVUt+Oslr for ; Thu, 28 Mar 2013 05:51:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 7E45B21F8C98 for ; Thu, 28 Mar 2013 05:51:04 -0700 (PDT) Received: from 3capp-gmx-bs55.server.lan ([172.19.170.139]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Lu28G-1UlDO50y3y-011WE1 for ; Thu, 28 Mar 2013 13:51:03 +0100 Received: from [194.251.119.196] by 3capp-gmx-bs55.server.lan with HTTP; Thu Mar 28 13:51:03 CET 2013 MIME-Version: 1.0 Message-ID: From: "Hannes Tschofenig" To: "" Content-Type: text/html; charset=UTF-8 Date: Thu, 28 Mar 2013 13:51:03 +0100 (CET) Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K0:C590VWqZfU8uvUnSelbkoyYzaI2mQo4S355IDeWCD+Q Bofz7/IljQYfhTHJckTVq/JwNrOveIWcr8WjdWo9LSVYas9l5J oTJnBN/RPekSlIwQS2Zx3TSL00LiD1nuuscg7Usfmp8FOID5GJ OWN4KYXbqA5d1/ukusB0GD4oxfYdiCma4ZaoHt2tebUTTg1/pn 7ZtLWg2KiJi5qX3Cxe52AndjJJ0M0BbZrJFaqzxqkDYAIqhgtx 2oItP4ILAmt6kusN5n9wKYyNk4NFDmiZHd8PPrJpaYFkXJRll3 q9X2MY= Subject: [TLS] draft-ietf-tls-multiple-cert-status-extension-04 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, 28 Mar 2013 12:51:06 -0000
Hi all,
 
I have looked at draft-ietf-tls-multiple-cert-status-extension-04 and have a few questions:
 
1) Shouldn't this document update RFC 6066 (or even obsolete functionality defined in Section 8 of RFC 6066)?
RFC 6066 defines a new extension, OCSPStatusRequest, to request the server to provide an OCSP response for the server certificate in the "CertificateStatus" message immediately after the "Certificate" message.
RFC 6066 defines the CertificateStatusRequest message as:
      struct {
          CertificateStatusType status_type;
          select (status_type) {
              case ocsp: OCSPStatusRequest;
          } request;
      } CertificateStatusRequest;
      enum { ocsp(1), (255) } CertificateStatusType;
      struct {
          ResponderID responder_id_list<0..2^16-1>;
          Extensions  request_extensions;
      } OCSPStatusRequest;
      opaque ResponderID<1..2^16-1>;
      opaque Extensions<0..2^16-1>;
      
and the CertificateStatus message as:
      struct {
          CertificateStatusType status_type;
          select (status_type) {
              case ocsp: OCSPResponse;
          } response;
      } CertificateStatus;
      opaque OCSPResponse<1..2^24-1>;
      
   
draft-ietf-tls-multiple-cert-status-extension-04 extends this mechanism to allow also OCSP responses for intermediate Certification Authority (CA) certificates.
draft-ietf-tls-multiple-cert-status-extension-04 defines the CertificateStatusRequestList message as an extension of the CertificateStatusRequest message:
  struct {
    CertificateStatusType status_type;
    uint16 request_length; /* Length of request field in bytes */
    select (status_type) {
      case ocsp: OCSPStatusRequest;
      case ocsp_multi: OCSPStatusRequest;
    } request;
  } CertificateStatusRequestItem;
  enum { ocsp(1), ocsp_multi(2), (255) } CertificateStatusType;
  struct {
    ResponderID responder_id_list<0..2^16-1>;
    Extensions request_extensions;
  } OCSPStatusRequest;
  opaque ResponderID<1..2^16-1>;
  opaque Extensions<0..2^16-1>;
  struct {
    CertificateStatusRequestItem certificate_status_req_list<1..2^16-1>;
  } CertificateStatusRequestList;
 
and the CertificateStatus message is defined as:
     struct {
       CertificateStatusType status_type;
       select (status_type) {
         case ocsp: OCSPResponse;
         case ocsp_multi: OCSPResponseList;
       } response;
     } CertificateStatus;
     opaque OCSPResponse<0..2^24-1>;
     struct {
       OCSPResponse ocsp_response_list<1..2^24-1>;
     } OCSPResponseList;
 
Would you expect that someone uses RFC 6066 or would they instead use draft-ietf-tls-multiple-cert-status-extension-04 with respect to the OCSP procedure?
 
2) OCSP Usage
I have been told that browsers don't use OCSP (or CRLs) because it introduces too much latency. This extension would clearly improve the situation since no separate roundtrips are required. Everything is tunneled within TLS itself. However, browsers have in the meanwhile found other ways to handle revocation, namely by using blacklists shipped as part of the software update.
So, I am curious whether there are plans by anyone to use this OCSP TLS extension?
 
3) Replay Attacks (in context of TLS Cached Info)
Without the usage of OCSP nonces replays are possible. In particular, the TLS server could easily replay an earlier OSCP response (within the validity interval specified via the thisUpdate and nextUpdate fields). Section 11 of RFC 6066 talks about this issue but the usage of nonces prevent caching. Do I see this wrong?
 
4) OCSP Response Faking
Since the OCSP response is tunneled through the TLS server (which could potentionally be compromised) it must be ensured that the OCSP response is (a) signed and (b) it is signed by some party other than the TLS server (or a closely associated entity).
Neither RFC 6066 nor draft-ietf-tls-multiple-cert-status-extension-04 talk about this issue. Do I miss something?  
 
Ciao
Hannes
PS: Many people use the term "OCSP stapling" for the functionality defined in RFC 6066 & draft-ietf-tls-multiple-cert-status-extension-04 but the term itself does not show up in these two documents. Wouldn't it be good to at least have it in the abstract of draft-ietf-tls-multiple-cert-status-extension-04?
From yngve@spec-work.net Thu Mar 28 09:52:06 2013 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 A1C6A21F8AA8 for ; Thu, 28 Mar 2013 09:52:06 -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 nfUj8Z7w+iCI for ; Thu, 28 Mar 2013 09:52:02 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 872CD21F89B2 for ; Thu, 28 Mar 2013 09:52:01 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:57077 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1ULG3T-0000bv-Og; Thu, 28 Mar 2013 17:51:59 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "" , "Hannes Tschofenig" References: Date: Thu, 28 Mar 2013 17:51:49 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.14 (Win32) Subject: Re: [TLS] draft-ietf-tls-multiple-cert-status-extension-04 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, 28 Mar 2013 16:52:06 -0000 Hello Hannes Thanks for the review. 1) Updating RFC 6066 It might be that it can be said to update 6066, but I have leaned towards that it is not updating 6066, since, while most of the new structures are derived from the 6066 definitions, they are really only defined for the new extension. If RFC 6066 had only defined the OCSP stapling system, I would have been inclined to say my draft obsoleted it, but that is not workable since there are other extensions defined in it. It could be that the update of the CertificateStatus message count as such an update, even if it is only defined for the new extension. Do the Chairs or AD have any opinions on this? > Would you expect that someone uses RFC 6066 or would they instead use > draft-ietf-tls-multiple-cert-status-extension-04 > with respect to the OCSP procedure? In a transition phase I would expect clients to send both the 6066 CertificateStatus request extension, and the new one defined by my draft. Long term I would expect a change to only using the new extension. Servers supporting both should IMO return the new extension. 2) OCSP vs. Blacklists The blacklists used by browsers are for emergency revocation, and do not scale very well (Updates require the CA to contact each browser, and each browser to add and test their updates, then ship the updates). They are not used for normal revocation, but for security incidents on the scale of the "Comodo" and "DigiNotar" incidents (CA failure), when nothing less will work. In many cases updating the binary executable is needed to distribute the updated list, although some browsers use online data updates instead. Most desktop browsers currently use OCSP (and support RFC 6066 stapling); I am unsure about mobile browsers (Opera does support it), and it was recently pointed out that Java was not checking revocation by default for signed applets. The exception on the desktop side is Chrome, which is instead using Google's CRLSets download, built from CRLs, when stapling is not used; if the CRLset is too old it will AFAIK use OCSP instead. The reason for this change was the delays introduced by checking revocation. Personally I am skeptical to this approach, since the CRLsets are only supposed to include serious revocations, not general revocations. Firefox is AFAIK using OCSP (and maybe CRLs) for intermediates when defined, but possibly only for EV certificates, although I am aware that NSS is in the process of being updated in this area. CRLs are used by both Opera and (AFAIK) MSIE for intermediates, and at least in Opera's case, if OCSP is not defined for the site certificate the CRL will be used instead (when defined). (Opera also have special requirements for revocation success to be able to indicate the site as secure.) The delay introduced by the online checking of revocation is one of the reasons a change to stapling is desirable. It is, however, also desirable to be able to check the revocation status of intermediates, since it is conceivable that intermediates can be revoked (as happened with the Malaysian CA in November 2011), and checking CRLs can introduce just as much delay as OCSP, which is why a multi-stapling spec was needed. 3) Replay attacks There is no difference in the replay risk between CachedInfo and normal stapling (or with a MITM atatck on the OCSP server). A malicious server can send a valid (unexpired) OCSP response for the entire period it is valid, even if it has later been replaced by a newer response indicating revoked status. This problem is why I am of the opinion that stapled OCSP responses should have a freshness requirement in the range of hours, even if the response is valid for a week. Alternatively, CAs can limit the lifetime of their responses to a few hours, which one CA have already done. However, I don't think the current draft is the right place for such a policy discussion/requirement. The use of nonces would prevent replays, but almost no responders support them (I think the only ones I have heard about are military ones), and no current mass-market clients are AFAIK sending nonces or requiring them. Also, using and requiring nonces would require the server to fetch new responses for each full handshake, eliminating the primary benefits of stapling: Removing the latency, and that the number of requests to the responder depend on the number of subscribers, not the number of users of the subscribers' sites. 4) Faking The OCSP response is always signed by the issuing CA, or a designated signer whose certificate is included in the response, not the server. I suspect the only way a site certificate could be able to sign a OCSP response for itself would be if it had somehow been issued with OCSP signer privileges, which would probably be reason enough to revoke the issuing CA certificate. Therefore, faking the OCSP response is not a problem. The OCSP responses still have to follow the rules in RFC 2560. 5) Mentioning "OCSP stapling" Will think about that. In the case of this draft, the concept is actually referred to as "Multi-stapling". On Thu, 28 Mar 2013 13:51:03 +0100, Hannes Tschofenig wrote: > Hi all, > > I have looked at draft-ietf-tls-multiple-cert-status-extension-04 and > have a few > questions: > > 1) Shouldn't this document update RFC 6066 (or even obsolete > functionality > defined in Section 8 of RFC 6066)? > > RFC 6066 defines a new extension, OCSPStatusRequest, to request the > server to > provide an OCSP response for the server certificate in the > "CertificateStatus" > message immediately after the "Certificate" message. > > RFC 6066 defines the CertificateStatusRequest message as: > > struct { > CertificateStatusType status_type; > select (status_type) { > case ocsp: OCSPStatusRequest; > } request; > } CertificateStatusRequest; > > enum { ocsp(1), (255) } CertificateStatusType; > > struct { > ResponderID responder_id_list<0..2^16-1>; > Extensions request_extensions; > } OCSPStatusRequest; > > opaque ResponderID<1..2^16-1>; > opaque Extensions<0..2^16-1>; > > > and the CertificateStatus message as: > > struct { > CertificateStatusType status_type; > select (status_type) { > case ocsp: OCSPResponse; > } response; > } CertificateStatus; > > opaque OCSPResponse<1..2^24-1>; > > > draft-ietf-tls-multiple-cert-status-extension-04 extends this mechanism > to allow > also OCSP responses for intermediate Certification Authority (CA) > certificates. > > draft-ietf-tls-multiple-cert-status-extension-04 defines the > CertificateStatusRequestList message as an extension of the > CertificateStatusRequest message: > > struct { > CertificateStatusType status_type; > uint16 request_length; /* Length of request field in bytes */ > select (status_type) { > case ocsp: OCSPStatusRequest; > case ocsp_multi: OCSPStatusRequest; > } request; > } CertificateStatusRequestItem; > > enum { ocsp(1), ocsp_multi(2), (255) } CertificateStatusType; > > struct { > ResponderID responder_id_list<0..2^16-1>; > Extensions request_extensions; > } OCSPStatusRequest; > > opaque ResponderID<1..2^16-1>; > opaque Extensions<0..2^16-1>; > > struct { > CertificateStatusRequestItem certificate_status_req_list<1..2^16-1>; > } CertificateStatusRequestList; > > and the CertificateStatus message is defined as: > > struct { > CertificateStatusType status_type; > select (status_type) { > case ocsp: OCSPResponse; > case ocsp_multi: OCSPResponseList; > } response; > } CertificateStatus; > > opaque OCSPResponse<0..2^24-1>; > > struct { > OCSPResponse ocsp_response_list<1..2^24-1>; > } OCSPResponseList; > > Would you expect that someone uses RFC 6066 or would they instead use > draft-ietf-tls-multiple-cert-status-extension-04 > with respect to the OCSP procedure? > > 2) OCSP Usage > > I have been told that browsers don't use OCSP (or CRLs) because it > introduces > too much latency. This extension would clearly improve the situation > since no > separate roundtrips are required. Everything is tunneled within TLS > itself. > However, browsers have in the meanwhile found other ways to handle > revocation, > namely by using blacklists shipped as part of the software update. > > So, I am curious whether there are plans by anyone to use this OCSP TLS > extension? > > 3) Replay Attacks (in context of TLS Cached Info) > > Without the usage of OCSP nonces replays are possible. In particular, > the TLS > server could easily replay an earlier OSCP response (within the validity > interval specified via the thisUpdate and nextUpdate fields). Section 11 > of RFC > 6066 talks about this issue but the usage of nonces prevent caching. Do > I see > this wrong? > > 4) OCSP Response Faking > > Since the OCSP response is tunneled through the TLS server (which could > potentionally be compromised) it must be ensured that the OCSP response > is (a) > signed and (b) it is signed by some party other than the TLS server (or a > closely associated entity). > > Neither RFC 6066 nor draft-ietf-tls-multiple-cert-status-extension-04 > talk about > this issue. Do I miss something? > > Ciao > Hannes > > PS: Many people use the term "OCSP stapling" for the functionality > defined in > RFC 6066 & draft-ietf-tls-multiple-cert-status-extension-04 but the term > itself > does not show up in these two documents. Wouldn't it be good to at least > have it > in the abstract of draft-ietf-tls-multiple-cert-status-extension-04? -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From turners@ieca.com Thu Mar 28 10:21:20 2013 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 2ED0E21F8AF8 for ; Thu, 28 Mar 2013 10:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.275 X-Spam-Level: X-Spam-Status: No, score=-102.275 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 CqOY4Yap8Cle for ; Thu, 28 Mar 2013 10:21:19 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [67.18.68.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8464321F87B1 for ; Thu, 28 Mar 2013 10:21:17 -0700 (PDT) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 29386B794EACE; Thu, 28 Mar 2013 12:21:10 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 19A54B794EA8B for ; Thu, 28 Mar 2013 12:21:10 -0500 (CDT) Received: from [108.45.16.214] (port=51242 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1ULGVo-0004OU-Qz; Thu, 28 Mar 2013 12:21:16 -0500 Message-ID: <51547C0C.20806@ieca.com> Date: Thu, 28 Mar 2013 13:21:16 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Hannes Tschofenig References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> In-Reply-To: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> 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) [108.45.16.214]:51242 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cached-info-14 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, 28 Mar 2013 17:21:20 -0000 Does this version address all known outstanding issues? spt On 3/28/13 3:29 AM, Hannes Tschofenig wrote: > Hi all, > > I just submitted an updated version of the TLS cached info document to incorporate the suggestions initially raised by Stefan in http://www.ietf.org/mail-archive/web/tls/current/msg09038.html, later discussed on the mailing list at http://www.ietf.org/mail-archive/web/tls/current/msg09253.html and also presented during the IETF#86 meeting. > > The updated document does not yet include the recently raised issue by Rob (see http://www.ietf.org/mail-archive/web/tls/current/msg09352.html). > > Ciao > Hannes > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From hannes.tschofenig@gmx.net Thu Mar 28 11:41:15 2013 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 657A221F8E2C for ; Thu, 28 Mar 2013 11:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 fGRAgsHpI1+E for ; Thu, 28 Mar 2013 11:41:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id E324C21F8DDD for ; Thu, 28 Mar 2013 11:41:13 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.35]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LbO5M-1V5uzK3Xwo-00ky6M for ; Thu, 28 Mar 2013 19:41:12 +0100 Received: (qmail invoked by alias); 28 Mar 2013 18:41:12 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.103]) [88.115.219.140] by mail.gmx.net (mp035) with SMTP; 28 Mar 2013 19:41:12 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19P+B8zR/tP+BP1NkegEf3iz/h+MfHqUGlRt01AMB BniQhRMdDp8+w7 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <51547C0C.20806@ieca.com> Date: Thu, 28 Mar 2013 20:41:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cached-info-14 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, 28 Mar 2013 18:41:15 -0000 Hi Sean, It addresses all open issues we had at the IETF meeting.=20 It does not yet contain the text for adding the OCSP response caching, = as suggested by Rob (see = http://www.ietf.org/mail-archive/web/tls/current/msg09352.html).=20 I could propose some text by tomorrow since I believe it is useful = functionality.=20 Ciao Hannes On Mar 28, 2013, at 7:21 PM, Sean Turner wrote: > Does this version address all known outstanding issues? >=20 > spt >=20 > On 3/28/13 3:29 AM, Hannes Tschofenig wrote: >> Hi all, >>=20 >> I just submitted an updated version of the TLS cached info document = to incorporate the suggestions initially raised by Stefan in = http://www.ietf.org/mail-archive/web/tls/current/msg09038.html, later = discussed on the mailing list at = http://www.ietf.org/mail-archive/web/tls/current/msg09253.html and also = presented during the IETF#86 meeting. >>=20 >> The updated document does not yet include the recently raised issue = by Rob (see = http://www.ietf.org/mail-archive/web/tls/current/msg09352.html). >>=20 >> Ciao >> Hannes >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 From turners@ieca.com Thu Mar 28 11:43:18 2013 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 3762521F8EBC for ; Thu, 28 Mar 2013 11:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 urPMUiobOO9s for ; Thu, 28 Mar 2013 11:43:17 -0700 (PDT) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.60.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8C25921F8E99 for ; Thu, 28 Mar 2013 11:43:17 -0700 (PDT) Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id 1E3D261298BD9; Thu, 28 Mar 2013 13:43:17 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway03.websitewelcome.com (Postfix) with ESMTP id 7542061298875 for ; Thu, 28 Mar 2013 13:43:16 -0500 (CDT) Received: from [108.45.16.214] (port=51430 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1ULHnA-0003xI-8Y; Thu, 28 Mar 2013 13:43:16 -0500 Message-ID: <51548F43.8050608@ieca.com> Date: Thu, 28 Mar 2013 14:43:15 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Hannes Tschofenig References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> In-Reply-To: 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) [108.45.16.214]:51430 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 14 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cached-info-14 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, 28 Mar 2013 18:43:18 -0000 I'd like to keep the pedal down on this one so please do suggest some text and let's try to get this one out the door. spt On 3/28/13 2:41 PM, Hannes Tschofenig wrote: > Hi Sean, > > It addresses all open issues we had at the IETF meeting. > > It does not yet contain the text for adding the OCSP response caching, as suggested by Rob (see http://www.ietf.org/mail-archive/web/tls/current/msg09352.html). > I could propose some text by tomorrow since I believe it is useful functionality. > > Ciao > Hannes > > On Mar 28, 2013, at 7:21 PM, Sean Turner wrote: > >> Does this version address all known outstanding issues? >> >> spt >> >> On 3/28/13 3:29 AM, Hannes Tschofenig wrote: >>> Hi all, >>> >>> I just submitted an updated version of the TLS cached info document to incorporate the suggestions initially raised by Stefan in http://www.ietf.org/mail-archive/web/tls/current/msg09038.html, later discussed on the mailing list at http://www.ietf.org/mail-archive/web/tls/current/msg09253.html and also presented during the IETF#86 meeting. >>> >>> The updated document does not yet include the recently raised issue by Rob (see http://www.ietf.org/mail-archive/web/tls/current/msg09352.html). >>> >>> Ciao >>> Hannes >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> From rob.stradling@comodo.com Thu Mar 28 14:23:30 2013 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 840F921F8FD1 for ; Thu, 28 Mar 2013 14:23:25 -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 Dc5V4Zcbkuch for ; Thu, 28 Mar 2013 14:23:24 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 16FB221F8FD7 for ; Thu, 28 Mar 2013 14:23:23 -0700 (PDT) Received: (qmail 29501 invoked from network); 28 Mar 2013 21:23:22 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 28 Mar 2013 21:23:22 -0000 Received: (qmail 27320 invoked by uid 1000); 28 Mar 2013 21:23:22 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 28 Mar 2013 21:23:22 +0000 Message-ID: <5154B4C9.1070405@comodo.com> Date: Thu, 28 Mar 2013 21:23:21 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Hannes Tschofenig References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cached-info-14 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, 28 Mar 2013 21:23:30 -0000 On 28/03/13 18:41, Hannes Tschofenig wrote: > Hi Sean, > > It addresses all open issues we had at the IETF meeting. > > It does not yet contain the text for adding the OCSP response caching, as suggested by Rob (see http://www.ietf.org/mail-archive/web/tls/current/msg09352.html). > I could propose some text by tomorrow since I believe it is useful functionality. Hannes, For Multi-Stapling, there will be cases where a TLS client has previously seen the OCSP Response(s) for the Intermediate(s) but not yet seen the OCSP Response for the End-entity cert. It would be useful in such cases if Cached-Info would enable the TLS server to only have to send the OCSP Response(s) that the TLS client hasn't previously cached. > Ciao > Hannes > > On Mar 28, 2013, at 7:21 PM, Sean Turner wrote: > >> Does this version address all known outstanding issues? >> >> spt >> >> On 3/28/13 3:29 AM, Hannes Tschofenig wrote: >>> Hi all, >>> >>> I just submitted an updated version of the TLS cached info document to incorporate the suggestions initially raised by Stefan in http://www.ietf.org/mail-archive/web/tls/current/msg09038.html, later discussed on the mailing list at http://www.ietf.org/mail-archive/web/tls/current/msg09253.html and also presented during the IETF#86 meeting. >>> >>> The updated document does not yet include the recently raised issue by Rob (see http://www.ietf.org/mail-archive/web/tls/current/msg09352.html). >>> >>> Ciao >>> Hannes >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From turners@ieca.com Fri Mar 29 06:02:43 2013 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 AA38B21F9405 for ; Fri, 29 Mar 2013 06:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[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 rw0fjLUGwuBL for ; Fri, 29 Mar 2013 06:02:43 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.238.10]) by ietfa.amsl.com (Postfix) with ESMTP id 31D4721F93EB for ; Fri, 29 Mar 2013 06:02:43 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 1DE06A60BD5E9; Fri, 29 Mar 2013 07:37:00 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 0F9FBA60BD5C8 for ; Fri, 29 Mar 2013 07:37:00 -0500 (CDT) Received: from [108.45.16.214] (port=52299 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1ULYYd-000765-Bs; Fri, 29 Mar 2013 07:37:23 -0500 Message-ID: <51558B02.6070302@ieca.com> Date: Fri, 29 Mar 2013 08:37:22 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Yngve N. Pettersen" References: In-Reply-To: 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) [108.45.16.214]:52299 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 16 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "" Subject: Re: [TLS] draft-ietf-tls-multiple-cert-status-extension-04 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, 29 Mar 2013 13:02:43 -0000 On 3/28/13 12:51 PM, Yngve N. Pettersen wrote: > > Hello Hannes > > Thanks for the review. > > 1) Updating RFC 6066 > > It might be that it can be said to update 6066, but I have leaned > towards that it is not updating 6066, since, while most of the new > structures are derived from the 6066 definitions, they are really only > defined for the new extension. > > If RFC 6066 had only defined the OCSP stapling system, I would have been > inclined to say my draft obsoleted it, but that is not workable since > there are other extensions defined in it. > > It could be that the update of the CertificateStatus message count as > such an update, even if it is only defined for the new extension. > > Do the Chairs or AD have any opinions on this? > > >> Would you expect that someone uses RFC 6066 or would they instead use >> draft-ietf-tls-multiple-cert-status-extension-04 >> with respect to the OCSP procedure? > > In a transition phase I would expect clients to send both the 6066 > CertificateStatus request extension, and the new one defined by my > draft. Long term I would expect a change to only using the new extension. If this is a new standalone extension, then it doesn't update RFC 6066. In the past "updates" has sometimes been used as a "see also" tag, but that's now gently being stomped out. > Servers supporting both should IMO return the new extension. If you say this in the draft then I'd be leaning towards an update. That is if you changing behavior about an extension that's in 6066 it's an update. spt From yngve@spec-work.net Fri Mar 29 08:09:59 2013 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 824A021F9445 for ; Fri, 29 Mar 2013 08:09:59 -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 a+I4NxPic9Ap for ; Fri, 29 Mar 2013 08:09:58 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id B055A21F8F25 for ; Fri, 29 Mar 2013 08:09:57 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:58066 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1ULawF-000068-Fe; Fri, 29 Mar 2013 16:09:55 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Sean Turner" References: <51558B02.6070302@ieca.com> Date: Fri, 29 Mar 2013 16:09:45 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <51558B02.6070302@ieca.com> User-Agent: Opera Mail/12.14 (Win32) Cc: "" Subject: Re: [TLS] draft-ietf-tls-multiple-cert-status-extension-04 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, 29 Mar 2013 15:09:59 -0000 On Fri, 29 Mar 2013 13:37:22 +0100, Sean Turner wrote: > On 3/28/13 12:51 PM, Yngve N. Pettersen wrote: >> >> Hello Hannes >> >> Thanks for the review. >> >> 1) Updating RFC 6066 >> >> It might be that it can be said to update 6066, but I have leaned >> towards that it is not updating 6066, since, while most of the new >> structures are derived from the 6066 definitions, they are really only >> defined for the new extension. >> >> If RFC 6066 had only defined the OCSP stapling system, I would have been >> inclined to say my draft obsoleted it, but that is not workable since >> there are other extensions defined in it. >> >> It could be that the update of the CertificateStatus message count as >> such an update, even if it is only defined for the new extension. >> >> Do the Chairs or AD have any opinions on this? >> >> >>> Would you expect that someone uses RFC 6066 or would they instead use >>> draft-ietf-tls-multiple-cert-status-extension-04 >>> with respect to the OCSP procedure? >> >> In a transition phase I would expect clients to send both the 6066 >> CertificateStatus request extension, and the new one defined by my >> draft. Long term I would expect a change to only using the new >> extension. > > If this is a new standalone extension, then it doesn't update RFC 6066. > In the past "updates" has sometimes been used as a "see also" tag, but > that's now gently being stomped out. OK >> Servers supporting both should IMO return the new extension. > > If you say this in the draft then I'd be leaning towards an update. That > is if you changing behavior about an extension that's in 6066 it's an > update. I am not planning such language. I'll leave it up to implementors to make such decisions, but I also hope they will see the benefit of using the newer extension when it is presented. -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From internet-drafts@ietf.org Fri Mar 29 09:17:08 2013 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 6A6F321F94E0; Fri, 29 Mar 2013 09:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 XHOz13Xrclpq; Fri, 29 Mar 2013 09:17:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3B421F9487; Fri, 29 Mar 2013 09:17:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130329161707.21778.41475.idtracker@ietfa.amsl.com> Date: Fri, 29 Mar 2013 09:17:07 -0700 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-multiple-cert-status-extension-05.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, 29 Mar 2013 16:17:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. 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-05.txt Pages : 9 Date : 2013-03-29 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extens= ion There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-multiple-cert-status-exte= nsion-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yngve@spec-work.net Fri Mar 29 09:25:39 2013 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 983C721F93EB for ; Fri, 29 Mar 2013 09:25:37 -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=[AWL=0.000, 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 dnC+9m9wIyTa for ; Fri, 29 Mar 2013 09:25:36 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1061B21F93B7 for ; Fri, 29 Mar 2013 09:25:35 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:59724 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1ULc7T-00048O-66 for tls@ietf.org; Fri, 29 Mar 2013 17:25:35 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org References: <20130329161707.21778.41475.idtracker@ietfa.amsl.com> Date: Fri, 29 Mar 2013 17:25:25 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <20130329161707.21778.41475.idtracker@ietfa.amsl.com> User-Agent: Opera Mail/12.14 (Win32) Subject: Re: [TLS] I-D Action: draft-ietf-tls-multiple-cert-status-extension-05.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, 29 Mar 2013 16:25:39 -0000 Hello all, This is an updated version of the multi-stapling draft, updated based on issues reported during the IETF Last Call. From Last Call: - Some "originally defined" references to 6066 - mentioning "OCSP stapling" in introduction (also added in abstract of next version) - presentation language reference - Client's preference change for list of methods My changes: - Slight rewrite about delays in sec. 1 (I found "adding additional" to be a bit incorrect language) - Changed name of CertificateStatusRequestItem to CertificateStatusRequestItemV2 to avoid confusion with the corresponding RFC 6066 structure, since the new version has a slightly different format on the wire. On Fri, 29 Mar 2013 17:17:07 +0100, 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-05.txt > Pages : 9 > Date : 2013-03-29 > > Abstract: > 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. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-multiple-cert-status-extension-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From hannes.tschofenig@gmx.net Fri Mar 29 11:34:34 2013 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 1F29F21F8A0D for ; Fri, 29 Mar 2013 11:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 62paUwEEXi5E for ; Fri, 29 Mar 2013 11:34:33 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id C67F621F86B9 for ; Fri, 29 Mar 2013 11:34:32 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MQKg6-1UDtqF35lE-00Tp5n for ; Fri, 29 Mar 2013 19:34:31 +0100 Received: (qmail invoked by alias); 29 Mar 2013 18:34:31 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.103]) [88.115.219.140] by mail.gmx.net (mp020) with SMTP; 29 Mar 2013 19:34:31 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+kc1c/QgOkdxoFgg3X4JiYFpAXt0MNamz40o/vX0 bnoK9GUm+xyIkd Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <5154B4C9.1070405@comodo.com> Date: Fri, 29 Mar 2013 20:34:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5096AB41-02FD-4E01-A78E-BEF272181F42@gmx.net> References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> <5154B4C9.1070405@comodo.com> To: Rob Stradling X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cached-info-14 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, 29 Mar 2013 18:34:34 -0000 Hi Rob,=20 I worked on a document update and the current snapshot can be found = here:=20 = https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-= info/draft-ietf-tls-cached-info-15.txt Let me know if that fits your needs.=20 Ciao Hannes On Mar 28, 2013, at 11:23 PM, Rob Stradling wrote: > On 28/03/13 18:41, Hannes Tschofenig wrote: >> Hi Sean, >>=20 >> It addresses all open issues we had at the IETF meeting. >>=20 >> It does not yet contain the text for adding the OCSP response = caching, as suggested by Rob (see = http://www.ietf.org/mail-archive/web/tls/current/msg09352.html). >> I could propose some text by tomorrow since I believe it is useful = functionality. >=20 > Hannes, >=20 > For Multi-Stapling, there will be cases where a TLS client has = previously seen the OCSP Response(s) for the Intermediate(s) but not yet = seen the OCSP Response for the End-entity cert. >=20 > It would be useful in such cases if Cached-Info would enable the TLS = server to only have to send the OCSP Response(s) that the TLS client = hasn't previously cached. >=20 >> Ciao >> Hannes >>=20 >> On Mar 28, 2013, at 7:21 PM, Sean Turner wrote: >>=20 >>> Does this version address all known outstanding issues? >>>=20 >>> spt >>>=20 >>> On 3/28/13 3:29 AM, Hannes Tschofenig wrote: >>>> Hi all, >>>>=20 >>>> I just submitted an updated version of the TLS cached info document = to incorporate the suggestions initially raised by Stefan in = http://www.ietf.org/mail-archive/web/tls/current/msg09038.html, later = discussed on the mailing list at = http://www.ietf.org/mail-archive/web/tls/current/msg09253.html and also = presented during the IETF#86 meeting. >>>>=20 >>>> The updated document does not yet include the recently raised issue = by Rob (see = http://www.ietf.org/mail-archive/web/tls/current/msg09352.html). >>>>=20 >>>> Ciao >>>> Hannes >>>>=20 >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 > --=20 > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > Office Tel: +44.(0)1274.730505 > Office Fax: +44.(0)1274.730909 > www.comodo.com >=20 > COMODO CA Limited, Registered in England No. 04058690 > Registered Office: > 3rd Floor, 26 Office Village, Exchange Quay, > Trafford Road, Salford, Manchester M5 3EQ >=20 > This e-mail and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = sender by replying to the e-mail containing this attachment. Replies to = this email may be monitored by COMODO for operational or business = reasons. Whilst every endeavour is taken to ensure that e-mails are free = from viruses, no liability can be accepted and the recipient is = requested to use their own virus checking software.