[TLS] Weekly github digest (TLS Working Group Drafts)

2024-11-23 Thread Repository Activity Summary Bot 




Issues
--
* tlswg/draft-ietf-tls-esni (+0/-0/💬1)
 1 issues received 1 new comments:
 - #628 DNS issues from AD review. (1 by ekr)
   https://github.com/tlswg/draft-ietf-tls-esni/issues/628 




Pull requests
-
* tlswg/draft-ietf-tls-esni (+3/-2/💬1)
 3 pull requests submitted:
 - Invalid names end in .invalid. Fixes #630 (by ekr)
   https://github.com/tlswg/draft-ietf-tls-esni/pull/636 
 - Update the key rotation text. Fixes #629 (by ekr)
   https://github.com/tlswg/draft-ietf-tls-esni/pull/635 
 - Fix typo (by martinthomson)
   https://github.com/tlswg/draft-ietf-tls-esni/pull/634 


 1 pull requests received 1 new comments:
 - #636 Invalid names end in .invalid. Fixes #630 (1 by ekr)
   https://github.com/tlswg/draft-ietf-tls-esni/pull/636 


 2 pull requests merged:
 - Fix typo in "Server Behavior" section
   https://github.com/tlswg/draft-ietf-tls-esni/pull/633 
 - Fix typo
   https://github.com/tlswg/draft-ietf-tls-esni/pull/634 


* tlswg/tls13-spec (+1/-0/💬1)
 1 pull requests submitted:
 - Appendix on RPK misbinding attacks (by ms-s)
   https://github.com/tlswg/tls13-spec/pull/1366 


 1 pull requests received 1 new comments:
 - #1366 Appendix on RPK misbinding attacks (1 by ms-s)
   https://github.com/tlswg/tls13-spec/pull/1366 



Repositories tracked by this digest:
---
* https://github.com/tlswg/certificate-compression
* https://github.com/tlswg/dnssec-chain-extension
* https://github.com/tlswg/draft-deprecate-obsolete-kex
* https://github.com/tlswg/draft-ietf-tls-cert-abridge
* https://github.com/tlswg/draft-ietf-tls-ctls
* https://github.com/tlswg/draft-ietf-tls-ecdhe-psk-aead
* https://github.com/tlswg/draft-ietf-tls-ech-keylogfile
* https://github.com/tlswg/draft-ietf-tls-esni
* https://github.com/tlswg/draft-ietf-tls-external-psk-importer
* https://github.com/tlswg/draft-ietf-tls-grease
* https://github.com/tlswg/draft-ietf-tls-iana-registry-updates
* https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate
* https://github.com/tlswg/draft-ietf-tls-semistatic-dh
* https://github.com/tlswg/draft-ietf-tls-svcb-ech
* https://github.com/tlswg/draft-ietf-tls-ticketrequest
* https://github.com/tlswg/draft-ietf-tls-tls13-vectors
* https://github.com/tlswg/dtls-conn-id
* https://github.com/tlswg/dtls-rrc
* https://github.com/tlswg/dtls13-spec
* https://github.com/tlswg/oldversions-deprecate
* https://github.com/tlswg/rfc4492bis
* https://github.com/tlswg/rfc8447bis
* https://github.com/tlswg/sniencryption
* https://github.com/tlswg/sslkeylogfile
* https://github.com/tlswg/sslv3-diediedie
* https://github.com/tlswg/super-jumbo-record-limit
* https://github.com/tlswg/tls13-spec
* https://github.com/tlswg/tls-exported-authenticator
* https://github.com/tlswg/tls-flags
* https://github.com/tlswg/tls-key-share-prediction
* https://github.com/tlswg/tls-key-update
* https://github.com/tlswg/tls-record-limit
* https://github.com/tlswg/tls-subcerts
* https://github.com/tlswg/tls12-frozen
* https://github.com/tlswg/tls13-pkcs1
* https://github.com/tlswg/tls13-rfc
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: ML-DSA in TLS

2024-11-23 Thread D. J. Bernstein 
Tim Hollebeek writes:
  [ regarding "composite and hybrid" ]
> To be clear, the draft says absolutely nothing about either of those
> two topics

To be clear, that's not a good thing. The draft is deviating from the
normal, amply justified security practices regarding PQ deployment. The
resulting security risks are on topic.

> ML-DSA support for TLS is obvious and straightforward.

Concatenated ECC+Dilithium support for TLS is obvious, straightforward,
and less risky than the draft at hand. The counterarguments don't hold
up to examination; see https://blog.cr.yp.to/20240102-hybrid.html.

For dilithium2, keys are 1312 bytes and signatures are 2420 bytes. A
typical ECC signature system adds 32 bytes and 64 bytes respectively.

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXT] Re: ML-DSA in TLS

2024-11-23 Thread D. J. Bernstein 
Ilari Liusvaara writes:
> The argument forgets that to break ECC+PQ, the attacker has to break
> _either_:
> a) ECC and PQ.
> b) The hybrid construction.

The combiner is much simpler than the PQ system. Furthermore, the main
way that academics manufacture literature on combiner attacks is by
hyping obscure security properties---whereas there are many more PQ
attack papers aiming for, and often achieving, devastating breaks.

https://blog.cr.yp.to/20240102-hybrid.html includes examples of how
things could go wrong with hybrids, and compares those risks to the
risks of PQ breaks.

> The risk from b) is very different for encryption and signatures.

I agree that encryption differs from signatures in the combiner details
and in the combiner security analyses. However, in both cases we're
talking about a much smaller attack surface than the PQ system. The
possibility of combiner attacks doesn't justify exposing users to the
much bigger risk of PQ breaks.

Here's a concrete example of how arguments about combiner details are
regarding much smaller security risks than PQ breaks.

One of my objections to X-Wing is that---even if we assume that the
application specifically wants to use Kyber---reviewing the security
claims for the X-Wing construction requires checking a claimed proof of
some properties of Kyber. It's not even clear what security level is
being claimed for those specific properties, and in any case I don't
like the fact that overloaded security reviewers are being asked to do
extra work so that X-Wing can skip a trivially affordable hash call.

But it's much more challenging to review the analyses of lattice
attacks, a complicated topic where the state of the art keeps changing,
with mistakes found all the time---often mistakes that had lasted for
years. Gentry's original ideal-lattice-based STOC 2009 FHE system wasn't
broken until 2014. The "Round2" lattice-based submission to NIST wasn't
broken until 2020. The 2010 paper introducing what's now called
"FrodoKEM" estimated security 2^150 for lattice dimension 256, which
today sounds absurd. https://eprint.iacr.org/2024/739 exploits a 40-bit
error in NIST's evaluation of the impact of memory-access costs upon
Kyber-512 security. Et cetera. Using the cost of security review as a
predictor of failure probability says that, whatever chance there is of
the combiner failing, we have to be much more worried about Kyber.

As for impact, Shoup pointed out in https://eprint.iacr.org/2001/112
that most protocols are fine with "benign malleability". In that
context, a combiner that simply hashes together two session keys is just
fine, and the extra goals of X-Wing don't matter. Similarly, a signature
combiner that simply concatenates two signatures is just fine for most
applications. Meanwhile a typical PQ break recovering keys is a disaster
for all of these applications.

I'm in favor of slightly more complicated combiners (Chempat for KEMs,
https://mailarchive.ietf.org/arch/msg/cfrg/LdvasJBpseekZtQkQF1nuPPDH_s/
for signatures), in part because some cheap extra hashing occasionally
compensates for carelessness in protocol designs, and in part to fix the
verification disconnect between

   * protocol analyses assuming IND-CCA2 (and SUF-CMA and so on) and
   * simple concatenation not generically guaranteeing IND-CCA2 against
 breaks of one component.

But the impact of attacks here is not on the same scale as a PQ break
recovering keys.

> With encryption, it is small risk because the constructions are simple
> and quite resilient to flaws (outside memory safety) in real world.

Again, having a signature that internally concatenates two signatures is
simple and works fine for most applications (e.g., TLS), the same way
that having a KEM session key that internally hashes together two KEM
session keys is simple and works fine for most applications (e.g., TLS).

The more complicated combiners mentioned above are still just a few
lines of code, with much smaller attack surfaces than PQ systems, in
both the encryption case and the signature case. I don't see why one
would assign higher risks to signature combiners than to encryption
combiners. More to the point, the PQ code is much more complicated than
the combiner code, with a vastly more complicated attack story; one has
to worry correspondingly more about PQ breaks.

> But with signatures, the risks become substantial because:
> - Complexity. Some of it to deal with known non-obvious attacks.
> - Known unknown attacks.

One could use exactly the same words to claim that encryption combiners
have "substantial" risks. Arguing about "small" vs. "substantial" risks
is pointless without quantification.

> Even just the LAMPS composite signature combiner is known to be
> cryptographically unsound. Sound signature combiners are in theory
> impossible

Again, it's easy to manufacture papers hyping minor security properties.
This is not how the TLS WG should be making security decisions.

As an analogy, imagine som

[TLS] Re: [EXT] Re: ML-DSA in TLS

2024-11-23 Thread John Mattsson 
+1 to what Dan says below.

From: D. J. Bernstein 
Date: Saturday, 23 November 2024 at 16:04
To: tls@ietf.org 
Subject: [TLS] Re: [EXT] Re: ML-DSA in TLS
Ilari Liusvaara writes:
> The argument forgets that to break ECC+PQ, the attacker has to break
> _either_:
> a) ECC and PQ.
> b) The hybrid construction.

The combiner is much simpler than the PQ system. Furthermore, the main
way that academics manufacture literature on combiner attacks is by
hyping obscure security properties---whereas there are many more PQ
attack papers aiming for, and often achieving, devastating breaks.

https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.cr.yp.to%2F20240102-hybrid.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C54e98d06552f4a0d47dd08dd0bd0120f%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638679710470218933%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6LgFCaILSoB5xu9f3NekoIcwMQQ3QpiVzGv2PvzRfxU%3D&reserved=0
 includes examples of how
things could go wrong with hybrids, and compares those risks to the
risks of PQ breaks.

> The risk from b) is very different for encryption and signatures.

I agree that encryption differs from signatures in the combiner details
and in the combiner security analyses. However, in both cases we're
talking about a much smaller attack surface than the PQ system. The
possibility of combiner attacks doesn't justify exposing users to the
much bigger risk of PQ breaks.

Here's a concrete example of how arguments about combiner details are
regarding much smaller security risks than PQ breaks.

One of my objections to X-Wing is that---even if we assume that the
application specifically wants to use Kyber---reviewing the security
claims for the X-Wing construction requires checking a claimed proof of
some properties of Kyber. It's not even clear what security level is
being claimed for those specific properties, and in any case I don't
like the fact that overloaded security reviewers are being asked to do
extra work so that X-Wing can skip a trivially affordable hash call.

But it's much more challenging to review the analyses of lattice
attacks, a complicated topic where the state of the art keeps changing,
with mistakes found all the time---often mistakes that had lasted for
years. Gentry's original ideal-lattice-based STOC 2009 FHE system wasn't
broken until 2014. The "Round2" lattice-based submission to NIST wasn't
broken until 2020. The 2010 paper introducing what's now called
"FrodoKEM" estimated security 2^150 for lattice dimension 256, which
today sounds absurd. 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2024%2F739&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C54e98d06552f4a0d47dd08dd0bd0120f%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638679710470238302%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=tSiqGijBbvndrxaTOdCXMoc70ND2aqb9socrn9jeRKA%3D&reserved=0
 exploits a 40-bit
error in NIST's evaluation of the impact of memory-access costs upon
Kyber-512 security. Et cetera. Using the cost of security review as a
predictor of failure probability says that, whatever chance there is of
the combiner failing, we have to be much more worried about Kyber.

As for impact, Shoup pointed out in 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2001%2F112&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C54e98d06552f4a0d47dd08dd0bd0120f%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638679710470249773%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=aPfzudcjGlyO1wH9BrOyzLXHjUcjJi7%2F4rNAQ7ARpSQ%3D&reserved=0
that most protocols are fine with "benign malleability". In that
context, a combiner that simply hashes together two session keys is just
fine, and the extra goals of X-Wing don't matter. Similarly, a signature
combiner that simply concatenates two signatures is just fine for most
applications. Meanwhile a typical PQ break recovering keys is a disaster
for all of these applications.

I'm in favor of slightly more complicated combiners (Chempat for KEMs,
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fcfrg%2FLdvasJBpseekZtQkQF1nuPPDH_s%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C54e98d06552f4a0d47dd08dd0bd0120f%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638679710470260551%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZXDxn5Tjacf6ezpFqtlA87qsB%2Bk%2F6zazeRRxU3cmJg8%3D&reserved=0
for signatures), in part because som

[TLS] Re: [EXT] Re: ML-DSA in TLS

2024-11-23 Thread Ilari Liusvaara 
On Thu, Nov 21, 2024 at 08:45:14PM -, D. J. Bernstein wrote:
> Blumenthal, Uri - 0553 - MITLL writes:
> > Given how the two (KEM and DSA) are used, and what threats may exist
> > against each of them, I think it’s perfectly fine to use PQ instead of
> > ECC+PQ here.
> 
> Hmmm. I don't see where your previous anti-hybrid argument
> (https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/rL9T8mpAkMs/m/i3QKJYZbEAAJ)
> distinguishes encryption from signatures.
> 
> Are you saying that you're now in favor of hybrids for encryption but
> not for signatures? What's the relevant difference?

The risks posed by the hybrid construction itself.


> On the pro-hybrid side, here's the common-sense argument again, where I
> again don't see a difference between signatures and encryption:
> 
>* With ECC+PQ encryption, an attacker with a PQ break still has to
>  break the ECC encryption. This makes ECC+PQ less risky than PQ for
>  encryption.
> 
>* With ECC+PQ signatures, an attacker with a PQ break still has to
>  break the ECC signatures. This makes ECC+PQ less risky than PQ for
>  signatures.

The argument forgets that to break ECC+PQ, the attacker has to break
_either_:

a) ECC and PQ.
b) The hybrid construction.

The risk from b) is very different for encryption and signatures.

With encryption, it is small risk because the constructions are simple
and quite resilient to flaws (outside memory safety) in real world.

But with signatures, the risks become substantial because:

- Complexity. Some of it to deal with known non-obvious attacks.
- Known unknown attacks.

Even just the LAMPS composite signature combiner is known to be
cryptographically unsound. Sound signature combiners are in theory
impossible (practical sound signature combiners might exist).




-Ilari

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Dnsdir last call review of draft-ietf-tls-svcb-ech-06

2024-11-23 Thread James Gannon via Datatracker 
Reviewer: James Gannon
Review result: Ready

Hi Folks,
I am the assigned DNS Directorate reviewer for this. Apologies for the late
review; we had a reviewer switch during the cycle. I have read the document,
and while I am not a TLS guy who can wrap my head around it well enough, I see
that Ted's comments from the -01 have been incorporated after discussion on the
list back in March so from that perspective green light from me.

I see no other major issues with my own review of the document. I will echo
Barry's two nits on the ART review. They would be good to tidy up, but from the
DNSDIR perspective, we are good.

Thank you and apologies again for the late review.


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXT] Re: ML-DSA in TLS

2024-11-23 Thread Scott Fluhrer (sfluhrer) 


> -Original Message-
> From: ilariliusva...@welho.com 
> Sent: Saturday, November 23, 2024 3:44 AM
> To: tls@ietf.org
> Subject: [TLS] Re: [EXT] Re: ML-DSA in TLS
> 
> 
> But with signatures, the risks become substantial because:
> 
> - Complexity. Some of it to deal with known non-obvious attacks.
> - Known unknown attacks.
> 
> Even just the LAMPS composite signature combiner is known to be
> cryptographically unsound. Sound signature combiners are in theory
> impossible (practical sound signature combiners might exist).
> 

Can you expound on that?  The composite signature combiner is "place the RSA 
signature here, place the ML-DSA signature there, we're done".

Given that the verifier checks both the RSA signature and the ML-DSA signature, 
I would naively expect that any successful forgery would need to break both.

Could you explain what I'm missing?


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org