Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C161A8974 for ; Tue, 27 Jan 2015 08:45:10 -0800 (PST) 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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q94KfGSoOcs9 for ; Tue, 27 Jan 2015 08:45:04 -0800 (PST) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86751A1BF5 for ; Tue, 27 Jan 2015 08:42:23 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id l6so12808959qcy.12 for ; Tue, 27 Jan 2015 08:42:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WoPQ7vrphVp7q99gVAfJxtg5fsn4jV9r1gRVBYUOtwg=; b=UIr8ULNl5kNR68pNs0mbx9IANXmxq5OHi5S5rJlcbWAQ9wei0kYmzTg1qNxEPlLqMG geppOQWAYHuXj5rnSJ6AlHw2zUE6WbW59Bw/oqx3jJyV0FHOWZ18vsCjanJYkwd6fxSq PGylcm86K6y+4cKJcrm+jkNL85Q5skIYGh9Rz0fcClBk3r7Z8idgNBo9u8TpuBMDL03q ekBkYEFJJVWWFIZrSCItfVpZFkXSJDzaiKJ926F0Ht7e1DtSrXh8tcRaDEek5XIlMpqm Ek7X3Y6xorJfRc/mj02XBq+KiFNKbchplU9Ufjf8vFKzVfgm2rWtHGMTlRgPulG8gyw4 EnRQ== X-Gm-Message-State: ALoCoQlfRI8v/J4yp2t2rIyVqnuEkZ8XKTydNVsddZgwmXThNG33eZ2wJf8CLaT+We1sg3YlqM3L MIME-Version: 1.0 X-Received: by 10.229.80.3 with SMTP id r3mr1792058qck.23.1422376943017; Tue, 27 Jan 2015 08:42:23 -0800 (PST) Received: by 10.96.238.73 with HTTP; Tue, 27 Jan 2015 08:42:22 -0800 (PST) X-Originating-IP: [50.206.82.141] In-Reply-To: <201501251833.50963.davemgarrett@gmail.com> References: <201412300503.03923.davemgarrett@gmail.com> <201501251833.50963.davemgarrett@gmail.com> Date: Tue, 27 Jan 2015 08:42:22 -0800 Message-ID: From: Joseph Salowey To: Dave Garrett Content-Type: multipart/alternative; boundary=001a1133cb786cf476050da4f0b8 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] consensus on backwards compatibility changes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jan 2015 16:45:10 -0000 --001a1133cb786cf476050da4f0b8 Content-Type: text/plain; charset=UTF-8 On Sun, Jan 25, 2015 at 3:33 PM, Dave Garrett wrote: > On Sunday, January 25, 2015 02:36:14 pm Eric Rescorla wrote: > > Based on reading the mailing list, it seems to me that there is rough > > consensus on PR#105, but not (yet?) on PR#107. > > I don't recall any objections to #107, but not much discussion either. > > To sum it up here, in addition to some editorial changes: > > 1) Fixes initial ClientHello record layer version to { 3, 1 } (TLS 1.0) & > mandates > all other record layer versions to match negotiated version. > (Brian's suggestion) > > [Joe] I think this makes sense. I added to comments to the PR. I propose to move the bit about the server accepting versions {3,x} to the same place and change the wording of the existing test to say: "The client MUST set the version to {3, 1} for the initial ClientHello." > In SCSV discussion, evidence was given that this improves interop by 5.3% > for TLS 1.3 & an additional 1.5% for TLS 1.2: > http://www.ietf.org/mail-archive/web/tls/current/msg15141.html > > 2) Mention some other interop concerns along side existing notes. > > 3) Cite RC4 prohibition pending RFC. > > 4) "If an implementation negotiates usage of TLS 1.2, then negotiation of > cipher > suites also supported by TLS 1.3 SHOULD be preferred, if available." > (only a SHOULD, and only if available; language up for negotiation if > needed) > > 5) Explicitly prohibit EXPORT ciphers and any others <100 bits. > (100 bit line is arbitrary; could be 112 if preferred) > > [Joe] draft-ietf-uta-tls-bcp-08 recommends 112 so we probably would match that. > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1133cb786cf476050da4f0b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jan 25, 2015 at 3:33 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Sunday, January 25,= 2015 02:36:14 pm Eric Rescorla wrote:
> Based on reading the mailing list, it seems to me that there is rough<= br> > consensus on PR#105, but not (yet?) on PR#107.

I don't recall any objections to #107, but not much discussion e= ither.

To sum it up here, in addition to some editorial changes:

1) Fixes initial ClientHello record layer version to { 3, 1 } (TLS 1.0) &am= p; mandates
all other record layer versions to match negotiated version.
(Brian's suggestion)


[Joe] I think this makes sense.=C2=A0 = I added to comments to the PR.=C2=A0 I propose to move the bit about the se= rver accepting versions {3,x} to the same place and change the wording of t= he existing test to say:

"The clien= t MUST set the version to {3, 1} for the initial ClientHello."<= br>

=C2=A0
In SCSV discussion, evidence was given that this improves interop by 5.3% for TLS 1.3 & an additional 1.5% for TLS 1.2:
http://www.ietf.org/mail-archive/web/tls/current/msg15141= .html

2) Mention some other interop concerns along side existing notes.

3) Cite RC4 prohibition pending RFC.

4) "If an implementation negotiates usage of TLS 1.2, then negotiation= of cipher
suites also supported by TLS 1.3 SHOULD be preferred, if available." (only a SHOULD, and only if available; language up for negotiation if neede= d)

5) Explicitly prohibit EXPORT ciphers and any others <100 bits.
(100 bit line is arbitrary; could be 112 if preferred)


[Joe]=C2=A0draft= -ietf-uta-tls-bcp-08 recommends 112 so we probably would match that. =C2=A0=
=C2=A0

Dave

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

--001a1133cb786cf476050da4f0b8--