Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates
William Whyte <wwhyte@onboardsecurity.com> Tue, 02 October 2018 14:08 UTC
Return-Path: <wwhyte@onboardsecurity.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 6A288130E9B for <tls@ietfa.amsl.com>; Tue, 2 Oct 2018 07:08:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=onboardsecurity-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 yHrGerxkogI2 for <tls@ietfa.amsl.com>; Tue, 2 Oct 2018 07:08:39 -0700 (PDT)
Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (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 E8E2A130E9D for <tls@ietf.org>; Tue, 2 Oct 2018 07:08:38 -0700 (PDT)
Received: by mail-pl1-x643.google.com with SMTP id p5-v6so1636595plk.3 for <tls@ietf.org>; Tue, 02 Oct 2018 07:08:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dvfra+igSzSuvrm6V06PRqF/WftPoFimXSrNOIQ/mMI=; b=h/OFXJ5Zh7ll9zHKXus6cspEVc/1QkqJrGcPfTm+/qQZZbiSwbxURK/5atMMXWiuY+ Oi3XM0G8jDJG0J8f/rfaPiGgCkwHQmWjbmqzL3WRdVJkvcAUzXiXCwuqfIEboO5elxcL MX+ZDDD4cdnK+XoZp3DEQgg45w1ut1N2IvlFV76hR9gRhzln6mCYPXLwEmLdxwQASF24 Sviy3IkeB1e/ZnClzJa50leuqGIxyph7ypaegrDrWB4c774L6LMtgwCdVQ1XOen7YZYg Tmc2SmjFqpgu6bz5+r4zvnBqE1G6xS24HAUzxEhd08Jvnc9X4VjiiQxFdbZ1mqr3dkiZ 0kSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dvfra+igSzSuvrm6V06PRqF/WftPoFimXSrNOIQ/mMI=; b=HdVzAj6i/y59rhbT9SE1PCPKHhgHOMEPtzl/B0liuzudvMeRGWCIrTLbplKa6DWvSK S4AFuxgSxQu7qfVuWuAO+IrLrZWACj6f2sS9tumEw5Bk4JGneY/gUkcxuB7WvAJ0O3Jv G8DVmFxnMklAd8EwXdCiDbN8AC6GsEyWFTlk/Q6c2s8J/EvA+PXXkXfxjGhoaEWnWFy5 BRX+/5CXnzR6Xyl+7Ysl4VE9T/TA1ANO+dOentQ81LYadvum3T5MOLLWS/nVKjWv4WOz eppzjYE630NTfmSlNQlkqQBAC74x2Lz7rByEn+a1ffjdk9PF9/QvSNJvMJMWRby1Q4pw 2VyQ==
X-Gm-Message-State: ABuFfohPvm95PYiGewM0vFwCKOh9HVkroyP7ph4h7POvjjdHwcBDK+RC wDW1lnH2FDRkBDtfdUdKURxZXT24u4LCeihGr0/cPQ==
X-Google-Smtp-Source: ACcGV62GHxQKML0JmQeqhmASSrq5ddTeWkpJxhxvFHYsQfdV5Dgg/ai+sdrxbE0D1wp7hOjLFfAQiFbs3YYd/eju3pU=
X-Received: by 2002:a63:f409:: with SMTP id g9-v6mr11390277pgi.369.1538489318070; Tue, 02 Oct 2018 07:08:38 -0700 (PDT)
MIME-Version: 1.0
References: <1231917830.3727154.1535119783361.JavaMail.zimbra@enst.fr> <20180827163405.GA19628@LK-Perkele-VII> <235113009.594519.1535390674699.JavaMail.zimbra@enst.fr> <6170599.o3dyPvx8Gh@pintsize.usersys.redhat.com> <1379020500.16565707.1537977448089.JavaMail.zimbra@enst.fr> <20180926192916.GA31766@LK-Perkele-VII>
In-Reply-To: <20180926192916.GA31766@LK-Perkele-VII>
From: William Whyte <wwhyte@onboardsecurity.com>
Date: Tue, 02 Oct 2018 10:08:26 -0400
Message-ID: <CAND9ES0XiBOhhKc5xT7wUCj5EQq2dq4q0O85zKivfF_dXGh+5Q@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: Mounira Msahli <mounira.msahli@telecom-paristech.fr>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004b74e905773f75b6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/tno0AkYlr2P6poCqfywLf_twx7s>
Subject: Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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, 02 Oct 2018 14:08:45 -0000
Hi Ilari, >> - The construction looks like it mixes different kinds of structures: 1609.2 Data of type signed versus TLS 1.3 signature. I do not think this is cryptographically kosher. In fact, I think the call for "extreme care" for certain kinds of modifications from TLS 1.3 specification appiles here. >> That is, with 1609.2 what is passed to actual raw signature is not TLS 1.3 signature structure, nor something compatible with it (the invariant part with dedicated context is only up to and including the zero separator). However, I do not think that changing the context and then hacking what comes afterwards (altough it seems cryptographically kosher) is a good idea for implemntation reasons. You're right, it uses the 1609.2 data structure. The rationale is as follows: Software: Most 1609.2 libraries offer only a high-level API for signing and verification, where: On signing: the input is the data, a handle for the key, and a set of options, and the output is a 1609.2 signed data. On verification: the input is the Ieee1609Dot2Data output by signing, the certificate, and some options, and the output is either “valid” or an error code. As such, using a 1609Dot2Data in the Signature field doesn’t require any software changes to 1609.2 libraries. It does require an additional change to the TLS library, which is to check if a 1609.2 certificate is being used and if so to send the Signature field to a 1609.2 verification engine rather than a “raw” ECDSA verification engine, but the TLS library is being changed anyway and this approach allows the changes to be confined to a single codebase. Philosophy: 1609.2 certificates are by intent more tightly coupled to the signing mechanism than X.509 certificates. 1609.2 specifies consistency between a certificate and the PDU that it signs in terms of validity period, (optionally) geographic location, and application permissions (PSID and SSP), and it would be unfortunate to create a setting in which they can be less tightly coupled. In particular, since a certificate can contain more than one PSID, it’s useful to state the PSID which the certificate holder is intending to assert in a given context. The most natural way to do this is to use an IEEE1609Dot2Data. A rationale for continuing to use the raw signature field would be to make the change to TLS as minimal as possible. This is a reasonable rationale, but we would argue that allowing the signature format to depend on the certificate type does not break the TLS model as much as allowing a different entry point to 1609.2 cryptographic processing breaks the 1609.2 model. Since one or the other has to be changed, and since the TLS implementation is being changed already, we prefer to keep the changes to the TLS. If it would help, we could add this rationale to the Security Considerations section. >> - Bleh: Hardcoding SHA-256 in place that requires a strong hash. One more place to mind if SHA-256 someday breaks. The hash looks extraneous too, as what needs to be signed is not long. 1609.2 currently only supports SHA-256 for message hashing -- it's extensible, in that it has a hash algorithm identifier that can in principle be extended with additional identifier values, but currently only SHA-256 is defined for message hashing. The hardcoding of SHA-256 in this draft should be read as informative text about a constraint that exists anyway in 1609.2. If 1609.2 is extended to support additional hash algorithms we'll circle back and change this part of this draft. >> - Changing CV format with certificate format could create problems with existing TLS implmentations, as there is no precendent for such change. In fact, there even isn't an extension that changes that (and such extension would require very careful analysis). I accept that this is a valid concern in general and complicates the TLS signing/verification logic. As described above, we reluctantly decided that this was a preferable approach to using raw signatures with 1609.2 certificates, because when you're using 1609.2 certificates it's because you want the tighter binding to owner permissions that you get from 1609.2 and as such it's important to use 1609.2 certificates accompanied by the 1609.2 signed data structure. I don't think this is a direct security concern, but I acknowledge that the additional complexity in TLS implementations is regrettable. >> And what about TLS 1.2, which does not use CV for server side, and has different format CV for client side? I'll be honest, when I drafted this part of the document I was thinking only about TLS 1.3. I don't have a strong feeling that 1609.2 certificates should be usable in TLS 1.2. We'd be happy to take guidance about how this could be integrated into TLS 1.2. Note re the comment about existing implementations above that if you're focusing on TLS 1.3, then there are fewer and less well-established existing implementations than there are with TLS 1.2, so I think the existing implementations concern is also diminished. >> - Nasty hack for psid that would not be crypographically questionable would be to throw it inside first certificate entry (just leave the overall entry length as 3 bytes to avoid trouble with certificate message parsing). Agreed, but also agreed that it's a hack :-) >> - The timestamp looks very questionable. What is it for? What if the generating clock is wrong (clocks are wrong depressingly often)? It seems that TLS exchanges are occuring "now" from viewpoint of the endpoints. Again, this is a constraint of using the full 1609.2 processing: the 1609.2 verification process requires that a generation time is available so that the verifier can check that the generation happened during the validity period of the certificate. Historically, this requirement came in because 1609.2 is in general used to authenticate broadcast messages, and so the generation time is the only way to guarantee freshness. In the TLS setting, freshness is guaranteed by the live protocol, so this doesn't add value, but 1609.2 libraries aren't configurable to turn this check off and including the generation time isn't a lot of overhead. The draft doesn't propose that the TLS handshake process makes any use of the generation time other than the use (which isn't explicitly stated but is implicit in the use of 1609.2 verification) to ensure the handshake was valid when generated; in other words, there's no stated requirement for consistency between the client and server clocks, the requirement is for consistency between the signer's clock and its use of its own certificate. Does this make the proposal seem more palatable? Cheers, William On Wed, Sep 26, 2018 at 3:29 PM Ilari Liusvaara <ilariliusvaara@welho.com> wrote: > On Wed, Sep 26, 2018 at 05:57:28PM +0200, Mounira Msahli wrote: > > Hi all, > > > > Please find attached a new version of the draft. We took account of > > pevious TLS group comments. William, editor of 1609.2, proposes to > > add the section certificate verify (section 4.3 in the draft). > > It concerns the addition of IEEE 1609.2 signature for the the > > ertificate verify. > > I took a brief look. The CertificateVerify changes look suspect: > > - The construction looks like it mixes different kinds of structures: > 1609.2 Data of type signed versus TLS 1.3 signature. I do not think > this is cryptographically kosher. In fact, I think the call for > "extreme care" for certain kinds of modifications from TLS 1.3 > specification appiles here. > > That is, with 1609.2 what is passed to actual raw signature is not > TLS 1.3 signature structure, nor something compatible with it > (the invariant part with dedicated context is only up to and > including the zero separator). However, I do not think that > changing the context and then hacking what comes afterwards > (altough it seems cryptographically kosher) is a good idea for > implemntation reasons. > > - Bleh: Hardcoding SHA-256 in place that requires a strong hash. One > more place to mind if SHA-256 someday breaks. The hash looks > extraneous too, as what needs to be signed is not long. > > - Changing CV format with certificate format could create problems with > existing TLS implmentations, as there is no precendent for such > change. In fact, there even isn't an extension that changes that > (and such extension would require very careful analysis). And > what about TLS 1.2, which does not use CV for server side, and has > different format CV for client side? > > - Nasty hack for psid that would not be crypographically questionable > would be to throw it inside first certificate entry (just leave > the overall entry length as 3 bytes to avoid trouble with certificate > message parsing). > > - The timestamp looks very questionable. What is it for? What if the > generating clock is wrong (clocks are wrong depressingly often)? It > seems that TLS exchanges are occuring "now" from viewpoint of the > endpoints. > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: wwhyte@onboardsecurity.com
- [TLS] TLS 1.3 Authentication using ETSI TS 103 09… Mounira Msahli
- Re: [TLS] TLS 1.3 Authentication using ETSI TS 10… William Whyte
- Re: [TLS] TLS 1.3 Authentication using ETSI TS 10… Ilari Liusvaara
- Re: [TLS] TLS 1.3 Authentication using ETSI TS 10… Mounira Msahli
- Re: [TLS] TLS 1.3 Authentication using ETSI TS 10… Mounira Msahli
- Re: [TLS] TLS 1.3 Authentication using ETSI TS 10… Wang Haiguang
- Re: [TLS] TLS 1.3 Authentication using ETSI TS 10… Mounira Msahli
- Re: [TLS] TLS 1.3 Authentication using ETSI TS 10… Wang Haiguang
- Re: [TLS] TLS 1.3 Authentication using ETSI TS 10… William Whyte
- Re: [TLS] TLS 1.3 Authentication using ETSI TS 10… Hubert Kario
- Re: [TLS] TLS 1.3 Authentication using ETSI TS 10… Mounira Msahli
- Re: [TLS] TLS 1.3 Authentication using ETSI TS 10… Ilari Liusvaara
- Re: [TLS] TLS 1.3 Authentication using ETSI TS 10… Watson Ladd
- Re: [TLS] TLS 1.3 Authentication using ETSI TS 10… Mounira Msahli
- Re: [TLS] TLS 1.3 Authentication using ETSI TS 10… Mounira Msahli
- Re: [TLS] TLS 1.3 Authentication using ETSI TS 10… Hubert Kario
- Re: [TLS] TLS 1.3 Authentication using ETSI TS 10… Mounira Msahli
- Re: [TLS] TLS 1.3 Authentication using ETSI TS 10… Mounira Msahli
- Re: [TLS] TLS 1.3 Authentication using ETSI TS 10… Ilari Liusvaara
- Re: [TLS] TLS 1.3 Authentication using ETSI TS 10… Russ Housley
- Re: [TLS] TLS 1.3 Authentication using ETSI TS 10… William Whyte
- Re: [TLS] TLS 1.3 Authentication using ETSI TS 10… Mounira Msahli
- [TLS] Updating the draft: TLS Authentication usin… Mounira Msahli
- [TLS] Updating the draft: TLS Authentication usin… Mounira Msahli