Re: [TLS] TLS 1.3 draft-07 sneak peek
Eric Rescorla <ekr@rtfm.com> Tue, 07 July 2015 16:05 UTC
Return-Path: <ekr@rtfm.com>
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 63E0B1A8A04 for <tls@ietfa.amsl.com>; Tue, 7 Jul 2015 09:05:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 mFjEXP-5lH8N for <tls@ietfa.amsl.com>; Tue, 7 Jul 2015 09:05:27 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (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 E5E8D1ACD52 for <tls@ietf.org>; Tue, 7 Jul 2015 09:05:26 -0700 (PDT)
Received: by wgjx7 with SMTP id x7so172160504wgj.2 for <tls@ietf.org>; Tue, 07 Jul 2015 09:05:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=K635PNo4TEQQE4oiPOe/IUC9ZiEjoTBda1VLeK4/8vo=; b=IHTNTL2wr7XBuL/2Wcz5i0wuilm6PjtP9U4poHZZ7QA567Hr82qgNOZCZKDYUcnqiY lFfvlMj/qPrkr/HkPVh9qkF3JyrUAhMuanu3T3+nPjnP/I2tBr2i/XI5XMh1AYx3b4uv RQ6kNyQbTBe4qq8XAKC1SdU1rupBXzAiciVHiHdmakdamjV/YEj4szBOKXic8HiIVt2x KWC4QSS6lSDj4vqvPTq1OEEkBjELD8EyBrvRyBkKXTzQdkoNL0Asysv8QnD1uoJZ7MsY 2rLt5Gn5kRfVT90hUK/paVoWs/dzas/ive+xcKMIrJAat/F3QVl3bqDF7creqpsXtq4a dHLg==
X-Gm-Message-State: ALoCoQlFmYsCrhzhZ2TQA1S2gtmVj84MKchcoSKEQBYjxvFStwaotUw3AP6UJTRdzP0kJeY5YBqg
X-Received: by 10.194.133.73 with SMTP id pa9mr9760316wjb.148.1436285125595; Tue, 07 Jul 2015 09:05:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.95.211 with HTTP; Tue, 7 Jul 2015 09:04:45 -0700 (PDT)
In-Reply-To: <BN1PR09MB124B3CB18E6E4B8ABE24739F3920@BN1PR09MB124.namprd09.prod.outlook.com>
References: <CABcZeBOWK_WnHAefsZUBr4UyEkyiZqi1mhoZH8ZeGFftdOqTTw@mail.gmail.com> <BN1PR09MB124B3CB18E6E4B8ABE24739F3920@BN1PR09MB124.namprd09.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 07 Jul 2015 09:04:45 -0700
Message-ID: <CABcZeBPWisn8n0gFGVZLRtemUKu67ZF0806kDGBPYcFqJ6ybjg@mail.gmail.com>
To: "Dang, Quynh" <quynh.dang@nist.gov>
Content-Type: multipart/alternative; boundary="089e011771a9b52c8f051a4b30ee"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/rJ8hP-uX-LthPj15n49kLlXCCjE>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek
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: <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, 07 Jul 2015 16:05:30 -0000
On Tue, Jul 7, 2015 at 7:04 AM, Dang, Quynh <quynh.dang@nist.gov> wrote: > > Hi Eric, > > Since the key derivation method is the HKDF method, I think the current > PRF (in TLS 1.2) should be removed/changed. The key-expansion step in the > HKDF should be used to generate keying materials. > Yes, that's how it's supposed to look. If I missed some PRF instances, please point them out. For resumptions, will you re-run the resumption master secrets through the > extraction step again or just run them through the key expansion step? I > don't think the extraction step is necessary here. > Since we're trying to model resumption as PSK, I want to run the entire key schedule for consistency. -Ekr > Quynh. > > ------------------------------ > *From:* TLS <tls-bounces@ietf.org> on behalf of Eric Rescorla < > ekr@rtfm.com> > *Sent:* Tuesday, June 30, 2015 6:23 PM > *To:* tls@ietf.org > *Subject:* [TLS] TLS 1.3 draft-07 sneak peek > > Folks, > > Yesterday, I posted the -06 draft which snapshots the consensus changes > made since -05, specifically: > > - Prohibit RC4 negotiation for backwards compatibility. > - Freeze & deprecate record layer version field. > - Update format of signatures with context. > - Remove explicit IV. > > > In the background, I've also been working with Hugo, Hoeteck, Karthik, > and others to develop a new draft using semi-ephemeral DH based on > Hugo's ideas as discussed in Dallas. I'm planning to merge this into > master soon and submit it as draft-07 next week, but I wanted to > e-mail the list and give people a chance to comment before I do > that. I've provided a summary of the major changes and open issues > below. Remember, this is a WIP so if you see something wrong, don't > panic, but do let me know. > > > CHANGES > 1. Move ClientKeyShare into an extension so that the ClientHello > is the only message in the client's first flight. This removes > a bunch of ugliness around the "early_data" extension which > could encapsulate handshake and application data. > > 2. Added a mechanism for the server to indicate a known (EC)DHE > key/configuration which the client can then use in subsequent > handshakes (via the known_configuration extension). The net > effect here is that the client and server can skip over the > signature in subsequent handshakes, which provides benefit > when signatures are much slower than key exchange, as with > RSA; it also enables 0-RTT. > > 3. Added support for 0-RTT data, both with and without > client authentication. > > 4. Removed most of the support for resumption in favor of > a mechanism proposed by Karthik where you just establish > a PSK in connection N which you then use to key a PSK > cipher suite in connection N+1. > > All of these keying mechanisms use a unified key schedule based on two > keys the "Ephemeral Secret" (ES) and the "Static Secret" > (SS). Depending on the exact handshake type, these may be equal, but > the logic is the same regardless. In the process, I also converted > the key schedule to use HKDF (per WG consensus). > > > OPEN ISSUES > There are still a number of known open issues to discuss: > > 1. The present known_configuration mechanism allows the client to > resurrect the handshake parameters (though not the keys) which were > negotiated in a previous handshake, but this is done implicitly, > i.e., the server provides a label and the client returns it on > the next connection. This has the advantage of keeping things short > but the disadvantage the it means that you can't have a static > configuration ID for everyone (instead, the server has to somehow > embed the properties in the configuration ID). There are (at least) > three potential alternative designs: > > (a) Have the client indicate in his first flight "these are the > parameters I expect you to negotiate", along with the > configuration identifier, based on what the server > negotiated the previous time. [Optionally, the server > can run the same negotiation locally and abort on mismatch.] > > (b) As in (a) but with no indication of the expected parameters, > just the configuration ID, and the client just preemptively > uses the parameters from the last time and if the negotiation > ends up differently, all the data is undecryptable > (ugh) and you somehow fall back. > > (c) Have the server provide a preference list in his > ServerConfiguration (this can be the same as in the > ClientHello) and have the client do the negotiation based on > that rather than the server (as in QUIC). This is a little odd > in that it means that sometimes the server selects the > parameters and sometimes the client does, but it's not that > hard to make this code symmetrical. > > As I think this through, I am leaning towards (a) but other people's > opinions on this topic would be welcome. > > > 2. Should we require that PSK cipher suites where the PSK is used for > resumption use compatible ciphers? This is the way it was in TLS 1.2 > and below for resumption and tickets, but once you have a PSK, that's > not really necessary [0]. So, for instance, if you had the following > cipher list order: > > ECDHE + AES-GCM > ECDHE + ChaCha/Poly > PSK + ChaCha/Poly > PSK + AES-GCM > > You could potentially negotiate one connection with GCM, use it > to establish a shared key, and then reconnect with ChaCha/Poly. > This seems like it probably should be something we avoid, though > I'm not sure we have a concrete reason why, and it means a > weird special case for PSK. Note that this issue might be > ameliorated some (though not completely) with a la carte negotiation. > > > 3. I don't currently have PSK/Resumption + 0-RTT working, because you > need a way to indicate the expected parameters (see point #1 above). > > > 4. I plan to rewrite the Handshake Protocol Overview (S 6.2) > to be clearer. I hope to do this before submitting -07. > > 5. Security Considerations is badly out of date, so I plan to > rewrite that soon, but probably not before Prague. I also intend > to do a pretty substantial editorial cleanup pass and potentially > some restructuring after Prague. > > > As indicated above, this is still a WIP, so no doubt contains > a number of errors, potentially serious ones. Comments and PRs > welcome. > > Thanks, > -Ekr > > > [0] With the exception of cryptographic concerns about the use > of the same IKM with different hash functions for HKDF, but this > is a problem that applies to any use of PSK, not just this one. > >
- [TLS] TLS 1.3 draft-07 sneak peek Eric Rescorla
- Re: [TLS] TLS 1.3 draft-07 sneak peek Eric Rescorla
- Re: [TLS] TLS 1.3 draft-07 sneak peek Dave Garrett
- Re: [TLS] TLS 1.3 draft-07 sneak peek Eric Rescorla
- Re: [TLS] TLS 1.3 draft-07 sneak peek Ilari Liusvaara
- Re: [TLS] TLS 1.3 draft-07 sneak peek Ilari Liusvaara
- Re: [TLS] TLS 1.3 draft-07 sneak peek Eric Rescorla
- Re: [TLS] TLS 1.3 draft-07 sneak peek Ilari Liusvaara
- Re: [TLS] TLS 1.3 draft-07 sneak peek Hanno Böck
- Re: [TLS] TLS 1.3 draft-07 sneak peek Eric Rescorla
- Re: [TLS] TLS 1.3 draft-07 sneak peek Dave Garrett
- Re: [TLS] TLS 1.3 draft-07 sneak peek Hubert Kario
- Re: [TLS] TLS 1.3 draft-07 sneak peek Eric Rescorla
- Re: [TLS] TLS 1.3 draft-07 sneak peek Dave Garrett
- Re: [TLS] TLS 1.3 draft-07 sneak peek Hubert Kario
- Re: [TLS] TLS 1.3 draft-07 sneak peek Hubert Kario
- Re: [TLS] TLS 1.3 draft-07 sneak peek Dave Garrett
- Re: [TLS] TLS 1.3 draft-07 sneak peek Martin Rex
- Re: [TLS] TLS 1.3 draft-07 sneak peek Martin Thomson
- Re: [TLS] TLS 1.3 draft-07 sneak peek Hubert Kario
- Re: [TLS] TLS 1.3 draft-07 sneak peek Dave Garrett
- Re: [TLS] TLS 1.3 draft-07 sneak peek Eric Rescorla
- Re: [TLS] TLS 1.3 draft-07 sneak peek Dave Garrett
- Re: [TLS] TLS 1.3 draft-07 sneak peek Martin Rex
- Re: [TLS] TLS 1.3 draft-07 sneak peek Quynh Dang
- Re: [TLS] TLS 1.3 draft-07 sneak peek Martin Rex
- Re: [TLS] TLS 1.3 draft-07 sneak peek Martin Rex
- Re: [TLS] TLS 1.3 draft-07 sneak peek Watson Ladd
- Re: [TLS] TLS 1.3 draft-07 sneak peek Dang, Quynh
- Re: [TLS] TLS 1.3 draft-07 sneak peek Quynh Dang
- [TLS] MTI Extensions (was Re: TLS 1.3 draft-07 sn… Dave Garrett
- Re: [TLS] TLS 1.3 draft-07 sneak peek William Whyte
- Re: [TLS] TLS 1.3 draft-07 sneak peek Dang, Quynh
- Re: [TLS] TLS 1.3 draft-07 sneak peek Hanno Böck
- Re: [TLS] TLS 1.3 draft-07 sneak peek Jeffrey Walton
- Re: [TLS] TLS 1.3 draft-07 sneak peek Peter Gutmann
- Re: [TLS] TLS 1.3 draft-07 sneak peek Dang, Quynh
- Re: [TLS] TLS 1.3 draft-07 sneak peek Martin Rex
- Re: [TLS] TLS 1.3 draft-07 sneak peek Martin Rex
- Re: [TLS] TLS 1.3 draft-07 sneak peek Ilari Liusvaara
- Re: [TLS] TLS 1.3 draft-07 sneak peek Karthikeyan Bhargavan
- Re: [TLS] TLS 1.3 draft-07 sneak peek Dave Garrett
- Re: [TLS] TLS 1.3 draft-07 sneak peek Salz, Rich
- [TLS] Deprecate SHA1 for signatures in TLS 1.3 (w… Dave Garrett
- Re: [TLS] TLS 1.3 draft-07 sneak peek Eric Rescorla
- Re: [TLS] TLS 1.3 draft-07 sneak peek Dave Garrett
- Re: [TLS] TLS 1.3 draft-07 sneak peek Eric Rescorla
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Eric Rescorla
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Salz, Rich
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Karthikeyan Bhargavan
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Ilari Liusvaara
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Eric Rescorla
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Thomson
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Salz, Rich
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Thomson
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Salz, Rich
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Thomson
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] TLS 1.3 draft-07 sneak peek Hubert Kario
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Yoav Nir
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Andrei Popov
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Hubert Kario
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] TLS 1.3 draft-07 sneak peek Jeffrey Walton
- Re: [TLS] TLS 1.3 draft-07 sneak peek Jeffrey Walton
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Yoav Nir
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Hubert Kario
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Henrik Grubbström
- Re: [TLS] TLS 1.3 draft-07 sneak peek Salz, Rich
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Watson Ladd
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Andrei Popov
- [TLS] Explicit error expectations (was Re: Deprec… Dave Garrett
- Re: [TLS] Explicit error expectations (was Re: De… Viktor Dukhovni
- Re: [TLS] Explicit error expectations (was Re: De… Dave Garrett
- Re: [TLS] Explicit error expectations (was Re: De… Ilari Liusvaara
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Eric Rescorla
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Ilari Liusvaara
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Eric Rescorla
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Eric Rescorla
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Ilari Liusvaara
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Eric Rescorla
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Eric Rescorla
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Andrei Popov
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Henrik Grubbström
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Ilari Liusvaara
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Eric Rescorla
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Andrei Popov
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Andrei Popov
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Andrei Popov
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- [TLS] DANE & TLS 1.3 (was Re: Deprecate SHA1 for … Dave Garrett
- Re: [TLS] DANE & TLS 1.3 (was Re: Deprecate SHA1 … Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Hubert Kario
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Andrei Popov
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Thomson
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Andrei Popov
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Thomson
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni