Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 23 November 2016 15:51 UTC

Return-Path: <ilariliusvaara@welho.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 253D7129E8D for <tls@ietfa.amsl.com>; Wed, 23 Nov 2016 07:51:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level:
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=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 HsQlp0c8O9JG for <tls@ietfa.amsl.com>; Wed, 23 Nov 2016 07:51:25 -0800 (PST)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5B398129E9C for <tls@ietf.org>; Wed, 23 Nov 2016 07:50:54 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 95DF3142E6; Wed, 23 Nov 2016 17:50:53 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id oIGXTQF6B0xh; Wed, 23 Nov 2016 17:50:53 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 1D0D521C; Wed, 23 Nov 2016 17:50:53 +0200 (EET)
Date: Wed, 23 Nov 2016 17:50:47 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Message-ID: <20161123155047.GA30446@LK-Perkele-V2.elisa-laajakaista.fi>
References: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.com> <7462904085cc4a94914298af81157031@usma1ex-dag1mb1.msg.corp.akamai.com> <7de8f9da-8ab1-cfc2-00ad-9c91c7694174@gmail.com> <8394bafcd99344838d878b5e8cf5b524@usma1ex-dag1mb1.msg.corp.akamai.com> <8262a7bf-6c19-0a23-9d0b-8f59344444aa@gmail.com> <D45B2AE4.55950%john.mattsson@ericsson.com> <91F6F914-17FB-4543-B916-F1829267B168@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <91F6F914-17FB-4543-B916-F1829267B168@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/jwH8_kW6PjIBR4FpkijWJc7ux6Y>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis
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: Wed, 23 Nov 2016 15:51:28 -0000

On Wed, Nov 23, 2016 at 03:39:38PM +0200, Yoav Nir wrote:
> 
> > On 23 Nov 2016, at 12:22, John Mattsson <john.mattsson@ericsson.com> wrote:
> > 
> > On 2016-11-21, 06:31, "TLS on behalf of Yaron Sheffer"
> > <tls-bounces@ietf.org <mailto:tls-bounces@ietf.org> on behalf of yaronf.ietf@gmail.com <mailto:yaronf.ietf@gmail.com>> wrote:
> > 
> >> So the key schedule changed and therefore we think cross-version attacks
> >> are impossible. Have we also analyzed other protocols to ensure that
> >> cross protocol attacks, e.g. with SSH or IPsec, are out of the question?
> >> 
> >> Put differently, algorithm designers gave us a cheap, easy to use tool
> >> to avoid a class of potential attacks. Why are we insisting on not using
> >> it?
> > 
> > Unless someone points out any major disadvantages with using a context, I
> > agree with Yaron.
> 
> I’m not even sure what my position is on this. Specifying the use of a
> context here goes against the recommendation in the CFRG draft:
> 
>       Contexts SHOULD NOT be used opportunistically, as that kind of use
>       is very error-prone.  If contexts are used, one SHOULD require all
>       signature schemes available for use in that purpose support
>       contexts.
> 
> If someone knows why this recommendation was made, that would be great.

Basically, then those other methods would be a weak point for attack.



Then there's the serious deployment problems with contexts, as those
don't fit into any standard notion of signature various libraries have.


-Ilari