Binary curves have some risks, due to recent work of Semaev on subexponential
ECDLP, building on much past work.
Even so, there's an argument from Koblitz and Menezes that special curves (e.g.
binary curves) may survive some wider collapse. I think it's a weak argument,
but for those for whom s
akest link. Ideally, the rainy day backups
should be disabled by default, but possible to quickly enable, by administrator
configuration or patch.
From: Tony Arcieri
Sent: Wednesday, July 15, 2015 9:47 PM
To: Dan Brown
Cc: Martin Rex;
Subject: Re: [TLS] sect571r1
On Wed, Jul 15, 2015 at 6:
r meant random as opposed to k which meant koblitz.
the koblitz curve had a and b coefficients like 0 and 1, but the r curves had a
and b derived from output of hash...
back in 2000 when SEC2 came out introducing these names (and OIDS) the attacks
on special curves (MOV and SASS attacks) were
From: TLS On Behalf Of Salz, Rich
> Do we need a short RFC saying “do not use static DH” ?
Don’t TLS 0-RTT and ESNI/ECH via HPKE use a type of (semi)static ECDH? If so,
then an RFC to ban static (EC)DH in TLS would need to be very clear about not
referring to these use cases of static ECDH.
Dear Michael,
Your concern that special primes in Diffie--Hellman might be weaker has some
truth: the famous and ingenious special number field sieve (SNFS) works
against primes with special structure. See
https://eprint.iacr.org/2016/961
for a recent application (which, as an extra wrinkle, is
Hi Douglas,
Your general approach paves the way for improved forward security, as
insurance against new attacks, a non-negligible risk (*). So, the TLS WG
should advance it soon. Sorry, that I've not yet looked at the details, but
I trust that your I-D is good.
Best regards,
Dan
PS
(*) The
> -Original Message-
> From: TLS On Behalf Of Douglas Stebila
> We wanted to see if there is any further feedback on our draft "Hybrid key
> exchange in TLS 1.3" ... We have not received any new feedback from the
working group
> since we posted our last non-trivial update in October 2020.
Deprecating non-forward-secure ECDH and FFDH is important.
Keeping FFDHE may be okay, e.g. for those who want forward security, but still
don't trust ECC.
--
This transmission (including any attachments) may contain confidential
re-used ephemeral keys).
Best regards,
Dan Brown
--
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other app
Dear Nimrod and team:
How does your concern compare to Campagna and Petcher’s report
https://eprint.iacr.org/2020/1364
which has security proofs for concatenation-based KDF?
(Maybe a detailed discussion is better suited to CFRG?)
Best regards,
Dan
From: TLS On Behalf Of Nimrod Avira
Hi John and Scott,
For even greater clarity, you might want to address these points:
If the receiver uses an x-only ladder (e.g. Brier-Joye) and re-uses private ECC
key, then, upon decoding the peer’s compress public key (represented via x),
the receiver ought to check that x^3+ax+b is a
Agreeing on security gains from hybrid.
Should TLS ask CFRG (again?) what to do about PQC?
> From: D. J. Bernstein
>
> Yoav Nir writes:
> > To justify a hybrid key exchange you need people who are both worried
> > about quantum computers and worried about cryptanalysis or the new
> > algorithm
Dear TLS WG,
Enterprise "visibility" is a network issue, not an Internet issue, and thus, to
my _limited_ understanding, should be out of scope of IETF.
Nonetheless, enterprise security is important, and enterprise networks use
Internet technology internally, so the topic is perhaps still proce
It's mainly due to CFRG's advice, isn't it?
Calling other curves potentially unsafe or inappropriate for general use is a
bit harsh and outside the scope of TLS, isn't it?
As to using a narrow or wide set of curves, there are reputable proposals for
the latter:
ia.cr/2015/647 and ia.cr/2015/366
to be potentially unsafe” loses most of these nuances.
From: Eric Rescorla [mailto:e...@rtfm.com]
Sent: Tuesday, July 17, 2018 11:02 AM
To: Dan Brown
Cc: Hanno Böck ; tls@ietf.org
Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?
Well, I note that the text also says
Is the security property mentioned below a defined goal of, and proved for,
TLS 1.3?
Just curious, because it seems a little counter-intuitive: impersonation of an
anonymous (unauthenticated) client, under the harsh conditions of all content
in the clear. It is certainly plausible by regardi
A brief reminder below about 2 new extra elements of ECDSA-Sig-Value.
> -Original Message-
> From: TLS On Behalf Of Hubert Kario
> Sent: Monday, September 30, 2019 8:56 AM
>
> At the same time SEC 1 v2.0[1] defines that structure as follows:
>
>ECDSA-Sig-Value ::= SEQUENC
Re ECDSA specs and paywells:
ANSI X9.62-2005 was withdrawn in 2015, expiring automatically after 10 years,
despite my weak effort.
A revival, ANSI X9.142, with almost the same content is under way, though even
its fate is unsure.
Also, I expect FIPS 186-5 is nearly ready, and will specify much of
> -Original Message-
> From: John Mattsson
>
> Dan Brown wrote:
>
> > ANSI X9.62-2005 was withdrawn in 2015
>
> Ok, that TLS 1.3 is relying on a withdrawn publication that used to be
> behind a
> paywall is even worse.
[DB] Have mercy on TLS: I expec
r that you are more baffled about all this than I am?
5. Yes, “revival” is my term, and in no way an official, so it’s sensible
to quote me on it.
Dan
From: Rene Struik
Sent: Tuesday, October 1, 2019 9:29 AM
To: Dan Brown ; John Mattsson
; Peter Gutmann
; Hubert Kario ; TLS@ie
???
Is it possible to do better with a non-extensible syntax?
The only breakdown is the old syntax parsers receiving the extensions, right?
That's the only place a lax parser would help.
Original Message
From: Peter Gutmann
Sent: Tuesday, October 1, 2019 6:15 PM
To: Hubert Kario; Dan Bro
use weaker crypto, to stop improving
crypto.
Best regards,
Dan Brown
BlackBerry
From: TLS On Behalf Of Joseph Salowey
Sent: Thursday, February 13, 2020 12:13 PM
To:
Subject: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design
The authors of "Hybrid Key Exchange&quo
> -Original Message-
> From: Cfrg On Behalf Of Salz, Rich
> Subject: [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)
>
> NIST SP 800-56C (Recommendation for Key-Derivation Methods in Key-
> Establishment Schemes) is currently a draft in review with a deadline of
> May 15.
> -Original Message-
> From: Salz, Rich
>
> >[DB] But NIST Draft SP 800-56Cr2 cites RFC 5869, which is HKDF, and
> > says
> HKDF
> is a version of 56C Section 5.1. So, I had thought that 56C would allow
> HKDF.
> What am I missing?
>
> It cites it, but doesn't include it in
Hi Hugo,
Some curious molehill questions. Please take with a grain of salt.
In short, does HKDF-Extract suffer from related-salt and repeated-IKM?
To elaborate:
Phillip raises a good point below about HMAC suffering from key-extension (by
zero bytes). You are right that this is no
Weaker crypto to stop insider attacks, is that the request? (And practice?)
Doesn’t that increase the risk of larger (but perhaps rarer) further insider
attacks?
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Hugo Krawczyk
Sent: Thursday, September 22, 2016 7:41 PM
To: BITS Security
Cc: t
As I understand the concern, the worry is that Bud is compromising Bob's (TLS)
server, to somehow send Bob's plaintext to the wrong place.
The proposed (existing?) strategy has Bob compromising his own forward-secrecy
to stop Bud, but only after the cat is out of the bag. This seems a high pri
Please keep aiming for forward-secrecy. (Just in case my wording has been
unclear.)
From: Yoav Nir [mailto:ynir.i...@gmail.com]
Sent: Wednesday, September 28, 2016 1:51 PM
>On 28 Sep 2016, at 7:16 PM, Dan Brown <mailto:danibr...@blackberry.com> wrote:
>> I know little about ex
Isn’t possible to achieve the goals of this proposal without re-using DH
secrets?
For example, let DH_secret = KDF ( monitoring_key, server.hello ,
client.hello), or something similar. Ideally, the monitoring_key should be
updated frequently as possible (while keeping it synchronized).
From:
I don't oppose any of the 4 given options, but I slightly prefer TLS 2.0, it
seems simple and clear.
In my opinion, the whole SSL vs TLS confusion needs better education to
confront, version numbers (even dates) alone might not be enough. Renaming
*SSL products to *TLS should help. Avoiding
not designed to be decrypted by third-parties—that's kind of the
>> point. Thus anyone doing this should not be surprised to hit a few
>> MUST NOTs and, potentially, to have to configure implementations to
>> allow such a deployment.
>
> The (presumably) accidental reu
I agree with Stephen: this ID and all its detailed discussion should move over
to the Intranet ETF and/or the Internet Subverting TF (wherever such a TF may
be). TLS 1.3 is already a big change.
Sent from my BlackBerry 10 smartphone on the Rogers network.
Original Message
From: Stephen Farrel
Hmm, I'd appreciate a brief reminder* of why 1.3 needs nonces at all, given
that ephemeral DH is mandated, if anybody has the time/patience. (* ok, not
that I truly ever knew).
I assume that the risk of misusing the nonces, to exfiltrate keys etc, is small
enough compared to other side channels
hdraw them. I did look over 1.3 once, fwiw, but have since forgot the
details, sorry.
Original Message
From: Russ Housley
Sent: Monday, July 24, 2017 12:58 PM
To: Dan Brown
Cc: IETF TLS
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
there was a discussion of adding a statement that a
I don't think 2 CSPRNGs is a good idea.
Wasn’t there a few years back some RSA keys with separate p and q, generated
independently leading to an attack...
Here if the seeds to initialize the RNGS are related, or one is weak, or worst
if the seed is a raw source that doesn’t change in the momen
hu, Jul 27, 2017 at 4:43 PM, Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
>
>> Respectfully disagree. Having two cryptographically independent
>> PRNGs, one for public data and one for key material, IMHO is a good
>> idea. Of course, both should be pro
Replies in-line (non-standardly enclosed with << >>, sorry ;)
-Original Message-
From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com]
Sent: Friday, July 28, 2017 11:09 AM
To: Dan Brown
Cc: tls@ietf.org
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello'
https://eprint.iacr.org/2012/064
mentions the problem of generating multiple secrets instead of a single secret
Original Message
From: Stephen Farrell
Sent: Friday, July 28, 2017 11:48 AM
To: Dan Brown; Eric Rescorla; Blumenthal, Uri - 0553 - MITLL
Cc: tls@ietf.org
Subject: Re: [TLS] 32 byte
d primes, but is plausible and relevant to the
question at hand. (I thought I mentioned this earlier.)
From: Colm MacCárthaigh
Sent: Saturday, July 29, 2017 2:04 PM
To: Dan Brown
Cc: Stephen Farrell; Eric Rescorla; Blumenthal, Uri - 0553 - MITLL; tls@ietf.org
Subject: Re: [TLS] 32 byte randoms in
-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
I don't think this is simply a case of multiple CSPRNGs.
DB> Not quite sure what you mean by "simply a case of multiple CSPRNGs", but I
am starting to get an idea below.
My guess is many TLS implementations don
Hi Tony,
Perhaps (some variant of) Menezes-Qu-Vanstone MQV key agreement might work for
your problem.
There are some security analyses for variants MQV, e.g. HMQV, and it offers
even better efficiency than triple-DH.
The original MQV appears in a few standards (NIST SP 63a, IEEE 1363, ANSI
X9
41 matches
Mail list logo
