Re: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt)

On Tue, Jul 10, 2018 at 11:46 AM Peter Gutmann wrote: > Hubert Kario writes: > > >but randoms in TLS 1.0 and TLS 1.1 are signed (effectively) with SHA-1... > > but with EMS or LTS in effect, with a lot more than that. > EMS does not fix the ServerKeyExchange signature payload. It's still j

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

On Mon, Jul 9, 2018 at 12:58 PM Eric Rescorla wrote: > On Mon, Jul 9, 2018 at 9:54 AM, Eric Rescorla wrote: > >> Thanks for writing this. >> >> I would be in favor of deprecating old versions of TLS prior to 1.2. >> Firefox Telemetry shows that about 1% of our connections are TLS 1.1 >> > > This

Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3

ave worked on the formal verification directly. > > > > > > > > If I can attempt to summarize some discussion that occurred in > > > the > > > > mic > > > > line today, Hannes was surprised that we would care, likening > > > this > > >

Re: [TLS] WG adoption call: draft-rescorla-tls-esni

I too support adoption and am happy to review it. On Tue, Jul 24, 2018 at 10:19 PM David Schinazi wrote: > I support adoption, and I'm happy to review it. > > David > > > On Jul 24, 2018, at 19:16, Joseph Salowey wrote: > > > The sense of the TLS@IETF102 room was the the WG should adopt > https

Re: [TLS] WG adoption call: draft-moriarty-tls-oldversions-diediedie

I support adoption. On Fri, Aug 17, 2018 at 1:07 PM Benjamin Beurdouche < benjamin.beurdou...@inria.fr> wrote: > I support adoption > > > On Aug 17, 2018, at 10:32 AM, Sean Turner wrote: > > > > At the TLS@IETF102 session, there seemed to be some interest in > adopting draft-moriarty-tls-oldvers

Re: [TLS] null auth ciphers for TLS 1.3?

On Tue, Aug 21, 2018 at 1:34 PM Viktor Dukhovni wrote: > > > > On Aug 21, 2018, at 2:18 PM, Eric Rescorla wrote: > > > >> As for TLS 1.3, it is indeed missing both null encryption and null > >> authentication ciphers. > > > > If by "null authentication" you mean "without certificates", then TLS

Re: [TLS] Another ClientHello length intolerance bug?

Wow! That's a bizarre one. I don't think we've run into this one before, but, from your description, any given implementation would only have a 1/256 chance of hitting it on every ClientHello change. 10 is a newline, so perhaps some implementation is doing a terrible job detecting TLS vs. some pla

Re: [TLS] I-D Action: draft-housley-tls-tls13-cert-with-extern-psk-02.txt

The resumption flow in this draft looks odd to me. While the handshake flow is the same, the use cases differ between which identity should be in play and when to use it. Separate extensions and documents may be better. (I suppose saying the semantics change completely between resumption and extern

[TLS] TLS 1.3 updates from Chrome

Dear all, The upcoming release of Google Chrome 70 is expected to enable the final version of TLS 1.3. As the release has progressed through our early release channels, we have learned about some deployment issues we would like to share with the community. First, we are aware of some intolerance

Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)

On Wed, Nov 7, 2018 at 1:12 AM Viktor Dukhovni wrote: > [ Quoted text slightly reordered to put the RSA issue first, as that's > the main thing I'm trying to get clarity on, and enabling keyUsage > enforcement is causing some interoperability issues now... ] > > > On Nov 5, 2018, at 11:11 PM,

Re: [TLS] regd. signature algorithm 0x0804 (rsa_pss_rsae_sha256) use in TLSv1.2 CertificateVerify

Yes, this is correct. On Tue, Nov 20, 2018 at 10:35 AM M K Saravanan wrote: > Hi, > > RFC8446: > = > 4.2.3. Signature Algorithms > > [...] > - Implementations that advertise support for RSASSA-PSS (which is > mandatory in TLS 1.3) MUST be p

Re: [TLS] Empty CertificateRequest.supported_signature_algorithms in TLS 1.2

On Wed, Nov 21, 2018 at 3:50 PM Martin Thomson wrote: > In attempting to fix a bug related to this, a question came up about > what the semantics of an empty value is here. Some implementations > seem to infer that empty means {*,SHA1}, which effectively assumes > that an empty value is equivale

[TLS] Further TLS 1.3 deployment updates

Hi folks, We have one more update for you all on TLS 1.3 deployment issues. Over the course of deploying TLS 1.3 to Google servers, we found that JDK 11 unfortunately implemented TLS 1.3 incorrectly. On resumption, it fails to send the SNI extension. This means that the first connection from a JDK

Re: [TLS] Further TLS 1.3 deployment updates

On Thu, Dec 13, 2018 at 10:54 AM Hubert Kario wrote: > On Wednesday, 12 December 2018 23:21:43 CET David Benjamin wrote: > > Hi folks, > > > > We have one more update for you all on TLS 1.3 deployment issues. Over > the > > course of deploying TLS 1.3 to Google

[TLS] ESNI robustness and GREASE PRs

Hi folks, We[*] wrote up some proposed changes for draft-ietf-tls-esni that we'd like the group's thoughts on. The goal is to make ESNI more robust and eliminate a bunch of deployment risks. The PRs are linked below: https://github.com/tlswg/draft-ietf-tls-esni/pull/124 https://github.com/tlswg/d

Re: [TLS] ESNI robustness and GREASE PRs - client tracking concerns?

that is more complex, so the simple solution seemed a better starting point. Does that address the concern, or have I missed something? David On Mon, Dec 17, 2018 at 10:45 PM David Fifield wrote: > On Mon, Dec 17, 2018 at 05:17:37PM -0600, David Benjamin wrote: > > We[*] wrote up so

Re: [TLS] ESNI robustness and GREASE PRs

On Tue, Dec 18, 2018 at 3:00 AM Ilari Liusvaara wrote: > On Mon, Dec 17, 2018 at 05:17:37PM -0600, David Benjamin wrote: > > Hi folks, > > > > We[*] wrote up some proposed changes for draft-ietf-tls-esni that we'd > like > > the group's thoughts on.

Re: [TLS] ESNI robustness and GREASE PRs - client tracking concerns?

On Tue, Dec 18, 2018 at 1:27 AM Viktor Dukhovni wrote: > On Tue, Dec 18, 2018 at 12:45:22AM -0600, David Benjamin wrote: > > > An earlier iteration even placed the retry on the same connection, which > > makes the analog clearer. (Doing it in the same connection is rather

Re: [TLS] ESNI robustness and GREASE PRs

On Tue, Dec 18, 2018 at 3:06 PM Ilari Liusvaara wrote: > On Tue, Dec 18, 2018 at 02:27:10PM -0600, David Benjamin wrote: > > On Tue, Dec 18, 2018 at 3:00 AM Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > > > On Mon, Dec 17, 2018 at

Re: [TLS] ESNI robustness and GREASE PRs

(Hit send too early) On Tue, Dec 18, 2018 at 3:32 PM David Benjamin wrote: > On Tue, Dec 18, 2018 at 3:06 PM Ilari Liusvaara > wrote: > >> On Tue, Dec 18, 2018 at 02:27:10PM -0600, David Benjamin wrote: >> > On Tue, Dec 18, 2018 at 3:00 AM Ilari Liusvaara <

Re: [TLS] I-D Action: draft-ietf-tls-grease-02.txt

On Thu, Jan 17, 2019 at 11:05 AM Hubert Kario wrote: > On Wednesday, 16 January 2019 21:25:26 CET internet-dra...@ietf.org wrote: > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-tls-grease-02 > > while record_size_limit extension sends just one value,

Re: [TLS] I-D Action: draft-ietf-tls-grease-02.txt

On Thu, Jan 17, 2019 at 2:31 PM Hubert Kario wrote: > On Thursday, 17 January 2019 21:23:37 CET David Benjamin wrote: > > On Thu, Jan 17, 2019 at 11:05 AM Hubert Kario wrote: > > > On Wednesday, 16 January 2019 21:25:26 CET internet-dra...@ietf.org > wrote: > >

Re: [TLS] I-D Action: draft-ietf-tls-grease-02.txt

On Thu, Jan 24, 2019 at 5:03 PM Martin Thomson wrote: > On Fri, Jan 18, 2019, at 07:23, David Benjamin wrote: > > > while record_size_limit extension sends just one value, it does > > > specifically > > > allow the client to advertise higher values t

Re: [TLS] ticket lifetimes

This two-lifetime thing is actually already what we implement in BoringSSL. :-) We track both a lifetime for the ticket (one day) and also for the original authentication the ticket roots up to (one week). The lifetime of the ticket is bounded by both these values, and the latter is not extendable

Re: [TLS] ticket lifetimes

t is willing to make vulnerable to a single session secret. We'd probably do something similar if we implemented TLS 1.3's plain psk_ke, but we only do psk_dhe_ke.) David > Subodh > -- > *From:* David Benjamin > *Sent:* Tuesday, January 29, 2019

Re: [TLS] ticket lifetimes

nvenience (per spec, ticket age and ticket lifetime are measured from issuance of the particular ticket, not the original auth point). There's also two timeouts on each ticket, as noted, and one of them never renews. Seems like there is room for clarification on the ticket lifetime. >

Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE

Thanks for the comments! Responses inline. On Wed, Feb 13, 2019 at 5:00 PM Stephen Farrell wrote: > > Hiya, > > On 13/02/2019 22:15, Christopher Wood wrote: > > > > > > [1] https://github.com/tlswg/draft-ietf-tls-esni/pull/124 > > I just re-read that. I've a question: why tie the version > chang

Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE

ble ESNI for all origins. > > -Original Message- > From: TLS On Behalf Of Stephen Farrell > Sent: Wednesday, February 13, 2019 4:24 PM > To: David Benjamin > Cc: TLS WG > Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and > GREASE > >

Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE

On Wed, Feb 13, 2019 at 7:37 PM Roelof DuToit wrote: > Questions for PR [1]: > > * Regarding this text: > The client MUST NOT use the server-provided retry keys until the handshake > completes successfully. On success, it MUST NOT overwrite the DNS-provided > keys with the retry keys. It MUST use

Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE

On Wed, Feb 13, 2019 at 6:24 PM Stephen Farrell wrote: > On 13/02/2019 23:55, David Benjamin wrote: > > On Wed, Feb 13, 2019 at 5:00 PM Stephen Farrell < > stephen.farr...@cs.tcd.ie> > > wrote: > > That text isn't prescribing any particular behavior. &

Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE

On Thu, Feb 14, 2019 at 1:46 PM Roelof DuToit wrote: > > > > On Thu, 14 Feb 2019 13:00:16 -0500 *David Benjamin > >* wrote > > On Wed, Feb 13, 2019 at 7:37 PM Roelof DuToit wrote: > >> >> Questions for PR [1]: >> >> * Regarding this t

Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE

On Thu, Feb 14, 2019 at 2:25 PM Roelof DuToit wrote: > On Thu, 14 Feb 2019 15:13:11 -0500 *David Benjamin > >* wrote > > On Thu, Feb 14, 2019 at 1:46 PM Roelof DuToit wrote: > >> On Thu, 14 Feb 2019 13:00:16 -0500 *David Benjamin >> >* wrote ---

Re: [TLS] Negotiated Finite Field Diffie-Hellman shared secret calculation

(We haven't actually implemented RFC 7919 and have no plans to, so I'm just going by the document.) RFC 7919 doesn't say anything, so I think the only reasonable interpretation is to continue with the legacy option for TLS 1.2 and below. It's also the only interoperable option given how the docume

Re: [TLS] Negotiated Finite Field Diffie-Hellman shared secret calculation

sn't the > > "The server indicates > the choice of group to the client by sending the group's parameters > as usual in the ServerKeyExchange" > https://tools.ietf.org/html/rfc7919#section-4 > > an evidence that the server supports RFC 7919? > > On

Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-04.txt

On Tue, Mar 26, 2019 at 5:07 PM Sniffen, Brian wrote: > >> WG - I’d like to echo Alessandro request for reviews. If this > outstanding WG item is not resolved before IETF103 we will discuss the > outstanding issue there, and barring any other major issues we are planning > to WGLC the draft aft

Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-04.txt

On Tue, Mar 26, 2019 at 6:21 PM Sniffen, Brian wrote: > Brotli has a dictionary built into the algorithm. I believe that is indeed > being used, as it's a part of Brotli. I think the earlier email was saying > no external certificate-specific dictionary used. > > > Brotli 1.03 and 1.05 each chang

Re: [TLS] A use of flags

Is the concern that servers which never renegotiate and do not send any renegotiation_info are being flagged on ratings systems? That is desired behavior. See the final paragraph of section 4.3 . Those servers should be sending an empty renegotiation

[TLS] draft-ietf-tls-dtls13-31 comments

Hi all, I read through draft-ietf-tls-dtls13-31 and gathered a bunch of comments. I uploaded https://github.com/tlswg/dtls13-spec/pull/85 for the easy bits. The remainder I figured I should send to the list. Hopefully this is a usable format. Apologies for the very late look over it. I haven't had

Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

On Mon, May 6, 2019 at 1:43 PM Viktor Dukhovni wrote: > On Mon, May 06, 2019 at 01:50:42PM -0400, Kathleen Moriarty wrote: > > > Is this better suited for another (short) draft? > > SHA-1 certificates are history now. If we're raising the floor, > it should IMHO be safe to deprecate the MD5 and

Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

> > > which exact piece of popular software actually still does that? > > It ain't curl, it ain't Chrome, it ain't Firefox. > > It definitely was implemented in Chrome and Firefox, which is how this > poor document got onto standards track: > >https://tools.ietf.org/html/rfc7507 > > TLS Fallba

Re: [TLS] AD review of draft-ietf-tls-grease-02

Thanks for the comments! I've addressed them in https://github.com/tlswg/draft-ietf-tls-grease/pull/10. On Wed, Jul 3, 2019 at 1:11 PM Benjamin Kaduk wrote: > Section 1 > >The TLS protocol [RFC8446] includes several points of extensibility, >including the list of cipher suites and the li

Re: [TLS] AD review of draft-ietf-tls-grease-02

Changes in draft-ietf-tls-grease-03. On Mon, Jul 8, 2019 at 6:23 PM David Benjamin wrote: > Thanks for the comments! I've addressed them in > https://github.com/tlswg/draft-ietf-tls-grease/pull/10. > > On Wed, Jul 3, 2019 at 1:11 PM Benjamin Kaduk wrote: > >>

Re: [TLS] ESNI GREASE - answer needed?

I think the GREASE bits still need more work to avoid sticking out[*], but you're right that there's a length leakage. But, rather than 50:50 of 16 bytes and ESNIKeys, I think it's better to pad all three cases up to an ESNIKeys size. Whether this is done via bespoke padding within the ESNI extensi

Re: [TLS] ESNI GREASE - answer needed?

On Mon, Jul 29, 2019 at 8:04 PM Stephen Farrell wrote: > > Hiya, > > On 30/07/2019 00:58, David Benjamin wrote: > > > > [*] I filed https://github.com/tlswg/draft-ietf-tls-esni/issues/177 last > > week with a sketch of an idea. Steven or I should hopefully hav

[TLS] Drafts for batch signing and PKCS#1 v1.5

Hi all, I’ve just uploaded a pair of drafts relating to signatures in TLS 1..3. https://tools.ietf.org/html/draft-davidben-tls13-pkcs1-00 https://tools.ietf.org/html/draft-davidben-tls-batch-signing-00 The first introduces optional legacy codepoints for PKCS#1 v1.5 signatures with client certific

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

I think this underestimates the complexity cost of option 1 to the protocol and implementations. Option 1 means group negotiation includes entire codepoints whose meaning cannot be determined without a parallel extension. This compounds across everything which interacts with named groups, impacting

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

> issue. > > > > Cheers, > > > > Andrei > > > > *From:* TLS *On Behalf Of * David Benjamin > *Sent:* Tuesday, July 30, 2019 11:24 AM > *To:* Watson Ladd > *Cc:* TLS List > *Subject:* Re: [TLS] Options for negotiating hybrid key exchang

Re: [TLS] Drafts for batch signing and PKCS#1 v1.5

n -01. On Mon, Jul 29, 2019 at 8:15 PM David Benjamin wrote: > Hi all, > > I’ve just uploaded a pair of drafts relating to signatures in TLS 1.3. > https://tools.ietf.org/html/draft-davidben-tls13-pkcs1-00 > https://tools.ietf.org/html/draft-davidben-tls-batch-signing-00 >

Re: [TLS] Adoption call for draft-lvelvindron-tls-md5-sha1-deprecate

I'm in favor of adoption. On Wed, Jul 24, 2019 at 11:28 AM Chris Inacio wrote: > Favor of adoption. > > > > On July 24, 2019 at 8:49:22 AM, Christopher Wood (c...@heapingbits.net) > wrote: > > At TLS@IETF105, there was interest in the room to adopt > draft-lvelvindron-tls-md5-sha1-deprecate as a

Re: [TLS] Drafts for batch signing and PKCS#1 v1.5

On Tue, Jul 30, 2019 at 11:59 PM Martin Thomson wrote: > On Wed, Jul 31, 2019, at 13:54, Ben Schwartz wrote: > > The batch signing idea is very cool. I'm not entirely sure I understand > > the intended use case, though. The intro suggests that this motivated > > by DoS defense, but presumably an

Re: [TLS] Drafts for batch signing and PKCS#1 v1.5

On Wed, Jul 31, 2019 at 3:35 AM Ilari Liusvaara wrote: > On Mon, Jul 29, 2019 at 08:15:44PM -0400, David Benjamin wrote: > > Hi all, > > > > I’ve just uploaded a pair of drafts relating to signatures in TLS 1..3. > > https://tools.ietf.org/html/draft-davidb

Re: [TLS] Drafts for batch signing and PKCS#1 v1.5

h could also be interesting > in the context of some of the post-quantum signing algorithms. > > Cheers, > > Thom > > Op di 30 jul. 2019 om 02:16 schreef David Benjamin >: > >> Hi all, >> >> I’ve just uploaded a pair of drafts relating to signatures in

Re: [TLS] Drafts for batch signing and PKCS#1 v1.5

On Wed, Jul 31, 2019 at 8:01 AM Ben Schwartz wrote: > > > On Wed, Jul 31, 2019 at 12:12 AM David Benjamin > wrote: > >> On Tue, Jul 30, 2019 at 11:59 PM Martin Thomson >> wrote: >> >>> On Wed, Jul 31, 2019, at 13:54, Ben Schwartz wrote: >>

Re: [TLS] [Technical Errata Reported] RFC8446 (5483)

There are two scalar multiplications involved. The first, as part of key generation, indeed passes in a known constant to the u value and outputs the byte string that goes into the key share. The second, the ECDH operation itself, passes in the peer key share and results in the shared secret. In th

Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-grease-03: (with COMMENT)

On Tue, Aug 20, 2019 at 1:39 PM Roman Danyliw via Datatracker < nore...@ietf.org> wrote: > -- > COMMENT: > -- > > (1) Per the following: > > Section 3.1 says “Not

Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-grease-03: (with COMMENT)

On Wed, Aug 21, 2019 at 11:18 PM Roman Danyliw wrote: > > > > -Original Message- > > From: Martin Thomson [mailto:m...@lowentropy.net] > > Sent: Wednesday, August 21, 2019 8:02 PM > > To: David Benjamin ; Roman > > Danyliw > > Cc: draft-ietf-tl

Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-grease-03: (with COMMENT)

On Thu, Aug 22, 2019 at 3:48 AM Mirja Kuehlewind wrote: > Thanks! > > > On 21. Aug 2019, at 23:34, David Benjamin 40google@dmarc.ietf.org> wrote: > > > > On Mon, Aug 19, 2019 at 3:51 AM Mirja Kuehlewind > wrote: > > Hi David, > > > > > >

Re: [TLS] TLSv1.2 - Is zero signature allowed in client CertificateVerify message?

The client should just abort the handshake and probably send an alert like internal_error since it cannot usefully proceed. On Tue, Sep 3, 2019 at 11:27 AM M K Saravanan wrote: > Thanks Richard for the reply. Let me rephrase my question: > > If a client encounter any error condition (e.g. does

Re: [TLS] Drafts for batch signing and PKCS#1 v1.5

A quick update: I've uploaded -01 of tls-batch-signing which should address the various comments that have come in thus far. https://tools.ietf.org/html/draft-davidben-tls-batch-signing-01 On Tue, Jul 30, 2019 at 3:09 PM David Benjamin wrote: > Oops. draft-davidben-tls-batch-signing-

Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

I don't think the statement should be included at all. Were these documents more of a WHATWG-style "living standard" model, it might make sense, but IETF documents involve much more deliberation, take longer to update, and are broader in scope. We should be careful about making statements about upp

Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1

I also support adoption and will contribute, unsurprisingly. :-) On Fri, Oct 18, 2019 at 2:46 PM Salz, Rich wrote: > I support adoption, will contribute. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > __

Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1

On Mon, Oct 21, 2019 at 9:42 AM Hubert Kario wrote: > On Friday, 18 October 2019 20:44:03 CEST Christopher Wood wrote: > > This email starts a call for adoption of draft-davidben-tls13-pkcs1-00, > > which can be found here: > > > >https://tools.ietf.org/html/draft-davidben-tls13-pkcs1-00 > >

Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1

On Mon, Oct 21, 2019 at 12:11 PM Richard Barnes wrote: > On Mon, Oct 21, 2019 at 11:44 AM David Benjamin > wrote: > >> On Mon, Oct 21, 2019 at 9:42 AM Hubert Kario wrote: >> >>> On Friday, 18 October 2019 20:44:03 CEST Christopher Wood wrote: >>> >

Re: [TLS] DTLS ChaCha20 header protection

I believe DTLS is wrong. ChaCha20 is little-endian with the counter going first and the nonce afterwards. See also RFC 8439, section 2.3, where the block count is placed before the nonce. https://tools.ietf.org/html/rfc8439#section-2.3 (Well, "wrong". Both are perfectly well-defined, but the DTLS

Re: [TLS] Adoption call for draft-davidben-tls-batch-signing

Deployments whose long-term private key is an ECDSA or EdDSA key stored in memory probably have no particular need for this, no. Such deployments probably see a signature cost comparable to the ECDH cost this document does not amortise. The existing signature algorithms are sufficient and no one's

Re: [TLS] WGLC for draft-ietf-tls-md5-sha1-deprecate

On Fri, Nov 22, 2019 at 8:35 AM Salz, Rich wrote: > >This is the working group last call for the "Deprecating MD5 and > SHA-1 signature hashes in TLS 1.2" draft available > https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/. > Please review the document and send your comments

Re: [TLS] WGLC for draft-ietf-tls-md5-sha1-deprecate

On Sat, Nov 23, 2019 at 8:40 AM Ilari Liusvaara wrote: > On Fri, Nov 22, 2019 at 08:18:47PM +0100, Hubert Kario wrote: > > On Friday, 22 November 2019 03:25:24 CET, David Benjamin wrote: > > > On Fri, Nov 22, 2019 at 8:35 AM Salz, Rich wrote: > > > > > > &g

Re: [TLS] TLS 1.3 supported versions and downgrade protection

On Thu, Dec 5, 2019 at 12:36 PM Benjamin Kaduk wrote: > On Thu, Dec 05, 2019 at 05:30:10PM +, Daniel Van Geest wrote: > > Hi all, > > > > I think there might be ambiguity or an interoperability issue with the > TLS 1.3 ServerHello Random value downgrade protection and some (possibly?) > legit

Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1

On Wed, Dec 11, 2019 at 9:22 AM Ilari Liusvaara wrote: > On Wed, Dec 11, 2019 at 02:21:48PM +0100, Hubert Kario wrote: > > On Saturday, 7 December 2019 11:20:17 CET, Ilari Liusvaara wrote: > > > > > > One test I just tried: > > > > > > - Smartcard capable of raw RSA. > > > - OpenSC PKCS#11 driver

Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1

On Thu, Dec 12, 2019 at 6:51 AM Hubert Kario wrote: > On Wednesday, 11 December 2019 18:06:19 CET, David Benjamin wrote: > > On Wed, Dec 11, 2019 at 9:22 AM Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > >> On Wed, Dec 11, 2019 at 02:21:4

Re: [TLS] I-D Action: draft-ietf-tls-batch-signing-00.txt

On Mon, Jan 13, 2020 at 6:58 PM Jeremy Harris wrote: > On 13/01/2020 17:48, internet-dra...@ietf.org wrote: > > Title : Batch Signing for TLS > > Author : David Benjamin > > Filename: draft-ietf-tls-batch-signing-0

Re: [TLS] TLS 1.2 - is it allowed to strip the leading zero byte(s) in RSA signature in ServerKeyExchange?

The signature is invalid. The client is correct to reject it, and the server is incorrect to produce it. RFC5246 cites PKCS1 (then RFC3447, now RFC8017). Both versions spell out the signing and verifying operations explicitly. The signing operation must produce a fixed-width output and the verific

Re: [TLS] TLS 1.2 - is it allowed to strip the leading zero byte(s) in RSA signature in ServerKeyExchange?

On Wed, Feb 12, 2020 at 11:10 AM Peter Gutmann wrote: > M K Saravanan writes: > > >Is this allowed? i.e. stripping the leading zero of the RSA signature and > >marking the length as 255? It is not clear to me from the RFC5246 > whether > >it is allowed or not. > > It's not allowed according t

Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer

On Mon, Feb 24, 2020 at 4:33 PM Jonathan Hoyland wrote: > Just looking at this again, it might be better to make a slightly > different tweak to the key schedule. > Instead of: > > 0 > | > v > PSK -> HKDF-Extract = Early Secret >

Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer

nger name would tip us into an > extra hash invocation at the last IETF, and concluding that it didn't, > although I'd have to double check that. > Of course. Yeah, I think the more pertinent question is whether "imp r binder" is actually a thing. > Regards, > >

Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer

On Fri, Feb 28, 2020 at 10:58 AM Jonathan Hoyland < jonathan.hoyl...@gmail.com> wrote: > On Fri, 28 Feb 2020 at 04:49, Christopher Wood > wrote: > >> On Thu, Feb 27, 2020, at 1:31 PM, David Benjamin wrote: >> > On Mon, Feb 24, 2020 at 5:58 PM Jonathan Hoyland >

Re: [TLS] consensus call: draft-ietf-tls-ticketrequests

On Wed, Mar 4, 2020 at 11:07 AM Sean Turner wrote: > one more time ... > > All, > > The purpose of this message is to help the chairs judge consensus on the > way forward for draft-ietf-tls-ticketrequests. The issue at hand is whether > the client-initiated ticket request mechanism [0] should be

Re: [TLS] Commentary on the client authentication presentation slides

Sent from the right email this time. (Sorry folks who got it twice. One of these days I'll not mess this up! :-) ) On Tue, Jul 28, 2015 at 6:28 PM David Benjamin wrote: > On Fri, Jul 24, 2015 at 1:02 AM Andrei Popov > wrote: > >> Thanks for the detailed comments, Ilari

Re: [TLS] Commentary on the client authentication presentation slides

On Sat, Aug 1, 2015 at 4:48 AM Ilari Liusvaara wrote: > > On Tue, Jul 28, 2015 at 6:28 PM David Benjamin > wrote: > > > > > Are you intending that this mechanism be enabled by default for HTTP/2 > or > > > would the prohibition against renego still apply? Wi

Re: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-00

On Tue, Aug 4, 2015 at 12:20 PM Salz, Rich wrote: > > Personally, I would rather see the nonce construction follow the form > > defined in the respective TLS version. [DB: Adding back in for context: > "That means including redundant bytes in TLS 1.2 and only getting the full > advantage when we

Re: [TLS] Commentary on the client authentication presentation slides

On Mon, Aug 10, 2015 at 3:05 PM Andrei Popov wrote: > > Ideally a solution would work with HTTP/1 over TLS 1.3, HTTP/2 over TLS > 1.3, HTTP/2 over TLS 1.2, and for completeness HTTP/1 over TLS 1.2. > Correct, anything less than this will create deployment problems. > But this proposal is only su

Re: [TLS] Should we require implementations to send alerts?

(Resending from the right address, again. Possibly I should have subscribed with the other one...) On Thu, Sep 17, 2015 at 6:23 PM David Benjamin wrote: > On Thu, Sep 17, 2015 at 5:46 PM Brian Smith wrote: > >> On Thu, Sep 17, 2015 at 1:50 PM, Nico Williams >> wrote: >

Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

On Wed, Oct 14, 2015 at 4:05 PM Matt Caswell wrote: > On 14/10/15 16:44, Martin Rex wrote: > > Matt Caswell wrote: > >> > >> Does anyone have any views on the below? > > > > Yup. Interleaving application & handshake records is a > > highly dangerous idea (and fortunately some TLS implementations

Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

On Wed, Oct 14, 2015 at 4:42 PM Martin Thomson wrote: > On 14 October 2015 at 13:29, David Benjamin wrote: > > If you really absolutely must support interleave and can't avoid it, I > think > > it being allowed everywhere except between CCS and Finished is probably > t

Re: [TLS] PR for anti-downgrade mechanism

On Mon, Oct 19, 2015 at 11:10 AM Eric Rescorla wrote: > On Mon, Oct 19, 2015 at 7:37 AM, Short, Todd wrote: > >> Does the sentinel have to be the first N bytes? >> >> RFC 5246 (S7.4.1.2) specifies Random as a combination of a uint32 time >> value and 28 random bytes. >> >> Rather than risk break

Re: [TLS] Version in record MAC

What purpose does putting the version in the AD serve? It's not harmful, sure, but just using the sequence number is simplest. It seems the only reason we'd consider putting it into the AD is because historically the record version was in there as part of the record header. In a vacuum, I'm having

Re: [TLS] Application data during renegotiation handshake

On Wed, Nov 11, 2015 at 10:43 PM Yoav Nir wrote: > > > On 12 Nov 2015, at 3:32 AM, Adam Langley wrote: > > > > The TLS 1.3 post-handshake client-auth was intended, as I recall, to > > support HTTP/1.1 over TLS 1.3. > > No, it was (and is) presented as a way to do client certificate > authenticat

Re: [TLS] Application data during renegotiation handshake

sible for the "something cleaner" and "ugly compat solution" to be the same, that is certainly preferable, no? It's possible my guesses about your constraints are incorrect, but so far I'm not seeing any reason that wouldn't be possible. What am I missing here? Davi

Re: [TLS] Fresh results

On Fri, Dec 4, 2015 at 1:17 PM Hubert Kario wrote: > On Friday 04 December 2015 00:52:08 Hanno Böck wrote: > > * Fully deprecate RSA key exchange. > > The compatibility costs of this one are high. They are even higher > > considering the fact that chrome wants to deprecate dhe and use rsa as > >

Re: [TLS] chacha/poly interop?

BoringSSL has an implementation of the AEAD itself you could test against. It's the EVP_AEAD named EVP_aead_chacha20_poly1305_rfc7539 (to be renamed to EVP_aead_chacha20_poly1305 later). On Wed, Dec 9, 2015 at 8:02 PM Salz, Rich wrote: > OpenSSL just landed our chacha/poly implementation into ma

Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

In terms of getting rid of TLS 1.0 and TLS 1.1 altogether, we're seeing around 3% of connections using TLS 1.0 or TLS 1.1. That's quite high, and it's likely that enterprise deployments are much worse. I started gathering numbers on ServerKeyExchange hashes back in November. The code isn't on Chro

Re: [TLS] Fixing TLS

On Tue, Jan 12, 2016 at 12:27 PM Peter Bowen wrote: > The gaps seem to be: > - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated > (BoringSSL has an implementation using cipher suite 0xca,0xfe) > 0xca,0xfe has since been removed as nothing was using it. I'm not aware of anything th

Re: [TLS] chacha/poly for http/2

Chrome is also expecting to ship the cipher in Chrome 49. It's available in Canary and Dev channel right now. It should interop with OpenSSL's master branch as of when I last tested this. David On Wed, Jan 13, 2016 at 12:48 PM Salz, Rich wrote: > We (OpenSSL) have already tested interop of chac

[TLS] Simplifying signature algorithm negotiation

Hi folks, This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS 1.2, signature algorithms are spread across the handshake. We have SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and HashAlgorithm, all in independent registries. NamedGroup is sent in one list, also used for (E

Re: [TLS] Simplifying signature algorithm negotiation

On Fri, Jan 15, 2016 at 7:08 PM Brian Smith wrote: > David Benjamin wrote: > >> 4. Deprecate ecdsa_sha256, etc., in favor of new >> ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_* >> values are for TLS 1.2 compatibility but ignored i

Re: [TLS] Simplifying signature algorithm negotiation

On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett wrote: > On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote: > > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS > > 1.2, signature algorithms are spread across the handshake. > [...] > &g

Re: [TLS] Simplifying signature algorithm negotiation

On Fri, Jan 15, 2016 at 8:10 PM David Benjamin wrote: > If changing the existing meaning is a nuisance, another option is to > continue to allocate new values but only define ecdsa_p256_sha256, > ecdsa_p384_sha384, and ecdsa_p521_sha512 (or whatever your favorite subset > is) for

Re: [TLS] Simplifying signature algorithm negotiation

On Mon, Jan 18, 2016 at 6:48 AM Hubert Kario wrote: > On Friday 15 January 2016 20:45:34 David Benjamin wrote: > > Hi folks, > > > > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In > > TLS 1.2, signature algorithms are spread across

Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

BoringSSL has a pair of implementations ready (in C and in our fork of Go's TLS stack for testing). We're using the value in the TLS 1.3 draft, so 29. It's not currently enabled in any Chrome builds, but I'm expecting to change this soon. David On Tue, Jan 19, 2016 at 12:54 PM Joseph Salowey wro

Re: [TLS] Simplifying signature algorithm negotiation

ies not only what > curves can be used for signing but also what curves can get signed. > > Or are you saying that the NamedGroup would stay, and would now specify > only the supported parameters for the key exchange, not how they are > authenticated (as it is now)? > Yes. >

<    1   2   3   4   5   >