IETF Logo Mail Archive

Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt

Bodo Moeller <bmoeller@acm.org> Thu, 26 September 2013 09:56 UTC

Return-Path: <SRS0=fyqm=TG=acm.org=bmoeller@srs.kundenserver.de>
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 210E811E8183 for <tls@ietfa.amsl.com>; Thu, 26 Sep 2013 02:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.51
X-Spam-Level:
X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, 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 F2cOesGUPklL for <tls@ietfa.amsl.com>; Thu, 26 Sep 2013 02:56:35 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id A405C21F9AEF for <tls@ietf.org>; Thu, 26 Sep 2013 02:56:31 -0700 (PDT)
Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0M7Ual-1Vl4uX1EF5-00x1uf; Thu, 26 Sep 2013 11:56:30 +0200
Received: by mail-oa0-f49.google.com with SMTP id i4so405113oah.36 for <tls@ietf.org>; Thu, 26 Sep 2013 02:56:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gAUXJnPG7ftWUms9lP0k8yS4VxZwVpeRQq9xWh+Qb/4=; b=VvZWJRAl48ciufXOwbq+rmcw56IvSZP6YVcL7JEQOek3oAs4nBfL9h5BgxVCQfuz7r V/R/KfPctsqcZfqd1f2gYmcKYnZ4bdyGoLD6j4UTkpWqLAcRdHQ2nbosFYOzBUJYYl4J vMHUAkzS/5W2TYSKSAqhEOv6StlLB677znzg7EPY0O0VMaMNcxVYO3MHjkQI2AakQi79 pmsT2JkiacDe0+pHmqWt2cuq+SGJ09IDRgBkL5HwakrczIszXZqENRGQocaLVzdEyr7Q ZxCl7P2U/LK7JLMg1k8YRF35vo00IvEvjbSTHMXnHH07sc7Dp26AGwozsjYg8rebd5z4 racg==
MIME-Version: 1.0
X-Received: by 10.60.58.10 with SMTP id m10mr239663oeq.61.1380189389000; Thu, 26 Sep 2013 02:56:29 -0700 (PDT)
Received: by 10.60.115.72 with HTTP; Thu, 26 Sep 2013 02:56:28 -0700 (PDT)
In-Reply-To: <524352D3.4020601@pobox.com>
References: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz> <CADMpkcJtp-+P8CFn_K7uptXtorYom0ALdaUn6xB16JFZSHoBtg@mail.gmail.com> <CAMfhd9U2eBdeO4MuDBW9hcuxzu0sttkifySSHJp9=bm5n3NNEg@mail.gmail.com> <5243119D.4070001@pobox.com> <CADMpkcKBOTs06DuJfsqDtZuhAzmxeGghXMhe2PPYBq9Ct_oxiA@mail.gmail.com> <CADMpkc+3ifDbnSxp9jiiPAKDPxaCWpkKHXTfgygpN3kOXMUFFQ@mail.gmail.com> <524352D3.4020601@pobox.com>
Date: Thu, 26 Sep 2013 11:56:28 +0200
Message-ID: <CADMpkcKXht8ttzTkf+3F8J58X-LDhu153RLfce_OZh5HMN_hAw@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: Michael D'Errico <mike-list@pobox.com>
Content-Type: multipart/alternative; boundary="089e01538bc441173d04e74662fe"
X-Provags-ID: V02:K0:lowpqWuX1r2lLiRxGYtmfKLa+i2gJreI0utC5yhpWmV d/qgwdb5RFzDyuirH2ep5W9mJSYdKv6FzjLncrdTcH4F5CIata G4R1aAPyjDyTi8gH0g4F2vn5Eslu32D5zCNu75IQYTLhDnDpHj ruKU0toJhoE2wucVf5QEC/chE5DZ7iMTXY1gHxLNWkshNaHbHo j6nIFZvskw1aFSCFh889ou3Zj3L5QCDQruyvYrpHlcuBQkjEDu Lm16n1IZzcKzLXDkgBniDfJL2HTYMy3NgJXMNrCdlJo7I2mPL8 s81gSjXJceFj/J5MTPXymXvpcjuuOtWL5oWbi7DK1+o30x2/mG QykCWIzeBnCWtbQ1gHlPmk5G76Fmfdpj+7yRfREeCx25PNmmRI pa/bsKgfaFuyHhglV1rsK6W3envO6pN0P8EWZB4C7qAC2G/ZFy nKF+t
Cc: TLS Mailing List <tls@ietf.org>
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-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." <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: Thu, 26 Sep 2013 10:00:48 -0000

2013/9/25 Michael D'Errico <mike-list@pobox.com>

> http://www.ietf.org/internet-**drafts/draft-bmoeller-tls-**
>> downgrade-scsv-00.txt<http://www.ietf.org/internet-drafts/draft-bmoeller-tls-downgrade-scsv-00.txt>
>>
>
> I think that the server MUST send a FATAL alert only if it would
> not have been willing to negotiate the lower TLS version in the
> absence of the SCSV.


> A WARNING alert from the server (or some extension_data with more
> information) lets the client decide whether to continue.  Both
> sides can keep track of these occurrences for further investigation
> by interested admins at their leisure (not via calls to the help
> desk).


I guess this would work, but I also want to keep the protocol simple.  (If
the client wants to continue with the downgraded protocol, it can send a
downgraded ClientHello without the SCSV.  Sending the SCSV is RECOMMENDED,
not REQUIRED.)



> Also RFC 3546 and 4366 have been obsoleted by RFC 6066.


I know -- so have RFC 2246 and RFC 4346 (by RFC 4346 and by RFC 5246,
respectively), but all of these are still relevant for implementations of
older TLS versions.  (RFC 6066 alone doesn't tell you how extensions work
in TLS 1.0 or TLS 1.1.)

Bodo

v2.23.0 | Report a Bug | By Email