IETF Logo Mail Archive

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

Bodo Moeller <bmoeller@acm.org> Fri, 26 September 2014 07:08 UTC

Return-Path: <SRS0=QEdY=6T=acm.org=bmoeller@srs.kundenserver.de>
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 4E5FE1A1A71 for <tls@ietfa.amsl.com>; Fri, 26 Sep 2014 00:08:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.714
X-Spam-Level:
X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no
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 Y1yCxLT7jSSA for <tls@ietfa.amsl.com>; Fri, 26 Sep 2014 00:08:55 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C7FE1A1A70 for <tls@ietf.org>; Fri, 26 Sep 2014 00:08:52 -0700 (PDT)
Received: from mail-yk0-f172.google.com (mail-yk0-f172.google.com [209.85.160.172]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0MC1IG-1XOeDh3ltg-008uzD; Fri, 26 Sep 2014 09:08:50 +0200
Received: by mail-yk0-f172.google.com with SMTP id 79so3932889ykr.31 for <tls@ietf.org>; Fri, 26 Sep 2014 00:08:48 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.142.7 with SMTP id h7mr55738yhj.133.1411715328917; Fri, 26 Sep 2014 00:08:48 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Fri, 26 Sep 2014 00:08:48 -0700 (PDT)
In-Reply-To: <CABkgnnWo9KGMkRrmA0wkJ5Dfnzh2Vo-cveCe_UeH71F8K_4oWw@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>
Date: Fri, 26 Sep 2014 09:08:48 +0200
Message-ID: <CADMpkcJpHeKGV-xc4Uon8KWj=+p=6nQO1_rxb6sRN04nFX--gQ@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="20cf303a36afb448b30503f2960f"
X-Provags-ID: V02:K0:44l78mThgx0pP1skCz+SGmcY6okcKlfnt6Kkn6ZMjHn 7xQcaPHyQgQwe9HsPqZsnP5pfcATT9IEKKhcgp2+TVtIgnAwfs UNmi3NqRQiEUudUD8qVYfGNHHB/kqZ4+blwDpOryxkL6b14Q28 3eNi7MIi/0y2XxFkD+v9WApjP2RNd/20Li8DnZVCvgWgihNHH9 Z1r5CtUg05z3+nD1wEqac6GA2ptpBFdrzNoKgnq+cn/KMCi2WB XCQfNbvm4Pbh6l/IkRMyNZPYL1pQowdzO58fL6kze70VmYsNwT XvysT1qvrjK1EWITIcz2yCVjbllFWg2OcX7zfnGVJW/hLLX0PD IrWadKHv3nwKFbveOvkz2rjq5LKdyEl8g+Buke1zfYyrO+jET1 UKXx3yAmmimH/wEy+zqH8RuAWkRerCsI2pGwf7v8GFDhTQb9Gm VT8in
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/E_OKzCYjSM9zQfa2TUjaXxVcuU4
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, 26 Sep 2014 07:08:56 -0000

Martin Thomson <martin.thomson@gmail.com>:

> Bodo Moeller <bmoeller@acm.org> wrote:
>


> > What specifically do you consider wasteful?
>
> 16 bits, that's all.  Not a big deal (unless you are close to having to
> pad...)
>
> > Note that ignoring the SCSV *on resumption* wouldn't quite work. The
> server
> > would need to ignore the SCSV on resumption *attempts*, successful or
> not; I
> > don't think I'd like that.
>
> The draft requires that downgrade on resumption attempts (yes, you are
> completely correct) is not guarded.  Whether that's a requirement on
> the server or client doesn't seem like a big deal to me.
>

Hm, I think I don't follow. Wouldn't having the server ignore the SCSV on
resumption attempts be strictly more wasteful than having the client not
send it?

The main thinking behind the draft, however, is that the server-side logic
should be as simple as possible, because I want *every* server to do this.
(What's more, I want every server to do it *correctly*.) The client-side
logic, in contrast, can be a bit more complicated: if your client never
does those fallback retries, you don't have to do anything.

Bodo

v2.43.4 | Report a Bug | By Email | System Status