Re: [TLS] Another IRINA bug in TLS

Aaron Zauner <azet@azet.org> Thu, 21 May 2015 13:27 UTC

Return-Path: <azet@azet.org>
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 6260D1A1BA5 for <tls@ietfa.amsl.com>; Thu, 21 May 2015 06:27:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 SEnSyDC3nELj for <tls@ietfa.amsl.com>; Thu, 21 May 2015 06:27:43 -0700 (PDT)
Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (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 8C21C1A1BA2 for <tls@ietf.org>; Thu, 21 May 2015 06:27:43 -0700 (PDT)
Received: by wghq2 with SMTP id q2so85712091wgh.1 for <tls@ietf.org>; Thu, 21 May 2015 06:27:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=INtcGd/AeJcyNgFVbG8AP2nmkH0MJ6UGy/KFjXsU2BU=; b=VXJrutLk0SDN9eaC7LutPMn8FWU5LwtL3ZjKQNVwa9OjUYCdR7Ljp4X2a6d2enDczm OiqWvuT91lDd/rH7p08LRIPQCzchU8sK+PLQXeTbV5h2a5WBzj8omeymdfwA5bCNOg+z 04Qy28+cfEjbEWLrk0C+2EnsJlRMuuAbZnDHCR4En2p8Ck9yOpUn8Bwvx6Xa5BIKogdC R+SzVRSAlMRQVUjG/IZKlX2OqnTfxy8wK+o6DZxRKZ/3ig6IPUpamnn+Bu5wK0mipTUu TsERfr/RSpyRGYqnTMFkieX5QmifYObGBpnf/oz/oqeeWqtPJkoHm2UnN+xW7LVTe3kh YSRw==
X-Gm-Message-State: ALoCoQm7NYJZT+HJ7rMz39O5yyiRIz9PHJBrK6NJxAEkLbGeVBA7hu5F3LKGNNoAKXpxO5cZ6qFi
X-Received: by 10.194.60.164 with SMTP id i4mr5350716wjr.133.1432214862156; Thu, 21 May 2015 06:27:42 -0700 (PDT)
Received: from [10.60.20.24] ([193.170.94.190]) by mx.google.com with ESMTPSA id x10sm1596146wjw.39.2015.05.21.06.27.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 May 2015 06:27:41 -0700 (PDT)
Message-ID: <555DDD4A.4040206@azet.org>
Date: Thu, 21 May 2015 15:27:38 +0200
From: Aaron Zauner <azet@azet.org>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Santiago Zanella-Beguelin <santiago@microsoft.com>
References: <CACsn0ckaML0M_Foq9FXs5LA2dRb1jz+JDX7DUej_ZbuSkUB=tQ@mail.gmail.com> , <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> , <555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com>, <1432209104.3243.65.camel@redhat.com> <1432211226723.39265@microsoft.com>
In-Reply-To: <1432211226723.39265@microsoft.com>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="------------enig1125E80655211DB5672830A7"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/gkANtNym8fJpFCo5V6NHZDlHWp0>
Cc: Florian Weimer <fweimer@redhat.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Another IRINA bug in TLS
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: <http://www.ietf.org/mail-archive/web/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, 21 May 2015 13:27:48 -0000

Hi,

Santiago Zanella-Beguelin wrote:
>> Well, you assume that the so-called "safe primes" are universally
>> used, which is not really the case. Expecting all servers sending
>> these parameters wouldn't really work.
> 
> Yes, non-safe primes should be first deprecated.
> 

I'm curious: what are instances where unsafe primes are still used,
generated and distributed for use in TLS? Hence where do we need to
deprecate?

Thanks,
Aaron