[TLS] Re: Working Group Last Call for ECH SSLKEYLOG

[Salz, Rich]

I support eventual publication of this (see last paragraph), but the IANA 
considerations (Section 6) does not belong.  First, it is the wrong level of 
review, as Stephen has pointed out; that alone is enough to send the draft back 
to the WG. Even if that is fixed, the instructions to the DE’s are insufficient 
– how are they (we) to decide between two submissions that cover the same item? 
 Really, the proper place for that kind of entry is in the document defining 
them. But I don’t think the WG has the stomach to enforce that kind of thing, 
and that seems to me not an unreasonable view to take.

As a nit “applicability statement” in Sec 5 should also point to the security 
considerations of the draft.

I disagree strongly with Stephen about whether or not this should be published 
at all. Enabling common debug tooling is a good thing to do.

I see that draft-ietf-tls-keylogfile is awaiting references and such.  I 
suggest that draft be pulled back to the WG, the 30 lines from this draft that 
make up Sec 3 and Sec 4 be merged into the basic keylogfile draft, and the 
WGLC, etc., be repeated and this draft be dropped.

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

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

[Repository Activity Summary Bot]

Issues
--
* tlswg/draft-ietf-tls-cert-abridge (+0/-0/💬1)
 1 issues received 1 new comments:
 - #16 Longterm versioning strategy (1 by ilaril)
   https://github.com/tlswg/draft-ietf-tls-cert-abridge/issues/16 





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: TLS against censorship

[evasilen]

Hi all,

 

*   I don't think there is much ECH spec can do about this - versatility of 
public name construction depends on many internal operational details of the 
hosting service.

Don’t agree. It is possible. Just introduce 2 stages for adoption:

1.  Stage 1: TLS extension that makes no any harm for censors. Add nested 
InnerHello header, just populate it with encrypted nonce (computer name + time 
may be enough).
Censors are lazy, they would not block it because it does not produce immediate 
problem for them.
2.  Stage 2: Monitor the InnerHello header adoption. After it would reach 
90+%, activate the real SNI inside InnerHello.
By the way, do not make a mistake to populate original SNI with the special DNS 
(it is assumed by the current spec), put there some random (but real) DNS name.

 

*   The ECH draft specifies a greasing mechanism that achieves exactly 
that. Clients can insert an ECH extension with fake values -- but only the 
client and the front end server know it is fake. The on-path attackers cannot 
tell -- they just see an ECH extension with a bunch of random bytes in it, 
which is not different from an ECH extension with encrypted data in it. If they 
block these packets, they are going to block way more that their desired 
targets.

Maybe I was not careful enough, I have not found it in the draft. Moreover, the 
article from CloudFlare stress that they would reserve a special DNS name (to 
make life of censor easy). Hence, CloudFlare has read the spec not careful too. 
Strange, right?

I need to repeat again: you currently provision 2 mechanisms for censor’s 
filtering:
1) new header in the hello packet.

2) clear DNS name in the original SNI to point that it is “evasion”.

The first one is an objective problem that needs something special (like 
2-stage feature introduction).

The second one is just an IETF/TLSWG mistake.

Please, clearly specify that original SNI should become finally random DNS name 
(it should be real one!).

 

*   You assume that the censorship will be deployed before the next browser 
versions are deployed, and that a browser that systematically grease the ECH 
extension would become immediately unusable. But blocking new versions of 
browsers will be very costly for the censor -- users do want the security, 
features and bug fixes of the new versions. We have no evidence of that 
happening yet.

Censors do not care about security. The only thing they care is the full 
country isolation from the internet. Up to 10% of population temporary 
isolation from the Internet – is an acceptable trade-off for them.

2 stage feature introduction is mandatory to rise harm from X% to 90%.

 

Ed/

From: Yaroslav Rosomakho  
Sent: Saturday, November 16, 2024 5:48 AM
To: Christian Huitema ; evasi...@yandex.ru
Cc: Raghu Saxena ;  
Subject: Re: [TLS] Re: TLS against censorship

 

Christian,

 

I believe the issue that we are currently observing with "blocked ECH" is 
specific to how public SNI is constructed. A given CDN uses a certain 
pre-defined public name for all ECH enabled resources - hence an inline 
filtering party that wants to prevent ECH can match on that specific public 
name and presence of ECH extension in ClientHello.

 

Ed,

 

I don't think there is much ECH spec can do about this - versatility of public 
name construction depends on many internal operational details of the hosting 
service.

 

On top of that, public SNI is used by some intermediaries to perform their own 
DNS lookup and replace destination IP. This is often done to optimise traffic 
routing by cloud security providers as the closest CDN node from cloud security 
provider perspective could be different than the one resulting from client DNS 
lookup. It is also a technique to prevent certain kinds of domain fronting 
attacks without invasive TLS inspection. Hence, replacing public SNI with a 
random string that would not be resolvable to the correct destination is likely 
to create another set of access issues.

 

Best Regards,

Yaroslav

 

On Sat, Nov 16, 2024 at 2:12 AM Christian Huitema mailto:huit...@huitema.net> > wrote:


On 11/15/2024 9:57 AM, Raghu Saxena wrote:
> Hey Ed,
>
> On 11/16/24 1:08 AM, evasi...@yandex.ru   wrote:
>> Actually, it is not a problem for them, not at all.
>> As I stated in the message that you did not copy in the quote: they 
>> would filter out any Hello that has nested InnerHello.
>> It is pretty automatic solution. As soon as implemented on DPI, this 
>> feature would not need any configuration or manual intervention.
>> Only people that upgraded their browser would be punished (not the 
>> whole population) - they would have to look how to downgrade the 
>> browser or disable feature.
>
> Well yes, any new TLS extension can be directly blocked by DPI if they 
> want. I think practically the best way around such stuff would be to 
> use existing TLS stuff which is too mainstream, e.g. an HTTPS proxy.

Ed,

[TLS] Re: ML-DSA in TLS

[D. J. Bernstein]

Watson Ladd writes:
> Authentication is not like encryption.

I presume that you're alluding to the following process: if the PQ
signature system is broken, we revert to ECC signatures, and then the
attacker doesn't benefit from forging the no-longer-accepted signatures
(whereas we can't stop attackers from breaking previous ciphertexts).

This process leaves computers completely exposed until they've reverted
to ECC. Sure, some environments are fast to make changes, but some
aren't. For comparison, using ECC+PQ in the first place avoids this
security failure, and will make many people less hesitant to upgrade.

The revert-in-case-of-disaster process also leaves computers completely
exposed to PQ attacks that haven't come to the public's attention yet.
Out of the 69 round-1 submissions to NIST, 33 have been publicly broken
by now (see https://cr.yp.to/papers.html#pqsrc), with some of the
attacks not published for years; is it so hard to imagine that
large-scale attackers found some attacks before the public did?

More broadly, conflating "no attacks have been published" with "no
attacks are being carried out" is unjustified, an extreme form of
availability bias. Occasionally there are leaks from attackers
illustrating how much damage this mistake has done. Example:

   
https://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html

---D. J. Bernstein

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

[TLS] Re: ML-DSA in TLS

[Santosh Chokhani]

+1

-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] 
Sent: Friday, November 15, 2024 11:41 AM
To: Bas Westerbaan ; tls@ietf.org
Subject: [TLS] Re: ML-DSA in TLS



On 15/11/2024 10:51, Bas Westerbaan wrote:
> We have posted a -00.
> 
> https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-mldsa-00

I'm unenthusiastic but don't strongly oppose adoption of this and similar 
drafts, mostly because I think we should try get some WG consensus on guidance 
for when these things may be needed (if ever) and what the consequences might 
be should people deploy 'em in the meantime. (By 'em I mean anything with any 
kind of PQ sig or non hybrid PQ key exchange.) That guidance might or might not 
be in a separate document, or be copied into each relevant one.

Cheers,
S.


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

[TLS] [Technical Errata Reported] RFC8422 (8179)

[RFC Errata System]

The following errata report has been submitted for RFC8422,
"Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security 
(TLS) Versions 1.2 and Earlier".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid8179

--
Type: Technical
Reported by: warren.wang <648936...@qq.com>

Section: 5.4.  Server Key Exc

Original Text
-
   The ServerKeyExchange message is extended as follows.

   enum {
   ec_diffie_hellman
   } KeyExchangeAlgorithm;

   o  ec_diffie_hellman: Indicates the ServerKeyExchange message
  contains an ECDH public key.

  select (KeyExchangeAlgorithm) {
  case ec_diffie_hellman:
  ServerECDHParamsparams;
  Signature   signed_params;
  } ServerKeyExchange;

.

enum {
ecdsa(3),
ed25519(7)
ed448(8)
} SignatureAlgorithm;
select (SignatureAlgorithm) {
   case ecdsa:
digitally-signed struct {
opaque sha_hash[sha_size];
};
   case ed25519,ed448:
digitally-signed struct {
opaque rawdata[rawdata_size];
};
} Signature;
  ServerKeyExchange.signed_params.sha_hash
  SHA(ClientHello.random + ServerHello.random +
 ServerKeyExchange.params);
  ServerKeyExchange.signed_params.rawdata
  ClientHello.random + ServerHello.random +
 ServerKeyExchange.params;

   NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange
   algorithm and "anonymous" for ECDH_anon.  These cases are defined in
   TLS.  SignatureAlgorithm is "ecdsa" or "eddsa" for ECDHE_ECDSA.

Corrected Text
--
The extended ServerKeyExchange message seems just for tls version 1.0 and 
version 1.1, not for 1.2, because tls version 1.2 ServerKeyExchange message 
format is different from version 1.0 and 1.1. The following is tls version 1.2 
ServerKeyExchange message format:

 struct {
 select (KeyExchangeAlgorithm) {
 case dh_anon:
 ServerDHParams params;
 case dhe_dss:
 case dhe_rsa:
 ServerDHParams params;
 digitally-signed struct {
 opaque client_random[32];
 opaque server_random[32];
 ServerDHParams params;
 } signed_params;
 case rsa:
 case dh_dss:
 case dh_rsa:
 struct {} ;
 /* message is omitted for rsa, dh_dss, and dh_rsa */
 /* may be extended, e.g., for ECDH -- see [TLSECC] */
 };
 } ServerKeyExchange;

it does not specify the message format for ECDH_RSA and ECDH_anon, the "NOTE" 
in original text does not apply to tls version 1.2, because it doesn't have the 
"Signature" field.

Notes
-
the ServerKeyExchange for ECDH_RSA and ECDH_anon should be specified for tls 
version 1.2.

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--
RFC8422 (draft-ietf-tls-rfc4492bis-17)
--
Title   : Elliptic Curve Cryptography (ECC) Cipher Suites for 
Transport Layer Security (TLS) Versions 1.2 and Earlier
Publication Date: August 2018
Author(s)   : Y. Nir, S. Josefsson, M. Pegourie-Gonnard
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

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