IETF Logo Mail Archive

Re: [TLS] Version in record MAC

Eric Rescorla <ekr@rtfm.com> Thu, 22 October 2015 13:33 UTC

Return-Path: <ekr@rtfm.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 CB0981A6F86 for <tls@ietfa.amsl.com>; Thu, 22 Oct 2015 06:33:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 oQLaiKiL3JhO for <tls@ietfa.amsl.com>; Thu, 22 Oct 2015 06:33:25 -0700 (PDT)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (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 52DDD1A6F6B for <tls@ietf.org>; Thu, 22 Oct 2015 06:33:25 -0700 (PDT)
Received: by ykaz22 with SMTP id z22so82567322yka.2 for <tls@ietf.org>; Thu, 22 Oct 2015 06:33:24 -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:content-type; bh=of9RnE+bIk1veR/Vr4v3eBaNJXkW2KpVUbr24uDrVJo=; b=jy2JclNpuBJjorT4APJo1AefQrpNeg6+rzKS0ebqYFTQ0ku9smaR0zj8+00a4LmJDO lbKfQaogEFAnMGznczkWwdiEymLIQ+vGUit73GK495KCnB/ByPZmmUlDehf4EeK2i984 WiIbw7/8xS4mf8dgfKuT/AxqdGy10Wt7SluC/UjqORXVdPp/rtW/1hPRjy0WdPWOO9+D Roh8lVLd38POB2xsc8kd+/StHdZV2glPwSK749XKBf2XPPJqVl7rGSlpGaZtkkDuIC7o AuxF9ed0KSEbwTsbKA8A1BJumAz5FipB6vYyRXnsQq6Bvu1/pw7qn7RAFmUI/19J6oG0 v8pA==
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:content-type; bh=of9RnE+bIk1veR/Vr4v3eBaNJXkW2KpVUbr24uDrVJo=; b=GhyXkAlE7tCvvYcPrf7k6x3ZGsJm2VMO32y2BJ8SIuY/1wb8CI/pWKZql3IarvPB/D mwDwhyeQrh2TRPnEZ8fcQO2VP+tjC/S+YQ/6r2eNNpiTqpNSek0AbdJ8cRJ3mn7FaaP5 M5W/T4w0gHw2X9vA3CUnEWEtf/o5Afcw2Yf7+1SsSxjBT4TEDq564UKUrBP3CfiE5tJw 3BqRdi1JFtRmvvBTD4EMOfmlU5ZCHpLS5/W3KjL9T0FoRHG21Qgw/bIdg4Yoi1AiY0Gc /OViZve3p56JAm5i3m0F7pLfs9XM5E2hz0BJWMIne22O8e+BCFkklbG7hGhrLWoPZwyT +omg==
X-Gm-Message-State: ALoCoQnv3i9ofNdEpR48npB52f3k4YDc5oFpFYDqrgQAGPc6ObRimK6nW30sX8G/MEWSppGdRiwf
X-Received: by 10.129.106.9 with SMTP id f9mr11987897ywc.223.1445520804635; Thu, 22 Oct 2015 06:33:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.221.85 with HTTP; Thu, 22 Oct 2015 06:32:45 -0700 (PDT)
In-Reply-To: <CAMfhd9V4WVxKbJh6KkNdVFGBGKh=tG5kC_7sPthOwhrrUi5eoQ@mail.gmail.com>
References: <CABcZeBODjk8rapgbNTST8bmFFVzKqB4tJyrvje-CTgk1=gfqFw@mail.gmail.com> <CABkgnnV+QrjcXJdZwwAGW-SpX0Z0_JroEVT-kMJgUAVe7DDQUw@mail.gmail.com> <CABcZeBOrL=TosONYfM_QPPYfT5N4VH7yR4hFw3Qt8W4V0uznkw@mail.gmail.com> <CABkgnnXis0mwqcsd1D0S61kqL6kvq9=ZU0BRbwbLH7Jesj0Y-w@mail.gmail.com> <CABcZeBNpV3uqOF4YohiCrtq03hR7LPnPGdny6yWB+zysVufiqA@mail.gmail.com> <CABkgnnWVJeeBuMitweCj=nOSB5cA-R-6btdQeWp0Bdnomd2XtQ@mail.gmail.com> <CAMfhd9V4WVxKbJh6KkNdVFGBGKh=tG5kC_7sPthOwhrrUi5eoQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 22 Oct 2015 06:32:45 -0700
Message-ID: <CABcZeBOc_9i83j4rjxve8PuBPWdd8eCVN2wQth3G0=T_xz1UKg@mail.gmail.com>
To: Adam Langley <agl@imperialviolet.org>
Content-Type: multipart/alternative; boundary="001a114934da139abe0522b18a91"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/eMlOUNyfxIxs29PViGG8SyIApcc>
Cc: David McGrew <mcgrew@cisco.com>, "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: Thu, 22 Oct 2015 13:33:27 -0000

I'm mostly convinced by this text in RFC 5116:
http://tools.ietf.org/html/rfc5116#section-2.1

   Because the authenticated decryption process
   detects incorrect nonce values, no security failure will result if a
   nonce is incorrectly reconstructed and fed into an authenticated
   decryption operation.  Any nonce reconstruction method will need to
   take into account the possibility of loss or reorder of ciphertexts
  between the encryption and decryption processes.

It would probably be worth checking with the cryptographers in the room.

CCing Hugo and McGrew.

-Ekr




On Mon, Oct 19, 2015 at 5:46 PM, Adam Langley <agl@imperialviolet.org>
wrote:

> On Monday, October 19, 2015, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
>> On 19 October 2015 at 11:17, Eric Rescorla <ekr@rtfm.com> wrote:
>> > Yeah, I think that's riding the nonce far too hard.
>>
>> On what basis?  Any change in the nonce will cause the record
>> decryption to fail.  That's the property we're looking for here, isn't
>> it?
>
>
> I don't believe that there's any reason to include the sequence number in
> the AD input of an AEAD. I think that an empty AD for TLS would be fine now
> that the content type is encrypted. (Not that I deeply care either way.)
>
>
> Cheers
>
> AGL
>
>
> --
> Adam Langley agl@imperialviolet.org https://www.imperialviolet.org
>

v2.23.0 | Report a Bug | By Email