Re: [TLS] Renumbering the new SignatureSchemes

Hubert Kario <hkario@redhat.com> Tue, 20 September 2016 18:14 UTC

Return-Path: <hkario@redhat.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 53F3312B436 for <tls@ietfa.amsl.com>; Tue, 20 Sep 2016 11:14:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.238
X-Spam-Level:
X-Spam-Status: No, score=-9.238 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 QVaEYjBsXQZY for <tls@ietfa.amsl.com>; Tue, 20 Sep 2016 11:14:31 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F02612B14C for <tls@ietf.org>; Tue, 20 Sep 2016 11:14:31 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A5BAA7F7D4; Tue, 20 Sep 2016 18:14:30 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8KIES1k000387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Sep 2016 14:14:29 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Tue, 20 Sep 2016 20:14:27 +0200
Message-ID: <16571109.7c9qxWjLg8@pintsize.usersys.redhat.com>
User-Agent: KMail/5.3.1 (Linux/4.7.3-200.fc24.x86_64; KDE/5.26.0; x86_64; ; )
In-Reply-To: <CAF8qwaBpksHy_=csDKmnSU3k5uQDkf2-0dGUsbf1v9h998cK2A@mail.gmail.com>
References: <CAF8qwaAo-MKJvxdpDkb-fyMfLmOpbhif=2Axik3wnr1DPzd5Eg@mail.gmail.com> <20160920153327.GA12381@LK-Perkele-V2.elisa-laajakaista.fi> <CAF8qwaBpksHy_=csDKmnSU3k5uQDkf2-0dGUsbf1v9h998cK2A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart98297888.hiKLUcGylj"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 20 Sep 2016 18:14:30 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/GPoGS4mrAQluW7X5SsOGA-r-rZY>
Subject: Re: [TLS] Renumbering the new SignatureSchemes
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: Tue, 20 Sep 2016 18:14:33 -0000

On Tuesday, 20 September 2016 15:56:01 CEST David Benjamin wrote:
> On Tue, Sep 20, 2016 at 11:33 AM Ilari Liusvaara <ilariliusvaara@welho.com>
> 
> wrote:
> > On Tue, Sep 20, 2016 at 03:07:51PM +0000, David Benjamin wrote:
> > > Hi folks,
> > > 
> > > I've just uploaded this PR to slightly tweak SignatureScheme numbering:
> > > https://github.com/tlswg/tls13-spec/pull/641
> > > 
> > > In principle, we should only have needed to burn values starting with
> > 
> > known
> > 
> > > HashAlgorithms, but TLS 1.2 said:
> > >    signature
> > >    
> > >       This field indicates the signature algorithm that may be used.
> > >       The values indicate anonymous signatures, RSASSA-PKCS1-v1_5
> > >       [PKCS1] and DSA [DSS], and ECDSA [ECDSA], respectively.  The
> > >       "anonymous" value is meaningless in this context but used in
> > >       Section 7.4.3.  It MUST NOT appear in this extension.
> > > 
> > > We'd started RSA-PSS along the train to get shipped in Chrome to get
> > 
> > early
> > 
> > > warning on any interoperability issues. We ran into an implementation
> > 
> > which
> > 
> > > enforced this MUST NOT. It's a MUST NOT in 1.2, so it seems prudent to
> > > allocate around it and avoid ending in known SignatureAlgorithms. Thus,
> > > rather than only burning {0x00-0x06, *}, we also burn {*, 0x00-0x03}.
> > 
> > This
> > 
> > > has the added benefit that TLS 1.2 dissector tools don't get confused.
> > 
> > Heck, I think one could put the RSA-PSS ones as 0404, 0504 and 0604,
> > as those do have the indicated "prehashes".
> > 
> > And one could probably also stick Ed25519/Ed448 in 00xx, as those have
> > no prehash, which is exactly what "hash #0" is about.
> > 
> > (Of course, this all is pretty pointless bikeshedding).
> 
> The ecdsa_p256_sha256 business means that the old scheme isn't quite
> accurate. And if we are to drop the old scheme, it was intentional on my
> part that RSA-PSS did not look like it, even though it still fit. I think
> that paid off. No one's going to implement Ed25519 for a while, so RSA-PSS
> is our smoke test that this SignatureScheme idea is sane. (Both for interop
> and for making sure removing the hash/sig decomposition in implementations
> internally is sound.)

I'll be running test looking for intolerances like this over the Alexa top 1 
million next month.

For now I have a probe that adds values 0x0003, 0x0004, 0x0700, 0x0703 and 
0x0704 at the end of the list of algorithms.

Would you suggest doing something more with it?

(I will be looking for key_share extension intolerance as a whole too)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic