Robert Moskowitz writes:
>The article is unclear if this is a TLS 1.2 and/or 1.3 problem. It does
>claim that 1.3 does not fix all problems with TLS.
It's neither TLS 1.2 or 1.3, it's an ECDSA problem. The paper happened to use
TLS because it's a convenient way to probe the Internet for proble
Kyle Rose writes:
>I wish I had some more context for this area of embedded devices. For example:
>
> * Why is an RTC more expensive (along whatever axis you choose) than a NIC
>(wifi or ethernet)?
Quoting "IoT / SCADA Crypto, What you Need to Know":
The device often won't have any on-board t
On Wed, Aug 17, 2022 at 11:10 AM Peter Gutmann
wrote:
> See my earlier comments on this.
>
Honestly, it sounds like these devices maybe shouldn't be using internet
technologies that were designed with certain assumptions about
extensibility in mind. With such strong constraints not only on behav
Kyle Rose writes:
>IMO, the two requirements "Prohibit upgrades" and "Leverage general-purpose
>network protocols with large attack surfaces" are in direct conflict.
Only if you implement them with large attack surfaces, for which again see my
earlier comments.
Peter.
_
On Wed, Aug 17, 2022 at 11:34 AM Peter Gutmann
wrote:
> Kyle Rose writes:
>
> >IMO, the two requirements "Prohibit upgrades" and "Leverage
> general-purpose
> >network protocols with large attack surfaces" are in direct conflict.
>
> Only if you implement them with large attack surfaces, for whi
Kyle Rose writes:
>A large attack surface can't be avoided with the MTI for these protocols.
It can be vastly reduced by only implementing the MTI rather than every
possible bell and whistle in existence. Also since an RTU (remote terminal
unit) doesn't need to talk to every single piece of bro
Hi All,
I've been putting together a generator for test vectors for DCs.
This code is available as a PR at
https://github.com/tlswg/tls-subcerts/pull/119
The vectors generated are for:
Leaf public key signature algorithm - DC public key signature algorithm
1. ECDSA (P-384) - EdDSA (Ed25519)
So that we get an initial answer to this (so we can put it into the draft - of
course, we can debate what's in the draft...)
Illari suggested:
X25519+Kyber768
P384+Kyber768
Well, I would suggest adding in
X25519+Kyber512
For those situations where we need to limit the message size (perhaps DT
I support those choices, but would also add P256+Kyber512.
* (1) same reason as below (by Scott)
* (2) to be able to declare security of generated keys in FIPS-mode for
_both_ - classical and post-quantum schemes (once Kyber is standardized).
After double-checking with NIST today, currently
+1 on the 3 proposed by Scott and P256+Kyber512 proposed by Kris.
From: TLS On Behalf Of Kris Kwiatkowski
Sent: Wednesday, August 17, 2022 3:31 PM
To: tls@ietf.org
Subject: RE: [EXTERNAL][TLS] WGLC for draft-ietf-tls-hybrid-design
CAUTION: This email originated from outside of the organization.
I forgot to suggest to add a paragraph in the Sec Considerations section about
Kyber-512.
Kyber-512 offers a CoreSVP hardness of ~120 bits of security which is a little
lower than it should. The Kyber submission refines the CoreSVP cost by using
sieving cost simulations and claims that the gate
+1 on the 3 proposed by Scott and P256+Kyber512 proposed by Kris.
“Me too”: +1 to the above.
From: TLS On Behalf Of Kris Kwiatkowski
Sent: Wednesday, August 17, 2022 3:31 PM
To: tls@ietf.org
I support those choices, but would also add P256+Kyber512.
* (1) same reason as below (by Scott)
*
On Sat, Aug 13, 2022, at 04:13, Scott Fluhrer (sfluhrer) wrote:
> Well, if we were to discuss some suggested hybrids (and we now know the
> NIST selection), I would suggest these possibilities:
>
> - X25519 + Kyber512
> - P256 + Kyber512
> - X448 + Kyber768
> - P384 + Kyber768
Any specific pairs
13 matches
Mail list logo
