Re: [TLS] PR#625: Change alert requirements
Hubert Kario <hkario@redhat.com> Tue, 20 September 2016 10:39 UTC
Return-Path: <hkario@redhat.com>
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 39F6F12B09F for <tls@ietfa.amsl.com>; Tue, 20 Sep 2016 03:39:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.238
X-Spam-Level:
X-Spam-Status: No, score=-9.238 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 HMY2xbpGyKL9 for <tls@ietfa.amsl.com>; Tue, 20 Sep 2016 03:39:34 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A115212B0CD for <tls@ietf.org>; Tue, 20 Sep 2016 03:39:34 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id ED03B31B306; Tue, 20 Sep 2016 10:39:33 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8KAdWhO031756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Sep 2016 06:39:33 -0400
From: Hubert Kario <hkario@redhat.com>
To: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 20 Sep 2016 12:39:31 +0200
Message-ID: <4268201.z3YH5P6ntS@pintsize.usersys.redhat.com>
User-Agent: KMail/5.3.1 (Linux/4.7.3-200.fc24.x86_64; KDE/5.26.0; x86_64; ; )
In-Reply-To: <CABcZeBOsN+_gUUb=HoUsoPOTBgANedT5Y5O+pAGXn0qTYjq1jg@mail.gmail.com>
References: <CABcZeBMeLgqjvr2cjWL=AHTQJbS9siNBB6U2=0654yigbBGkYA@mail.gmail.com> <47532130.8rB6yCJVvA@pintsize.usersys.redhat.com> <CABcZeBOsN+_gUUb=HoUsoPOTBgANedT5Y5O+pAGXn0qTYjq1jg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2973557.TPoE23oAkJ"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 20 Sep 2016 10:39:34 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/r-Z5m3t4A2SIAuSakmnLW1RZtcU>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] PR#625: Change alert requirements
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 20 Sep 2016 10:39:36 -0000
On Monday, 19 September 2016 18:12:22 CEST Eric Rescorla wrote: > Resolutions below. Thanks! I'll go over the post-merge text again later. > On Thu, Sep 8, 2016 at 11:08 AM, Hubert Kario <hkario@redhat.com> wrote: > > On Monday, 5 September 2016 11:02:57 CEST Eric Rescorla wrote: > > Finished section doesn't describe what to do if the contents don't match > > the > > expected value. > > > > Should it be illegal_parameter or bad_record_mac is more appropriate? > > This is specified in the decrypt_error section. on one hand, this give a side channel to detect mismatch between decryption error and finished value compare, on the other hand, the timing difference between those will be huge anyway... > > --- > > > > Record Layer doesn't describe what to do if a record with zero-length > > payload > > and handshake or alert type is received. > > I'm comfortable leaving these as-is. so what would be the expected alert description in such situation? > > --- > > > > Record Layer includes > > > > legacy_record_version : (...) This field is deprecated and MUST be > > > > ignored > > > > for all purposes. > > > > Record Layer Protection does not. > > I don't follow. in Record Layer there's the following text: legacy_record_version : This value MUST be set to { 3, 1 } for all records. This field is deprecated and MUST be ignored for all purposes. in Record Layer Protection there's the following text: legacy_record_version : The legacy_record_version field is identical to TLSPlaintext.legacy_record_version and is always { 3, 1 }. Note that the handshake protocol including the ClientHello and ServerHello messages authenticates the protocol version, so this value is redundant. which doesn't say if the version can be ignored completely (skipped while parsing) or if it should be verified. Less error-prone solution would be to have the same behaviour specified for encrypted and non-encrypted record layer. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
- [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Sean Turner
- Re: [TLS] PR#625: Change alert requirements Watson Ladd
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Andrei Popov
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Martin Rex
- Re: [TLS] PR#625: Change alert requirements David Benjamin
- Re: [TLS] PR#625: Change alert requirements Timothy Jackson
- Re: [TLS] PR#625: Change alert requirements Ilari Liusvaara
- Re: [TLS] PR#625: Change alert requirements Salz, Rich
- Re: [TLS] PR#625: Change alert requirements Martin Rex
- Re: [TLS] PR#625: Change alert requirements Salz, Rich
- Re: [TLS] PR#625: Change alert requirements Salz, Rich
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Hannes Tschofenig
- Re: [TLS] PR#625: Change alert requirements Benjamin Kaduk
- Re: [TLS] PR#625: Change alert requirements Martin Thomson
- Re: [TLS] PR#625: Change alert requirements Ilari Liusvaara
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Sean Turner
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- [TLS] (strict) decoding of legacy_record_version? Benjamin Kaduk
- Re: [TLS] (strict) decoding of legacy_record_vers… David Benjamin
- Re: [TLS] (strict) decoding of legacy_record_vers… Eric Rescorla
- Re: [TLS] (strict) decoding of legacy_record_vers… Brian Smith
- Re: [TLS] (strict) decoding of legacy_record_vers… Martin Thomson
- Re: [TLS] (strict) decoding of legacy_record_vers… Brian Smith
- Re: [TLS] (strict) decoding of legacy_record_vers… Martin Thomson
- Re: [TLS] (strict) decoding of legacy_record_vers… Benjamin Kaduk
- [TLS] Treatment of (legacy_record_)version field … Andreas Walz
- Re: [TLS] Treatment of (legacy_record_)version fi… Eric Rescorla
- Re: [TLS] Treatment of (legacy_record_)version fi… Andreas Walz