Re: [TLS] PR#625: Change alert requirements
Eric Rescorla <ekr@rtfm.com> Tue, 20 September 2016 13:04 UTC
Return-Path: <ekr@rtfm.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 D4EC412B0DE for <tls@ietfa.amsl.com>; Tue, 20 Sep 2016 06:04:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 ntg_-qwvac2U for <tls@ietfa.amsl.com>; Tue, 20 Sep 2016 06:04:34 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E895F12B071 for <tls@ietf.org>; Tue, 20 Sep 2016 06:04:33 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id u82so11101307ywc.2 for <tls@ietf.org>; Tue, 20 Sep 2016 06:04:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qFs7ZrMDlOTzuf21SGLOSOjVBb/1H0t0n8iqu4al7/4=; b=P/HGYsRwKTf9Ml8axVH7Ur2mua1HM7+MIpX7PgiW8C85eQNVyoap1Qa2GlQNb+1rA9 8GwP5nEj63rhpJvI4Kcle0doS3j64cDbYaXD2+z8Z9TbM0jBrG9ETwGx99j9NHkIFBzu gTE7GN4fpPkeOb9lpPL0HHso92AXyVWNdpY+9sXFA5jWEuXuZ06KvAfOdrQVuYl2EdwF opRKKPi5Ylwj1eCg6iFciblu0slyIts1yvA2RaHtd0pZwIlqszrrt8jeyQgr4ScQBX/I gdjU7geAKRVILXMhLMYdIEGLaKFL6ZneIcqq08u3c8zlBPSIk7Wmm+FenCywaJS+jLT5 GSgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qFs7ZrMDlOTzuf21SGLOSOjVBb/1H0t0n8iqu4al7/4=; b=b9VNuggnqlC9zvJTvSRgJ/AauICS3sjSA/NaqntEmasoDbCyAoYncS94uc07P7ywa0 S8QozfNoBktV3709eVSVMEU2ARsc9UaW0gBFYQK1zpWFvZfwjYXnd0th3NUjbI8jc7O/ IAU2Bpfn4cdwdLQQhE9XIX38MahPjzznTq/AjxuEy3fH/26CcHEixIMfnue5QspmQ4Ji CLXlbIGVr3i2DnRnmb2fIIfpw8fjlLmj/v63w1GPGuRO8s5Ae2u5/euwVDgbEk9Xh034 s9sAGQ8DIJlkCoJyyULWkUn5ts+h7EUrMbi8rtHHRTkUVDKfpe1X+8WI/gqku1ThFsm9 Thfw==
X-Gm-Message-State: AE9vXwOMK4OUMRSc0RTinbQZ0LSyZgEs+D98RA+NbWKSzjHMUshepNDUU2ESZD/T/zrr+Hm1UZ8cw2kuQSA9gA==
X-Received: by 10.129.83.193 with SMTP id h184mr30261931ywb.52.1474376673229; Tue, 20 Sep 2016 06:04:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.160.10 with HTTP; Tue, 20 Sep 2016 06:03:52 -0700 (PDT)
In-Reply-To: <4268201.z3YH5P6ntS@pintsize.usersys.redhat.com>
References: <CABcZeBMeLgqjvr2cjWL=AHTQJbS9siNBB6U2=0654yigbBGkYA@mail.gmail.com> <47532130.8rB6yCJVvA@pintsize.usersys.redhat.com> <CABcZeBOsN+_gUUb=HoUsoPOTBgANedT5Y5O+pAGXn0qTYjq1jg@mail.gmail.com> <4268201.z3YH5P6ntS@pintsize.usersys.redhat.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 20 Sep 2016 06:03:52 -0700
Message-ID: <CABcZeBMg_QjHQf3b1mJcuDtCH1o2Gpv=YDdDPkAu5GwEhVaCfg@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>
Content-Type: multipart/alternative; boundary="001a114d6f1cdfb3d5053cf011d9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VevLMn2bNHi6LR8MPKHYLVYgk0M>
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 13:04:36 -0000
On Tue, Sep 20, 2016 at 3:39 AM, Hubert Kario <hkario@redhat.com> wrote: > 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? > Probably bad_record_mac, because it's a deprotection failure. > > 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. > These are different fields. Less error-prone solution would be to have the same behaviour specified for > encrypted and non-encrypted record layer. > The rationale for this is that we need to allow flexibility for the plaintext messages because there are stacks which don't conform already, but not for the encrypted. Please feel free to file a PR and start a discussion on the list if you disagree, but this is out of scope for this PR. -Ekr > -- > 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