IETF Logo Mail Archive

Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

Martin Thomson <martin.thomson@gmail.com> Fri, 10 October 2014 20:08 UTC

Return-Path: <martin.thomson@gmail.com>
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 49E901A6F17 for <tls@ietfa.amsl.com>; Fri, 10 Oct 2014 13:08:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 6On0afkR1iwQ for <tls@ietfa.amsl.com>; Fri, 10 Oct 2014 13:08:29 -0700 (PDT)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DBDD1A6FCE for <tls@ietf.org>; Fri, 10 Oct 2014 13:07:45 -0700 (PDT)
Received: by mail-la0-f51.google.com with SMTP id ge10so3886667lab.24 for <tls@ietf.org>; Fri, 10 Oct 2014 13:07:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q+E1uD2SuhoE7SIcKIHhoC8y4JJ0/SnWHarApvafQsg=; b=wODaJAUFpt36+iARk0hxvtDkU3s9yaBSYnCc6G9/DyxWtzX929T97SMG4N31YN1eyy yG++3qldX9xjfK5z4ImT01Rx3hdn6V/Qqtwtck1N9wbIk04YerEsQS/5aqUSr7EzKWsg ecoEGLDQeIYZ8AGufHmwHcCTKrcWFViMfV8XznlV4uteVRCGS9/bk6aDep0BP4wuFiIp aAVTcUSmFaJl3L1jkXmpoaJDvpt2ekjWIWj9+kINLsKTcWVxJlzKbdJEn+84neOyNAc5 RlZnkX2S0w6fc94JWcBOeDNNMEkZ7Mm+OXt5kvBLnGW60f6ODu/3NnAR4UkWW1Oa1JkI k/og==
MIME-Version: 1.0
X-Received: by 10.112.140.137 with SMTP id rg9mr5810425lbb.93.1412971663576; Fri, 10 Oct 2014 13:07:43 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Fri, 10 Oct 2014 13:07:43 -0700 (PDT)
In-Reply-To: <CADMpkcKh=6Y9u_utfLiccZTUKT-BV1+3NQO7OzDN-Dn38sx-TQ@mail.gmail.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <CABkgnnUxeouqDNhYFGDC2xqUaT8r7zFvAT5U1OUGJwHwCOuOwA@mail.gmail.com> <CADMpkcJKJiTCQXdDbepyiAf22J9VC03DDgiE521n3NsNnFmALA@mail.gmail.com> <CABkgnnWo9KGMkRrmA0wkJ5Dfnzh2Vo-cveCe_UeH71F8K_4oWw@mail.gmail.com> <CADMpkcJpHeKGV-xc4Uon8KWj=+p=6nQO1_rxb6sRN04nFX--gQ@mail.gmail.com> <CABkgnnU8DyzRvvq1e24bUsZdwx48mFOC6KstZaUCbvyQ-WwesQ@mail.gmail.com> <CADMpkc+wXf=SG3=C==SV77YXZdbXnbXspJLRZ1UORPF-WbVMEw@mail.gmail.com> <CAFewVt5mEodyqB6TWCmvOUBek9Bnb43bmw5mAqph-hQU=F=EpA@mail.gmail.com> <CAFewVt40ewzwujJZ8KQYYALnPjBSZnF-bDiVaz54URA6MaqPEg@mail.gmail.com> <CADMpkcKh=6Y9u_utfLiccZTUKT-BV1+3NQO7OzDN-Dn38sx-TQ@mail.gmail.com>
Date: Fri, 10 Oct 2014 13:07:43 -0700
Message-ID: <CABkgnnXj=ADJVPaAWyhWD7kvBpCOs_VLpO57k91piXFL+z1Jrw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Bodo Moeller <bmoeller@acm.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kUAVc4XYbWp94p8b9MsECUe4evo
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Oct 2014 20:08:31 -0000

On 10 October 2014 12:52, Bodo Moeller <bmoeller@acm.org> wrote:
> Previously I'd assumed you'd want to keep "normal" behavior (simply continue
> to use the previous protocol version), but I don't see a compelling reason
> for the specification to prescribe that to clients.

Yes, that's in general a good change.

Maybe a small editorial concern with the following:

> "[...]  Sending TLS_FALLBACK_SCSV, in contrast, could lead
> to an inappropriate_fallback alert if the client should start anew
> to create a new session using the new highest protocol version.)"

This doesn't read particularly well to me.  It places the option to
create a new session as a condition on the first part of the
statement.

Maybe, "Sending TLS_FALLBACK_SCSV could lead to an
inappropriate_fallback alert. Clients that encounter an
inappropriate_fallback alert in response to a session resumption
attempt SHOULD use highest protocol version available to it when
connecting to that server."

I don't know if that's strictly better, but I hope that you catch my meaning.

v2.23.0 | Report a Bug | By Email