Re: [TLS] Transcript ambiguity in cTLS

[Ilari Liusvaara]

On Mon, Jul 25, 2022 at 06:47:53PM -0400, Ben Schwartz wrote:
> I noticed some confusion today about the topic of ambiguous
> transcripts in cTLS.  My claim was not that any single cTLS profile
> has an ambiguous transcript.  If such a thing were true, I believe
> that would be a bug in the cTLS specification.
> 
> Instead, I was trying to highlight the concern of "profile confusion"
> attacks, in which an attacker is able to convince the two parties
> that different profiles (with the same ID) are in use.  In these
> cases, the two parties can verify their agreed-upon transcript,
> but interpret it differently, which could lead to vulnerabilities.
> 
> Including the "template" in the transcript rules out these attacks.
> However, this protection depends on the use of a strong transcript
> hash in the Finished message, and shortening or omitting this hash
> has also been discussed.
> 
> As you can see, there are still many interesting open questions
> related to cTLS.

Furthermore (this is just from "known unknown" category):

- The impact of shortening the finished is probably different for PSK
  versus certificate modes.
- Impact of record protection probably can not be ignored if finished
  is shortened. Traditional TLS 1.3 security analysis ignores RP
  completely (conservative choice to make analysis easier).
- None of the common record protectors in TLS 1.3 are committing
  (except the NULL ones!), which might have an impact on security
  analysis.
- PSK has binders, which are finished-like, but not protected. The
  impact of shortening those is probably very different from impact
  of shortening actual finished.




-Ilari

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

[TLS] PQC key exchange sizes

[Thom Wiggers]

Hi all,

In yesterday’s working group meeting we had a bit of a discussion of the
impact of the sizes of post-quantum key exchange on TLS and related
protocols like QUIC. As we neglected to put Kyber’s key sizes in our slide
deck (unlike the signature schemes), I thought it would be a good idea to
get the actual numbers of Kyber onto the mailing list.

Note that in the context of TLS’s key exchange, the public key would be
what goes into the ClientHello key_shares extension, and the ciphertext
would go into the Server’s ServerHello key_shares extension.

Kyber512: NIST level I, "strength ~AES128"
  public key: 800 bytes
  ciphertext: 768 bytes
  secret key: 1632 bytes
Kyber768: NIST level III, "~AES192"
  public key: 1184
  ciphertext: 1088
  secret key: 2400 bytes
Kyber1024: NIST level V, "~AES256"
  public key: 1568
  ciphertext: 1568
  secret key: 3168

So for the key exchange at least, it seems to me Kyber512 should work for
TLS and QUIC just fine; Kyber768 might be a bit of a squeeze if you want to
stay in QUIC’s default 1300 byte initial packet? Also, I don't really know
how the D of DTLS might change the story.

All the numbers we reported are as of the latest version of the individual
submissions (except as discussed below). The standards that NIST eventually
names FIPS-xyz might have (mildly) different sizes. NIST has said that
they’re always happy to receive feedback and information about use cases
and constraints.

Lastly, Bas Westerbaan has talked about a Kyber draft in yesterday’s CFRG
meeting. I believe a stated goal is to use that for coordinating any
experiments before the NIST standard is out. So keep an eye out if that
interests you.

Cheers,

Thom

PS: Let me also correct the mistake I had introduced in the SPHINCS+
numbers in the TLS talk: SPHINCS+ has indeed gotten slightly smaller than
the numbers I reported. The smallest SPHINCS+ variant (sphincs+-128s) has a
signature size of 7,856 bytes. There’s a nice table with the different
parameter sets of SPHINCS+ on their Github repository
https://github.com/sphincs/sphincsplus#parameters. I’m glad that people
were paying attention, apparently more than I was :-)

I will also clarify that when we mentioned that Falcon needs very careful
attention when implementing, this concerns Falcon's signing routines. These
require constant-time double-width floating point maths; on many CPUs this
will need to be emulated in software. Verification, on the other hand, is a
lot less sensitive.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PQC key exchange sizes

[Ilari Liusvaara]

On Tue, Jul 26, 2022 at 02:15:34PM +0200, Thom Wiggers wrote:
> 
> In yesterday’s working group meeting we had a bit of a discussion of the
> impact of the sizes of post-quantum key exchange on TLS and related
> protocols like QUIC. As we neglected to put Kyber’s key sizes in our slide
> deck (unlike the signature schemes), I thought it would be a good idea to
> get the actual numbers of Kyber onto the mailing list.
> 
> Note that in the context of TLS’s key exchange, the public key would be
> what goes into the ClientHello key_shares extension, and the ciphertext
> would go into the Server’s ServerHello key_shares extension.
> 
> Kyber512: NIST level I, "strength ~AES128"
>   public key: 800 bytes
>   ciphertext: 768 bytes
>   secret key: 1632 bytes
> Kyber768: NIST level III, "~AES192"
>   public key: 1184
>   ciphertext: 1088
>   secret key: 2400 bytes
> Kyber1024: NIST level V, "~AES256"
>   public key: 1568
>   ciphertext: 1568
>   secret key: 3168
> 
> So for the key exchange at least, it seems to me Kyber512 should work for
> TLS and QUIC just fine; Kyber768 might be a bit of a squeeze if you want to
> stay in QUIC’s default 1300 byte initial packet? Also, I don't really know
> how the D of DTLS might change the story.

The initial packet size is 1200, so Kyber768 public key does not fit
into a packet. However, the initial packets can be split, so even
Kyber1024 key does fit into two initial packets (this also doubles the
server initial window from 3600 to 7200 due to the way amplification
limit works)


DTLS is a bit more problematic. There are two ways to deal with the key
being too big to fit in a single IP packet.

- IP-level fragmentation. REALLY SHOULD NOT be used.
- DTLS-level fragmentation. There are buggy implementations that break
  if one tries this.

And in both case, the failure modes are not easy to recover from.




-Ilari

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

[TLS] I-D Action: draft-ietf-tls-tlsflags-10.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : A Flags Extension for TLS 1.3
Author  : Yoav Nir
  Filename: draft-ietf-tls-tlsflags-10.txt
  Pages   : 9
  Date: 2022-07-26

Abstract:
   A number of extensions are proposed in the TLS working group that
   carry no interesting information except the 1-bit indication that a
   certain optional feature is supported.  Such extensions take 4 octets
   each.  This document defines a flags extension that can provide such
   indications at an average marginal cost of 1 bit each.  More
   precisely, it provides as many flag extensions as needed at 4 + the
   order of the last set bit divided by 8.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tlsflags-10


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

Re: [TLS] PQC key exchange sizes

[Stephen Farrell]

On 26/07/2022 13:15, Thom Wiggers wrote:

Hi all,

In yesterday’s working group meeting we had a bit of a discussion of the
impact of the sizes of post-quantum key exchange on TLS and related
protocols like QUIC. As we neglected to put Kyber’s key sizes in our slide
deck (unlike the signature schemes), I thought it would be a good idea to
get the actual numbers of Kyber onto the mailing list.

Note that in the context of TLS’s key exchange, the public key would be
what goes into the ClientHello key_shares extension, and the ciphertext
would go into the Server’s ServerHello key_shares extension.

Kyber512: NIST level I, "strength ~AES128"
   public key: 800 bytes
   ciphertext: 768 bytes
   secret key: 1632 bytes


Be interested in how that'd change the CH if ECH is used too.
I guess the answer mightn't make us happy;-)

S.


Kyber768: NIST level III, "~AES192"
   public key: 1184
   ciphertext: 1088
   secret key: 2400 bytes
Kyber1024: NIST level V, "~AES256"
   public key: 1568
   ciphertext: 1568
   secret key: 3168

So for the key exchange at least, it seems to me Kyber512 should work for
TLS and QUIC just fine; Kyber768 might be a bit of a squeeze if you want to
stay in QUIC’s default 1300 byte initial packet? Also, I don't really know
how the D of DTLS might change the story.

All the numbers we reported are as of the latest version of the individual
submissions (except as discussed below). The standards that NIST eventually
names FIPS-xyz might have (mildly) different sizes. NIST has said that
they’re always happy to receive feedback and information about use cases
and constraints.

Lastly, Bas Westerbaan has talked about a Kyber draft in yesterday’s CFRG
meeting. I believe a stated goal is to use that for coordinating any
experiments before the NIST standard is out. So keep an eye out if that
interests you.

Cheers,

Thom

PS: Let me also correct the mistake I had introduced in the SPHINCS+
numbers in the TLS talk: SPHINCS+ has indeed gotten slightly smaller than
the numbers I reported. The smallest SPHINCS+ variant (sphincs+-128s) has a
signature size of 7,856 bytes. There’s a nice table with the different
parameter sets of SPHINCS+ on their Github repository
https://github.com/sphincs/sphincsplus#parameters. I’m glad that people
were paying attention, apparently more than I was :-)

I will also clarify that when we mentioned that Falcon needs very careful
attention when implementing, this concerns Falcon's signing routines. These
require constant-time double-width floating point maths; on many CPUs this
will need to be emulated in software. Verification, on the other hand, is a
lot less sensitive.


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


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PQC key exchange sizes

[Martin Thomson]

On Tue, Jul 26, 2022, at 11:21, Stephen Farrell wrote:
> Be interested in how that'd change the CH if ECH is used too.
> I guess the answer mightn't make us happy;-)

PQ HPKE would not fit, but the Kyber-512 numbers mean that we should be OK for 
ECH if we stuck with classical security.  For obvious reasons, that might not 
be OK though.

If we wanted a PQ HPKE (or a Hybrid KEM) then ECH would blow out the size so 
that we would end up with multiple packets for the CH.  That would be basically 
unworkable from a performance perspective.

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

Re: [TLS] PQC key exchange sizes

[Blumenthal, Uri - 0553 - MITLL]

What are the implications for environments that require NIST Sec Level 3 or 5?

Regards,
Uri

> On Jul 26, 2022, at 11:33, Martin Thomson  wrote:
> 
> On Tue, Jul 26, 2022, at 11:21, Stephen Farrell wrote:
>> Be interested in how that'd change the CH if ECH is used too.
>> I guess the answer mightn't make us happy;-)
> 
> PQ HPKE would not fit, but the Kyber-512 numbers mean that we should be OK 
> for ECH if we stuck with classical security.  For obvious reasons, that might 
> not be OK though.
> 
> If we wanted a PQ HPKE (or a Hybrid KEM) then ECH would blow out the size so 
> that we would end up with multiple packets for the CH.  That would be 
> basically unworkable from a performance perspective.
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


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

Re: [TLS] PQC key exchange sizes

[Martin Thomson]

On Tue, Jul 26, 2022, at 11:42, Blumenthal, Uri - 0553 - MITLL wrote:
> What are the implications for environments that require NIST Sec Level 3 or 5?

Poor performance.  By which I mean increased exposure to packet loss and 
additional round trips.  For instance, in QUIC servers might be forced to use 
Retry, which adds a round trip.

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

Re: [TLS] Extensibility in SCVP draft

[Ashley Kopman]

Rob,

I apologize, I am not sure that I fully understand your question. I originally 
created the structure of path_validation_type to make it easier in the future 
to potentially expand the extension to use other protocols for path validation. 
But Martin, Rich and Russ pointed out that this likely adds an unnecessary 
layer of nesting complexity that may never be utilized. 

Are you concerned that if additional validation extensions were added it could 
lead to multiple validations for the same handshake? If that is the case, I 
believe that this is somewhat mitigated by it being optional for the server to 
choose to perform the SCVP validation. If the TLS server were to receive 
multiple validation requests it could potentially select to perform only one.

If I have missed your point, please let me know.

Thank you,
Ashley Kopman

> On Jul 25, 2022, at 11:30 PM, Rob Sayre  wrote:
> 
> Hi,
> 
> Doesn’t it depend on whether it would be easier to do this select* or deal 
> with multiple validations in the same message? No one’s said that exactly 
> afaik, but I haven’t watched the meeting yet.
> 
> thanks,
> Rob
> 
> * in the recent past, the stuff I’ve worked on has made this easy, but I 
> agree they’re a bit annoying.
> 
> On Mon, Jul 25, 2022 at 13:25 Russ Housley  > wrote:
> I was thinking the same thing during the presentation.  An extension for SCVP 
> seems fine to me.  Then in the future, if another validation comes along some 
> day, a new extension can be assigned for that protocol.
> 
> Russ
> 
> > On Jul 25, 2022, at 4:13 PM, Martin Thomson  > > wrote:
> > 
> > Take this:
> > 
> > struct {
> > PathValidationType path_validation_type;
> > select (path_validation_type) {
> >  case scvp: SCVPValidationRequest;
> > } request;
> > } PathValidationRequest;
> > enum { scvp(1), (255) } PathValidationType;
> > 
> > This adds a layer of extensibility that doesn't do a lot.  Please consider 
> > making this less generic.  If we want a different validation design, then 
> > another extension can be defined.  We have a poor track record of being 
> > able to use these nested extension points and it will be more efficient to 
> > just put the SCVP pieces in their own extension.
> 
> ___
> 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] Extensibility in SCVP draft

[Rob Sayre]

On Tue, Jul 26, 2022 at 9:08 AM Ashley Kopman 
wrote:

>
> Are you concerned that if additional validation extensions were added it
> could lead to multiple validations for the same handshake? If that is the
> case, I believe that this is somewhat mitigated by it being optional for
> the server to choose to perform the SCVP validation. If the TLS server were
> to receive multiple validation requests it could potentially select to
> perform only one.
>

Hi,

It's correct that this is my concern, and I thought you might consider
adding text along these lines to the document.

I don't feel strongly about this issue, though.

thanks,
Rob






>
> If I have missed your point, please let me know.
>
> Thank you,
> Ashley Kopman
>
> On Jul 25, 2022, at 11:30 PM, Rob Sayre  wrote:
>
> Hi,
>
> Doesn’t it depend on whether it would be easier to do this select* or deal
> with multiple validations in the same message? No one’s said that exactly
> afaik, but I haven’t watched the meeting yet.
>
> thanks,
> Rob
>
> * in the recent past, the stuff I’ve worked on has made this easy, but I
> agree they’re a bit annoying.
>
> On Mon, Jul 25, 2022 at 13:25 Russ Housley  wrote:
>
>> I was thinking the same thing during the presentation.  An extension for
>> SCVP seems fine to me.  Then in the future, if another validation comes
>> along some day, a new extension can be assigned for that protocol.
>>
>> Russ
>>
>> > On Jul 25, 2022, at 4:13 PM, Martin Thomson  wrote:
>> >
>> > Take this:
>> >
>> > struct {
>> > PathValidationType path_validation_type;
>> > select (path_validation_type) {
>> >  case scvp: SCVPValidationRequest;
>> > } request;
>> > } PathValidationRequest;
>> > enum { scvp(1), (255) } PathValidationType;
>> >
>> > This adds a layer of extensibility that doesn't do a lot.  Please
>> consider making this less generic.  If we want a different validation
>> design, then another extension can be defined.  We have a poor track record
>> of being able to use these nested extension points and it will be more
>> efficient to just put the SCVP pieces in their own extension.
>>
>> ___
>> 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] Extensibility in SCVP draft

[Ashley Kopman]

That is a good suggestion. I will look into expanding on the text to address 
this concern.

Thank you,

Ashley

> On Jul 26, 2022, at 1:33 PM, Rob Sayre  wrote:
> 
> On Tue, Jul 26, 2022 at 9:08 AM Ashley Kopman  > wrote:
> 
> Are you concerned that if additional validation extensions were added it 
> could lead to multiple validations for the same handshake? If that is the 
> case, I believe that this is somewhat mitigated by it being optional for the 
> server to choose to perform the SCVP validation. If the TLS server were to 
> receive multiple validation requests it could potentially select to perform 
> only one.
> 
> Hi,
> 
> It's correct that this is my concern, and I thought you might consider adding 
> text along these lines to the document.
> 
> I don't feel strongly about this issue, though.
> 
> thanks,
> Rob
> 
> 
> 
> 
>  
> 
> If I have missed your point, please let me know.
> 
> Thank you,
> Ashley Kopman
> 
>> On Jul 25, 2022, at 11:30 PM, Rob Sayre > > wrote:
>> 
>> Hi,
>> 
>> Doesn’t it depend on whether it would be easier to do this select* or deal 
>> with multiple validations in the same message? No one’s said that exactly 
>> afaik, but I haven’t watched the meeting yet.
>> 
>> thanks,
>> Rob
>> 
>> * in the recent past, the stuff I’ve worked on has made this easy, but I 
>> agree they’re a bit annoying.
>> 
>> On Mon, Jul 25, 2022 at 13:25 Russ Housley > > wrote:
>> I was thinking the same thing during the presentation.  An extension for 
>> SCVP seems fine to me.  Then in the future, if another validation comes 
>> along some day, a new extension can be assigned for that protocol.
>> 
>> Russ
>> 
>> > On Jul 25, 2022, at 4:13 PM, Martin Thomson > > > wrote:
>> > 
>> > Take this:
>> > 
>> > struct {
>> > PathValidationType path_validation_type;
>> > select (path_validation_type) {
>> >  case scvp: SCVPValidationRequest;
>> > } request;
>> > } PathValidationRequest;
>> > enum { scvp(1), (255) } PathValidationType;
>> > 
>> > This adds a layer of extensibility that doesn't do a lot.  Please consider 
>> > making this less generic.  If we want a different validation design, then 
>> > another extension can be defined.  We have a poor track record of being 
>> > able to use these nested extension points and it will be more efficient to 
>> > just put the SCVP pieces in their own extension.
>> 
>> ___
>> 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] PQC key exchange sizes

[Kampanakis, Panos]

Hi Ilari,

> - DTLS-level fragmentation. There are buggy implementations that break if one 
> tries this.

DTLS servers have been fragmenting and sending cert chains that don’t fit in 
the MTU for a long time. Is this buggy on the TLS client side? Any public info 
you can share about these buggy implementations for my education?



-Original Message-
From: TLS  On Behalf Of Ilari Liusvaara
Sent: Tuesday, July 26, 2022 10:59 AM
To:  
Subject: RE: [EXTERNAL][TLS] PQC key exchange sizes

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.



On Tue, Jul 26, 2022 at 02:15:34PM +0200, Thom Wiggers wrote:
>
> In yesterday’s working group meeting we had a bit of a discussion of 
> the impact of the sizes of post-quantum key exchange on TLS and 
> related protocols like QUIC. As we neglected to put Kyber’s key sizes 
> in our slide deck (unlike the signature schemes), I thought it would 
> be a good idea to get the actual numbers of Kyber onto the mailing list.
>
> Note that in the context of TLS’s key exchange, the public key would 
> be what goes into the ClientHello key_shares extension, and the 
> ciphertext would go into the Server’s ServerHello key_shares extension.
>
> Kyber512: NIST level I, "strength ~AES128"
>   public key: 800 bytes
>   ciphertext: 768 bytes
>   secret key: 1632 bytes
> Kyber768: NIST level III, "~AES192"
>   public key: 1184
>   ciphertext: 1088
>   secret key: 2400 bytes
> Kyber1024: NIST level V, "~AES256"
>   public key: 1568
>   ciphertext: 1568
>   secret key: 3168
>
> So for the key exchange at least, it seems to me Kyber512 should work 
> for TLS and QUIC just fine; Kyber768 might be a bit of a squeeze if 
> you want to stay in QUIC’s default 1300 byte initial packet? Also, I 
> don't really know how the D of DTLS might change the story.

The initial packet size is 1200, so Kyber768 public key does not fit into a 
packet. However, the initial packets can be split, so even
Kyber1024 key does fit into two initial packets (this also doubles the server 
initial window from 3600 to 7200 due to the way amplification limit works)


DTLS is a bit more problematic. There are two ways to deal with the key being 
too big to fit in a single IP packet.

- IP-level fragmentation. REALLY SHOULD NOT be used.
- DTLS-level fragmentation. There are buggy implementations that break
  if one tries this.

And in both case, the failure modes are not easy to recover from.




-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