Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

[Dan Brown]

Agreeing on security gains from hybrid.  

Should TLS ask CFRG (again?) what to do about PQC?

> From: D. J. Bernstein
> 
> Yoav Nir writes:
> > To justify a hybrid key exchange you need people who are both worried
> > about quantum computers and worried about cryptanalysis or the new
> > algorithms, 

Reminder: most in TLS WG know that Castryck and Decru broke SIKE on July 30, 
2022,
https://eprint.iacr.org/2022/975
but I, for one, sometimes forget details of articles, and am helped by 
reminders.

> Google and Cloudflare encrypted quite a bit of actual user data using SIKE:
> 
> The only reason this didn't give the user data away to today's attackers is 
> that
> Google and Cloudflare had the common sense to insist that any post-quantum
> algorithm be added as a second layer of encryption on top of the existing
> X25519 layer, rather than removing the existing layer.

Aka "hybrid key exchange" (= second layer), to use the Y. Nir's words.

> That was in 2019. For anyone who thinks a few years of subsequent study were
> enough for the public to identify which post-quantum cryptosystems are
> breakable, it's useful to look at NIST's official report in July 2022 saying 
> that

- i.e., a short time before the attack -

>* SIKE is "being considered for future standardization";

[etc.]
 
> SIKE had been advertised in 2021 as "A decade unscathed". I think I was the 
> only
> person speaking up to object, and as far as I know there was only one other
> cryptographer on record recommending against using SIKE.

Section 3.8 of https://eprint.iacr.org/2021/608 recommend against using SIKE, 
albeit in a very artificial set-up, and not in all situations.

However, I think NIST was right to promote SIKE to Round 4, as doing so 
continued crypto diversity. 

Dropping FrodoKEM, and delaying code-based KEMs to Round 4, which reduced and 
delayed crypto diversity, is a separate issue (and not on the topic of hybrid). 
 

Should TLS support any of these (code-based KEM, or FrodoKEM) as options in 
hybrid key exchange?  TLS has not always limited itself to NIST-only crypto.  
Maybe this is a sub-question worth asking CFRG?  I think fewer options, and 
standards alignment are important for security, by encouraging 
interoperability, but crypto diversity may be more important.




--
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] New Version Notification for draft-mattsson-tls-compact-ecc-00.txt

[Dan Brown]

Hi John and Scott,

 

For even greater clarity, you might want to address these points:

 

If the receiver uses an x-only ladder (e.g. Brier-Joye) and re-uses private ECC 
key, then, upon decoding the peer’s compress public key (represented via x), 
the receiver ought to check that x^3+ax+b is a square?  [SafeCurves says to do 
check this, but, of course, also adds the twist secure can avoid this check.]

 

Actually, it's a little bit tricky to find invalid x where y = 
(x^3+a+b)^((p+1)/4) gives (x,y) of low order.  I mentioned this to CFRG:

https://mailarchive.ietf.org/arch/msg/cfrg/nzxkGIo97GlIGszJirvS_TFUUio/

Despite this extra wrinkle of difficulty, an attack is avoided by validating a 
decompressed point.  (So, I’m not sure if the statement “the implementation 
will naturally detect invalid points when it …” is entirely realistic.  
[Safecurves say this where, by the way?]

 

I’m a little confused by the sentence “As not even the sign of the y-coordinate 
is encoded, compact representation avoids ‘benign malleability’ where an 
attacker changes the sign”.  Is this about the attack changing (r,s) to 
(r,p-s)?  Since r and s are integers, there are no y coordinates in play, the 
change from (r,s) to (r,p-s) is possible regardless of y coordinates.  (Ok, 
there is a connection to y coordinates: a point R, of which r is the x 
coordinate (mod p), does implicitly change by way of negating its y coordinate, 
but R is not sent in ECDSA, instead, ECDSA only sends x (via r).  I.e. r is 
already a “compact” version of R.)

 

Best regards,

​

Dan

 

From: TLS  On Behalf Of Scott Fluhrer (sfluhrer)
Sent: Tuesday, January 17, 2023 11:10 AM
To: John Mattsson ; TLS@ietf.org
Subject: Re: [TLS] New Version Notification for 
draft-mattsson-tls-compact-ecc-00.txt

 


CAUTION - This email is from an external source. Please be cautious with links 
and attachments. (go/taginfo)

 

It looks good; just one comment:

 

The current draft says (section 3.2)

A full validation according to Section 5.6.2.3.3 of

   [SP-800-56A] can be achieved by also checking that 0 ≤ x < p and that

   y^2 ≡ x^3 + a ⋅ x + b (mod p)

(emphasis added).

 

I believe such a validation check should be mandatory.  For the curves listed 
in the draft, the corresponding twists are not of prime order; hence someone 
injecting an invalid curve point has some advantage at recovering the peer’s 
secret value (and hence if an implementation reuses ECDHE private values, that 
gives them some advantage at recovering the keys for other sessions).

 

Yes, this is not a major point (this relies on the device under attack reusing 
private values, which they’re not supposed to do); on the other hand, the 
expense is fairly minimal (just computing y^2 (after all, you’ve already 
computed x^3+a+b), and the additional complexity needed to perform this check), 
hence I believe it is warranted.

 

Alternatively, you can mandate a safe curve (e.g. X25519), which is immune to 
this sort of attack.

 

From: TLS mailto:tls-boun...@ietf.org> > On Behalf Of 
John Mattsson
Sent: Monday, January 16, 2023 4:45 PM
To: TLS@ietf.org  
Subject: [TLS] FW: New Version Notification for 
draft-mattsson-tls-compact-ecc-00.txt

 

Hi,

 

I wrote a draft specifying new optimal fixed-length encodings for ECDHE and 
ECDHA with the NIST P-curves. This seems to be exactly what is needed for cTLS. 
The new encodings are defined as a subset of the old encodings which hopefully 
makes them easy to implement.

Cheers,
John

 

From: internet-dra...@ietf.org   
mailto:internet-dra...@ietf.org> >
Date: Monday, 16 January 2023 at 22:38
To: John Mattsson mailto:john.matts...@ericsson.com> >, John Mattsson 
mailto:john.matts...@ericsson.com> >
Subject: New Version Notification for draft-mattsson-tls-compact-ecc-00.txt


A new version of I-D, draft-mattsson-tls-compact-ecc-00.txt
has been successfully submitted by John Preuß Mattsson and posted to the
IETF repository.

Name:   draft-mattsson-tls-compact-ecc
Revision:   00
Title:  Compact ECDHE and ECDSA Encodings for TLS 1.3
Document date:  2023-01-16
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/archive/id/draft-mattsson-tls-compact-ecc-00.txt 

 
Status: 
https://datatracker.ietf.org/doc/draft-mattsson-tls-compact-ecc/ 

 
Html:   
https://www.ietf.org/archive/id/draft-mattsson-tls-compact-ecc-00.html 

Re: [TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3

[Dan Brown]

Dear Nimrod and team:

How does your concern compare to Campagna and Petcher’s report

https://eprint.iacr.org/2020/1364

which has security proofs for concatenation-based KDF?

(Maybe a detailed discussion is better suited to CFRG?)

Best regards,

​Dan

 

From: TLS  On Behalf Of Nimrod Aviram
Sent: Wednesday, September 1, 2021 3:57 PM
To:  
Cc: Eylon Yogev ; Ilan Komargodski ; 
Benjamin Dowling ; Eyal Ronen 
Subject: [TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3

 

(This note is also available on Github 

  for ease of reading.)

 

This note identifies a possible security problem in the "Hybrid key exchange in
TLS 1.3" document, stemming from how cryptographic secrets are combined. In
short: constructions that concatenate secrets are vulnerable when the underlying
hash function is not collision-resistant. We are unaware of a full attack
that leverages the underlying problem. However, we view this as an opportunity
to defend-in-depth against such issues, while the document is not yet finalized.
We propose a new construction that seems robust to this potential issue, and we
are in the process of writing a technical report that includes a full security
proof.

# Concatenating Secrets May Be Dangerous

The APOP attack (see appendix for a brief description) demonstrates that
concatenating secrets to potentially attacker-controlled input might be
dangerous. Currently, the "Hybrid key exchange in TLS 1.3" document uses secret
concatenation as the preferred way to combine secrets. (This was an
understandable design choice given how little this issue has been studied.)

We recommend a defense-in-depth approach against this potential issue. We should
not concede to an attacker even the ability to cause a collision in an internal
state of the key schedule. Moreover, this part of TLS is likely particularly
amenable to ossification: Whatever we standardize will likely persist for 5-10
years. (We do note that TLS mixes in the client and server nonces, so additional
offensive techniques would be required to exploit this for a full attack.)

We note that concatenation is also used in the "TLS 1.3 Extended Key Schedule"
document.

# Our proposed construction

We have identified an alternative construction that we believe could provide
defense-in-depth against this issue. We are in the process of writing a
technical report that includes a full security proof.
The required assumptions on the hash function appear to be much milder than
collision resistance; instead, we likely only need multi-preimage-resistance:
Essentially, requiring only that computing preimages for multiple images is
hard.

The construction is: 
combined_key = H(HMAC(key=H1(k1), data=2||F(k2)) xor HMAC(key=H2(k2), 
data=1||F(k1))) 
where || denotes concatenation, H denotes the underlying hash function, and: 
H1(k) = H('derive1' || k) 
H2(k) = H('derive2' || k) 
F is defined as follows:
Let m denote the input to F. We split m into blocks, according to the block size
of H: 
m = m1||m2||...||mn 
Let j~=3 denote an “expanding factor” (the value chosen for j in practice
depends on how strong an assumption we want to rely on; we expect 3 to be 
enough).
Then 
F(m) = 
H(0||m1)||H(1||m1)||...||H(j-1||m1)||H(0||m2)||H(1||m2)||...||H(j-1||m2)||H(0||mn)||H(1||mn)||...||H(j-1||mn)

This construction is cheap to calculate and would be used only in the key
schedule, which is not a bottleneck for TLS performance.

# Adding another layer to the TLS key schedule may also be problematic

Another strategy for mixing secrets is to add the second secret to another layer
of the TLS key schedule. This strategy is already used to mix a PSK and an ECDHE
secret in TLS 1.3, as well as in AuthKEM, and it was also considered for the
Hybrid key exchange document. This strategy is vulnerable as well to collisions
in the underlying hash function, and we propose using one secure construction
for mixing secrets.

Consider a standard PSK+ECDHE TLS 1.3 handshake. Then 
handshake_secret = HKDF_Extract(IKM=ECDHE_secret, 
salt=Derive_Secret(early_secret)) 
early_secret = HKDF_Extract(IKM=PSK, salt=000) 
HKDF_Extract(IKM, salt) = HMAC(k=salt, data=IKM)

Therefore, early_secret = HMAC(k=000, data=PSK). 
Assume a non-collision-resistant hash function. Then an attacker that can
establish multiple PSKs of their choice with another party can cause two
sessions with two different PSKs to share the same early_secret. If the other
party reuses ECDH(E) values, the attacker can also cause the handshake_secret to
be identical.

Furthermore, 
Client_Handshake_Traffic_Secret = 
  HMAC(k=Handshake_Secret, data=Label||H(ClientHello...ServerHello)) 
If the attacker is the server, and the hash function allows for chosen-prefix
collisions, the attacker can choose two ServerHello messages such that for two
different ClientHello messages, 

[TLS] FYI, a subverted implementation attack against TLS at ia.cr/2020/1452

[Dan Brown]

Dear TLS list,

FYI, ICYMI,

Berndt et al. describe a subverted implementation attack against TLS
https://eprint.iacr.org/2020/1452
I just noticed this report today and don't remember seeing it mentioned on the 
TLS list already.  It seems to be worth at least considering.

A summary and brief discussion:

The subverted TLS implementation (IIUC) uses server randoms (nonce) to quickly 
exfiltrate the server's signing key - so it could be characterized as proof of 
concept instance of a well-known idea, kleptography, (but please correct this 
summary if necessary, since it is only based on a skimming of the report).

Granted: it is difficult (impossible?) to thwart all subverted implementation 
attacks. But this attack is easier than others in that category, so might be 
notable.

This general issue with public random nonces has been discussed on TLS, for 
example:
https://mailarchive.ietf.org/arch/msg/tls/56N_-KDN0LuWyEvAhmFnm7g8p6A/
This past discussion led to a recommendation to use different RNGs for the 
public random versus the DH secrets, but I don't see how that would be enough 
to stop this attack.

In reviewing the TLS archive (from the thread above), I see that the general 
difficulty of thwarting subverted implementations has also already been raised. 
Basically, this argues that the best solution is to prevent subversion of 
implementations in the first place, and that making the protocol robust against 
subverted implementations is hopeless and wasteful. Maybe that's right.  (Maybe 
part of this anti-subversion defense would be separating the server keys, e.g. 
in a separate signing module, from the rest of the implementation?  Maybe some 
TLS servers already do this.)

>From the abstract of the attack report:
"... We show that these protocols can be easily subverted by carefully placing 
ASAs. Our analysis shows that careful design of ASAs makes detection unlikely 
while leaking long-term secrets within a few messages in the case of TLS ..., 
allowing impersonation attacks. ..."

The attack report also says that forward secrecy makes an implementation 
inherently more vulnerable to this attack.  I didn't look at the details, but I 
suspect that this is because ephemeral public keys can also be filtered by 
hashing, e.g. a Simmons subliminal channel,  - but this is presumably more 
costly, and more detectable?

The attack report has a section on Countermeasures and Design Lessons, the most 
general countermeasure is to re-design the protocol not to send freely random 
nonces, which I agree with, since it is so simple.  They also suggest requiring 
time-stamps to prevent replay attacks, (in case re-used ephemeral keys).

Best regards,
​​​​​
Dan Brown

--
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.


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

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

[Dan Brown]

Deprecating non-forward-secure ECDH and FFDH is important.
Keeping FFDHE may be okay, e.g. for those who want forward security, but still 
don't trust ECC.


--
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.


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

Re: [TLS] Advancing draft-ietf-tls-hybrid-design

[Dan Brown]

> -Original Message-
> From: TLS  On Behalf Of Douglas Stebila
> We wanted to see if there is any further feedback on our draft "Hybrid key
> exchange in TLS 1.3" ...  We have not received any new feedback from the
working group
> since we posted our last non-trivial update in October 2020.

Allowing 3 or more key exchange methods in a hybrid combination should
somehow be an option, for a user who can afford the extra cost and is
risk-averse and has high-value data to protect.
 
I was told this issue (2 versus 2+) was already discussed on the list, but I
must have forgotten (or missed) that conversation.

A workaround is to nest TLS into TLS, to get more types of key exchange, or
to apply the extra key exchanges at the application layer, on top of TLS,
for those (few) who want the extra security.  These workarounds imply
applying symmetric crypto twice, which does not help against the quantum
threat.




--
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.


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

Re: [TLS] Advancing draft-ietf-tls-hybrid-design

[Dan Brown]

Hi Douglas,

Your general approach paves the way for improved forward security, as
insurance against new attacks, a non-negligible risk (*).  So, the TLS WG
should advance it soon.  Sorry, that I've not yet looked at the details, but
I trust that your I-D is good. 

Best regards,

Dan

PS

(*) The non-negligible risk of new (or secret) attacks does not discount the
existing protocols or past work of the TLS WG. The TLS WG priority has
rightly been to address much greater risks (TCP unprotected by
cryptography), etc., but can now build on that work to further improve
security.

A strawman counter-argument to "hybrid public-key": why not do the same
thing for symmetric-key, i.e. the TLS record layer?  Two reasons. One: the
quantum computer risk more greatly affects public-key, while many of the PQC
alternatives are not yet tested (as much as the symmetric-key options).
Two: internally, typical symmetric-key cryptography already applies rounds
of different types of operations, e.g. linear and non-linear, so
symmetric-key is "hybrid" already (to a limited degree).


About "hybrid" terminology

> -Original Message-
> From: TLS  On Behalf Of Douglas Stebila
 
> ...  Though at
> this point changing the word "hybrid" to "composite" would be a rather big
> rewrite so I'll omit that unless there are very strong objections to the
word
> hybrid.

On the "hybrid" terminology (i.e. which paint for the bike-shed), other
names seem better, if less slick.  

There's "layered diverse cryptography", but that conflicts with the L in
TLS.  Also, "strongest-link" is quite clear.  There's several other
alternatives, but maybe not as good. 


PPS: off-topic rant (for TLS ): 

Consider that CFRG has a draft about "Hybrid PKE" (HPKE, *).  This raises a
question: what to call a hybrid of this hybrid (e.g. ECC+PQC) with that
hybrid (e.g. KEM+DEM)?  Hyper-hybrid?

Although HPKE is not destined for TLS, consistent terminology for
cryptography across WGs would be ideal.  It could be confusing if each WG
used different terminology for the same cryptographic methods, or in this
case, the same terminology for different cryptographic methods.  That said,
coordination of a large open organization like IETF is difficult, and so is
choosing clear terminology for complicated ideas of cryptography.



--
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.


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

Re: [TLS] DH generator 2 problem?

[Dan Brown]

Dear Michael,

Your concern that special primes in Diffie--Hellman might be weaker has some
truth: the famous and ingenious special number field sieve (SNFS) works
against primes with special structure.  See 
https://eprint.iacr.org/2016/961 
for a recent application (which, as an extra wrinkle, is also able to hide
the special structure). 

Therefore, applied cryptography like TLS already uses vetted primes in
Diffie--Hellman, with careful guidance from cryptographers such as those in
CFRG, which specialize in such fundamentals.  (Full disclosure: I proposed
some primes for DH to the CFRG list (for reductionist security), but never
followed through with an I-D.)

Scott explains below very well, as one'd expect, why the generator choice
should generally not matter (random self-reducibility).

Best regards,

Dan

> -Original Message-
> From: TLS  On Behalf Of Scott Fluhrer (sfluhrer)
> Sent: Thursday, October 8, 2020 3:09 PM
> To: Michael D'Errico ; TLS List 
> Subject: Re: [TLS] DH generator 2 problem?
> 
> > -Original Message-
> > From: TLS  On Behalf Of Michael D'Errico
> > Sent: Thursday, October 08, 2020 1:54 PM
> > To: TLS List 
> > Subject: [TLS] DH generator 2 problem?
> >
> > Using finite-field Diffie-Hellman with a generator of 2 is probably
> > not the best choice.  Unfortunately all of the published primes (RFCs
> > 2409, 3526, and
> > 7919) use 2 for the generator.  Any other generator would likely be
> > (not sure how much?) more secure.
> 
> No, that is known to be not true.
> 
> In particular, if you can compute discrete logs to the base 2, you can
compute
> discrete logs to any base (except in the cases where 2 generates an
> anomalously small subgroup, which is not the case in the above groups).
> 
> Here's how it works; suppose you were given the problem of solving the
> discrete log problem g^x = h, for some g, h.  Then, if you can solve
discrete logs
> to base 2, you would solve these two problems:
> 
> 2^y = g
> 2^z = h
> 
> Once you have solved those two problems, then you have x = y z^-1 mod p-1.
> 
> It's a little more complex if g, h is not in the subgroup that 2
generates, but not
> that much more (unless, as above, the size of that subgroup is far smaller
than
> p-1).
> 
> >
> > The problem is that 2^X consists of a single bit of value 1 followed
> > by a huge string of zeros.  When you then reduce this modulo a large
> > prime number, there will be a pattern in the bits which may help an
> > attacker discern the value of X.  This is further helped by the fact
> > that all of the published primes have 64 bits of 1 in the topmost and
bottom-
> most bits.
> > In addition, the larger published primes are very similar to the
> > shorter ones, the shorter ones closely matching truncated versions of
the
> larger primes.
> >
> > If you were to manually perform the modulo-P operation yourself, you
> > would add enough zeros to the end of P until the topmost bit is just
> > to the right of the 1 bit from 2^X, and then you'd subtract.  This bit
> > pattern will always be the same, no matter the value of X.  In
> > particular, the top 64 bits disappear since they're all one.
> > Continuing the mod-P operation, you adjust the number of zeros after
> > the prime P and then subtract again, reducing the size of the operand.
> > The pattern of bits again will be the same, regardless of the value of
X, the
> only difference being the number of trailing zeros.
> 
> Actually, for these group, the value of 2^x mod p can take on (p-1)/2
different
> values; there is no chance that the bit pattern will be trapped in some
cul-de-
> sac, as you appear to be suggesting...
> 
> >
> > I have not looked at the cyclic patterns which happen as you do this,
> > but I wouldn't be surprised to find that the "new" primes based on e
> > (RFC 7919) have easier-to-spot bit patterns than those based on pi.
> 
> I would be surprised; do you have some reason that would suggest why bits
> derived from the binary expansion of 'e' would be somehow qualitatively
> different from bits derived from the binary expansion of 'pi'?
> 
> >
> > This is speculation of course.
> 
> Might I suggest you learn a bit of number theory to go along with your
> speculation?
> 
> >
> > Should we define some new DH parameters which use a different
> > generator?  Maybe the primes are fine
> 
> If the prime is fine, so is the generator...

--
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this 

Re: [TLS] Static DH timing attack

[Dan Brown]

From: TLS  On Behalf Of Salz, Rich
> Do we need a short RFC saying “do not use static DH” ?

 

Don’t TLS 0-RTT and ESNI/ECH via HPKE use a type of (semi)static ECDH? If so, 
then an RFC to ban static (EC)DH in TLS would need to be very clear about not 
referring to these use cases of static ECDH.

 

My 2c. What about combining static ECDH (instead of signatures) with ephemeral 
ECDH, e.g. for more fully deniable authentication?  (ECMQV does this.)  
(Perhaps this is also similar to the KEMTLS proposal for PQC, 
https://ia.cr/2020/534 - still need to study that.)

 

--
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.


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

Re: [TLS] [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)

[Dan Brown]

Hi Hugo,

 

Some curious molehill questions. Please take with a grain of salt.

 

In short, does HKDF-Extract suffer from related-salt and repeated-IKM?

 

To elaborate:

 

Phillip raises a good point below about HMAC suffering from key-extension (by 
zero bytes).  You are right that this is not a MAC attack, the main intended 
use of HMAC, but now the scope of HMAC has expanded to non-MAC purposes.   

 

Surely HMAC has good PRF properties, so non-MAC applications make sense.  For 
what little it’s worth, I had just presumed that HKDF always used HMAC with the 
a strong secret key, like a good PRF should.  (I failed to verify this, though.)

 

But Phillip seems to want to use structured HMAC keys (i.e. not uniformly 
distributed keys), specifically the salts in HKDF-Extract, I presume.  Under my 
presumption, this would not be best practice (using structure or related keys).

 

So, I went to the HKDF RFC, basically expecting to find this clearly 
disallowed.  Re-reading the RFC, it was unclear to me what kind of salt was 
allowed. (The eprint might be clearer, but it is longer to find this needle.) 
Would it (dis)allow the structured salts Phillip described? 

 

Then, I saw a phrase in the HKDF RFC that salts were unlike IKM, because they 
could be re-used.  I inferred that IKM was not to be re-used.  If so, related 
salts should cause no problem for extraction, because a different IKM would 
always be used.  But might IKM be re-used?  For example, the rare event that 
TLS client and server both re-use their ECDHE keys.  So, I went to look at TLS 
1.3.

 

In TLS 1.3, HKDF-Extract is used with both structured salts (e.g. 0), and 
structured IKMs (e.g. 0).  In the end, all is fine, because at least one of the 
salt or IKM has lots of entropy, and there were no related salts.  (The case 
HKDF-Extract(0,0) is mentioned in TLS 1.3, but very clearly that this case does 
not provide security.)  I presume TLS 1.3 designers were adhering to the 
intended use of HKDF-Extract.  

 

To summarize, related-salt + repeated-IKM in HKDF-Extract might lead to 
repeated PRK, right? This could be bad if PRK used in HKDF-Expand to create two 
identical stream cipher keys.  If two identical authentication keys, perhaps an 
unexpected replay attack might apply?  Are these a concern?  Is TLS 1.3 fine, 
mainly because HKDF was used correctly?  Are these related-salts really 
realistic: would an implementer do this? Do you think better implementer 
guidance is needed to prevent this type of accident?  

 

Best regards,

​

Dan

 

PS

 

The HKDF RFC clearly excludes an adversary causing related salts, so that’s 
good.

 

I really like both defense in depth and provable security, but I would also 
like it to be clear that is the main motivation for HKDF in key derivation..  
To wit, HMAC itself internally derives two closely-related keys using XOR ipad 
and XOR opad.   You have proved this turns out fine, despite the relatedness of 
the two keys, because the robust property of hash function.  My point here, is 
if we assumed the derived keys are used in robust algorithms, e.g. AES-GCM, 
could they tolerate simpler ways of deriving keys, i.e. XORing a key with a 
non-random separation string?  To repeat, I am totally fine to use robust key 
derivation, like HKDF, but I would want the reason to be clear.  E.g. TLS 1.3 
handshake uses HKDF as hedge against possible related-key attacks on the 
symmetric-key crypto in the record layer, or for better or simpler security 
proofs (e.g. compared to past key derivation methods).

 

As many know, hashes were, once upon a time, only used for message digests in 
signatures. Message-extension in hashes did not result in signature forgery.   
But then people naturally wanted to use hashes (as a “utility function” in 
Phillip’s terms) for a MAC.  But hashes with message extension suffer from MAC 
forgery. Along came HMAC to the rescue, saving the day, and the rest is 
history.  (To exaggerate: it is, on a minute scale, repeating;)

 

 

From: TLS  On Behalf Of Phillip Hallam-Baker
Sent: Tuesday, May 12, 2020 1:49 AM
To: Hugo Krawczyk 
Cc: Dang, Quynh H. (Fed) ; c...@ietf.org; 
tls@ietf.org; Salz, Rich 
Subject: Re: [TLS] [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)

 

 

 

On Mon, May 11, 2020 at 4:36 PM Hugo Krawczyk mailto:h...@ee.technion.ac.il> > wrote:

There is no flaw if you use HMAC and HKDF as intended. See details below.

 

One time pads aren't flawed if you use them right. When they become a two time 
pad, there is a problem.

 

My point is that if we are developing schemes that are supposed to be used as 
utility building blocks, we need to consider all the ways they might be used 
and not just limit ourselves to the ones we expect. That was the argument made 
for defining authenticated encryption modes, it holds here as well.

 

The bottom line advise is: If you are using related (not random) salt values in 
HKDF, you are probably using it with  

Re: [TLS] NIST crypto group and HKDF (and therefore TLS 1.3)

[Dan Brown]

> -Original Message-
> From: Salz, Rich 
>
> >[DB] But NIST Draft SP 800-56Cr2 cites RFC 5869, which is HKDF, and 
> > says
> HKDF
> is a version of 56C Section 5.1. So, I had thought that 56C would allow 
> HKDF.
> What am I missing?
>
> It cites it, but doesn't include it in the 800-56 doc.

To be clear, are you saying that RFC 5869 HKDF is not compatible with 
800-56Cr2?

(I had assumed they were compatible, but just used different notation for the 
same idea.)

Looking just now, I see 800-56C refers to 800-108, whose Section 5.2, KDF in 
Feedback Mode looks really close to HKDF in RFC 5869.  I see the same overall 
design, but some different orderings of inputs, which could cause non-interop. 
Is that the case?


--
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.


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

Re: [TLS] NIST crypto group and HKDF (and therefore TLS 1.3)

[Dan Brown]

> -Original Message-
> From: Cfrg  On Behalf Of Salz, Rich
> Subject: [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)
>
> NIST SP 800-56C (Recommendation for Key-Derivation Methods in Key-
> Establishment Schemes) is currently a draft in review with a deadline of
> May 15.  That is not a lot of time.  The NIST crypto group is currently 
> unlikely
> to include HKDF, which means that TLS 1.3 would not be part of FIPS. The
> CMVP folks at NIST understand this, and agree that this would be bad; they 
> are
> looking at adding it, perhaps via an Implementation Guidance update.

[DB] But NIST Draft SP 800-56Cr2 cites RFC 5869, which is HKDF, and says HKDF 
is a version of 56C Section 5.1. So, I had thought that 56C would allow HKDF. 
What am I missing?


--
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.


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

Re: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design

[Dan Brown]

I support rapid adoption, if only based on general principles, as elaborated 
below.

 

***

 

I have not studied the draft in detail, but I think that strongest-link 
security is important to allow, the sooner the better, for those that can 
afford it, I think the benefit is worth cost.

 

I think that the how-to of strongest-link is straightforward enough to start 
working on it, and I trust the draft authors to have done a good job at it.  
Any subtleties or optimizations of strongest-link crypto can be perfected as 
they arise.

 

I would also favor using both ECC and PQC, (a) _after_ NIST PQC is done, (b) 
_before_ a Shor-capable QC arrives.  I’m hoping the time of (a) < (b), and 
therefore hybrid should be ready to roll out.

 

I would also favor adding PQC support to TLS _before_ even NIST PQC is done, 
then just switching over to NIST choices at the time, even though this seems 
not to be the interpretation consensus opinion, e.g. CFRG opted to wait for 
NIST.  I agree waiting for NIST is sensible, if one want the best PQC 
protection, but not to the point of delaying having any PQC protection, see 
next point.

 

Getting details right is a known difficulty, with mistakes inevitable.  Haste 
makes waste, sure, but delay is deadly, so let’s get to debugging the details 
right away.  Bugs are a nuisance, but better than nothing.

 

I realize that anybody worried about Shor-capable QC, can add a PQC out-of-band 
to official TLS, but I understand TLS to offer many benefits as security 
protocol, such that adding in PQC would create synergy (excuse my word choice 
here).

 

I think “hybrid” is the wrong word.  CFRG has adopted another document where 
“hybrid” means weakest-link.  Can we choose clearer words?  I like “compound”, 
but strongest-link, and defense-in-depth are clearer at the price of being 
longer.  (I prefer hybrid to synergy, of course!)

 

General arguments that attackers will find other system weaknesses than 
directly attacking crypto are valid, but these arguments already rely on good 
crypto, and are invalid as an excuse to use weaker crypto, to stop improving 
crypto.

 

Best regards,

​

Dan Brown

BlackBerry

 

From: TLS  On Behalf Of Joseph Salowey
Sent: Thursday, February 13, 2020 12:13 PM
To:  
Subject: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design

 

The authors of "Hybrid Key Exchange" have asked for adoption of their draft as 
a WG item.  Please state whether you support adoption of this draft as a WG 
item by posting a message to the TLS list by 2359 UTC 28 February 2020..  
Please include any additional information that is helpful in understanding your 
position.

NOTE:
If the draft is adopted, the working group has change control over the draft 
and the timing of its progression.  This means the document does not have to be 
perfect as the working group can and will make changes.  Adopting the draft 
means the working group thinks the topic is a good idea and the draft is a good 
place to start the work.  

Thanks,
Chris, Joe, and Sean

[0]  
<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dstebila-2Dtls-2Dhybrid-2Ddesign_=DwMFaQ=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw=YGrWhrwPJMcluBHfaPE8h_pponmVeM1dfJFrLKO-Y2c=QH64ybNj9x2PM84z-J18Fb113WNyH8szhQxy-UzKDZc=>
 https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/

 

 

--
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.


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

Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?

[Dan Brown]

Does reading Ecdsa-sig-value need a full DER parser?
The new syntax does not rely on a buggy parser, as far as I know.  
The biggest bug is in the old syntax, which is not extensible.
Use a valid DER parser plus new syntax to accept signatures, and all old syntax 
signatures will accepted, right???
Is it possible to do better with a non-extensible syntax?
The only breakdown is the old syntax parsers receiving the extensions, right?
That's the only place a lax parser would help.


  Original Message  
From: Peter Gutmann
Sent: Tuesday, October 1, 2019 6:15 PM
To: Hubert Kario; Dan Brown
Cc: TLS@ietf.org
Subject: Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?

Hubert Kario  writes:

>a lax DER parser sounds like an oxymoron to me... :)

That's why I assumed it was an accident/error. Writing a spec that relies on
buggy parser implementations in order to work is asking for trouble.

Peter.



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

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

[Dan Brown]

Sorry to TLS-WG if this getting out of TLS scope.  (Let me know, and I will be 
happy to cease this thread.)

Hi Rene,

Did you mean to ask me about the ANSI X9.62 expiration off-list? I’ll assume 
not, and answer on-list.  

1.  I was told often by X9 admin and chairs that ANSI X9.62 was withdrawn.  
Are you doubting the withdrawal?
2.  When I visited ANSI just to confirm 62 expiration, 
https://webstore.ansi.org/Search/Find?in=1 
<https://webstore.ansi.org/Search/Find?in=1=X9.62> =X9.62 reports nothing 
found.
3.  ​The globalspec site you mention is news to me, though I never 
bother to search the whole web for X9.62.  I sympathize with others that need 
to: sorry to you.
4.  I imagine that there many reasons for the expiration, many beyond my 
grade, but, as you say, I (unlike some) often nap, so it’d be fair to grade me 
at 50%.  Am I to infer that you are more baffled about all this than I am?
5.  Yes, “revival” is my term, and in no way an official, so it’s sensible 
to quote me on it.

Dan

From: Rene Struik  
Sent: Tuesday, October 1, 2019 9:29 AM
To: Dan Brown ; John Mattsson 
; Peter Gutmann 
; Hubert Kario ; TLS@ietf.org
Subject: (question on ANSI X9.62-2005) Re: [TLS] Ecdsa-sig-value in TLS 1.3 – 
need for erratum?

 

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 <mailto: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 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__standards.globalspec.com_std_1955141_ANSI-2520X9.62=DwMDaQ=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE=mf6j6fOClApRsArWE9wqI1rEGUVkfxZ0aXWmn35nK_c=GWxp2Bkr_PO-b6yqjHlSg6UyHEqtMmHRuBwfpqchO7c=jYe-ABDhTsOLtk6YVz_62-Hc3mixZpwqMVoyCllAYOE=>
 
 
 

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 <mailto:TLS@ietf.org> 
Subject: Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?
 
Hubert Kario  <mailto:hka...@redhat.com>  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 <mailto:TLS@ietf.org> 
https://urldefense.proofpoint.com/v2/ur

Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?

[Dan Brown]

> -Original Message-
> From: John Mattsson 
>
> Dan Brown  wrote:
>
> > ANSI X9.62-2005 was withdrawn in 2015
>
> Ok, that TLS 1.3 is relying on a withdrawn publication that used to be 
> behind a
> paywall is even worse.

[DB] Have mercy on TLS: I expect they had plenty of working code, and archived 
ECDSA specs for documentation, so it's not at all their fault that another 
organization's specs expired while they were undertaking a major improvement.

>
> > Also, I expect FIPS 186-5 is nearly ready, and will specify much of ECDSA
>
> That NIST FIPS 186-5 will include all the details needed to implement ECDSA 
> is
> great.

[DB] I think I also said that I was not sure if it will have any ASN.1 (i.e. 
resolution of ECDSA-Sig-Value).

>
> >IETF has specs for sigs and their formats already, no?
>
> At the time when RFC 8446 was published, there was probably no quick and
> easy solution to the problem. But the fact that IETF has historically been 
> fine
> with relying on specifications behind paywalls is part of the problem. If 
> IETF had
> implemented a strong open-access policy a long-time ago, there would
> probably be an open-access version of ECDSA (NIST or IETF) a long time ago.
>
[DB] SECG was created, among several other reasons, to provide a kind of 
open-read-access ECC specifications.  I think some IETF docs even refer to 
SECG, maybe SEC2?

Doesn't IETF have RFC 5480, 6090, 6979, which cover a fair amount of ground in 
specifying (some variation of) ECDSA?  Although, that's not a policy, and 
maybe was not even an easy enough solution for RFC 8446, etc.



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

Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?

[Dan Brown]

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=DwICAg=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw=A-9JTBh7dU_hCbOrrx-iACEmGPbjipnEohllYGLju6I=p2p9Y_hh-jb_qBNaNqTbSTYE2tAuJo-BaKDbemFVLxU=



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

Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?

[Dan Brown]

A brief reminder below about 2 new extra elements of ECDSA-Sig-Value.

> -Original Message-
> From: TLS  On Behalf Of Hubert Kario
> Sent: Monday, September 30, 2019 8:56 AM

>
> At the same time SEC 1 v2.0[1] defines that structure as follows:
>
>ECDSA-Sig-Value ::= SEQUENCE {
>r INTEGER,
>s INTEGER,
>a INTEGER OPTIONAL,
>y CHOICE { b BOOLEAN, f FieldElement } OPTIONAL
>}

The new a and y values help a verifier recover the point R (where R=kG, and 
r=x(R) mod n, s=(e+dr)/k mod n), if desired.

Of course, it is possible to recover R from r, without a or y, but the 
downside is that such recovery seems to requiring test two different 
candidates for R.

There are a few small benefits of recovering R.

Faster verification: the verifier can verify as tsR=teG+trQ with a value t 
chosen to make both ts and tr small, which can be faster than using r alone.

Public-key recovery: the verifier can compute the signer's public key as Q = 
(1/r)(sR-eG).  The subtle sub-applications of Q-recovery include: 
proof-of-generation (if the message signed contains Q, then Q seems to be 
uniquely tagged), data compression (omitting Q from the cert), assisted key 
generation (a trusted authority adds entropy into Q).

I'm not sure if these applications are relevant to TLS, however.

At the ASN.1 and DER formatting level, the intent was that
 (1) old syntax signatures (r,s only) would be compatible with the new syntax 
since optional fields are DER-encoded as empty strings, to empty string should 
DER-decode (is this right?), and
 (2) a lax, liberal implementation of the old syntax would understand the new 
syntax, simply by ignoring the new values a and y, (and ignoring the total 
length of the DER encoding).

Of course, the strictly proper way to do (2) was to have put an ASN.1 "..." 
placeholder in the old syntax, thereby accommodating for future extensions. 
Alas, this was not put in.  So a strict, literal implementation of the old 
syntax should reject the new syntax.



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

[TLS] Question about client impersonation... was Re: ETSI releases standards for enterprise security and data centre management]

[Dan Brown]

Is the security property  mentioned below a defined goal of, and proved‎ for, 
TLS 1.3?

Just curious, because it seems a little counter-intuitive: ‎impersonation of an 
anonymous (unauthenticated) client, under the harsh conditions of all content 
in the clear. It is certainly plausible by regarding the client as having a a 
MAC key and a pseudonym from the handshake: I think many key exchange proofs 
have a notion of sessions, etc., and PKE definitions also have notions of 
non-malleability, so I would not be surprised if a proof of this property is 
known for TLS 1.3. ‎ If there is a proof, then could it be said that eTLS 
defeats the proof, etc.


From: Tony Arcieri
Sent: Saturday, December 1, 2018 11:00 AM
To: beld...@gmail.com
Cc: Crypto; 
Subject: Re: [TLS] ETSI releases standards for enterprise security and data 
centre management

This does not seem to address a problem which was brought up when the similar 
draft-green-tls-static-dh-in-tls13-00 was discussed, namely any system in 
possession of one of the non-ephemeral-ECDHE private keys, ostensibly for the 
purposes of passive traffic decryption, can arbitrarily resume decrypted 
sessions and therefore impersonate any observed clients..

I'm not a fan of systems like this, but I believe for security reasons they 
should be designed in such a way that only the confidentiality of traffic is 
impacted, and a "visibility" system isn't able to leverage the decrypted 
traffic to resume decrypted sessions and thereby impersonate clients.

-- 
Tony Arcieri



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

Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?

[Dan Brown]

The TLS 1.3 draft sentence “They are no longer considered appropriate for 
general use and should be assumed to be potentially unsafe” seems a bit 
excessive.  I suggest deleting it, and think that its encompassing paragraph 
flows fine without it, and is sufficiently logical.  I see its removal as an 
editorial change (though I am not sure it is too late or not to make such a 
change).

 

More rationale below …

 

For example, consider secp256k1 (used in bitcoin), one of the curves 
obsoleted/deprecated in TLS 1.3 and 4492bis.  I certainly agree with the 
prevailing wisdom (first suggested by Miller) that, because secp256k1 is a 
special CM curve, it is a greater security risk than non-CM curves (including 
secp251r1 (aka NIST P256), Curve25519, and the Brainpool curves).  It is fine 
for TLS to heed this advice.

 

But there is still no proof that the risk is greater, and various reputable 
authors have pointed out situations that special algorithms may sometimes 
better survive disasters than their less special counterparts, I can dig up 
references if needed.  (My view is that this risk of disaster is to apply both 
types of algorithms, i.e. defense in depth, (hence I proposed a new CM curve to 
CFRG) but I would perfectly understand if doubling the cost of key agreement is 
too expensive for TLS.

 

I also don’t dispute that supporting (a choice of) many curves might induce 
security risks (e.g. spreading security analysis too thin, etc., weakest option 
attacks, etc.), and that there may be greater implementation risks (of some 
curves vs others), and so on, but I view most of these risk as pragmatic risks, 
which are mitigatable with sufficient effort.

 

The quoted sentence “They are no longer considered appropriate for general use 
and should be assumed to be potentially unsafe” loses most of these nuances. 

 

From: Eric Rescorla [mailto:e...@rtfm.com] 
Sent: Tuesday, July 17, 2018 11:02 AM
To: Dan Brown 
Cc: Hanno Böck ; tls@ietf.org
Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?

 

Well, I note that the text also says "or have had very little usage,"

 

-Ekr

 

 

On Tue, Jul 17, 2018 at 7:57 AM, Dan Brown mailto:danibr...@blackberry.com> > wrote:

It's mainly due to CFRG's advice, isn't it?
Calling other curves potentially unsafe or inappropriate for general use is a 
bit harsh and outside the scope of TLS, isn't it?
As to using a narrow or wide set of curves, there are reputable proposals for 
the latter:

ia.cr/2015/647 <http://ia.cr/2015/647>  and ia.cr/2015/366 
<http://ia.cr/2015/366> 

which may be too slow for TLS, or lacking in some other practicalities, but it 
is hard to conclude it is riskier or less secure.

If it's not too late then an editorial softening for the reason for the set of 
allowed TLS curves makes sense.

Best regards,

Dan


  Original Message
From: Hanno Böck
Sent: Tuesday, July 17, 2018 9:56 AM
To: tls@ietf.org <mailto:tls@ietf.org> 
Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?



Hi,

I think there's been a mentality change in the TLS community that
explains this.
Back when Brainpool curves were standardized there was a "more is
better" mentality when it came to algorithms. I.e. if an algorithm is
not broken it's good to have it in TLS. Particularly all kinds of
nationalized algs made it into TLS.

There's a very strong reason against this: It creates complexity. More
opportunities for attacks, more fragmentation of the ecosystem. I
believe I speak for a lot of people here when I say that fewer
algorithms is better and having more algs "just because" is not a good
reason. With that in mind an algorithm doesn't have to be weak to be
removed from TLS. It's reason enough if it's rarely used and doesn't
have a significant advantage over alternatives.

Brainpool curves were never widely used in mainstream deployments of TLS
(aka browsers). They have no significant advantage over the other
choices. They pretty much exist because Germany wanted to have their
homegrown crypto algorithm, too, meaning they exist for nationalistic
reasons, not technical ones. So deprecating them has the same reason we
don't have SEED or Camellia in TLS any more.

--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de <mailto:ha...@hboeck.de> 
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

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

___
TLS mailing list
TLS@ietf.org <mailto: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] Why are the brainpool curves not allowed in TLS 1.3?

[Dan Brown]

It's mainly due to CFRG's advice, isn't it?
Calling other curves potentially unsafe or inappropriate for general use is a 
bit harsh and outside the scope of TLS, isn't it?
As to using a narrow or wide set of curves, there are reputable proposals for 
the latter:

ia.cr/2015/647 and ia.cr/2015/366

which may be too slow for TLS, or lacking in some other practicalities, but it 
is hard to conclude it is riskier or less secure.

If it's not too late then an editorial softening for the reason for the set of 
allowed TLS curves makes sense.

Best regards,

Dan


  Original Message
From: Hanno Böck
Sent: Tuesday, July 17, 2018 9:56 AM
To: tls@ietf.org
Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?


Hi,

I think there's been a mentality change in the TLS community that
explains this.
Back when Brainpool curves were standardized there was a "more is
better" mentality when it came to algorithms. I.e. if an algorithm is
not broken it's good to have it in TLS. Particularly all kinds of
nationalized algs made it into TLS.

There's a very strong reason against this: It creates complexity. More
opportunities for attacks, more fragmentation of the ecosystem. I
believe I speak for a lot of people here when I say that fewer
algorithms is better and having more algs "just because" is not a good
reason. With that in mind an algorithm doesn't have to be weak to be
removed from TLS. It's reason enough if it's rarely used and doesn't
have a significant advantage over alternatives.

Brainpool curves were never widely used in mainstream deployments of TLS
(aka browsers). They have no significant advantage over the other
choices. They pretty much exist because Germany wanted to have their
homegrown crypto algorithm, too, meaning they exist for nationalistic
reasons, not technical ones. So deprecating them has the same reason we
don't have SEED or Camellia in TLS any more.

--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

___
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] Breaking into TLS for enterprise "visibility" (don't do it)

[Dan Brown]

Dear TLS WG,

Enterprise "visibility" is a network issue, not an Internet issue, and thus, to 
my _limited_ understanding, should be out of scope of IETF.

Nonetheless, enterprise security is important, and enterprise networks use 
Internet technology internally, so the topic is perhaps still procedurally 
discussable, so I continue.  I (naively) worry that "visibility" is also 
"siphonability", creating an incentive for a Snowden-sized (but malicious) 
leak, which could hurt enterprises and their customers.  In other words: who 
watches the watchers; avoid a single point of weakness; prevent social 
engineering opportunities; decentralize power; make sure the cure is not worse 
than the ailment; etc.  It is not yet clear (to me) which attackers 
"visibility" would thwart, but if it is just naïve (but plentiful) insiders, 
then I imagine the optimal solution would be better endpoint management (which 
may be a more difficult road than "visibility", but should still be the 
long-term solution).

Best regards,

Dan

PS: I never directly worked on enterprise security (usually, I just think about 
the math of basic crypto primitives), but I don't recall hearing about such a 
"visibility" feature in the enterprise security work of colleagues (whom I do 
_not_ speak for), e.g. one system used forward-secure ECMQV to establish a 
connection between smartphones and the enterprise network.





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

Re: [TLS] Preshared Keypairs for (D)TLS 1.2

[Dan Brown]

Hi Tony,

Perhaps (some variant of) Menezes-Qu-Vanstone MQV key agreement might work for 
your problem.

There are some security analyses for variants MQV, e.g. HMQV, and it offers 
even better efficiency than triple-DH.

The original MQV appears in a few standards (NIST SP 63a, IEEE 1363, ANSI 
X9.63, even SEC1, and was dropped from Suite B ...).  I believe that some I-Ds 
were written on using MQV in TLS (or elsewhere in IETF), but they expired.

Best regards,

Dan

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Tony Putman
Sent: Thursday, October 26, 2017 11:03 AM
To: tls@ietf.org
Subject: [TLS] Preshared Keypairs for (D)TLS 1.2

Hi all,

I've recently started working in the IoT space and wish to standardize
our transport security by introducing the use of DTLS. It seems that the
usual practice is to use PSK for mutual authentication, but I'm not
happy with this solution. A breach of server security allows not only
server impersonation, but also, due to the PSK symmetry, client
impersonation.

We are already using static ECDH keys for authentication (at the
application layer), so I looked for a way to make use of these in DTLS
and came up with the following solution using (D)TLS 1.2:

Assume the client is provisioned with an Id, a corresponding private key
'c_id' and a corresponding server public key 'S_id' (the server key may
be different for each Id or it may be common across all clients); the
server has a list of client public keys 'C_id' and corresponding server
private key(s) 's_id'. This OOB pre-provisioning corresponds to that of
a symmetric PSK.

The TLS 1.2 message exchange is identical to that for a TLS_(EC)DHE_PSK
handshake as in RFC4279. This solution applies to both DH/DHE keys and
to ECDH/ECDHE keys. The IoT solutions will typically use ECDH/ECDHE, so
the following explanation focuses on the EC variant. The messages are:

Client Server
-- --
ClientHello ->
  ServerHello
ServerKeyExchange
<-ServerHelloDone
ClientKeyExchange
ChangeCipherSpec
Finished->
 ChangeCipherSpec
<-   Finished
Application Data<>   Application Data

The way this differs from TLS_ECDHE_PSK is only in the generation of
the premaster secret. Suppose the ECDHE keys are 'a' (private) and 'A'
(public) from the server; and 'b' (private) and 'B' (public) from the
client. Then the client and server form the premaster secret in a struct
with the following information (where [x]Y represents multiplication of
the point 'Y' by the scalar 'x'):
Client Premaster:   [b]A || [c_id]A || [b]S_id
Server Premaster:   [a]B || [a]C_id || [s_id]B

The first term provides PFS even if both client and server static
private keys become known; the second term provides client
authentication even if server keys are compromised; and the third term
provides server authentication even if client keys are compromised.

My questions to the list are:
=
1. Has anything similar to this been proposed before (I found nothing)?
2. Can anyone see a problem with this formulation?
3. Is there any interest in this (I would be happy to write an ID)?

The reason that I advocate this for IoT devices over signature schemes
is that the code for ECDH will already have to be present if modern
key agreement methods with PFS are to be used. So this solution uses
fewer resources than ECDHE together with a signature scheme in terms of
code space and RAM, and improves execution speed (I believe ECDH is about
twice as fast as equivalent signature generation/checking). Also, fewer
messages are needed and the messages are smaller (even if using raw keys).

A constraint not made explicit above is that the (EC)DHE keys must use
the same group/curve parameters as define the preshared keypairs. Since
the ClientHello does not contain any client information, this means the
server endpoint (e.g. as defined by SNI) can only support a single form
of preshared keypair. This could be improved on in TLS 1.3.

I don't believe that this constraint is serious, because this method is
designed to be used in the same scenarios as PSK; that is, where client
and server have an OOB method of receiving authentication credentials
from a common source. In this situation, the server is unlikely to be
serving clients which use multiple types of preshared keypairs, though
it does mean that if the keypair format is changed (e.g. strengthened)
during the life of an IoT product then a new server endpoint will have
to be defined for the upgraded products.

Additionally, this method is proposed to prevent the leaking of client
credentials if the server is compromised. This means that the client
private key must be high-entropy: this method is not suitable for keys

Re: [TLS] 32 byte randoms in TLS1.3 hello's

[Dan Brown]

-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] 

I don't think this is simply a case of multiple CSPRNGs.

DB> Not quite sure what you mean by "simply a case of multiple CSPRNGs", but I 
am starting to get an idea below.

My guess is many TLS implementations don't have visibility into how the CSPRNG 
operates. That code does however, know which output values will be public and 
which not. For me, that implies that any good separation scheme applied within 
the TLS code that differentiates between public and non public outputs is a 
good plan. 

DB> Ok, suppose the TLS implementation wishes to just read /dev/urandom, which 
is presumably a good CSPRNG.  Unlike the NIST RBGs, there's no interface to 
create independent and separate instantiations of /dev/urandom (as far as I 
know, although newer versions may provide this feature).  So, what would count 
as your "separation scheme"?  Are you saying the TLS code should post-process 
the output of a single CSPRNG?  If so, then that's probably a good idea, if 
done right.  At least it doesn't have the downside risk of the TLS coder 
generating its own seeds, writing its own CSPRNG (instead of using 
/dev/urandom), etc.  (I thought that I was being very specific that launching 2 
CSPRNGs was not a good idea, yet it seems I was read as preferring as doing 
nothing and keeping the status quo, which is not what I intended.)  So, I think 
some kind of clarification of the currently proposed text (for -21 ?)  may be 
worthwhile, because I read it creating two separate CSPRNGs.  (Of course, defenc
 e in depth is good, and often worth the implementation cost, but if it 
introduces new security problems, then it is not too good.  More 
philosophically, in an ideal world, any additions to the TLS spec should be 
vetted with pedigree.  Trying to create independently seeded CSPRNGs goes 
against the current best practices as I understand them.  By contrast, TLS 
already has all kinds of key derivation, separation for different purposes 
(unless that was dropped in 1.3???), which TLS might as well continue to use.  

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

Re: [TLS] 32 byte randoms in TLS1.3 hello's

[Dan Brown]

‎Section 3, of the eprint "Ron is wrong, Whit is right", subsection "Moduli 
with shared primes", suggests to me that it's not unlikely when seeding two 
secrets near in time, one has low entropy (by accident). That's not the only 
explanation of the observed shared primes, but is plausible and relevant to the 
question at hand. (I thought I mentioned this earlier.)
From: Colm MacCárthaigh
Sent: Saturday, July 29, 2017 2:04 PM
To: Dan Brown
Cc: Stephen Farrell; Eric Rescorla; Blumenthal, Uri - 0553 - MITLL; tls@ietf.org
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's




I don't see anything relevant to the problem at hand in that paper. Did you 
reference the right one? There are some mentions about not re-using random 
secrets, but that applies no matter how many RNGs you use.

In your previous mail, even if an implementer were to seed two RNGs from one 
CSPRNG, and all 3 are bad generator, this is still strictly better than one 
broken generator; because the amount of work an attacker must do is far greater.

On Sat, Jul 29, 2017 at 8:54 AM, Dan Brown 
<danibr...@blackberry.com<mailto:danibr...@blackberry.com>> wrote:
https://eprint.iacr.org/2012/064
mentions the problem of generating multiple secrets instead of a single secret




  Original Message
From: Stephen Farrell
Sent: Friday, July 28, 2017 11:48 AM
To: Dan Brown; Eric Rescorla; Blumenthal, Uri - 0553 - MITLL
Cc: tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's


I don't think this is simply a case of multiple CSPRNGs.

My guess is many TLS implementations don't have visibility
into how the CSPRNG operates. That code does however, know
which output values will be public and which not. For me,
that implies that any good separation scheme applied within
the TLS code that differentiates between public and non
public outputs is a good plan. Yes, if an attacker can bork
your CSPRNG, they may be able to get at the TLS code too
sometimes, but I'd argue the defence in depth is worthwhile.

Cheers,
S.

On 28/07/17 14:37, Dan Brown wrote:
> I try below to better explain my points against separated public and private 
> CSPRNG instances.
>
> Perhaps the easiest way to get "independent" seeds for the two instances of a 
> CSPRNG, is to use a third CSPRNG instance to generate the seeds.  But then 
> the problem arises again, if the 3 CSPRNGs are bad enough, (0=seeder, 
> 1=public, 2=private), there is a risk that:
>
> Public_nonce=output1=>seed1=output0_for_1=>seed0=>output0_for_2=seed2=>output_2=private_key=TLS_insecurity.
>
> In short, generally speaking, three bad CSPRNGs do not combine easily into 1 
> good CSPRNG.
>
> (I'm not yet sure if this attack on three CSPRNGs combined applies to 
> Dual_EC, since it may do something hash-like to the seed (I forgot details), 
> and also output leaks the next state, not the previous state, as I recall, so 
> that might break the chain above.)
>
> The alternative to a 3rd CSPRNG is to get the seeds from directly from a raw 
> entropy source. In that case, keep in mind that one of the purposes of 
> CSPRNGs is that raw entropy sources are unreliable (sometimes stall, etc. 
> [references to be added]) and generally weak on the independence (they are 
> non-uniform, hence have correlations).  CSPRNGs are supposed to correct these 
> deficiencies, among other things.  So, if the 2 seeds are generated directly 
> from a raw entropy sources (without a CSPRNG), two things may go wrong. 
> First, deriving one seed from the other might be feasible because of 
> non-uniformity. A bad CSPRNG might enable this this to be exploited, by 
> finding one seed from the other.  Second, if the entropy source stalls (down 
> a trickle of low entropy), between too close seed requests - accidentally - 
> then even a good CSPRNG couldn't cope.
>
> Maybe, all this wouldn't be a problem on many higher end systems, with high 
> entropy, so my concern is lower end systems, and also unnecessary 
> complications of maintaining multiple bad CSPRNGs, potentially to no avail.
>
> Finally, on systems with a linux-style interface, /dev/urandom and 
> /dev/random could be used as the two CSPRNGs on some systems (or seed 
> sources), although I think one of these is now deprecated?
>
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>] On 
> Behalf Of Stephen Farrell
> Sent: Friday, July 28, 2017 4:47 AM
> To: Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>>; Blumenthal, Uri - 
> 0553 - MITLL <u...@ll.mit.edu<mailto:u...@ll.mit.edu>>
> Cc: tls@ietf.org<mailto:tls@ietf.org>
> Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
>
>
> Hiya,
>
> On 28/07/17 00:50, Eric Rescorla wrote:
>> I used the te

Re: [TLS] 32 byte randoms in TLS1.3 hello's

[Dan Brown]

I try below to better explain my points against separated public and private 
CSPRNG instances. 

Perhaps the easiest way to get "independent" seeds for the two instances of a 
CSPRNG, is to use a third CSPRNG instance to generate the seeds.  But then the 
problem arises again, if the 3 CSPRNGs are bad enough, (0=seeder, 1=public, 
2=private), there is a risk that:
 
Public_nonce=output1=>seed1=output0_for_1=>seed0=>output0_for_2=seed2=>output_2=private_key=TLS_insecurity.

In short, generally speaking, three bad CSPRNGs do not combine easily into 1 
good CSPRNG.  

(I'm not yet sure if this attack on three CSPRNGs combined applies to Dual_EC, 
since it may do something hash-like to the seed (I forgot details), and also 
output leaks the next state, not the previous state, as I recall, so that might 
break the chain above.)

The alternative to a 3rd CSPRNG is to get the seeds from directly from a raw 
entropy source. In that case, keep in mind that one of the purposes of CSPRNGs 
is that raw entropy sources are unreliable (sometimes stall, etc. [references 
to be added]) and generally weak on the independence (they are non-uniform, 
hence have correlations).  CSPRNGs are supposed to correct these deficiencies, 
among other things.  So, if the 2 seeds are generated directly from a raw 
entropy sources (without a CSPRNG), two things may go wrong. First, deriving 
one seed from the other might be feasible because of non-uniformity. A bad 
CSPRNG might enable this this to be exploited, by finding one seed from the 
other.  Second, if the entropy source stalls (down a trickle of low entropy), 
between too close seed requests - accidentally - then even a good CSPRNG 
couldn't cope.

Maybe, all this wouldn't be a problem on many higher end systems, with high 
entropy, so my concern is lower end systems, and also unnecessary complications 
of maintaining multiple bad CSPRNGs, potentially to no avail.  

Finally, on systems with a linux-style interface, /dev/urandom and /dev/random 
could be used as the two CSPRNGs on some systems (or seed sources), although I 
think one of these is now deprecated? 

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell
Sent: Friday, July 28, 2017 4:47 AM
To: Eric Rescorla <e...@rtfm.com>; Blumenthal, Uri - 0553 - MITLL 
<u...@ll.mit.edu>
Cc: tls@ietf.org
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's


Hiya,

On 28/07/17 00:50, Eric Rescorla wrote:
> I used the term "separate" here, which was intended to convey this, 
> but if people think "independent" or something is better, happy to change.

I think your change is a fine improvement over -21, thanks.
(And my suggested text was as imperfect as I usually manage:-)

I'm not clear if implementers will or will not get the ramifications of 
"separate" (or "independent"), so I think we ought describe (or reference) at 
least one way in which that separation can be achieved.

I also think we ought at least RECOMMEND separate CSPRNGs.
I'd prefer a MUST myself but since there's no one good way we can describe to 
achieve the effect that'd work in all cases, I don't think we can say MUST.

Cheers,
S.


> 
> -Ekr
> 
> 
> On Thu, Jul 27, 2017 at 4:43 PM, Blumenthal, Uri - 0553 - MITLL < 
> u...@ll.mit.edu> wrote:
> 
>> Respectfully disagree. Having two cryptographically independent 
>> PRNGs, one for public data and one for key material, IMHO is a good 
>> idea. Of course, both should be properly seeded - but that's a different 
>> issue.
>>
>> Regards,
>> Uri
>>
>> Sent from my iPhone
>>
>> On Jul 27, 2017, at 19:33, Dan Brown <danibr...@blackberry.com> wrote:
>>
>>
>> I don't think 2 CSPRNGs is a good idea.
>>
>> Wasn’t there a few years back some RSA keys with separate p and q, 
>> generated independently leading to an attack...
>>
>> Here if the seeds to initialize the RNGS are related, or one is weak, 
>> or worst if the seed is a raw source that doesn’t change in the 
>> moments between the two CSPRNG inits, that'd be bad, even if the CSPRNGs 
>> were good.
>> *From: *Eric Rescorla
>> *Sent: *Thursday, July 27, 2017 6:34 PM
>> *To: *Stephen Farrell
>> *Cc: *tls@ietf.org
>> *Subject: *Re: [TLS] 32 byte randoms in TLS1.3 hello's
>>
>> Spec updated here;
>> https://github.com/tlswg/tls13-spec/commit/465de0e189b2b59090d0eac0ac
>> bc42
>> 942af9ca77
>>
>> -Ekr
>>
>>
>> On Wed, Jul 26, 2017 at 4:27 PM, Stephen Farrell < 
>> stephen.farr...@cs.tcd.ie> wrote:
>>
>>>
>>> I've suggested some text for this in a PR [1] based on what people 
>>> have said in this thread.
>>>
>>> I'm sure that can be further i

Re: [TLS] 32 byte randoms in TLS1.3 hello's

[Dan Brown]

I don't think 2 CSPRNGs is a good idea.

Wasn’t there a few years back some RSA keys with separate p and q, generated 
independently leading to an attack...

Here if the seeds to initialize the RNGS are related, or one is weak, or worst 
if the seed is a raw source that doesn’t change in the moments between the two 
CSPRNG inits, that'd be bad, even if the CSPRNGs were good.
From: Eric Rescorla
Sent: Thursday, July 27, 2017 6:34 PM
To: Stephen Farrell
Cc: tls@ietf.org
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's


Spec updated here;
https://github.com/tlswg/tls13-spec/commit/465de0e189b2b59090d0eac0acbc42942af9ca77

-Ekr


On Wed, Jul 26, 2017 at 4:27 PM, Stephen Farrell 
> wrote:

I've suggested some text for this in a PR [1]
based on what people have said in this thread.

I'm sure that can be further improved.

It might be no harm to add more pointers to that
appendix from elsewhere in the spec, and/or to
add a list of the various public/private random
numbers that are needed to that appendix. (I'd be
happy to do a pass to identify those if folks
basically like this kind of addition.)

I also need to figure out how to handle the
reference properly:-) Can do that tomorrow.

Cheers,
S.

[1] https://github.com/tlswg/tls13-spec/pull/1068


___
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] 32 byte randoms in TLS1.3 hello's

[Dan Brown]

Thanks for the quick answers.

Yet more naive quick questions: ‎in the reused DH setting could a counter do 
the job of random nonce?‎ doesn't the record layer have an IV or nonce too? (or 
is that passe?).

If these questions are too naive, or too last minute, let me know and I'll 
withdraw them. I did look over 1.3 once, fwiw, but have since forgot the 
details, sorry.
  Original Message
From: Russ Housley
Sent: Monday, July 24, 2017 12:58 PM
To: Dan Brown
Cc: IETF TLS
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's


there was a discussion of adding a statement that a fresh ephemeral key MUST be 
used for each session.  It was decided not to do that.  Without such a 
requirement, nonces are needed.

Russ


> On Jul 24, 2017, at 12:40 PM, Dan Brown <danibr...@blackberry.com> wrote:
>
> Hmm, I'd appreciate a brief reminder* of why 1.3 needs nonces at all, given 
> that ephemeral DH is mandated, if anybody has the time/patience. (* ok, not 
> that I truly ever knew).
>
> I assume that the risk of misusing the nonces, to exfiltrate keys etc, is 
> small enough compared to other side channels to justify their added value.
>
>
>  Original Message
> From: Stephen Farrell
> Sent: Monday, July 24, 2017 11:15 AM
> To: tls@ietf.org
> Subject: [TLS] 32 byte randoms in TLS1.3 hello's
>
>
> Hiya,
>
> I'm guessing many folks interested in TLS may have been
> at the QUIC session in Prague and hence missed out on the
> excellent talk by Stephen Checkoway on the juniper dual-ec
> incident. (I highly recommend taking a peek at the slides [1]
> or reading the paper [2] or watching the video wherever
> that may be;-).
>
> Anyway, in TLS1.3 we've gotten rid of the gmt time option
> in the client and server hello, which is good, (and I do
> recall that discussion) but we've also changed from:
>
>   // RFC5246
>   struct {
>  uint32 gmt_unix_time;
>  opaque random_bytes[28];
>   } Random;
>
> to:
>
>   // tls1.3 -21
>   opaque Random[32];
>
> Now if some TLS1.3 deployment were affected by a dual-ec
> attack, it'd seem like the -21 version of Random might be
> even better than the TLS1.2 version, for the attacker.
>
> I tried to see where that 28->32 change came from but
> didn't find it (apologies if I missed that). I guess it
> just ensures that the overall length of the struct is
> the same.
>
> So, a question and a possible suggestion:
>
> Q: Why do we need 32 bytes of Random?
>
> Suggestion: if we don't need that much, maybe we could
> change the length there, (I can see that might trigger
> bugs and middlebox issues) or encourage/require folks
> to mask out some of those bits (e.g. with zeros or some
> catchy hex encoded message about dual-ec:-).
>
> Cheers,
> S.
>
>
> [1]
> https://www.ietf.org/proceedings/99/slides/slides-99-irtfopen-anrp-stephen-checkoway-a-systematic-analysis-of-the-juniper-dual-ec-incident-00.pdf
> [2] https://web.eecs.utk.edu/~mschucha/netsec/readings/p468-checkoway.pdf
>
> ___
> 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] 32 byte randoms in TLS1.3 hello's

[Dan Brown]

Hmm, I'd appreciate a brief reminder* of why 1.3 needs nonces at all, given 
that ephemeral DH is mandated, if anybody has the time/patience. (* ok, not 
that I truly ever knew).

I assume that the risk of misusing the nonces, to exfiltrate keys etc, is small 
enough compared to other side channels to justify their added value.


  Original Message
From: Stephen Farrell
Sent: Monday, July 24, 2017 11:15 AM
To: tls@ietf.org
Subject: [TLS] 32 byte randoms in TLS1.3 hello's


Hiya,

I'm guessing many folks interested in TLS may have been
at the QUIC session in Prague and hence missed out on the
excellent talk by Stephen Checkoway on the juniper dual-ec
incident. (I highly recommend taking a peek at the slides [1]
or reading the paper [2] or watching the video wherever
that may be;-).

Anyway, in TLS1.3 we've gotten rid of the gmt time option
in the client and server hello, which is good, (and I do
recall that discussion) but we've also changed from:

   // RFC5246
   struct {
  uint32 gmt_unix_time;
  opaque random_bytes[28];
   } Random;

to:

   // tls1.3 -21
   opaque Random[32];

Now if some TLS1.3 deployment were affected by a dual-ec
attack, it'd seem like the -21 version of Random might be
even better than the TLS1.2 version, for the attacker.

I tried to see where that 28->32 change came from but
didn't find it (apologies if I missed that). I guess it
just ensures that the overall length of the struct is
the same.

So, a question and a possible suggestion:

Q: Why do we need 32 bytes of Random?

Suggestion: if we don't need that much, maybe we could
change the length there, (I can see that might trigger
bugs and middlebox issues) or encourage/require folks
to mask out some of those bits (e.g. with zeros or some
catchy hex encoded message about dual-ec:-).

Cheers,
S.


[1]
https://www.ietf.org/proceedings/99/slides/slides-99-irtfopen-anrp-stephen-checkoway-a-systematic-analysis-of-the-juniper-dual-ec-incident-00.pdf
[2] https://web.eecs.utk.edu/~mschucha/netsec/readings/p468-checkoway.pdf

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

Re: [TLS] chairs - please shutdown wiretapping discussion...

[Dan Brown]

I agree with Stephen: this ID and all its detailed discussion should move over 
to the Intranet ETF and/or the Internet Subverting TF (wherever such a TF may 
be).‎ TLS 1.3 is already a big change.

Sent from my BlackBerry 10 smartphone on the Rogers network.
  Original Message
From: Stephen Farrell
Sent: Saturday, July 8, 2017 5:17 AM
To: tls chair
Cc: tls@ietf.org
Subject: [TLS] chairs - please shutdown wiretapping discussion...


Sean/Joe,

This is a request that you, as chairs, shut down the distracting
wiretapping discussion, at least until DTLS1.3 is done.

I have planned to spend time reading draft 21 and DTLS, but that
won't happen if we keep having to fight off the latest attempts
to break TLS. I'd not be surprised if I weren't the only one
finding that distraction an irritating waste of time. Finishing
TLS1.3 and getting DTLS1.3 on the way surely needs to not be
constantly de-railed by these attempts to break TLS.

Therefore I'd ask that you declare this discussion closed for at
least that long (i.e until DTLS1.3 is done).

I'd also ask that you not allocate agenda time for wiretapping
in Prague.

Thanks,
S.

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

Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh

[Dan Brown]

 connections, but we're not the police and fixing
DH values is probably how they would do it. If it's going to be A
Thing then it's much more likely that things will get misconfigured
and it'll be enabled in places where it shouldn't be. If we have no
detection mechanism then what we'll probably end up with is a Blackhat
talk in a few years time about how x% of banks botched forward
security at their frontends.

Say that a value of an hour makes sense for some device and we feel
that an hour's forward-security window is reasonable for security. The
issue is that it significantly diminishes our detection ability
because clients need to remember more than an hour's worth of values
and I don't know if we can dedicate that amount of storage to this.

Since I think the utility of this falls off as a reciprocal, I'll try
making a concrete suggestion for a time limit: 10 seconds.

>> Also, this cost doesn't seem too high: 85.6% of servers /don't/ reuse
>> values and manage fine today. The generation of (EC)DH public values
>> is also a fixed-based operation and thus can be much faster than DH
>> key-agreement.
>
> According to the paper, a large majority of servers in the Alexa top
> 1M are reusing keys. That 14.4% number is a fraction of the 80%
> servers consistently in the Alexa top 1M that use browser-trusted
> certificates and that use ECDHE. IIUC, approximately 20% of servers in
> the Alexa top 1M that use browser-trusted certificates are using RSA
> key exchange, which means they are also reusing the same key for every
> connection. Also, according to the paper, more than half of servers
> aren't using TLS or aren't using browser-trusted certificates, which
> means that web browser connections to them are likely using the same
> NULL key.

Thanks for pointing that out. I thought that saying "14.4%" and so on
was reasonable because it's a prevalence and we can assume that if
other sites did enable (EC)DHE then they would probably make the same
mistakes at a similar rate. But then I subtracted it from 100 and that
really doesn't make sense.

> Also, the Alexa top 1M isn't representative of every use of TLS, but
> rather only one kind of application.
>
>> Lastly, some have proposed[2] (EC)DH reuse as a mechanism for enabling
>> TLS connections to be decrypted and monitored by a middlebox. TLS is
>> not designed to be decrypted by third-parties—that's kind of the
>> point. Thus anyone doing this should not be surprised to hit a few
>> MUST NOTs and, potentially, to have to configure implementations to
>> allow such a deployment.
>
> The (presumably) accidental reuse of keys for long periods of time is
> bad, and this MitM idea is even worse. But, if reuse were made a MUST
> NOT, wouldn't such systems just use a different, perhaps worse, more
> complex, and undetectable mechanism, like the one Dan Brown suggested
> in the earlier thread? I think we should assume that while we may be
> able to help prevent the former accidental badness with such a rule,
> such a mechanism probably isn't going to have much effect on the
> latter intentional badness.

I much prefer people who are going to backdoor their TLS to use DH as
the mechanism rather than something less detectable. I don't expect a
MUST NOT will slow them down at all. I just want to ensure that this
doesn't accidently carry into 1.3, and that any unofficial backdoor
mechanism needed by some organisations doesn't inadvertently get
enabled more widely than planned.


Cheers

AGL

--
Adam Langley a...@imperialviolet.org<mailto:a...@imperialviolet.org> 
https://www.imperialviolet.org

___
TLS mailing list
TLS@ietf.org<mailto: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] Confirming consensus: TLS1.3->TLS*

[Dan Brown]

I don't oppose any of the 4 given options, but I slightly prefer TLS 2.0, it 
seems simple and clear.  

In my opinion, the whole SSL vs TLS confusion needs better education to 
confront, version numbers (even dates) alone might not be enough.  Renaming 
*SSL products to *TLS should help.  Avoiding "SSL/TLS" might help.

Since others have proposed new options, how about TLS 2.017? Using the date has 
benefits, but the actual crypto changes are much more important, so the decimal 
makes that point.  An old crypto principle is that older is better (among 
equally unbroken options) -- but naming new stuff is just not enough to rid us 
of broken old stuff, so putting dates in names might not undermine this 
principle.  For future naming, on minor changes (or even pre-scheduled reviews 
with no changes), update the date part, on major changes, start from scratch 
(as in 3.2024, or even use different letters ... ).  

By the way, I'm sorry if my opinion diverges from the currently forming 
consensus.

Just my $0.02.
  
Dan

PS Just to be clear, if votes are to be tallied, my vote on this issue should 
be weighted quite low (i.e. 0, unless other votes are weighted low too, and 
some kind of tie-breaker is needed), for at least three reasons: I have not 
followed the TLS 1.3/2.0 spec closely (i.e., I had no part in building the 
shed); I have nearly zero experience dealing with user interpretation (i.e. 
marketing) of protocol names; my preference is weak. (Enough to deserve a 
negative weight, if that were not cheatable;)

PPS I've said before that I prefer TLC(rypto) to TLS(ecurity), but that's 
unlikely to fly, and it may be okay to grandfather this tradition.  (I hope 
names of future crypto protocols (that TLS WG might work on) can be more 
specific and realistic.)

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Dave Garrett
Sent: Tuesday, November 22, 2016 5:07 PM
To: tls@ietf.org
Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS*

(replies to a bunch of ideas in this thread)

As the person who lit the match under this latest bikeshed debate, personally, 
I don't see a strong consensus building here. Leaving the bikeshed unpainted 
seems like the option we're headed for, at this rate. I'm fine with TLS 1.3 if 
that's the result here.

That said, I think I've been somewhat swayed to the TLS 4 camp with the "fourth 
version of TLS" message. It makes a kind of messy sense that's kind of fitting 
for TLS. I'm no longer against it.

I've also suggested highlighting the year in the past, but only in the context 
of the title and messaging, not actually replacing the version number itself. 
I'd be ok with TLS 1.3-2017 (or something), not doing a find/replace of 1.3 and 
changing it to 2017, wholesale. That just feels even more confusing.

Lastly, I am vehemently against the suggestion of ditching the TLS name in 
favor of SSL again, as was also brought up in this thread. SSL is dead and 
insecure, and that message needs to stay. We need to get people to stop 
conflating the two and making this worse, not accepting it.


Dave


On Sunday, November 20, 2016 08:16:07 pm Eric Rescorla wrote:
> I mildly prefer TLS 1.3 to TLS 2 and TLS 4 (If we're going to rev the 
> major version number we should abandon the minor one).
> TLS 2017 strikes me as quite bad; we're certainly not planning to do a 
> TLS 2018. I am strongly opposed to TLS 2017.
> 
> -Ekr
> 
> 
> On Fri, Nov 18, 2016 at 11:12 AM, Sean Turner  wrote:
> 
> > At IETF 97, the chairs lead a discussion to resolve whether the WG 
> > should rebrand TLS1.3 to something else.  Slides can be found @
> > https://www.ietf.org/proceedings/97/slides/slides-
> > 97-tls-rebranding-aka-pr612-01.pdf.
> >
> > The consensus in the room was to leave it as is, i.e., TLS1.3, and 
> > to not rebrand it to TLS 2.0, TLS 2, or TLS 4.  We need to confirm 
> > this decision on the list so please let the list know your top choice 
> > between:
> >
> > - Leave it TLS 1.3
> > - Rebrand TLS 2.0
> > - Rebrand TLS 2
> > - Rebrand TLS 4
> >
> > by 2 December 2016.

___
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] TLS Visibility Inside the Data Center (was: I-D Action: draft-green-tls-static-dh-in-tls13-00.txt)

[Dan Brown]

Isn’t possible to achieve the goals of this proposal without re-using DH 
secrets?

For example, let DH_secret = KDF ( monitoring_key, server.hello , 
client.hello), or something similar.  Ideally, the monitoring_key should be 
updated frequently as possible (while keeping it synchronized).

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Matthew Green
Sent: Wednesday, November 16, 2016 8:55 AM
To: ynir.i...@gmail.com
Cc: tls@ietf.org
Subject: Re: [TLS] TLS Visibility Inside the Data Center (was: I-D Action: 
draft-green-tls-static-dh-in-tls13-00.txt)

Thanks for pointing out the line in Appendix D.1. I also agree that the 
proposal requires no changes to the current 1.3 specification, which is very 
much a point in its favor.

I don’t think there is a desired action from the TLS-WG. The goal is simply to 
have a document that other implementers can reference and work from, and 
preferably one that is developed openly within view of the working group — 
rather than having the implementers do this in another forum. A side benefit is 
that this Draft also help to drive some thinking on the part of the TLS 
protocol designers around how TLS 1.3 will actually be deployed in certain 
environments (see e.g., related thread on point validation).

Matt

On Nov 14, 2016, at 10:50 PM, tls-requ...@ietf.org 
wrote:

Message: 4
Date: Tue, 15 Nov 2016 10:28:05 +0900
From: Yoav Nir >
To: Sean Turner >
Cc: ">" >
Subject: Re: [TLS] TLS Visibility Inside the Data Center (was: I-D
Action: draft-green-tls-static-dh-in-tls13-00.txt)
Message-ID: 
<2f41d793-19e2-4c04-a914-e2f2581f8...@gmail.com>
Content-Type: text/plain; charset=us-ascii

If I understand this draft correctly, this draft describes server behavior. It 
does not change anything within the TLS 1.3 protocol. IOW a server doing this 
will interoperate with any client.

I searched the tls13 draft to see if it has anything to say about this, and the 
only thing I found was this line in appendix D.1:

  If fresh (EC)DHE keys are used for each connection, then the output keys are 
forward secret.

So a server is not required to generate fresh (EC)DHE keys for each connection. 
In fact, generating fresh keys periodically and discarding the old ones are a 
legitimate way to achieve forward secrecy. What this draft does differently is 
to save the old (EC)DHE private keys, which loses the forward secrecy.

So given that what the draft proposes is possible with the current TLS 1.3, 
what do the proponents want? Is it just to have a document that describes this 
server behavior?

Yoav

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

Re: [TLS] Industry Concerns about TLS 1.3

[Dan Brown]

Weaker crypto to stop insider attacks, is that the request? (And practice?) 
Doesn’t that increase the risk of larger (but perhaps rarer) further insider 
attacks?

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Hugo Krawczyk
Sent: Thursday, September 22, 2016 7:41 PM
To: BITS Security 
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

If the problem is the use of forward secrecy then there is a simple solution, 
don't use it.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] sect571r1

[Dan Brown]

FFDHE with prime field is one big step away from FFDHE with binary field, which 
has quasipoly time DLP, so that's quite a large risk.
ECDHE with binary field is also one big step away from binary FFDHE, but it's a 
different type of step: hence diversity.
I agree that diversity risks weakest link. Ideally, the rainy day backups 
should be disabled by default, but possible to quickly enable, by administrator 
configuration or patch.
From: Tony Arcieri
Sent: Wednesday, July 15, 2015 9:47 PM
To: Dan Brown
Cc: Martin Rex; tls@ietf.org
Subject: Re: [TLS] sect571r1


On Wed, Jul 15, 2015 at 6:42 PM, Dan Brown 
dbr...@certicom.commailto:dbr...@certicom.com wrote:
Even so, there's an argument from Koblitz and Menezes that special curves (e.g. 
binary curves) may survive some wider collapse. I think it's a weak argument, 
but for those for whom supporting more curves is easy, it could justify 
supporting a diversity of curves.

Others are pushing FFDHE in the event of some ECC disaster. I'm not really a 
fan of that either (all these things add attack surface in addition to being 
backups), but if we're going to keep a little used thing around in our pocket 
just in case of an ECC disaster, why do we need backup curves in addition to 
FFDHE?

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