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