Re: [TLS] Consistency for Signature Algorithms?

Eric Rescorla <ekr@rtfm.com> Mon, 24 July 2017 17:58 UTC

Return-Path: <ekr@rtfm.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 65CB6129B55 for <tls@ietfa.amsl.com>; Mon, 24 Jul 2017 10:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 XDAsnVeTHjd8 for <tls@ietfa.amsl.com>; Mon, 24 Jul 2017 10:58:55 -0700 (PDT)
Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 46E5A129B19 for <tls@ietf.org>; Mon, 24 Jul 2017 10:58:55 -0700 (PDT)
Received: by mail-yw0-x232.google.com with SMTP id x125so54055223ywa.0 for <tls@ietf.org>; Mon, 24 Jul 2017 10:58:55 -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; bh=LzuVQdIok55iPXBMgP4TH8HATddx96wadp9AeyWsf3U=; b=PigqwiUtIr7rD4hHjeAAjmm7/qwvyozf5KUw5JPnbHRV5Nc0MDu4S6xyOABoUqFfD5 egxHnvIMrrMvjeUumgJT0UGpEc0KMdLwAcA0BiGHpijuGRIKkXWkRPV+COjMOmQbQBIV b0yLgmrgE6UexWYQB+xtHaXuQRCRVfqLo+FMBkAQdxo5qutevYq6h2Ymk8OgNeUASvuO v8G+N59QgsAG0oI8JDv/WCI23/T7fQIyihbjkILfkE4pNGpYawOqGdCmywVnI7ecQdUU N1mcZTq5a6ogm5JEp3jAUZayEeIvGm7dy1uFhWVyKwqGRTVmpe/cbKzhKyhagaLhHQFe rztw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LzuVQdIok55iPXBMgP4TH8HATddx96wadp9AeyWsf3U=; b=YM2E1q+y506l9TMO+A8oHc+fCNO4tQO251bwM/USOSMzQhMIBUP0i9cYySPdhasb7K 8wDRyDkA7zb8yd6RhTQ5GmOLESNuQiyggyCk2RntykTPy3eC6kqB8/DhIqplwH3qT7rZ CgauL3FLSDJtSDEfx+yBDhJwZtyE1YPwwf65I3wJgD1MaDY7MhWH1LwTJ++Vfh+WQrdH 87Kt806sWswqRYlL3lxCVdUvYAoV4JAI5kT7jYSjO7f/o7dGmLUjAIf15aFdANQnahDe v+MEQOkk3Ksn8/B9rH9k4WRjoLPBn+0zFVQkVlIF41mux7q+9IGVhMVqC7o6wIrFfO+n qs3A==
X-Gm-Message-State: AIVw1100SJ9/kTCLTR20GQ4DyPjbx6+xMuTCyUVtD80j628AtqbU+Wle jDp4HvUs2NGVKUgP3aVyLwIdT/uiVipU
X-Received: by 10.129.75.5 with SMTP id y5mr3947284ywa.222.1500919133135; Mon, 24 Jul 2017 10:58:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.36.12 with HTTP; Mon, 24 Jul 2017 10:58:12 -0700 (PDT)
In-Reply-To: <4846144.teiDd8FNEU@pintsize.usersys.redhat.com>
References: <3586282.tDsyLpRkWM@pintsize.usersys.redhat.com> <166770404.4ZRqQnPX1I@pintsize.usersys.redhat.com> <19a5f6c2-20fd-3bf9-f40c-4684c5cbf4f2@akamai.com> <4846144.teiDd8FNEU@pintsize.usersys.redhat.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 24 Jul 2017 10:58:12 -0700
Message-ID: <CABcZeBO_ydF7kVk1+KU5FLheks4MFEVxDTCQUM5Zo=73woa0Kg@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>
Cc: Benjamin Kaduk <bkaduk@akamai.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a113f1e9ac46f83055513f70d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fcX9Nk286papGdgTH33IEqsN2FI>
Subject: Re: [TLS] Consistency for Signature Algorithms?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 24 Jul 2017 17:58:57 -0000

On Mon, Jul 24, 2017 at 10:15 AM, Hubert Kario <hkario@redhat.com> wrote:

> On Monday, 24 July 2017 15:09:48 CEST Benjamin Kaduk wrote:
> > On 07/24/2017 05:49 AM, Hubert Kario wrote:
> > > On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote:
> > >> I'm afraid I don't understand this remark. There is the caveat to
> which
> > >> Ilari alludes, that the server can send whatever chain it has, if the
> > >> server can't send a chain that complies with the client's
> > >> signature_algorithms.  Since certificate validation is assumed to be
> > >> largely a function of the PKI library and not really in scope for the
> > >> TLS spec itself, this is not particularly problematic.
> > >
> > > true; that disjoint between "stuff that TLS library is supposed to do"
> and
> > > "stuff that PKI library is supposed to do" could be spelled out more
> > > explicitly in the RFC though
> >
> > I pasted that into https://github.com/tlswg/tls13-spec/issues/1062 but I
> > don't have high hopes that it won't just get closed with no action.
> >
> > >> The other main
> > >> usage of the signature_algorithms limits what can be used in
> > >> CertificateVerify, which is directly relevant to TLS and depends on
> the
> > >> key attested to in the certificate.  Are you claiming that there are
> > >> servers that only possess certificates with p384 keys (i.e., no RSA or
> > >> p256 or other fallback cert)?
> > >
> > > Yes, there are servers that have P-384 keys. Not sure if they have a
> dual
> > > stack (but that is unlikely as only about 30% of servers with ECDSA
> certs
> > > have also RSA cert).
> >
> > To clarify, you are arguing that P-384 should also be listed as MTI?
>
> no, I'm arguing either for dropping the curve from signature algorithms,
> or to
> bind RSA key sizes to hashes too
>


I don't think that either of these are good ideas. It turns out that curves
and
signature algorithms just aren't orthogonal (and even less orthogonal than
hash algorithms) nbut RSA is qualitatively different.

-Ekr


> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>