Hi all,
DSA is supported in the previous versions of TLS. It would be nice if someone
who uses DSA can use it in TLS 1.3 as well.
People who don't use DSA, then they don't use DSA. People who use DSA right, it
should be fine for them to use DSA.
I don't see a convincing reason to remove sup
laces than just public servers and common
browsers. For the people who use DSA in TLSs, it would be nice if they could
run TLS 1.3 with DSA if they choose to do so.
Quynh.
From: TLS on behalf of Dang, Quynh
Sent: Friday, August 28, 2015 3:17 PM
To: e..
Hi IIari,
>From all of the RFCs about suite B that I have read, DSA has never been a part
>of it.
RSA can be used for signatures and key wrap/transport.
Quynh.
From: TLS on behalf of Ilari Liusvaara
Sent: Wednesday, September 2, 2015 1:49 PM
To: Sal
I am just curious why we need the content type here?
Quynh.
From: TLS on behalf of Dave Garrett
Sent: Tuesday, September 22, 2015 7:45 PM
To: Sean Turner
Cc: tls@ietf.org
Subject: Re: [TLS] '15 TLS Fall Interim Minutes
On Tuesday, September 22, 2015 0
How about making fixed length(s) for each message type, then pad it with 0x01
then optional 0x00s?
Quynh.
From: TLS on behalf of Dave Garrett
Sent: Friday, September 25, 2015 2:11 PM
To: tls@ietf.org; m...@sap.com
Subject: Re: [TLS] Encrypted SNI (was
Hi Eric,
As you asked the question about how many ciphertext blocks should be safe under
a single key, I think it is safe to have 2^96 blocks under a given key if the
IV (counter) is 96 bits.
When there is a collision between two ciphertext blocks when two different
counter values are used ,
Cs I generated before are useless now.
From: Watson Ladd
Sent: Monday, November 2, 2015 5:07 AM
To: Dang, Quynh
Cc: tls@ietf.org; c...@ietf.org; Eric Rescorla
Subject: Re: [Cfrg] Collision issue in ciphertexts.
On Nov 2, 2015 2:14 AM, "Dang, Quynh"
authentication.
However, rekeying often is a good thing which could help prevent disaster to
keep go on if there is something wrong with the IV or the key.
Quynh.
From: Dang, Quynh
Sent: Monday, November 2, 2015 3:00 PM
To: Watson Ladd
Cc: tls@ietf.org; c...@ietf.org
I did not talk under indistinguishability framework. My discussion was about
confidentiality protection and authentication.
Quynh.
From: Watson Ladd
Sent: Wednesday, November 4, 2015 3:17:00 PM
To: Dang, Quynh
Cc: Eric Rescorla; tls@ietf.org
Subject: Re
.
From: Tony Arcieri
Sent: Friday, November 6, 2015 7:59 PM
To: Watson Ladd
Cc: Dang, Quynh; tls@ietf.org
Subject: Re: [TLS] Data limit for GCM under a given key.
On Friday, November 6, 2015, Watson Ladd
mailto:watsonbl...@gmail.com>> wrote:
On Wed, Nov 4, 2015 at 3:43 PM, Dang, Quynh wrote:
&
Hi Eric,
I explained the issue before and some other people recently explained it again
on this thread. AES has 128-bit block. Therefore, when there are 2^64 or more
ciphertext blocks, there are likely collisions among the ciphertext blocks (the
collision probability increases rapidly when th
The collision probability of ciphertext blocks also depends on the size of the
plaintext (record size in a TLS implementation) in each call of the GCM
encryption function. Let's call each plaintext to be 2^x 128-bit blocks.
TLS 1.3 uses 96-bit IV.
If someone wants the collision probability
.
From: TLS on behalf of Dang, Quynh
Sent: Friday, December 18, 2015 10:49 AM
To: tls@ietf.org
Subject: Re: [TLS] Data volume limits
The collision probability of ciphertext blocks also depends on the size of the
plaintext (record size in a TLS
Hi all,
Why don't we use an even more elegant RSA signature called " full-domain hash
RSA signature" ?
As you know, a SHAKE (as a variable output-length hash function) naturally
produces a hash value which fits any given modulus size. Therefore, no paddings
are needed which avoids any potentia
AM
To: tls@ietf.org
Subject: Re: [TLS] RSA-PSS in TLS 1.3
On Thu, 3 Mar 2016 13:35:46 +
"Dang, Quynh (Fed)" wrote:
> Why don't we use an even more elegant RSA signature called "
> full-domain hash RSA signature" ?
Full Domain Hashing was originally developed
PSS+SHAKE128/512+SHAKE128 or PSS+SHAKE256/512+SHAKE256 (as SHAKEs being used as
MGF) would be more efficient options. NIST is working on a formal specification
for the SHAKEs being used as fixed output-length hash functions such as
SHAKE128/256, SHAKE128/512 and SHAKE256/512.
Prepending a rand
Hi Sean and all,
I support the first condition: A spec gets a "Y" when it has the IETF consensus.
Regards,
Quynh.
From: TLS on behalf of Hannes Tschofenig
Sent: Thursday, March 31, 2016 9:45 AM
To: Sean Turner;
Subject: Re: [TLS] call for consensus:
Hi Sean,
I would like to express my opinion again.
I think the first requirement is great and sufficient.
I have great support, appreciation and respect for the open source communities.
However, the second requirement means that an IETF consensus can have no values
in theory and that sounds n
Hi Stephen,
The one below can be used.
[FIPS 180-4] Federal Information Processing Standards Publication
(FIPS PUB) 180-4, Secure Hash Standard (SHS), August 2015.
Regards,
Quynh.
From: TLS on behalf of Stephen Farrell
Sent: Thursday,
Hi Eric,
1. For this text: "plus the length of the output of the signing algorithm. "
in the last paragraph of Section 4.8.1, did you mean "plus the output of the
signing algorithm." ?
2. "The length (in bytes) of the following TLSCiphertext.fragment. The length
MUST NOT exceed 2^14 + 256. An
On 5/24/16, 12:13 PM, "Martin Thomson" wrote:
>On 24 May 2016 at 08:20, Dang, Quynh (Fed) wrote:
>> 1. For this text: "plus the length of the output of the signing
>>algorithm.
>> " in the last paragraph of Section 4.8.1, did you mean "plus the o
On 5/24/16, 12:58 PM, "ilariliusva...@welho.com on behalf of Ilari
Liusvaara" wrote:
>On Tue, May 24, 2016 at 03:20:17PM +, Dang, Quynh (Fed) wrote:
>> Hi Eric,
>>
>> 1. For this text: "plus the length of the output of the signing
>> algorithm
On 5/24/16, 2:42 PM, "Martin Thomson" wrote:
>On 24 May 2016 at 10:46, Dang, Quynh (Fed) wrote:
>>>We discussed this at quite some length. I originally took your
>>>position, but the IVs add an extra layer of safety at very little
>>>cost.
>>
Hi Eric and all,
In my opinion, we should give better information about data limit for AES_GCM
in TLS 1.3 instead of what is current in the draft 14.
In this paper: http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf, what is called
confidentiality attack is the known plaintext differentiality atta
Hi Eric and all,
In my opinion, we should give better information about data limit for AES_GCM
in TLS 1.3 instead of what is current in the draft 14.
In this paper: http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf, what is called
confidentiality attack is the known plaintext differentiality atta
eaking this notion does
>not break confidentiality. Can you explain what you mean by
>"confidentiality", in a precise way? I can then try to tell you whether
>this notion will imply yours.
>
>Regards
>
>Kenny
>
>On 12/07/2016 14:04, "TLS on behalf of Dang, Quynh
>>data bytes. To come to the 2^38 record limit, they assume that each
>>record is the maximum 2^14 bytes. Of course, at a 1Gbps rate, it'd take
>>over a year to encrypt that much data...
>>
>>> -Original Message-
>>> From: TLS [mailto:tls-boun
Hi Kenny,
On 7/12/16, 1:05 PM, "Paterson, Kenny" wrote:
>Hi
>
>On 12/07/2016 16:12, "Dang, Quynh (Fed)" wrote:
>
>>Hi Kenny,
>>
>>The indistinguishability-based security notion in the paper is a stronger
>>security notion than the (old)
Hi Kenny,
On 7/12/16, 1:39 PM, "Paterson, Kenny" wrote:
>Hi
>
>On 12/07/2016 18:12, "Dang, Quynh (Fed)" wrote:
>
>>Hi Kenny,
>>
>>On 7/12/16, 1:05 PM, "Paterson, Kenny" wrote:
>>
>>>Hi
>>>
>>>On 12/
the maximum 2^14 bytes. Of course, at a 1Gbps rate, it'd take
>>over a year to encrypt that much data...
>>
>>> -Original Message-
>>> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Dang, Quynh (Fed)
>>> Sent: Tuesday, July 12, 2016 11:1
Good morning Kenny,
On 7/12/16, 3:03 PM, "Paterson, Kenny" wrote:
>Hi,
>
>> On 12 Jul 2016, at 18:56, Dang, Quynh (Fed) wrote:
>>
>> Hi Kenny,
>>
>>> On 7/12/16, 1:39 PM, "Paterson, Kenny"
>>>wrote:
>>>
>>
Hi Kenny,
On 7/12/16, 3:03 PM, "Paterson, Kenny" wrote:
>Hi,
>
>> On 12 Jul 2016, at 18:56, Dang, Quynh (Fed) wrote:
>>
>> Hi Kenny,
>>
>>> On 7/12/16, 1:39 PM, "Paterson, Kenny"
>>>wrote:
>>>
>>
, Scott Fluhrer (sfluhrer) wrote:
>>> -Original Message-
>>> From: Paterson, Kenny [mailto:kenny.pater...@rhul.ac.uk]
>>> Sent: Tuesday, July 12, 2016 1:17 PM
>>> To: Dang, Quynh (Fed); Scott Fluhrer (sfluhrer); Eric Rescorla;
>>> tls@ietf.org
>>> Su
known plaintexts. In protocols such as TLS and Ipsec, there are known
plaintexts, but I don¹t think the amount of known plaintexts (even though
the amount of encrypted repeated-plaintexts can be big) is enough to
create risk for AES_128 by the targeted plaintext recovery attack. A known
plaintex
Hi Eric and all,
Regardless of the actual record size, each 128-bit block encryption is
performed with a unique 128-bit counter which is formed by the 96-bit IV and
the 32-bit counter_block value called CB in NIST SP 800-38D under a given key
as long as the number of encrypted records is not mo
eying too often than needed would just create more room for issues for the
connection/session without gaining any additional practical security at all.
Quynh.
From: Martin Thomson
Sent: Sunday, November 13, 2016 6:54 PM
To: Dang, Quynh (Fed)
Cc: e...@rtfm.
Hi Ilari,
You were right, for testing, a smaller number should be used.
Quynh.
From: ilariliusva...@welho.com on behalf of Ilari
Liusvaara
Sent: Monday, November 21, 2016 3:42 PM
To: Dang, Quynh (Fed)
Cc: Martin Thomson; tls@ietf.org; c...@ietf.org
Hi Sean and all,
I agree with everyone that the text in (b) was not very good text.
The problem with (c) is that it is not precise at places and it leaves out a
lot of informative discussions which users should know.
The sentence "The maximum amount of plaintext data that can be safely encry
Hi Kenny,
From: TLS mailto:tls-boun...@ietf.org>> on behalf of
"Paterson, Kenny" mailto:kenny.pater...@rhul.ac.uk>>
Date: Friday, February 10, 2017 at 4:06 AM
To: Sean Turner mailto:s...@sn3rd.com>>
Cc: IRTF CFRG mailto:c...@irtf.org>>,
"mailto:tls@ietf.org>>" mailto:tls@ietf.org>>
Subject: Re:
Hi Rene,
From: TLS mailto:tls-boun...@ietf.org>> on behalf of Rene
Struik mailto:rstruik@gmail.com>>
Date: Friday, February 10, 2017 at 10:51 AM
To: Sean Turner mailto:s...@sn3rd.com>>,
"mailto:tls@ietf.org>>" mailto:tls@ietf.org>>
Cc: IRTF CFRG mailto:c...@irtf.org>>
Subject: Re: [TLS] [Cfr
tls@ietf.org>>" mailto:tls@ietf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769)
Dear Quynh,
On 10/02/2017 12:48, "Dang, Quynh (Fed)"
mailto:quynh.d...@nist.gov>> wrote:
Hi Kenny,
Hi,
My preference is to go with th
truik
Sent: Friday, February 10, 2017 2:02:14 PM
To: Dang, Quynh (Fed); Sean Turner;
Cc: IRTF CFRG
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769)
Hi Quynh:
Not sure where to start (there is vast literature on side channel attacks and
other impleme
o either measure the amount of plaintext or ciphertext.
Regards,
Quynh.
From: Paterson, Kenny
Sent: Friday, February 10, 2017 2:06:46 PM
To: Dang, Quynh (Fed); Sean Turner
Cc: IRTF CFRG;
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PR
Hi Markulf,
The probability of a bad thing to happen is actually below (or about) 2^(-33).
It practically won’t happen when the chance is 1 in 2^32. And, to achieve that
chance, you must collect 2^48 128-bit blocks.
Regards,
Quynh.
From: TLS mailto:tls-boun...@ietf.org>> on behalf of
Markulf
Hi Markulf and all,
I provided more explanation below.
From: 'Quynh' mailto:quynh.d...@nist.gov>>
Date: Monday, February 13, 2017 at 10:45 AM
To: Markulf Kohlweiss mailto:mark...@microsoft.com>>,
"Paterson, Kenny"
mailto:kenny.pater...@rhul.ac.uk>>, Sean Turner
mailto:s...@sn3rd.com>>
Cc: Anto
n't think point 2 is a problem because it gives people a good enough
heuristic, however this can be fixed easily by minimally modifying the
original text.
Atul
On 2017-02-14 03:59, Dang, Quynh (Fed) wrote:
Hi Markulf and all,
I provided more explanation below.
From: 'Quynh'
t;
Regards,
Quynh.
________
From: Dang, Quynh (Fed)
Sent: Tuesday, February 14, 2017 1:20:12 PM
To: Atul Luykx; Dang, Quynh (Fed)
Cc: Markulf Kohlweiss; Antoine Delignat-Lavaud; IRTF CFRG; tls@ietf.org
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage&q
nding to a success probability of 2^{-32}.
Atul
On 2017-02-14 11:45, Yoav Nir wrote:
Hi, Quynh
On 14 Feb 2017, at 20:45, Dang, Quynh (Fed)
mailto:quynh.d...@nist.gov>>
wrote:
Hi Sean and all,
Beside my suggestion at
https://www.ietf.org/mail-archive/web/tls/current/msg22381.html [1],
I hav
.3 "Limits on key usage" PRs
(#765/#769)
Hi Quynh,
I'm meant to be on vacation, but I'm finding this on-going discussion
fascinating, so I'm chipping in again.
On 15 Feb 2017, at 21:12, Dang, Quynh (Fed)
mailto:quynh.d...@nist.gov>> wrote:
Hi Atul,
I hope you
Hi Sean, Joe, Eric and all,
I would like to address my thoughts/suggestions on 2 issues in option a.
1) The data limit should be addressed in term of blocks, not records. When the
record size is not the full size, some user might not know what to do. When the
record size is 1 block, the limit
g>>
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).
On 25 Feb 2017, at 14:28, Dang, Quynh (Fed)
mailto:quynh.d...@nist.gov>> wrote:
Hi Sean, Joe, Eric and all,
I would like to address my thoughts/suggestions on 2 issues in option a.
1) The data li
gt;>" mailto:tls@ietf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769).
Hi,
On 01/03/2017 14:31, "TLS on behalf of Dang, Quynh (Fed)"
mailto:tls-boun...@ietf.org> on behalf of
quynh.d...@nist.gov<mailto:quynh.d...@nist.g
g>>
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).
On 01 Mar 2017, at 13:18, Dang, Quynh (Fed)
mailto:quynh.d...@nist.gov>> wrote:
From: Aaron Zauner mailto:a...@azet.org>>
Date: Wednesday, March 1, 2017 at 8:11 AM
To: 'Quynh' mai
What is the percentage ? Even all records were small, providing a correct
number would be a good thing. If someone wants to rekey a lot often, I am not
suggesting against that.
Quynh.
because they result from small writes.
On Mar 1, 2017 6:48 AM, "Dang, Quynh (Fed)"
mailto:quynh.d...@ni
;,
"tls@ietf.org<mailto:tls@ietf.org>" mailto:tls@ietf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769).
On 2 March 2017 at 05:44, Dang, Quynh (Fed)
mailto:quynh.d...@nist.gov>> wrote:
OK. What is the percentage ? E
This website has a good summary of the candidates:
https://pqc-wiki.fau.edu/w/Special:DatabaseHome .
Quynh.
From: TLS on behalf of Martin Thomson
Sent: Wednesday, February 12, 2020 4:57 PM
To: Blumenthal, Uri - 0553 - MITLL ; tls@ietf.org
Subject: Re: [TLS]
Hi Rich, Sean and all,
1) Traditionally, a HKDF-Extract is used to extract entropy from a DH type
shared secret. However, the first HKDF-Extract in the key schedule takes a PSK
instead of a DH shared secret.
We don't see security problems with this instance in TLS 1.3. NIST requires the
PSK to
d for being used as expansion steps.
Regards,
Quynh.
From: "Torsten Schütze"
Sent: Tuesday, May 12, 2020 7:39 AM
To: Hugo Krawczyk
Cc: Dang, Quynh H. (Fed) ; c...@ietf.org ;
tls@ietf.org ; rs...@akamai.com
Subject: Re: [Cfrg] NIST crypto group and HKDF (a
, we'll publish their test vectors.
Regards,
Quynh.
From: "Torsten Schütze"
Sent: Tuesday, May 12, 2020 8:36 AM
To: Dang, Quynh H. (Fed)
Cc: Hugo Krawczyk ; c...@ietf.org ;
tls@ietf.org ; rs...@akamai.com
Subject: Aw: Re: [Cfrg] NIST crypto group
Hi Kris and Deirdre,
We talked about cases of X||Y internally at NIST.
1) X is a raw shared secret such as Z in 56C and Y is the output of a
NIST-approved PQ KEM. Their order can be reversed. This should be approved for
PQ security solution.
2) X is an output of a NIST-approved classical key
Hi Eric and all,
NIST allows the shared secret key, called K, of a ML-KEM to be in the place of
Z (a raw shared secret) in 56C.
In 56C, Z can be X||Y, but X must be either a raw shared secret generated by a
NIST-approved key agreement/establishment method or K.
A X25519’s raw shared secret or
Hi all,
Be noted that in this discussion, I don't speak on behalf of anybody else
including the NIST PQC team and my message does not intent to imply any
technical policies in the future. I just wanted to explain some technical
matters.
In SP 800-56C, we specified Z = Z' || T as an option whe
KeyGen is very cheap (generally). So, for many use cases, it seems it does not
make sense to keep a private key around for later uses.
In very constrained environments, if the goal is to save computation as much as
possible, some users could decide to reuse keys.
Regards,
Quynh.
From: Richard
Hi all,
It is sad to know that many people would like to join in the discussions but
decide not to do so because of their anticipation of the pain they would get
and the time they would need to spend.
There are ways to help the situation. For example, the chairs could decide to
say that 80% a
The server can detect a reused encapsulation key if it saves the keys which
have been received and check the newly received key against the list of its
saved keys. The server could just save the hashes of the keys or a "small"
portion of the keys as the key IDs. My guess is that that would be a
65 matches
Mail list logo
