Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2

David Benjamin <davidben@chromium.org> Tue, 12 July 2016 21:13 UTC

Return-Path: <davidben@google.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 E883D12D8F5 for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 14:13:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Level:
X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 I3IKOs25q9RI for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 14:13:55 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 E432C12D8F0 for <tls@ietf.org>; Tue, 12 Jul 2016 14:13:54 -0700 (PDT)
Received: by mail-io0-x235.google.com with SMTP id q83so28772761iod.1 for <tls@ietf.org>; Tue, 12 Jul 2016 14:13:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q140c/R16TQFCB6I5BqrvtsfDIYXzbKZ68VbwK1E3VA=; b=d2IlkW4lgGlu0R+3DyxR3GuECaMo3zFogaR1fZO3ZSFDWmEflvj7zbgOMHTGPz6L62 JzCnipCrVAsTA04ztpF65J9UVVMWXaY2cFOLen1u+rnW6g3jj+YGJUDwH4t9QSsETKia nv+sQ1A8QIH5P+sE+rjFERAQIHKmZ8iuTGTvM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q140c/R16TQFCB6I5BqrvtsfDIYXzbKZ68VbwK1E3VA=; b=SkKaElN6BaYAxWZthm60jFOP1a8oA2e7Bfyi/vFAJbynDLlrpHQcwtGn9xAhh8h+P1 ulgc/Ipyl6d9SniI3iojXLQ/HDcu+Q8n4Ymmcog+OgxGZTeqIfMp/i4Z05Pnf0P2YL2y 8FJpmxNOEBFIk3ZW261WWkjqoZm/6ocUiViHKSrHtIw5uMUhi8ofJwHqTNx1m2ZvyCq3 juReFliEtFLxu4uhCNrPpuz+ATWFo3PNtVmwyo38DXnOu02QkBKgybxjFfJx/GeBBeRr VlEnxS28E+F1yCuGjuirgM+DCh80ohkc/UNeHbAdkeGKQ4D1IqzESWC0Y5btgN3A9Oo5 GqKA==
X-Gm-Message-State: ALyK8tKeuNTMb6BKNfisiY23Zh/mdI7QKE6LUTICtZrRndlxYFdpbSSiinHv7XHYP/4UqVJrOxhUqsKRfCwMluuu
X-Received: by 10.107.13.82 with SMTP id 79mr5722275ion.97.1468358034150; Tue, 12 Jul 2016 14:13:54 -0700 (PDT)
MIME-Version: 1.0
References: <CABcZeBMiLmwBeuLt=v4qdcJwe5rdsK_9R4-2TUXYC=sttmwH-g@mail.gmail.com> <20160712041624.GA30472@LK-Perkele-V2.elisa-laajakaista.fi> <CAF8qwaDcf99O46F1v5ZK8_0079iWgkSoGwD+w-KFd-cRqM_sdw@mail.gmail.com> <20160712192929.GA32063@LK-Perkele-V2.elisa-laajakaista.fi> <CAF8qwaB_h_k0bvnemKfbTBGNXYN4VYjrJ0+iZ_R7gF2w4wJX7w@mail.gmail.com> <20160712201707.GA32363@LK-Perkele-V2.elisa-laajakaista.fi>
In-Reply-To: <20160712201707.GA32363@LK-Perkele-V2.elisa-laajakaista.fi>
From: David Benjamin <davidben@chromium.org>
Date: Tue, 12 Jul 2016 21:13:43 +0000
Message-ID: <CAF8qwaBcn1HQRUawoSjGS-tNUKLBP17RvxYcct2OGW=KFKqt9g@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary="001a113fdb5e07bcf5053776bf6d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/hLEtF-aRNCAVAw621EQYFgh4n6Q>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2
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, 12 Jul 2016 21:13:57 -0000

On Tue, Jul 12, 2016 at 4:17 PM Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Tue, Jul 12, 2016 at 07:53:41PM +0000, David Benjamin wrote:
> > On Tue, Jul 12, 2016 at 3:29 PM Ilari Liusvaara <
> ilariliusvaara@welho.com>
> > wrote:
> >
> > Right, there is a risk of interop failures if two implementations
> disagree
> > on whether the algorithms exist in 1.2. Since getting these algorithms
> into
> > 1.2 is not that important, I want everyone to standardize on the easier
> > option (that is, they do *not* exist in 1.2). Otherwise we risk some
> > implementations backporting (because the spec says to) and some not
> > (because it is easier not to).
>
> Unfortunately, the way things are, it is both easier and way safer to
> say that they *do* exist in TLS 1.2, at least for server signatures
> (one can leave the crazy mess that is client signatures[1]).
>
> And here RSA-PSS is even worse hazard than EdDSA. EdDSA at least
> requires its own EE certs, RSA-PSS works with standard RSA EE
> certs that are widespread. Have a TLS 1.3-capable server that
> doesn't check versions (easy enough[2]) and have it capped to TLS 1.2
> by something (either misconfig or API issues, no end of those
> kind of servers) and there you go...
>

That's fair. If you do the backport version, then you do have to go out of
your way to do the version check.

I guess the question is what other implementors intend then? We've actually
done the backport on our end. Perhaps my guess that not everyone will do
this is wrong.

That is, if client advertises EdDSA or RSA-PSS, it MUST be able to
> verify those, even after downnegotiation to TLS 1.2. If it doesn't,
> it MUST NOT advertise them, even in TLS 1.3 ClientHello.
>

Well, we could define that EdDSA/RSA-PSS in TLS 1.2 doesn't exist and then
spec-wise we're fine. The question is just which we think will cause fewer
interop issues.

Either way, worst case, we'd just end up in an awkward state where, when
signing, one does not pick RSA-PSS in 1.2 but when verifying, one should
accept it. Not the end of the world. I might just go ahead and do that
anyway so I don't have to care about this issue...


>
> [1] How many borked/buggy servers there are that say they support
> X, but fail if you try to use X? Outside known trouble like mixing
> and matching curves and hashes in ECDSA?
>
> [2] There is actually very simple way to implement things that seems
> to work, only it blows up when client that claims it supports
> something it doesn't comes along...
>
>
>
> -Ilari
>