[TLS] (selection criteria for crypto primitives) Re: sect571r1

[Rene Struik]

Dear colleagues:

It seems prudent to keep some diversity of the gene pool and not only 
have curves defined over prime curves. Similarly, one should perhaps 
have some diversity of gene pool criteria within the set of recommend 
curves and not only include special primes. Should some problem with a 
particular subclass show up over time, one then at least has other 
classes available.


On a general note, I do not understand what is wrong with having a 
dictionary of curves that is well-specified, but whose members are not 
all widely used. To my knowledge, having a dictionary does not force 
everyone to use every term in this (mandatory vs. optional to implement 
vs. mandatory to use, etc.).


If one follows the line of reasoning of some people on the mailing list 
earlier today, doesn't this also call into question Brainpool curves, 
or, e.g., the Misty cipher, etc.? Moreover, this certainly calls into 
question why one would have a whole set of new DLP groups (which 
certainly cannot be widely used yet, since the ink to write the 
parameters down is still wet). What about RSA-1024, etc.?


I would suggest one to have a clear criteria by which to judge 
inclusion/exclusion of cryptographic algorithms.


As a final note: if one can define curves explicitly, then removing 
these from a list does  not really remove them, except "pestering" 
people who would like to use them by forcing sending big chunks of 
descriptive text instead of short-hand references.


Best regards, Rene

On 7/15/2015 8:20 PM, Martin Rex wrote:

Tony Arcieri wrote:
[ Charset UTF-8 unsupported, converting... ]

Dave Garrett  wrote:

It's the most used of the rarely used curves.


I think all "rarely used curves" should be removed from TLS. Specifically,
I think it would make sense for TLS to adopt a curve portfolio like this:

- CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks
- NIST curves (SUPPORTED): P-256, P-384, P-521

P-256 and P-384 seem to be pretty important to some folks
(those with a NIST/NSA Suite B checklist).  I'm OK with P-521,
but I would prefer to get rid of pretty much all _other_
NIST curves with unexplained parameters, including 571

Either the NIST curves with unexplained constants _are_ backdoored,
then you get screwed no matter which one of them you use.
Or the NIST curves are OK, then P-521 will be good enough.  IMO.

-Martin


Microsoft SChannel seems to implent the 3 NIST curves (P-256, P-384, P-521),
and MSIE 10 exhibits a curious behaviour on my Win7 machine:
when only TLSv1.0 is enabled, then MSIE 10 sends a ClientHello
with P-521 as the first curve in the named_curve extension.
when TLSv1.2 is also enabled, then MSIE 10 sends a ClientHello
with P-256 as the first curve in the named_curve extension.

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



--
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

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

Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1

[Rene Struik]

Of potential interest to this group:

Steven Galbraith's perspective on papers, such as IACR ePrint 2015-310:
https://ellipticnews.wordpress.com/2015/04/13/elliptic-curve-discrete-logarithm-problem-in-characteristic-two/

Best regards, Rene

On 7/16/2015 9:08 AM, Blumenthal, Uri - 0553 - MITLL wrote:
I think you convinced me. And to think of it, I never did like binary 
curves. :-)


No binary curves for the future. :-)

Tnx!

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
*From: *Tony Arcieri
*Sent: *Wednesday, July 15, 2015 22:32
*To: *Rene Struik
*Cc: *
*Subject: *Re: [TLS] (selection criteria for crypto primitives) Re: 
sect571r1


‎
To respond more specifically to your concerns:

On Wed, Jul 15, 2015 at 6:42 PM, Rene Struik <mailto:rstruik@gmail.com>> wrote:


It seems prudent to keep some diversity of the gene pool and not
only have curves defined over prime curves. Similarly, one should
perhaps have some diversity of gene pool criteria within the set
of recommend curves and not only include special primes. Should
some problem with a particular subclass show up over time, one
then at least has other classes available.


Binary curves in particular are showing warning signs of potential 
future security issues:


https://eprint.iacr.org/2015/310.pdf

I think even if we don't completely pare down the TLS curve portfolio 
to the list I suggested, if nothing else I would like to see binary 
curves removed.


--
Tony Arcieri
‎



--
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

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

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Rene Struik]

Dear colleagues:

I think this document should absolutely *not* be adopted, without 
providing far more technical justification. The quoted Raccoon attack is 
an easy to mitigate attack (which has nothing to do with finite field 
groups, just with poor design choices of postprocessing, where one uses 
variable-size integer representations for a key). There are also good 
reasons to have key exchanges where one of the parties has a static key, 
whether ecc-based or ff-based (e.g., sni, opaque), for which secure 
implementations are known. No detail is provided and that alone should 
be sufficient reason to not adopt.


Rene

On 2021-07-29 5:50 p.m., Joseph Salowey wrote:
This is a working group call for adoption for Deprecating FFDH(E) 
Ciphersuites in TLS (draft-bartle-tls-deprecate-ffdhe-00 
). 
We had a presentation for this draft at the IETF 110 meeting and since 
it is a similar topic to the key exchange deprecation draft the chairs 
want to get a sense if the working group wants to adopt this draft 
(perhaps the drafts could be merged if both move forward).  Please 
review the draft and post your comments to the list by Friday, August 
13, 2021.


Thanks,

The TLS chairs

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



--
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

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

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Rene Struik]

{officially on vacation till Labor Day, but weighing-in briefly}

Hi Filippo:

I had a brief look at the CVEs you referenced and at your Blackhat 2018 
presentation.


Some observations on your Blackhat 2018 presentaton: (a) the attack 
seems to be a reincarnation of the so-called Goubin attack presented 19 
years earlier (in 1999); (b) the attack requires many (100s) of reuses 
of the same private key string. Both the 1999 attack and your Blackhat 
2018 version can be easily prevented if one uses blinded private keys.


A closer look at your referenced CVEs suggests these can be classified 
as (i) lack of checking for improperly generated DH groups; (ii) 
exploiting overflow/underflow/carry bugs. To me, nothing seems to be new 
here and more likely a failure of implementers to heed to results and 
advice predating the CVEs by years (and sometimes decades) or in QA 
processes. E.g., with respect to (i), one had not gotten oneself into 
trouble if one had actually bothered to implement domain parameter 
checks. In the literature of implementation attacks, OpenSSL has proven 
to be an excellent "implementation security flaw paper generator".


I have yet to see evidence that ephemeral-static ECDH would be 
inherently insecure.


Rene

On 2021-08-27 9:34 a.m., Filippo Valsorda wrote:

[snip]

This is empirically disproved by a number of vulnerabilities that are 
exploitable (or near-misses for other reasons) only in 
ephemeral-static mode, such as CVE-2016-0701, CVE-2016-7055, 
CVE-2017-3732, CVE-2017-3736, CVE-2017-3738, CVE-2019-1551 just in the 
past 5 years in OpenSSL, and CVE-2017-8932 and CVE-2021-3114 in Go. 
https://eprint.iacr.org/2011/633  
gives a good explanation of how these attacks work, and you might find 
https://i.blackhat.com/us-18/Wed-August-8/us-18-Valsorda-Squeezing-A-Key-Through-A-Carry-Bit-wp.pdf 
 
interesting as well.


OpenSSL:

CVE-2016-0701: improper generation of Diffie-Hellman group

The DH_check_pub_key function in crypto/dh/dh_check.c in OpenSSL 1.0.2 
before 1.0.2f does not ensure that prime numbers are appropriate for 
Diffie-Hellman (DH) key exchange, which makes it easier for remote 
attackers to discover a private DH exponent by making multiple 
handshakes with a peer that chose an inappropriate number, as 
demonstrated by a number in an X9.42 file.


CVE-2016-7055: carry-propagation bug

There is a carry propagating bug in the Broadwell-specific Montgomery 
multiplication procedure in OpenSSL 1.0.2 and 1.1.0 before 1.1.0c that 
handles input lengths divisible by, but longer than 256 bits. Analysis 
suggests that attacks against RSA, DSA and DH private keys are 
impossible. This is because the subroutine in question is not used in 
operations with the private key itself and an input of the attacker's 
direct choice. Otherwise the bug can manifest itself as transient 
authentication and key negotiation failures or reproducible erroneous 
outcome of public-key operations with specially crafted input. Among 
EC algorithms only Brainpool P-512 curves are affected and one 
presumably can attack ECDH key negotiation. Impact was not analyzed in 
detail, because pre-requisites for attack are considered unlikely. 
Namely multiple clients have to choose the curve in question and the 
server has to share the private key among them, neither of which is 
default behaviour. Even then only clients that chose the curve will be 
affected.


CVE-2017-3732: carry-propagation bug

There is a carry propagating bug in the x86_64 Montgomery squaring 
procedure in OpenSSL 1.0.2 before 1.0.2k and 1.1.0 before 1.1.0d. No 
EC algorithms are affected. Analysis suggests that attacks against RSA 
and DSA as a result of this defect would be very difficult to perform 
and are not believed likely. Attacks against DH are considered just 
feasible (although very difficult) because most of the work necessary 
to deduce information about a private key may be performed offline. 
The amount of resources required for such an attack would be very 
significant and likely only accessible to a limited number of 
attackers. An attacker would additionally need online access to an 
unpatched system using the target private key in a scenario with 
persistent DH parameters and a private key that is shared between 
multiple clients. For example this can occur by default in OpenSSL DHE 
based SSL/TLS ciphersuites. Note: This issue is very similar to 
CVE-2015-3193 but must be treated as a separate problem.


CVE-2017-3736: carry-propagation bug

There is a carry propagating bug in the x86_64 Montgomery squaring 
procedure in OpenSSL before 1.0.2m and 1.1.0 before 1.1.0g. No EC 
algorithms are affected. Analysis suggests that attacks against RSA 
and DSA as a result of this defect would be very difficult to perform 
and are not believed likely. Attacks against DH are considered just 
feasib

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Rene Struik]

 On Sun, Aug 22, 2021 at 9:32 PM Carrick Bartle
mailto:cbartle...@icloud.com>> wrote:


>   which is a main reason cited for deprecating RSA
in draft-aviram-tls-deprecate-obsolete-kex.

Have the authors look at Post-Quantum KEMs?


I'm not sure why PQ KEMs are relevant here.



On Aug 17, 2021, at 10:41 AM, Blumenthal, Uri - 0553 - MITLL
mailto:u...@ll.mit.edu>> wrote:

> Regardless of the Raccoon attack, the static DH and ECDH
ciphersuites do not provide
> forward secrecy,

Unless you use semi-static exchange, which in many cases
makes sense.

>   which is a main reason cited for deprecating RSA
in draft-aviram-tls-deprecate-obsolete-kex.

Have the authors look at Post-Quantum KEMs?

> Do you object to just the citation of the Raccoon attack
or do you also feel that we
> should keep these ciphersuites that do not provide forward
secrecy around?

I think these suites should stay around.

While static-static indeed do not provide forward secrecy
(and many of us – though not everybody! – carry for that),
static-ephemeral DH and ECDH are perfectly fine from that
point of view.



On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 -
MITLL mailto:u...@ll.mit.edu>> wrote:

I agree with Rene’s points.

-- 
Regards,

Uri


*From:*TLS mailto:tls-boun...@ietf.org>> on behalf of Rene Struik
mailto:rstruik@gmail.com>>
*Date:*Friday, August 13, 2021 at 09:58

Dear colleagues:

I think this document should absolutely *not* be adopted,
without providing far more technical justification. The
quoted Raccoon attack is an easy to mitigate attack (which
has nothing to do with finite field groups, just with poor
design choices of postprocessing, where one uses
variable-size integer representations for a key). There are
also good reasons to have key exchanges where one of the
parties has a static key, whether ecc-based or ff-based
(e.g., sni, opaque), for which secure implementations are
known. No detail is provided and that alone should be
sufficient reason to not adopt.

Rene

On 2021-07-29 5:50 p.m., Joseph Salowey wrote:

This is a working group call for adoption for Deprecating
FFDH(E) Ciphersuites in TLS
(draft-bartle-tls-deprecate-ffdhe-00
<https://datatracker.ietf.org/doc/draft-bartle-tls-deprecate-ffdhe/>).
We had a presentation for this draft at the IETF 110
meeting and since it is a similar topic to the key
exchange deprecation draft the chairs want to get a sense
if the working group wants to adopt this draft (perhaps
the drafts could be merged if both move forward). Please
review the draft and post your comments to the list by
Friday, August 13, 2021.

Thanks,

The TLS chairs


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



-- 
email:rstruik@gmail.com  <mailto:rstruik@gmail.com>  | Skype: rstruik

cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

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


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



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


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



--
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

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

[TLS] (crypto agility may benefit from private extensions) Re: Additional changes for draft-ietf-tls-iana-registry-updates

[Rene Struik]

Hi Sean:

Quick question: does "closing the registry" not contradict catering towards 
crypto agility? What happens if, say, one wishes to add another signature 
scheme, besides Ed25519, to the mix. If there is no private field, does this 
mean that, e.g., Schnorr+BSI Brainpool256r1 is now ruled out? 

My more serious concern is, however, that if the Private Use case is 
"verboten", there is no chance for people to signal private extensions (since 
IETF will just have killed this off).

I do not think it is prudent to have a slow process in place (IETF 
standardization) to effectuate crypto agility, if private use can already do 
this without waiting for 3-year public discussions and heated debate (if a 
weakness is discovered, dark forces will exploit this right away and won't wait 
for IETF to catch up to exploit an issue).

As case in point, suppose US Gov't wants to roll its own "Suite A" scheme, or 
if one wants to use TLS with something tailored towards the sensor world (which 
operates in quite a hostile environment for implementation security), how is 
one going to do this in context of TLS if the signaling required has just been 
removed?

NOTE: this is not an invite for endless discussions on the legitimacy of 
whoever may wish a private extensions (it is private after all), it does 
question though the wisdom of removing the option for using this. If Zulu hour 
arrives, one should have tools to act...

Best regards, Rene

On 3/16/2018 10:01 AM, Sean Turner wrote:
> During Adam Roach’s AD review of draft-ietf-tls-tls13, he noted something 
> about the HashAlgorithm and that made me go look at what was said in 
> draft-ietf-tls-iana-registry-updates.  Turns out that 4492bis assigned some 
> values draft-ietf-tls-iana-registry-updates was marking as reserved.  I have 
> fixed that up in:
> https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/65
>
> One further point brought out in discussions with Adam was that if we’re 
> really closing the HashAlgorithm and SignatureAlgorithms registry we need to 
> also mark 224-255 as deprecated.  Currently these are marked as Reserved for 
> Private Use.  So the question is should we mark 224-255 as deprecated in 
> these two registries?
>
> spt
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


-- 
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

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

Re: [TLS] (crypto agility may benefit from private extensions) Re: Additional changes for draft-ietf-tls-iana-registry-updates

[Rene Struik]

Hi Eric:

I may have an incorrect impression about the code points, but, let us
say, one finds out an attack on one of the TLS1.3 algorithms and wishes
to swap the algorithm set for a new one (that is clearly specified, say,
"RS-Alg-X"). How does one do this if one marks 224-255 as deprecated.
How does one signal private use of "RS-Alg-X" now. If you could tell me,
please let me know, so that I feel more at ease with this. {This should
not be something where reliability is impossible to achieve).

Thanks!

Rene

> One further point brought out in discussions with Adam was that if
we’re really closing the HashAlgorithm and SignatureAlgorithms registry
we need to also mark 224-255 as deprecated.  Currently these are marked
as Reserved for Private Use.  So the question is should we mark 224-255
as deprecated in these two registries?

On 3/20/2018 10:54 AM, Eric Rescorla wrote:
>
>
> On Tue, Mar 20, 2018 at 2:51 PM, Rene Struik  <mailto:rstruik@gmail.com>> wrote:
>
> Hi Sean:
>
> Quick question: does "closing the registry" not contradict
> catering towards crypto agility? What happens if, say, one wishes
> to add another signature scheme, besides Ed25519, to the mix. If
> there is no private field, does this mean that, e.g., Schnorr+BSI
> Brainpool256r1 is now ruled out?
>
>
> No. Private just means "we're not going to allocate these code points,
> so you should use them without coordination".
>
> The key point here is that this is a big space and so we're instead
> going to make it easy for people to reserve code points by writing a
> stable spec, that need not be an IETF standard, and that's what they
> should do.
>
>
> -Ekr
>  
>
>
> My more serious concern is, however, that if the Private Use case
> is "verboten", there is no chance for people to signal private
> extensions (since IETF will just have killed this off).
>
> I do not think it is prudent to have a slow process in place (IETF
> standardization) to effectuate crypto agility, if private use can
> already do this without waiting for 3-year public discussions and
> heated debate (if a weakness is discovered, dark forces will
> exploit this right away and won't wait for IETF to catch up to
> exploit an issue).
>
> As case in point, suppose US Gov't wants to roll its own "Suite A"
> scheme, or if one wants to use TLS with something tailored towards
> the sensor world (which operates in quite a hostile environment
> for implementation security), how is one going to do this in
> context of TLS if the signaling required has just been removed?
>
> NOTE: this is not an invite for endless discussions on the
> legitimacy of whoever may wish a private extensions (it is private
> after all), it does question though the wisdom of removing the
> option for using this. If Zulu hour arrives, one should have tools
> to act...
>
> Best regards, Rene
>
> On 3/16/2018 10:01 AM, Sean Turner wrote:
> > During Adam Roach’s AD review of draft-ietf-tls-tls13, he noted
> something about the HashAlgorithm and that made me go look at what
> was said in draft-ietf-tls-iana-registry-updates.  Turns out that
> 4492bis assigned some values draft-ietf-tls-iana-registry-updates
> was marking as reserved.  I have fixed that up in:
> >
> https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/65
> <https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/65>
> >
> > One further point brought out in discussions with Adam was that
> if we’re really closing the HashAlgorithm and SignatureAlgorithms
> registry we need to also mark 224-255 as deprecated.  Currently
> these are marked as Reserved for Private Use.  So the question is
> should we mark 224-255 as deprecated in these two registries?
> >
> > spt
> > ___
> > TLS mailing list
> > TLS@ietf.org <mailto:TLS@ietf.org>
> > https://www.ietf.org/mailman/listinfo/tls
> <https://www.ietf.org/mailman/listinfo/tls>
>
>
> --
> email: rstruik@gmail.com <mailto:rstruik@gmail.com> |
> Skype: rstruik
> cell: +1 (647) 867-5658  | US: +1
> (415) 690-7363 
>
> ___
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls
> <https://www.ietf.org/mailman/listinfo/tls>
>
>

-- 
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

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

Re: [TLS] Draft for SM cipher suites used in TLS1.3

[Rene Struik]

Hi Paul:

I tried and look up the documents GMT.0009-2012 and GBT.32918.5-2016 on 
the (non-secured) websites you referenced, but only found Chinese 
versions (and Chinese website navigation panels [pardon my poor language 
skills here]). Since the ISO documents are not available to the general 
public without payment, it would be helpful to have a freely available 
document (in English) from an authoritative source. Having such a 
reference available would be helpful to the IETF community (and 
researchers). Please note that BSI provides its specifications in German 
and English, so as to foster use/study by the community. If the Chinese 
national algorithms would be available in similar form, this would serve 
a similar purpose.


FYI - I am interested in full details and some time last year I tried to 
download specs, but only Parts 2, 4, and 5 were available [1], [2], [3], 
not Parts 1 and 3.


Best regards, Rene

[1] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - 
Part 5 - Parameter Definition (SEMB, July 24, 2018)
[2] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - 
Part 2 - Digital Signature Algorithm (SEMB, July 24, 2018)
[3] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - 
Part 4 - Public Key Encryption Algorithm (SEMB, July 24, 2018)


On 8/15/2019 10:16 AM, Paul Yang wrote:

Hi all,

I have submitted a new internet draft to introduce the SM cipher 
suites into TLS 1.3 protocol.


https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00

SM cryptographic algorithms are originally a set of Chinese national 
algorithms and now have been (or being) accepted by ISO as 
international standards, including SM2 signature algorithm, SM3 hash 
function and SM4 block cipher. These algorithms have already been 
supported some time ago by several widely used open source 
cryptographic libraries including OpenSSL, BouncyCastle, Botan, etc.


Considering TLS1.3 is being gradually adopted in China's internet 
industry, it's important to have a normative definition on how to use 
the SM algorithms with TLS1.3, especially for the mobile internet 
scenario. Ant Financial is the company who develops the market leading 
mobile app 'Alipay' and supports payment services for Alibaba 
e-commerce business. We highly are depending on the new TLS1.3 
protocol for both performance and security purposes. We expect to have 
more deployment of TLS1.3 capable applications in China's internet 
industry by this standardization attempts.


It's very appreciated to have comments from the IETF TLS list :-)

Many thanks!

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



--
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

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

[TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3

[Rene Struik]

Arguably, "national" crypto specifications garnish more stature if these 
are made available to the pubic by that standard-setting body itself 
(who, thereby, acts as its authoritative source), without deference to a 
third party (that may, independently from the originator, enforce 
document control [e.g., by effectuating technical changes or enforcing 
controlled dissemination]).


Since your draft introducing SM cipher suites with TLS1.3 appeals to the 
authority of a standard-setting authority, easy availability of the full 
and accredited technical documentation to the IETF community helps in 
scrutiny and, e.g., evaluating claims in the security considerations 
section.


On 8/16/2019 3:06 AM, Kepeng Li wrote:

Hi Rene and all,

> Since the ISO documents are not available to the general > public without payment, it would be helpful to have a freely 
available > document (in English) from an authoritative source. Having 
such a > reference available would be helpful to the IETF community 
(and > researchers).
About the references to ISO documens, I think it is a general issue 
for IETF drafts.


How does the other IETF drafts make the references to ISO documents? 
ISO documents are often referenced by IETF drafts.


Thanks,

Kind Regards
Kepeng
——


  Re: [TLS] Draft for SM cipher suites used in TLS1.3

Rene Struik mailto:rstruik@gmail.com>>Thu, 
15 August 2019 15:34 UTCShow header 
<https://mailarchive.ietf.org/arch/browse/tls/?index=NHbHOGtsR1S5cCr9nWN9_sdyTgg&gbt=1#>


Hi Paul:

I tried and look up the documents GMT.0009-2012 and GBT.32918.5-2016 on
the (non-secured) websites you referenced, but only found Chinese
versions (and Chinese website navigation panels [pardon my poor language
skills here]). Since the ISO documents are not available to the general
public without payment, it would be helpful to have a freely available
document (in English) from an authoritative source. Having such a
reference available would be helpful to the IETF community (and
researchers). Please note that BSI provides its specifications in German
and English, so as to foster use/study by the community. If the Chinese
national algorithms would be available in similar form, this would serve
a similar purpose.

FYI - I am interested in full details and some time last year I tried to
download specs, but only Parts 2, 4, and 5 were available [1], [2], [3],
not Parts 1 and 3.

Best regards, Rene

[1] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC -
Part 5 - Parameter Definition (SEMB, July 24, 2018)
[2] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC -
Part 2 - Digital Signature Algorithm (SEMB, July 24, 2018)
[3] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC -
Part 4 - Public Key Encryption Algorithm (SEMB, July 24, 2018)

On 8/15/2019 10:16 AM, Paul Yang wrote:
> Hi all,
>
> I have submitted a new internet draft to introduce the SM cipher 
> suites into TLS 1.3 protocol.

>
> https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00
>
> SM cryptographic algorithms are originally a set of Chinese national 
> algorithms and now have been (or being) accepted by ISO as 
> international standards, including SM2 signature algorithm, SM3 hash 
> function and SM4 block cipher. These algorithms have already been 
> supported some time ago by several widely used open source 
> cryptographic libraries including OpenSSL, BouncyCastle, Botan, etc.

>
> Considering TLS1.3 is being gradually adopted in China's internet 
> industry, it's important to have a normative definition on how to use 
> the SM algorithms with TLS1.3, especially for the mobile internet 
> scenario. Ant Financial is the company who develops the market leading 
> mobile app 'Alipay' and supports payment services for Alibaba 
> e-commerce business. We highly are depending on the new TLS1.3 
> protocol for both performance and security purposes. We expect to have 
> more deployment of TLS1.3 capable applications in China's internet 
> industry by this standardization attempts.

>
> It's very appreciated to have comments from the IETF TLS list :-)
>
> Many thanks!
>
> ___
> TLS mailing list
> TLS@ietf.org  <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls



--
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

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

[TLS] (question on ANSI X9.62-2005) Re: Ecdsa-sig-value in TLS 1.3 – need for erratum?

[Rene Struik]

Hi Dan:

Just curious about the fate of ANSI X9.62-2005: On the website below, this specification 
is still listed as "active" (whereas ANSI X9.62-1998 is labelled historic).
I purchased that spec for a project on Nov 22, 2016 from the ANSI webstore 
(when, surely, it was not labelled as expired) [see purchase info below].

What happened? Was someone sleeping at the wheel? Why would there be a completely 
differently named "revival", ANSI X9.142, with almost the same content, under 
way, and why would its fate, 4 years after 2015, be unsure? Is there a technical reason 
ANSI did not wish to pursue this, or admin mishaps?

Rene

Note: purchase info RS from ansi store below:
Subject: Your Order Confirmation for X_458150
From: e...@ansi.org
Date: 11/22/2016, 2:57 PM
To: [snip]
25 West 43 Street
New York, NY 10036
Tel: 212.642.4900
Fax: 212.398.0023
Sold To
Rene Struik
[snip]
CANADA
Order ID X_458150
Card Received Mastercard
Charged to Account [snip]
Date 11/22/2016
Quantity Product Unit Price Total Price
1 ANSI X9.62:2005 $100.00 $100.00 Download
Total $100.00
THANK YOU FOR USING THE ANSI STANDARDS STORE.
The American National Standards Institute (ANSI) is a private non-profit 
organization that administers and
coordinates the U.S. voluntary standardization and conformity assessment system.
The standards you purchased were added to your Alerts Profile, which will allow 
you to receive an automatic
notification via email when the documents are revised or amended. You may 
manage your alerts at any time.

https://standards.globalspec.com/std/1955141/ANSI%20X9.62


On 10/1/2019 6:47 AM, Dan Brown wrote:

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 ECDSA and 
EdDSA (not ASN.1?), which many may like (even better than ANSI).
Meanwhile, SEC1, versions 1.0 and 2.0, are available, fortunately or not, 
despite my weak effort.
IETF has specs for sigs and their formats already, no?
Then there's ISO, IEEE, ...


   Original Message
From: John Mattsson
Sent: Tuesday, October 1, 2019 5:25 AM
To: Peter Gutmann; Hubert Kario; TLS@ietf.org
Subject: Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?

Hubert Kario  wrote:


Now, I don't have access to X9.62-2005, but there's a possibility of confusion.

I think references to specifications behind paywalls and other types of limited 
access is a major problem. Not only for the standardization process, but also 
for researchers and implementors. In general, I think people should be able to 
implement and analyze IETF standards without having to pay for access.

Open-access is even more important for security specifications. ANSI X.62 is 
hopefully quite well-studied, but for other references, the lack of analysis 
often leads to mistakes and unknown weaknesses.

I would like the IETF to take a much stronger stance against normative 
references to paywalls.

Cheers,
John

___
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=A-9JTBh7dU_hCbOrrx-iACEmGPbjipnEohllYGLju6I&s=p2p9Y_hh-jb_qBNaNqTbSTYE2tAuJo-BaKDbemFVLxU&e=


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



--
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

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

[TLS] (TLS1.3 - algorithm agility support is enough; no need to crystal ball gaze PQ right now, except as pass-time) Re: RSA-PSS in TLS 1.3

[Rene Struik]

Hi Scott:

I think it is really premature to speculate on features PQ-secure 
algorithms can or cannot provide (*) and try and have this influence 
*current* TLS1.3 protocol design.  Should one wish to include PQ 
algorithms in a future update of TLS1.3, one can simply specify which 
protocol ingredients those updates relate to. As long as the current 
TLS1.3 specification has some facility for implementing algorithm 
agility, one can shy away from crystal ball gazing for now.


Best regards, Rene

(*) I am not sure everyone would concur with your speculation, but 
crypto conferences may be a better venue to discuss this than a TLS 
mailing list.


On 3/7/2016 12:21 PM, Scott Fluhrer (sfluhrer) wrote:


*From:*Tony Arcieri [mailto:basc...@gmail.com]
*Sent:* Monday, March 07, 2016 11:40 AM
*To:* Scott Fluhrer (sfluhrer)
*Cc:* Nikos Mavrogiannopoulos; Hanno Böck; Blumenthal, Uri - 0553 - 
MITLL; tls@ietf.org

*Subject:* Re: [TLS] RSA-PSS in TLS 1.3

On Mon, Mar 7, 2016 at 8:34 AM, Scott Fluhrer (sfluhrer) 
mailto:sfluh...@cisco.com>> wrote:


Defenses against the first type of attack (passive evesdropping by 
someone who will build a QC sometime in the future) are something that 
this WG should address; even if the PKI people don't have an answer, 
we would at least be secure from someone recording the traffic and 
decrypting it later



I think it would make sense to wait for the CFRG to weigh in on 
post-quantum crypto. Moving to a poorly studied post-quantum key 
exchange algorithm exclusively runs the risk that when it does receive 
wider scrutiny new attacks will be found. I think we need to define 
hybrid pre/post-quantum key exchange algorithms (e.g. 
ECC+Ring-LWE+HKDF), and that sounds like work better suited for the 
CFRG than the TLS WG.


I’m sorry that I wasn’t clearer; I agree that **now** isn’t the time 
to define a postquantum ciphersuite/named group; we’re not ready yet 
(and this WG probably isn’t the right group to define it). However, I 
believe that we will need to do at some point; my guess is that it’ll 
be sooner rather than later.  What (IMHO) this WG should be doing now 
is making sure that there isn’t something in TLS 1.3 that’ll make it 
harder to transition to postquantum crypto when we do have a concrete 
proposal.


One thing that proposed QR key exchanges have is that they don’t have 
the full flexibility that (EC)DH have; either they aren’t secure with 
static key shares, or we can’t use the same key share as both an 
‘initiator’ and a ‘responder’ key share.  This would indicate to me 
that we need to make sure that TLS 1.3 should be engineered to use 
(EC)DH as only a simple, ephemeral-only key exchange – yes, it has 
more flexibility than that, however taking advantage of such 
flexibility might cause us problems in the future




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



--
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

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

Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA

[Rene Struik]

Hi Hanno:

The papers [1] and [2] may be of interest here. In [2], Section 3.3, 
Alfred Menezes and Neil Koblitz compare FDH-hash RSA signatures, PSS 
(lots of randomness in the salt), and a scheme by Wang and Katz that 
only contains one bit of randomness with signing and is claimed to have 
tight reductions (see also [1]) and argue a "Pass on PSS".


[1] Signature Schemes - Efficient, with Tight Security Reductions 
(Jonathan Katz, Nan Wang, CCCS 2003). Available from 
https://www.cs.umd.edu/~jkatz/papers/CCCS03_sigs.pdf
[2] Provable Security, Another Look at (Alfred Menezes, Neal Koblitz, 
IACR ePrint 2004-152). Available from https://eprint.iacr.org/2004/152


On 8/7/2016 2:57 AM, Hanno Böck wrote:

Hi,

On Sat, 6 Aug 2016 18:54:56 -1000
Brian Smith  wrote:


Also, I think it would be great if people working on proofs of
security for TLS could take into consideration the fact that
some--perhaps many--implementations will intentionally or accidentally
use some form of deterministic or less-than-random salt generation for
RSA-PSS. For example, it would be great to see a "What if the salt(s)
in the RSA PSS signature(s) were generated deterministically?" section
of papers describing such proofs.

Actually there is some info on that in the PSS spec [1]. What I write
here is my limited understanding, but roughly I'd interpret it as this:
It says that if you use a non-random salt the security gets reduced to
the security of full domain hashing, which was kinda the predecessor of
PSS.
I'd conclude from that that even in a situation where the salt
generation is a non-random value nothing really bad happens. The
security of a PSS scheme without randomness is still better than that
of a PKCS #1 1.5 signature.

Maybe some more knowledgable people want to add something, but the
bottom line is I think that we don't need to worry too much about the
randomness part here. Unlike with other situations (e.g. ecdsa/dsa) the
randomness is not a piece that once you take it away everything blows
up.


[1] https://tools.ietf.org/html/rfc3447



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



--
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

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

[TLS] (confusing the issues) Re: [Cfrg] 3DES diediedie

[Rene Struik]

I think it is a mistake to think that simply using block ciphers with a 
larger block size is enough to counter attacks, as the literature on 
successful side channel attacks on such block cipher demonstrates. The 
real message is that one should not reuse keys ad infinitum, which 
unfortunately seems hard to sink in.


Singling out 3-DES in this respect does not seem to tackle the real 
issue (which is a system security issue often only paid lip service to 
in practice).


Rene

On 8/29/2016 8:56 AM, Joachim Strömbergson wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Aloha!

As a side note, there has been a bunch of lightweight block ciphers
suggested the last few years, most of them with a block size of 64 bits.
And there has been discussion on IETF maillists about IETF accepting
them. For example the SIMON and SPECK ciphers. These ciphers can have
block sizes as small as 32 bits.

https://www.cryptolux.org/images/a/a0/Beaulieu-DAC2015.pdf
https://eprint.iacr.org/2015/209.pdf

Yours
JoachimS



David McGrew (mcgrew) wrote:

Hi Peter,

You make a bunch of good points.   But it is also worth noting that
some people feel that current crypto standards, including IETF
standards, are suitable for IoT.   See for instance slides 8 and 9 of
Daniel Shumow's talk at NIST’s LWC workshop last year:
http://csrc.nist.gov/groups/ST/lwc-workshop2015/presentations/session4-shumow.pdf
Also, CoAP isn’t on his list, but it could be, and it uses DTLS.   So
while I agree with you that overuse of a 64-bit block cipher is far
from the biggest security concern for IoT, the IETF should expect its
protocols to be used in some IoT scenarios.

The malleability of the term IoT is causing trouble here.   Slide 6
of Daniel’s talk is quite revealing.  To my thinking, by definition
IoT devices are connected to the Internet in some way.

David



On 8/28/16, 8:01 AM, "Peter Gutmann" 
wrote:


David McGrew (mcgrew)  writes:


I don’t think you understood my point. IoT is about small devices
connecting to the Internet, and IETF standards should expect
designed-for-IoT crypto to be increasingly in scope.  It is
important to not forget about these devices, amidst the current
attention being paid to misuses of 64-bit block ciphers, which
was the ultimate cause of this mail thread.

But the IETF has a long history of creating standards that
completely ignore IoT.  I can't think of a single general-purpose
IETF security standard (TLS, SSH, IPsec, etc) that has any hope of
working with IoT devices (say a 40Mhz ARM-core ASIC with 32kB RAM
and 64kB flash).  This is why the ITU/IEC and a million
lesser-known standards bodies are all busy inventing their own
exquisitely homebrew crypto protocols, most of which make WEP look
like a model of good design.

(I've always wanted to sit down and design a generic "encrypted
pipe from A to B using minimal resources" spec, and I'm sure many
other people have had the same thought at one time or another).

So it seems like you've got:

- The "TLS = the web" crowd (browser vendors and the like) who will
implement whatever's trendy at the moment and assume everyone has a
quad-core 2GHz CPU with gigabytes of RAM and access to weekly live
updates and hotfixes.

- Embedded/SCADA folks who need to deal with 10-15 year product
cycles (see my TLS-LTS draft for more on this) and are kind of
stuck.

- IoT people, who can't use any standard protocol and will get the
least unqualified person on staff to invent something that seems OK
to them.

I'm not sure that a draft on theoretical weaknesses in 64-bit block
ciphers is going to affect any of those...

Peter.

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


- -- 
Med vänlig hälsning, Yours


Joachim Strömbergson - Alltid i harmonisk svängning.

  Joachim Strömbergson  Secworks AB  joac...@secworks.se

-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJXxDECAAoJEF3cfFQkIuyNY1UP/2lUJo53s27wlqvgPWpZYWzi
HViof7jYA7yvbZm9SeYkV88y4sOMUQrhSsAWUZ7GfwcjkjC8+sL8mD7uacPx0zpW
rAnLnAHJbnU8rkWRT2OKWiZBvwMpMNw/UYGy13dwilRExj22N4dsLK98vath3r52
FjAIL2GpCWUuzPB6P5d+B8MjEwEr1tEYzvlvWo032RB91irOOKveryGGe5ifnSKj
SP1a9CbakaLdTHMkrhOre0I4Ckr2A97eI3oo/5QjRJ81zKJ/4VZzOOe3lGjPkXhO
kzkANctte+Eb5ttlaXcg/dL7lStzaYo8rnm3PRHsBKpHr/oNEgbdJti1U78/MfLf
o0v+s4TbY7YBPXOU7zKWpo9VD1Mcq9eMAslIQokEE2CfIq3wBSEEgKwJXu6HVSht
Ohahc7HUBnz2+uXJ+x4hl/bW/qM3DFhTfhPCYQ11IiXpPlxhsAnxbszBe4XtHd7y
z2Uc+Jef8aUq7sEGYBdcnGs+SSNFQwtUIicKI3pU61xvtAhqRriNOsfmCVvC2V7Z
iz5EodInPjUBkVMwDbmiFd5lp782SqYZsivwabPGE1p2GG+o421KZmQJ3VRC3ctw
xjwk2HszIv7Wo+gomL0hqF7Wi0YIP556rRYrRMc9gLV513xzxD5T99eR+2HtiRJF
TvYYPXZjzP087liGF7SA
=Z0iM
-END PGP SIGNATURE-

_

Re: [TLS] [Cfrg] (confusing the issues) Re: 3DES diediedie

[Rene Struik]

My argument was aimed at focusing on the real topic at hand, not at 
mixing this with "religious" beliefs as ditching ciphers without clear 
justification (no matter how ancient 3-DES may be [I was in elementary 
school then]).


I think it is unwise thinking too lightly about writing IETF drafts with 
"die-die-die" in the title, just because one feels like it, in an almost 
context-free manner. Or, is the idea to launch an entire series of 
die-die-die drafts, because one finds some excuse to do so? I cannot 
deny I also like shiny new things and we may all suffer from 
not-invented-here syndromes, but acknowledging this playing in the 
background of our perceptions should also give us some reason to pause 
and have some restraint here.


Rene

On 8/29/2016 5:48 PM, Jon Callas wrote:

On Aug 29, 2016, at 6:26 AM, Rene Struik  wrote:

I think it is a mistake to think that simply using block ciphers with a larger 
block size is enough to counter attacks, as the literature on successful side 
channel attacks on such block cipher demonstrates. The real message is that one 
should not reuse keys ad infinitum, which unfortunately seems hard to sink in.

Singling out 3-DES in this respect does not seem to tackle the real issue 
(which is a system security issue often only paid lip service to in practice).

Yes, we should just stop using 64-bit block ciphers and deal with the issues 
you mention within the context of larger blocks.

Jon




--
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

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

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

[Rene Struik]

Dear colleagues:

I would suggest adding the following paragraph at the end of Section 5.5:

[current text of Section 5.5]

There are cryptographic limits on the amount of plaintext which can be 
safely encrypted under a given set of keys.[AEAD-LIMITS] 
provides an analysis of 
these limits under the assumption that the underlying primitive (AES or 
ChaCha20) has no weaknesses. Implementations SHOULD do a key 
updateSection 4.6.3 
prior to reaching these 
limits.


For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be 
encrypted on a given connection while keeping a safety margin of 
approximately 2^-57 for Authenticated Encryption (AE) security. For 
ChaCha20/Poly1305, the record sequence number would wrap before the 
safety limit is reached.


[suggested additional text]

The above upper limits do not take into account potential side channel 
attacks, which - in some implementations - have been shown to be 
successful at recovering keying material with a relatively small number 
of messages encrypted using the same key. While results are highly 
implementation-specific, thereby making it hard to provide precise 
guidance, prudence suggests that implementations should not reuse keys 
ad infinitum. Implementations SHALL therefore always implement the key 
update mechanism of Section 4.6.3.


{editorial note: perhaps, one should impose the limit 2^20, just to make 
sure people do not "forget" to implement key updates?}



See also my email of August 29, 2016:
https://mailarchive.ietf.org/arch/msg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno

On 2/10/2017 12:07 AM, Sean Turner wrote:

All,

We’ve got two outstanding PRs that propose changes to draft-ietf-tls-tls13 
Section 5.5 “Limits on Key Usage”.  As it relates to rekeying, these limits 
have been discussed a couple of times and we need to resolve once and for all 
whether the TLS WG wants to:

a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

Please indicate you preference to the TLS mailing list before Feb 17.  Note 
that unless there’s clear consensus to change the text will remain as is (i.e., 
option a).

J&S

[0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5
[1] https://github.com/tlswg/tls13-spec/pull/765
[2] https://github.com/tlswg/tls13-spec/pull/769
___
Cfrg mailing list
c...@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg



--
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

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

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

[Rene Struik]

Hi Quynh:

Not sure where to start (there is vast literature on side channel 
attacks and other implementation attacks). A good starting point would 
be the book [1], but one could also look at some NIST publications [2].


Side channel attacks differs from cryptanalytic attacks in that it does 
not merely study I/O behavior of crypto contructs, but also looks into 
what information can be obtained from what is going on "under the hood" 
of the computations (power consumption, radiation, timing, etc; or even 
invasive attacks). Most commonly one looks at crypto building blocks, 
but ultimately side channels can comprise any system behavior ("Lucky13" 
does, e.g., exploit this, if I remember correctly).


From the last page of [2]: Finally, the most important conclusion from 
this paper is that it is not only a necessity but also a must, in the 
coming version of FIPS 140-3 standard, to evaluate cryptographic modules 
for their resistivity against SCA attacks.


Ref:
[1] Stefan Mangard, Elisabeth Oswald, Thomas Popp, "Power Analysis 
Attacks - Revealing the Secrets of Smart Cards", Springer, 2007.
[2] 
http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-3/physec/papers/physecpaper19.pdf

[2]


On 2/10/2017 1:47 PM, Dang, Quynh (Fed) wrote:

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] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs 
(#765/#769)


Dear colleagues:

I would suggest adding the following paragraph at the end of
Section 5.5:

[current text of Section 5.5]

There are cryptographic limits on the amount of plaintext which
can be safely encrypted under a given set of keys.[AEAD-LIMITS]
<https://tlswg.github.io/tls13-spec/#AEAD-LIMITS>provides an
analysis of these limits under the assumption that the underlying
primitive (AES or ChaCha20) has no weaknesses. Implementations
SHOULD do a key updateSection 4.6.3
<https://tlswg.github.io/tls13-spec/#key-update>prior to reaching
these limits.

For AES-GCM, up to 2^24.5 full-size records (about 24 million) may
be encrypted on a given connection while keeping a safety margin
of approximately 2^-57 for Authenticated Encryption (AE) security.
For ChaCha20/Poly1305, the record sequence number would wrap
before the safety limit is reached.

[suggested additional text]

The above upper limits do not take into account potential side
channel attacks, which - in some implementations - have been shown
to be successful at recovering keying material with a relatively
small number of messages encrypted using the same key. While
results are highly implementation-specific, thereby making it hard
to provide precise guidance, prudence suggests that
implementations should not reuse keys ad infinitum.
Implementations SHALL therefore always implement the key update
mechanism of Section 4.6.3.

{editorial note: perhaps, one should impose the limit 2^20, just
to make sure people do not "forget" to implement key updates?}


How do you do side channel attacks on TLS ? Do these side-channel 
attacks work for AES-GCM only in TLS 1.3 ?





See also my email of August 29, 2016:
https://mailarchive.ietf.org/arch/msg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno

On 2/10/2017 12:07 AM, Sean Turner wrote:

All,

We’ve got two outstanding PRs that propose changes to draft-ietf-tls-tls13 
Section 5.5 “Limits on Key Usage”.  As it relates to rekeying, these limits 
have been discussed a couple of times and we need to resolve once and for all 
whether the TLS WG wants to:

a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

Please indicate you preference to the TLS mailing list before Feb 17.  Note 
that unless there’s clear consensus to change the text will remain as is (i.e., 
option a).

J&S

[0]https://tlswg.github.io/tls13-spec/#rfc.section.5.5
[1]https://github.com/tlswg/tls13-spec/pull/765
[2]https://github.com/tlswg/tls13-spec/pull/769
___
Cfrg mailing list
Cfrg@irtf.orghttps://www.irtf.org/mailman/listinfo/cfrg



-- 
email:rstruik@gmail.com  | Skype: rstruik

cell: +1 (647) 867-5658 | US: +1 (415) 690-7363




--
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

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