Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)

Alfredo Pironti <> Sat, 30 November 2013 17:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9FE761AE472 for <>; Sat, 30 Nov 2013 09:25:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Status: No, score=-1.379 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, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LcCO-iHGWuqS for <>; Sat, 30 Nov 2013 09:25:15 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c02::22f]) by (Postfix) with ESMTP id 0F2241AE471 for <>; Sat, 30 Nov 2013 09:25:14 -0800 (PST)
Received: by with SMTP id k1so11452014oag.20 for <>; Sat, 30 Nov 2013 09:25:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=BbcsTUVmUZRzgylWFRFFf+7k/KxdyP+emnyOcjKDQso=; b=NaEnJEPLAoGTPi48cXgRLvrWLBzaOOz0s3d3AvorCjAgoCKuwHhGZF317KIuPdrgTy RMjl/plh786lnDV9X9QIy8wqeQRldWO2lnZk/iiOQLCbDGYisdwvTadqFf3bR30CEEvw ZpSGwrEHeapKHwBXtNmorLUjFNJMby7znpZK0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=BbcsTUVmUZRzgylWFRFFf+7k/KxdyP+emnyOcjKDQso=; b=TdOshGYXUCmCd3bBb7c7r8JxVvD4pndky1xNmlFzT98jiB7ZNSlv4VKXB+72XA9CaG OMtYTGoFRHE8AVIMz7yXVjIiLhdVien+Wbwr7OjMU2B7ZvxvKzXopRcd6mDClElWx8Lg wxlBpJyH57qavzeIdFYmTGDoFh9kRGjUcC/S6k0jy1gSR/+EtcKDvrihvBIzPb/Pv7Af g7lz977pKvtnerPiMsfkB1ikJIxI7gOgLS6GTuem4EsaxAcsZD+nugq8fQ6DtCrVJJLs YYoCKBnUHTk6CN/arFYmRkeA1XKrmUrphElJLBkCEv5NBl+358/M/zJw2kSHCuVcBkF+ U/cg==
X-Gm-Message-State: ALoCoQl3m7tri/gsQkdXZKxAsz5C6b4ifT+7/Um339DjTr/rxb3sMz+o/4djs3KR285CXx2M28PB
MIME-Version: 1.0
X-Received: by with SMTP id w3mr29364298oep.37.1385832312900; Sat, 30 Nov 2013 09:25:12 -0800 (PST)
Received: by with HTTP; Sat, 30 Nov 2013 09:25:12 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <>
Date: Sat, 30 Nov 2013 18:25:12 +0100
Message-ID: <>
From: Alfredo Pironti <>
To: "<>" <>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 30 Nov 2013 17:25:16 -0000

> I'm going to prepare a proposal I-D to do exactly (and only) what
> Serge Vaudenay had recommended in 2001, and what TLSv1.1 failed to fix,
> change mac-pad-encrypt into pad-mac-encrypt for the GenericBlockCipher PDU.
> When doing this, we can also consistently adopt the explicit random IV
> (which can be implemented as a random confounder) to all versions of TLS.

Please don't!
I think [1] does just what you're asking for. With 2 differences we
can agree upon:
1) Adding explicit IVs everywhere is a nice idea, and I'm up to add it
to the I-D.
2) If the paragraphs on non-GenericBlockCiphers really annoy you, just
ignore them.
To get a compliant implementation with non-block ciphers, all you have to do
is to add a 2-bytes empty vector to user data when sending, and parsing it when
receiving. All TLS implementations have a function for this, and it's
then a 2-lines patch.

> Signaling of this PDU change will be through a new SCSV in ClientHello,
> confirmation by the Server through a simple ServerHelloExtension, similar
> to how signaling is done for rfc5746 (TLS renegotiation_info extension).

I disagree with this. The more we add SSL3-compatible hacks, the more excuses
we give to vendors and to this WG to keep using SSL3.



> -Martin
> _______________________________________________
> TLS mailing list