Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Martin Thomson]

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 of primitives should be specified in a different document to 
this one.

Ultimately, I want fewer choices, but the direction the discussion is headed 
seems about right.  At least in the short term, I think we need to eschew 
compression and only include one offer.  Partly because I think that there 
might be better options available to us than compression, partly because 
compression will be annoying to implement correctly, and partly because we're 
still in the phase where this is being trialed.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Blumenthal, Uri - 0553 - MITLL]

+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)
* (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 there is no clear plan for
updating SP 800-56A with X25519 (opposite to SP 800-186).

Kind regards,
Kris

On 8/17/22 20:06, Scott Fluhrer (sfluhrer) wrote:
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 DTLS and 
QUIC).
 
Is the working group happy with that?
 
-Original Message-
From: TLS  On Behalf Of Ilari Liusvaara
Sent: Saturday, August 13, 2022 11:12 AM
To: TLS@ietf.org
Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
 
On Fri, Aug 12, 2022 at 06:13:38PM +, Scott Fluhrer (sfluhrer) wrote:
Again, this is late, however Stephen did ask this to be discussed in the
working group, so here we go:
 
-Original Message-
From: TLS  On Behalf Of Stephen Farrell
Sent: Saturday, April 30, 2022 11:49 AM
To: Ilari Liusvaara ; TLS@ietf.org
Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
 
 
Hiya,
 
On 30/04/2022 10:05, Ilari Liusvaara wrote:
On Sat, Apr 30, 2022 at 01:24:58AM +0100, Stephen Farrell wrote:
- section 5: IMO all combined values here need to have
recommended == "N" in IANA registries for a while and that needs
to be in this draft before it even gets parked. Regardless of
whether or not the WG agree with me on that, I think the current
text is missing stuff in this section and don't recall the WG
discussing that
 
I think that having recommended = Y for any combined algorithm
requires NIST final spec PQ part and recommended = Y for the
classical part (which allows things like x25519 to be the classical part).
 
That is, using latest spec for NISTPQC winner is not enough. This
impiles recommended = Y for combined algorithm is some years out
at the very least.
 
I agree, and something like the above points ought be stated in the
draft after discussion in the WG.
 
Section 5 is 'IANA considerations', and would be where we would list
the various supported hybrids, which we don’t at the moment.
 
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
 
I would take:
 
X25519+Kyber768
P384+Kyber768
 
The reason for taking Kyber768 is because the CRYSTALS team recommends
it. The reason for taking P384 is because it is CNSA-approved, so folks that
need CNSA can use that.
 
Of course, that is likely to bust packet size limits. I do not think that is an
issue in TLS, but DTLS and QUIC might be another matter entierely (in theory
DTLS and QUIC can handle it just fine, practice might be another matter
entierely. And if such problems are there, it is good to know about those...
This stuff is experimental).
 
 
Of course, it's possible that NIST will tweak the definition of Kyber;
that's just a possibility we'll need to live with (and wouldn't change
what hybrid combinations we would initially define)
 
I would think such changes would just mean the interim post-quantum kex is
not compatible with the final one. Not that big of deal, there are tens of
thoursands of free codepoints. If an implementation  needs both, it can
probably share vast majority of the code.
 
 
 
-Ilari



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Kampanakis, Panos]

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 and memory cost is ~2^150 and 
~2^90 approximately which they argue is better than AES. I think it would be 
worth to call out the CoreSVP hardness and the refined estimate for Kyber-512 
in the Sec Considerations section.



From: Kampanakis, Panos
Sent: Wednesday, August 17, 2022 4:26 PM
To: 'Kris Kwiatkowski' ; tls@ietf.org
Subject: RE: [EXTERNAL][TLS] WGLC for draft-ietf-tls-hybrid-design

+1 on the 3 proposed by Scott and P256+Kyber512 proposed by Kris.

From: TLS mailto:tls-boun...@ietf.org>> 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. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.



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 there is no clear plan for
updating SP 800-56A with X25519 (opposite to SP 800-186).

Kind regards,
Kris
On 8/17/22 20:06, Scott Fluhrer (sfluhrer) wrote:

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 DTLS and 
QUIC).



Is the working group happy with that?



-Original Message-

From: TLS  On Behalf Of 
Ilari Liusvaara

Sent: Saturday, August 13, 2022 11:12 AM

To: TLS@ietf.org

Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design



On Fri, Aug 12, 2022 at 06:13:38PM +, Scott Fluhrer (sfluhrer) wrote:

Again, this is late, however Stephen did ask this to be discussed in the

working group, so here we go:



-Original Message-

From: TLS  On Behalf Of 
Stephen Farrell

Sent: Saturday, April 30, 2022 11:49 AM

To: Ilari Liusvaara 
; 
TLS@ietf.org

Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design





Hiya,



On 30/04/2022 10:05, Ilari Liusvaara wrote:

On Sat, Apr 30, 2022 at 01:24:58AM +0100, Stephen Farrell wrote:

- section 5: IMO all combined values here need to have

recommended == "N" in IANA registries for a while and that needs

to be in this draft before it even gets parked. Regardless of

whether or not the WG agree with me on that, I think the current

text is missing stuff in this section and don't recall the WG

discussing that



I think that having recommended = Y for any combined algorithm

requires NIST final spec PQ part and recommended = Y for the

classical part (which allows things like x25519 to be the classical part).



That is, using latest spec for NISTPQC winner is not enough. This

impiles recommended = Y for combined algorithm is some years out

at the very least.



I agree, and something like the above points ought be stated in the

draft after discussion in the WG.



Section 5 is 'IANA considerations', and would be where we would list

the various supported hybrids, which we don’t at the moment.



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



I would take:



X25519+Kyber768

P384+Kyber768



The reason for taking Kyber768 is because the CRYSTALS team recommends

it. The reason for taking P384 is because it is CNSA-approved, so folks that

need CNSA can use that.



Of course, that is likely to bust packet size limits. I do not think that is an

issue in TLS, but DTLS and QUIC might be another matter entierely (in theory

DTLS and QUIC can handle it just fine, practice might be another matter

entierely. And if such problems are there, it is good to know about those...

This stuff is experimental).





Of course, it's possible that NIST will tweak the definition of Kyber;

that's just a possibility we'll need to live with (and wouldn't change

what hybrid combinations we would initially define)



I would think such changes would just mean the interim post-quantum kex is

not compatible with the final one. Not that big of deal, there are tens of

thoursands of free codepoints. If an implementation  needs both, it can

probably share vast majority of the code.

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Kampanakis, Panos]

+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. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.



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 there is no clear plan for
updating SP 800-56A with X25519 (opposite to SP 800-186).

Kind regards,
Kris
On 8/17/22 20:06, Scott Fluhrer (sfluhrer) wrote:

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 DTLS and 
QUIC).



Is the working group happy with that?



-Original Message-

From: TLS  On Behalf Of 
Ilari Liusvaara

Sent: Saturday, August 13, 2022 11:12 AM

To: TLS@ietf.org

Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design



On Fri, Aug 12, 2022 at 06:13:38PM +, Scott Fluhrer (sfluhrer) wrote:

Again, this is late, however Stephen did ask this to be discussed in the

working group, so here we go:



-Original Message-

From: TLS  On Behalf Of 
Stephen Farrell

Sent: Saturday, April 30, 2022 11:49 AM

To: Ilari Liusvaara 
; 
TLS@ietf.org

Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design





Hiya,



On 30/04/2022 10:05, Ilari Liusvaara wrote:

On Sat, Apr 30, 2022 at 01:24:58AM +0100, Stephen Farrell wrote:

- section 5: IMO all combined values here need to have

recommended == "N" in IANA registries for a while and that needs

to be in this draft before it even gets parked. Regardless of

whether or not the WG agree with me on that, I think the current

text is missing stuff in this section and don't recall the WG

discussing that



I think that having recommended = Y for any combined algorithm

requires NIST final spec PQ part and recommended = Y for the

classical part (which allows things like x25519 to be the classical part).



That is, using latest spec for NISTPQC winner is not enough. This

impiles recommended = Y for combined algorithm is some years out

at the very least.



I agree, and something like the above points ought be stated in the

draft after discussion in the WG.



Section 5 is 'IANA considerations', and would be where we would list

the various supported hybrids, which we don’t at the moment.



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



I would take:



X25519+Kyber768

P384+Kyber768



The reason for taking Kyber768 is because the CRYSTALS team recommends

it. The reason for taking P384 is because it is CNSA-approved, so folks that

need CNSA can use that.



Of course, that is likely to bust packet size limits. I do not think that is an

issue in TLS, but DTLS and QUIC might be another matter entierely (in theory

DTLS and QUIC can handle it just fine, practice might be another matter

entierely. And if such problems are there, it is good to know about those...

This stuff is experimental).





Of course, it's possible that NIST will tweak the definition of Kyber;

that's just a possibility we'll need to live with (and wouldn't change

what hybrid combinations we would initially define)



I would think such changes would just mean the interim post-quantum kex is

not compatible with the final one. Not that big of deal, there are tens of

thoursands of free codepoints. If an implementation  needs both, it can

probably share vast majority of the code.







-Ilari



___

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls

___

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Kris Kwiatkowski]

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 there is no clear plan for
updating SP 800-56A with X25519 (opposite to SP 800-186).

Kind regards,
Kris

On 8/17/22 20:06, Scott Fluhrer (sfluhrer) wrote:

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 DTLS and 
QUIC).

Is the working group happy with that?


-Original Message-
From: TLS  On Behalf Of Ilari Liusvaara
Sent: Saturday, August 13, 2022 11:12 AM
To:TLS@ietf.org
Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

On Fri, Aug 12, 2022 at 06:13:38PM +, Scott Fluhrer (sfluhrer) wrote:

Again, this is late, however Stephen did ask this to be discussed in the

working group, so here we go:

-Original Message-
From: TLS  On Behalf Of Stephen Farrell
Sent: Saturday, April 30, 2022 11:49 AM
To: Ilari Liusvaara;TLS@ietf.org
Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design


Hiya,

On 30/04/2022 10:05, Ilari Liusvaara wrote:

On Sat, Apr 30, 2022 at 01:24:58AM +0100, Stephen Farrell wrote:

- section 5: IMO all combined values here need to have
recommended == "N" in IANA registries for a while and that needs
to be in this draft before it even gets parked. Regardless of
whether or not the WG agree with me on that, I think the current
text is missing stuff in this section and don't recall the WG
discussing that

I think that having recommended = Y for any combined algorithm
requires NIST final spec PQ part and recommended = Y for the
classical part (which allows things like x25519 to be the classical part).

That is, using latest spec for NISTPQC winner is not enough. This
impiles recommended = Y for combined algorithm is some years out
at the very least.

I agree, and something like the above points ought be stated in the
draft after discussion in the WG.

Section 5 is 'IANA considerations', and would be where we would list
the various supported hybrids, which we don’t at the moment.

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

I would take:

X25519+Kyber768
P384+Kyber768

The reason for taking Kyber768 is because the CRYSTALS team recommends
it. The reason for taking P384 is because it is CNSA-approved, so folks that
need CNSA can use that.

Of course, that is likely to bust packet size limits. I do not think that is an
issue in TLS, but DTLS and QUIC might be another matter entierely (in theory
DTLS and QUIC can handle it just fine, practice might be another matter
entierely. And if such problems are there, it is good to know about those...
This stuff is experimental).



Of course, it's possible that NIST will tweak the definition of Kyber;
that's just a possibility we'll need to live with (and wouldn't change
what hybrid combinations we would initially define)

I would think such changes would just mean the interim post-quantum kex is
not compatible with the final one. Not that big of deal, there are tens of
thoursands of free codepoints. If an implementation  needs both, it can
probably share vast majority of the code.



-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Scott Fluhrer (sfluhrer)]

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 DTLS and 
QUIC).

Is the working group happy with that?

> -Original Message-
> From: TLS  On Behalf Of Ilari Liusvaara
> Sent: Saturday, August 13, 2022 11:12 AM
> To: TLS@ietf.org
> Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
> 
> On Fri, Aug 12, 2022 at 06:13:38PM +, Scott Fluhrer (sfluhrer) wrote:
> > Again, this is late, however Stephen did ask this to be discussed in the
> working group, so here we go:
> >
> > > -Original Message-
> > > From: TLS  On Behalf Of Stephen Farrell
> > > Sent: Saturday, April 30, 2022 11:49 AM
> > > To: Ilari Liusvaara ; TLS@ietf.org
> > > Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
> > >
> > >
> > > Hiya,
> > >
> > > On 30/04/2022 10:05, Ilari Liusvaara wrote:
> > > > On Sat, Apr 30, 2022 at 01:24:58AM +0100, Stephen Farrell wrote:
> > > >> - section 5: IMO all combined values here need to have
> > > >> recommended == "N" in IANA registries for a while and that needs
> > > >> to be in this draft before it even gets parked. Regardless of
> > > >> whether or not the WG agree with me on that, I think the current
> > > >> text is missing stuff in this section and don't recall the WG
> > > >> discussing that
> > > >
> > > > I think that having recommended = Y for any combined algorithm
> > > > requires NIST final spec PQ part and recommended = Y for the
> > > > classical part (which allows things like x25519 to be the classical 
> > > > part).
> > > >
> > > > That is, using latest spec for NISTPQC winner is not enough. This
> > > > impiles recommended = Y for combined algorithm is some years out
> > > > at the very least.
> > >
> > > I agree, and something like the above points ought be stated in the
> > > draft after discussion in the WG.
> >
> > Section 5 is 'IANA considerations', and would be where we would list
> > the various supported hybrids, which we don’t at the moment.
> >
> > 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
> 
> I would take:
> 
> X25519+Kyber768
> P384+Kyber768
> 
> The reason for taking Kyber768 is because the CRYSTALS team recommends
> it. The reason for taking P384 is because it is CNSA-approved, so folks that
> need CNSA can use that.
> 
> Of course, that is likely to bust packet size limits. I do not think that is 
> an
> issue in TLS, but DTLS and QUIC might be another matter entierely (in theory
> DTLS and QUIC can handle it just fine, practice might be another matter
> entierely. And if such problems are there, it is good to know about those...
> This stuff is experimental).
> 
> 
> > Of course, it's possible that NIST will tweak the definition of Kyber;
> > that's just a possibility we'll need to live with (and wouldn't change
> > what hybrid combinations we would initially define)
> 
> I would think such changes would just mean the interim post-quantum kex is
> not compatible with the final one. Not that big of deal, there are tens of
> thoursands of free codepoints. If an implementation  needs both, it can
> probably share vast majority of the code.
> 
> 
> 
> -Ilari
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Delegated Credentials Test Vectors

[Jonathan Hoyland]

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)
   2.  ECDSA (P-384) - RSAPSS (2048 + SHA512)
   3.  EdDSA (Ed25519) - ECDSA (P-256 + SHA256)
   4.  EdDSA (Ed25519) - RSAPSS (2048 + SHA256)
   5.  RSAPSS (2048 + SHA256) - ECDSA (P-256 + SHA256)
   6.  RSA (2048 + SHA256) - EdDSA (Ed25519)

Where possible the test vectors are checked against multiple
implementations to ensure they actually work.

Any feedback is welcome.

Regards,

Jonathan
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Getting started, clock not set yet

[Peter Gutmann]

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 broken software on the
planet but only what the master station it's talking to is running, all you
need is whatever the de facto universal standard config is, either DH+RSA+AES
or P256 ECDH/ECDSA+AES and nothing else, no suite negotiation, no extensions,
nothing.

And that goes all the way up and down the protocol stack.  TCP options,
fragmentation, UDP, ICMP, packet reordering, most flow control and congestion
avoidance, none of that's there.  Fuzzing these things is mostly a waste of
time because there's no alternate code paths or corner cases to discover in
the fuzzing.  Makes them remarkably resistant to attack because there's very
little there to attack.

Peter.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Getting started, clock not set yet

[Kyle Rose]

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 which again see
> my
> earlier comments.
>

A large attack surface can't be avoided with the MTI for these protocols.
And if you don't implement what's required, don't complain when it doesn't
interop. 🤷‍♂️

Kyle
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Getting started, clock not set yet

[Peter Gutmann]

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Getting started, clock not set yet

[Kyle Rose]

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 behavior
but on implementation, it really seems like the right thing to do is to
shrink-wrap every interface around exactly what you need and avoid all
unnecessary complexity. That means no TLS, no X.509, no IP, etc. IMO, the
two requirements "Prohibit upgrades" and "Leverage general-purpose network
protocols with large attack surfaces" are in direct conflict.

Kyle
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Getting started, clock not set yet

[Peter Gutmann]

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 time source because it's not
  feasible to include an RTC in the design. An RTC adds considerable cost
  (possibly as much as the rest of the device), may be larger/heavier than the
  rest of the device, typically requires one or more extra assembly steps to
  fit because they can't be installed via pick-and-place and reflow soldering,
  make the device more vulnerable to issues like high and low temperatures
  that embedded devices are typically exposed to, and wear out (the batteries
  die) long before the rest of the device does.

> * What classes of devices would reasonably sit on a shelf for ten years and
>subsequently prove useful without being updated?

Any number of SCADA devices.  They're an exact replacement for an existing
device, so the fact that you're replacing something that's failed with
something else that's exactly identical is a requirement.  You don't want to
replace it with something that someone's fiddled with in the meantime because
you can't guarantee that it'll behave the same as the original device did.

> * If it's been sitting on a shelf for ten years, why is reattaching it to
>the network easy, while plugging it into an upgrade klosk first and *then*
>reattaching it to the network is hard?

See my earlier comments on this.

Peter.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS ECDSA nonce reuse attack?

[Peter Gutmann]

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 problematic
implementations, but it's a problem with ECDSA, not with TLS.  You could do
the same thing with SSH, there's just a lot less of it out there, and since
TLS servers are things you want everyone to see and access while SSH servers
are ones you don't, I would imagine probing SSH servers in the same manner
would run into a lot more problems than probing TLS ones, e.g running into
fail2ban rules and similar which would mess up your results.

As an aside, it also backs up my comments earlier about ECDH being just as
problematic as DH in TLS:

  Our data shows that non-unique server ECDH parameters are very common; in
  the UCSD data almost 15% of observed connections used a non-unique set of
  server key exchange parameters.

In other words telling everyone to move from DH to ECDH just moves the same
problem across to a different algorithm.

Peter.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls