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
>