Re: [TLS] Version in record MAC

David Benjamin <davidben@chromium.org> Mon, 19 October 2015 16:49 UTC

Return-Path: <davidben@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49AE1A8A64 for <tls@ietfa.amsl.com>; Mon, 19 Oct 2015 09:49:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.088
X-Spam-Level:
X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 TPiZ5ouwJ7m3 for <tls@ietfa.amsl.com>; Mon, 19 Oct 2015 09:49:13 -0700 (PDT)
Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 2CF1C1A8A47 for <tls@ietf.org>; Mon, 19 Oct 2015 09:49:13 -0700 (PDT)
Received: by iofz202 with SMTP id z202so56788946iof.2 for <tls@ietf.org>; Mon, 19 Oct 2015 09:49:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=V4Rks//eSfTsAvantYFv3UiHVTGiWCnXnbZ0ovtPxpI=; b=eAspoDJ4VN8EX8LUGLwZAd3ALXMUrIfs3h3vPTA0ZPI0fEB3PzQVRTz7CH8vdAo/w4 d4+co87bXaL1L1AwxLLOB7uC8VgHEIy39QqdAUNTLtZQoMgykbiSuehs4+DnblYM1vPg aciXWhSDv7g20yxMInmgwHfRyoRHyWHUI71NA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=V4Rks//eSfTsAvantYFv3UiHVTGiWCnXnbZ0ovtPxpI=; b=kWMX8fyFo1Tp9qxraD1YR2lXSL74w8W0Ut9duRPc+GmcfMY27UqtmSkx/jNSkCt2/Q xLn+HKxNPzQ2N8h43rPcO+t0Wkaq4GTvZUe0WKl3jPUIXMspFIMYPQ4Ogo2PRif6k5N4 M0VsUsKUeP5TerTJPb9eDIPWlyD1RbhGaSy5KepBxdwAO0habnX5GSntCbZHp4hGMLXS 25z84O/VCtTWwu9mktwSjg34NZCo91Uw+jaInxpurxeUPsgVAUFyMBWFWXgEUsJ+k+rq 5r0DyAq1fczZXtnB55xeyF5FovVb6NuFKHKUHox3Q3Fr6wQifHzISSTZor5RtuhahJXS pW0w==
X-Gm-Message-State: ALoCoQltQL+1fT48qbEXkwTvzdcsZiQZsVYbit0eqEOoCBjsV/J3mtYMzIWkJ4Dig+jwcBQJUf+t
X-Received: by 10.107.30.8 with SMTP id e8mr2856487ioe.166.1445273351181; Mon, 19 Oct 2015 09:49:11 -0700 (PDT)
MIME-Version: 1.0
References: <CABcZeBODjk8rapgbNTST8bmFFVzKqB4tJyrvje-CTgk1=gfqFw@mail.gmail.com> <CAAF6GDeSiEV9GtBWaDE5CJd-sO2S3jnUfSeQ25CdcWe+JB0_-Q@mail.gmail.com>
In-Reply-To: <CAAF6GDeSiEV9GtBWaDE5CJd-sO2S3jnUfSeQ25CdcWe+JB0_-Q@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Mon, 19 Oct 2015 16:49:01 +0000
Message-ID: <CAF8qwaCbM4nWMFHO2iBr+5o2ibAW3PF0EDQpv8CCpiAySmCTAA@mail.gmail.com>
To: Colm MacCárthaigh <colm@allcosts.net>, Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="001a1140ea4ab3c87d052277ec7b"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/vuTJ5ZwNJ0kQsAgNVm_v5sU-DIM>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Version in record MAC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 19 Oct 2015 16:49:14 -0000

What purpose does putting the version in the AD serve? It's not harmful,
sure, but just using the sequence number is simplest. It seems the only
reason we'd consider putting it into the AD is because historically the
record version was in there as part of the record header. In a vacuum, I'm
having a hard time imagining why one would want negotiated_version in there
that wouldn't also apply to putting the whole handshake hash in there. Am I
missing something?

David

On Mon, Oct 19, 2015 at 12:40 PM Colm MacCárthaigh <colm@allcosts.net>
wrote:

>
> If (2.) is used, would it be nice to make it  negotiated_version
> + seq_num? I think for some algorithms, the MAC can be partially
> pre-computed if things are in that order.
>
> On Mon, Oct 19, 2015 at 9:28 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>> Folks,
>>
>> https://github.com/tlswg/tls13-spec/issues/278
>>
>> The additional data field presently includes the version:
>>
>>       additional_data = seq_num + TLSPlaintext.record_version
>>
>> However, TLSPlaintext.record_version is now always {3, 1}, so
>> this is redundant. There seem to be two primary options here:
>>
>>      1. Don't MAC the version at all.
>>      2. MAC the negotiated version (which should be clear at
>>         this point).
>>
>> I could go either way on this (slightly leaning towards #2) but
>> the current thing seems silly.
>>
>> -Ekr
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>
>
> --
> Colm
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>