Re: [TLS] [EXT] Re: WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Blumenthal, Uri - 0553 - MITLL]

AFAIK, they aren’t on TLS 1.3, at least so far. 

Regards,
Uri

> On Jul 14, 2023, at 12:54, Peter Gutmann  wrote:
> 
> !---|
>  This Message Is From an External Sender
>  This message came from outside the Laboratory.
> |---!
> 
> Blumenthal, Uri - 0553 - MITLL  writes:
> 
>> I’m aware of at least one company (using the term loosely) that uses custom
>> group, 
> 
> How does that work with TLS 1.3?
> 
> Peter.
> 


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

Re: [TLS] [EXT] WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Hubert Kario]

I'm not claiming that I know about all users, I can just say that of all 
our

customers that do care about working in FIPS mode (which is not limited to
people that fall under US Federal regulation) none have complained 
intensively

about accepting only well known groups in FIPS mode. SHA-1 deprecation was
more impactful.

And while the company you mention may not want to change to a widely-known
group, they still can choose a group known to then as secure.

I'm not saying that we should mandate use of well known groups for FFDHE,
I'm saying that not allowing use of RSA and allowing use of FFDHE under 
very

specific conditions is workable to a large set of users.

On Friday, 14 July 2023 18:48:27 CEST, Blumenthal, Uri - 0553 - MITLL 
wrote:

Hubert,

I’m aware of at least one company (using the term loosely) that 
uses custom group, and probably understands FFDH(E) better than 
you or me. Since they had their reasons for choosing custom, 
“can change … to use well-known groups” (obviously) does not 
apply. 


Regards,
Uri


On Jul 14, 2023, at 12:33, Hubert Kario  wrote:

!---|
This Message Is From an External Sender
This message came from outside the Laboratory.
|---!


On Friday, 14 July 2023 18:03:25 CEST, Peter Gutmann wrote:
Hubert Kario  writes:
 ...


I wouldn't go as far as "nobody uses them", it's more like 
"people that use

them, either have them configured unknowingly or can change configuration
to use well known groups". So while it may cause interoperability issues,
for people that really do care about interoperability with old systems,
they are fine with tweaking DH configuration to make it happen (or simply
end up using ECDHE and are completely unaware of the whole issue).

One more side note: in FIPS mode we also disable RSA ciphersuites, so the
FFDHE and ECDHE, both with only well known groups, are the only two key
exchanges that do work.

And can something similar be said about SSH implementations?  
There's fixed DH

groups and then the Swiss-army-knife diffie-hellman-group-exchange-*, but
AFAIK the only groups that ever get exchanged there are the RFC 3526/7919
ones.


nope, for OpenSSH those will be the safe-primes from 
/etc/ssh/moduli, though

in FIPS mode we do ignore that file and indeed use RFC 3526 or 7919 groups
of at least 2048 bits (don't remember what we default to, but 
we will accept

either)
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

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





--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

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

Re: [TLS] WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Viktor Dukhovni]

On Fri, Jul 14, 2023 at 04:03:25PM +, Peter Gutmann wrote:

> Interesting, so you're saying that essentially no-one uses custom groups?  My
> code currently fast-tracks the known groups (RFC 3526 and RFC 7919) but also
> allows custom groups (with additional checking) to be on the safe side because
> you never know what weirdness is out there, do you have an idea of what sort
> of magnitude "hardly any" represents?

The "almost no one" is likely technology-sector specific.  Postfix prior
to 3.7 (released Q1 2022) or linked with OpenSSL 1.1.1 (rather than 3.0)
uses a compiled-in 2048-bit safe-prime DH group by default, or a locally
generated group if configured.

With Postfix 3.7 or later linked with OpenSSL 3.0 or later, the group
selection defaults to the the OpenSSL "auto" list, which is based on
the security bits of the server certificate or cipher with anonDH:

if (dh_secbits >= 192)
p = BN_get_rfc3526_prime_8192(NULL);
else if (dh_secbits >= 152)
p = BN_get_rfc3526_prime_4096(NULL);
else if (dh_secbits >= 128)
p = BN_get_rfc3526_prime_3072(NULL);
else if (dh_secbits >= 112)
p = BN_get_rfc3526_prime_2048(NULL);
else
p = BN_get_rfc2409_prime_1024(NULL);

The most common result will be the rfc3526 2048-bit group.  It is not
clear that these are actually better, but they are perhaps more likely
interoperable for being widely-used 'standard' groups.

-- 
Viktor.

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

Re: [TLS] [EXT] Re: WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Peter Gutmann]

Blumenthal, Uri - 0553 - MITLL  writes:

>I’m aware of at least one company (using the term loosely) that uses custom
>group, 

How does that work with TLS 1.3?

Peter.

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

Re: [TLS] [EXT] Re: WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Blumenthal, Uri - 0553 - MITLL]

Hubert,

I’m aware of at least one company (using the term loosely) that uses custom 
group, and probably understands FFDH(E) better than you or me. Since they had 
their reasons for choosing custom, “can change … to use well-known groups” 
(obviously) does not apply. 

Regards,
Uri

> On Jul 14, 2023, at 12:33, Hubert Kario  wrote:
> 
> !---|
> This Message Is From an External Sender
> This message came from outside the Laboratory.
> |---!
> 
>> On Friday, 14 July 2023 18:03:25 CEST, Peter Gutmann wrote:
>> Hubert Kario  writes:
>> 
>>> FIPS requires to support only well known groups (all of them 2048 bit or
>>> larger), and we've received hardly any customer issues after implementing
>>> that as hard check (connection will fail if the key exchange uses custom DH
>>> parameters) good few years ago now.
>> 
>> Interesting, so you're saying that essentially no-one uses custom groups?  My
>> code currently fast-tracks the known groups (RFC 3526 and RFC 7919) but also
>> allows custom groups (with additional checking) to be on the safe side 
>> because
>> you never know what weirdness is out there, do you have an idea of what sort
>> of magnitude "hardly any" represents?
> 
> I wouldn't go as far as "nobody uses them", it's more like "people that use
> them, either have them configured unknowingly or can change configuration
> to use well known groups". So while it may cause interoperability issues,
> for people that really do care about interoperability with old systems,
> they are fine with tweaking DH configuration to make it happen (or simply
> end up using ECDHE and are completely unaware of the whole issue).
> 
> One more side note: in FIPS mode we also disable RSA ciphersuites, so the
> FFDHE and ECDHE, both with only well known groups, are the only two key
> exchanges that do work.
> 
>> And can something similar be said about SSH implementations?  There's fixed 
>> DH
>> groups and then the Swiss-army-knife diffie-hellman-group-exchange-*, but
>> AFAIK the only groups that ever get exchanged there are the RFC 3526/7919
>> ones.
> 
> nope, for OpenSSH those will be the safe-primes from /etc/ssh/moduli, though
> in FIPS mode we do ignore that file and indeed use RFC 3526 or 7919 groups
> of at least 2048 bits (don't remember what we default to, but we will accept
> either)
> -- 
> Regards,
> Hubert Kario
> Principal Quality Engineer, RHEL Crypto team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
> 
> ___
> TLS mailing list
> 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] WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Hubert Kario]

On Friday, 14 July 2023 18:03:25 CEST, Peter Gutmann wrote:

Hubert Kario  writes:


FIPS requires to support only well known groups (all of them 2048 bit or
larger), and we've received hardly any customer issues after implementing
that as hard check (connection will fail if the key exchange 
uses custom DH

parameters) good few years ago now.


Interesting, so you're saying that essentially no-one uses 
custom groups?  My

code currently fast-tracks the known groups (RFC 3526 and RFC 7919) but also
allows custom groups (with additional checking) to be on the 
safe side because

you never know what weirdness is out there, do you have an idea of what sort
of magnitude "hardly any" represents?


I wouldn't go as far as "nobody uses them", it's more like "people that use
them, either have them configured unknowingly or can change configuration
to use well known groups". So while it may cause interoperability issues,
for people that really do care about interoperability with old systems,
they are fine with tweaking DH configuration to make it happen (or simply
end up using ECDHE and are completely unaware of the whole issue).

One more side note: in FIPS mode we also disable RSA ciphersuites, so the
FFDHE and ECDHE, both with only well known groups, are the only two key
exchanges that do work.

And can something similar be said about SSH implementations?  
There's fixed DH

groups and then the Swiss-army-knife diffie-hellman-group-exchange-*, but
AFAIK the only groups that ever get exchanged there are the RFC 3526/7919
ones.


nope, for OpenSSH those will be the safe-primes from /etc/ssh/moduli, 
though

in FIPS mode we do ignore that file and indeed use RFC 3526 or 7919 groups
of at least 2048 bits (don't remember what we default to, but we will 
accept

either)
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

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

Re: [TLS] WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Peter Gutmann]

Hubert Kario  writes:

>FIPS requires to support only well known groups (all of them 2048 bit or
>larger), and we've received hardly any customer issues after implementing
>that as hard check (connection will fail if the key exchange uses custom DH
>parameters) good few years ago now.

Interesting, so you're saying that essentially no-one uses custom groups?  My
code currently fast-tracks the known groups (RFC 3526 and RFC 7919) but also
allows custom groups (with additional checking) to be on the safe side because
you never know what weirdness is out there, do you have an idea of what sort
of magnitude "hardly any" represents?

And can something similar be said about SSH implementations?  There's fixed DH
groups and then the Swiss-army-knife diffie-hellman-group-exchange-*, but
AFAIK the only groups that ever get exchanged there are the RFC 3526/7919
ones.

Peter.

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

Re: [TLS] WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Peter Gutmann]

I wrote:

>Salz, Rich  writes:

Argh, sorry, text-trimming fail, I was quoting Viktor Dukhovni but cut out the 
wrong block of text.

Peter.

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

Re: [TLS] WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Peter Gutmann]

Salz, Rich  writes:

>The formulation I would choose would be:
>
> - MUST prefer ECDHE key exchange, when supported, over FFDHE key exchange.
> - MUST prefer FFDHE key exchange, when supported, over RSA key exchange.

I think there should also be some wording around avoiding falling back to RSA
because of choices made elsewhere.  In the cases I'm aware of the use of RSA
wasn't because anyone chose to use it but because some (I assume) best-
practices document somewhere told admins "herp derp, disable DH" and the
result was use of RSA without them being aware of it (it's led to weird
configs where what might be enabled on one or both sides is a few ECDH suites
at the start followed by a large hole where FFDH is and then finally a bunch
of RSA suites at the other end).  I would hope no-one actually *chooses* to
use RSA, it just ends up as the silent fallback when other things are
unavailable.

So perhaps a note wherever some form of "SHOULD NOT FFDHE" appears along the
lines of:

  Note that disabling FFDHE may cause systems to silently fall back to the far
  less secure RSA instead.  If choosing to disable FFDHE, users should ensure
  that this doesn't result in clients or servers silently falling back to RSA,
  as this is far less secure than FFDHE.

I realise that "MUST prefer FFDHE" says this too, but since users have already
fallen into this trap in the past it'd be worth emphasising how to avoid it.

Peter.

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

Re: [TLS] WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Salz, Rich]

> - MUST prefer ECDHE key exchange, when supported, over FFDHE key exchange.
> - MUST prefer FFDHE key exchange, when supported, over RSA key exchange.

I agree with this.

> That's a reasonable position to take, but at this stage I guess the
> discussion is mostly around the presentation and structure of the document.

Substantive changes can happen at any point in the review process.  The chairs 
need to decide if a renewed consensus call, and/or renewed WGLC needs to happen.


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

Re: [TLS] WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Viktor Dukhovni]

On Fri, Jul 14, 2023 at 04:53:42PM +0300, Nimrod Aviram wrote:

> There are a few valid arguments, from yourself and others here, to soften
> the prescription regarding FFDHE from MUST NOT to SHOULD NOT, or similar.

The formulation I would choose would be:

 - MUST prefer ECDHE key exchange, when supported, over FFDHE key exchange.
 - MUST prefer FFDHE key exchange, when supported, over RSA key exchange.

> That's a reasonable position to take, but at this stage I guess the
> discussion is mostly around the presentation and structure of the document.

That's a shame, because the goal surely isn't to punish the users of
legacy systems, but rather to encourage the use of preferred
alternatives.

A narrow section of the user base may well want to refuse to communicate
with the aid of any of the legacy algorithms, they already have that
option.  For the rest, I think rfc7435's emphasis on raising the ceiling
is better aligned with security goals than efforts to raise the floor.

Yes, I am well aware that sometimes we also need to raise the floor
(e.g. drop support for SSLv2).  I am not convinced this is such a
situation.

-- 
Viktor.

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

Re: [TLS] WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Nimrod Aviram]

> At the moment the blanket "don't do DH" is in effect saying "use RSA
keyex" to a chunk of the market.
Does the document in question say in effect "use RSA keyex"? Or could it be
read that way?
The first sentence is "This document deprecates the use of RSA key exchange
and Diffie Hellman". That seems pretty clear.

There are a few valid arguments, from yourself and others here, to soften
the prescription regarding FFDHE from MUST NOT to SHOULD NOT, or similar.
That's a reasonable position to take, but at this stage I guess the
discussion is mostly around the presentation and structure of the document.

best,
Nimrod


On Fri, 14 Jul 2023 at 10:02, Peter Gutmann 
wrote:

> Viktor Dukhovni  writes:
>
> >What benefit do we expect from forcing weaker security (RSA key exchange
> or
> >cleartext in the case of SMTP) on the residual servers that don't do
> either
> >TLS 1.3 or ECDHE?
>
> This already happens a lot in wholesale banking, the admins have dutifully
> disabled DH because someone said so and so all keyex falls back to RSA
> circa
> 1995, and worst possible situation to be in.
>
> There needs to be clear text in there to say that if you can't do ECC then
> do
> DH but never RSA, or even just "keep using DH because it's still vastly
> better
> than the alternative of RSA".  At the moment the blanket "don't do DH" is
> in
> effect saying "use RSA keyex" to a chunk of the market.
>
> Peter.
>
> ___
> 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] WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Hubert Kario]

On Friday, 14 July 2023 09:01:30 CEST, Peter Gutmann wrote:

Viktor Dukhovni  writes:

What benefit do we expect from forcing weaker security (RSA 
key exchange or
cleartext in the case of SMTP) on the residual servers that 
don't do either

TLS 1.3 or ECDHE?


This already happens a lot in wholesale banking, the admins have dutifully
disabled DH because someone said so and so all keyex falls back to RSA circa
1995, and worst possible situation to be in.

There needs to be clear text in there to say that if you can't 
do ECC then do
DH but never RSA, or even just "keep using DH because it's 
still vastly better

than the alternative of RSA".  At the moment the blanket "don't do DH" is in
effect saying "use RSA keyex" to a chunk of the market.


Yes, what the text should say, is "MUST NOT use RSA key exchange, SHOULD 
NOT
support ephemeral FFDHE, and if it does support FFDHE the key shares MUST 
be

ephemeral and never reused."
There _needs_ to be a clear preference for FFDHE over RSA, as otherwise 
people

will end up using RSA because "it's faster", or "it's more interoperable",
completely missing the part that it's also vastly less secure.

Frankly, I find the interoperability issues of TLS 1.2 FFDHE overblown,
the FIPS requires to support only well known groups (all of them 2048 bit 
or

larger), and we've received hardly any customer issues after
implementing that as hard check (connection will fail if the key exchange 
uses

custom DH parameters) good few years ago now.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

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

Re: [TLS] [EXT] Re: WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Blumenthal, Uri - 0553 - MITLL]

Yes to Viktor's and Peter's comments. 

I can't understand fanaticism expressed in this "deprecate..." attempt. 
Besides, it is simply unwise. 

--
V/R,
Uri
 
There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare
 

On 7/14/23, 03:02, "TLS on behalf of Peter Gutmann"  wrote:
Viktor Dukhovni  writes:

>What benefit do we expect from forcing weaker security (RSA key exchange or
>cleartext in the case of SMTP) on the residual servers that don't do either
>TLS 1.3 or ECDHE?

This already happens a lot in wholesale banking, the admins have dutifully
disabled DH because someone said so and so all keyex falls back to RSA circa
1995, and worst possible situation to be in.

There needs to be clear text in there to say that if you can't do ECC then 
do
DH but never RSA, or even just "keep using DH because it's still vastly 
better
than the alternative of RSA".  At the moment the blanket "don't do DH" is in
effect saying "use RSA keyex" to a chunk of the market.

Peter.



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

Re: [TLS] Abridged Certificate Compression

[Rob Stradling]

Hi Dennis.  I did read section 3.2.1 of the draft before posting, but I got the 
impression that the lexicographically ordered list of log identifiers produced 
in the "Secondly" step was only intended to be used as a reference in the 
"Finally" step, rather than emitted as "output".

I understand that "This dictionary is constructed in three stages, with the 
output of each stage being concatenated with the next", but the only explicit 
language regarding which artifacts should be emitted as "output" is 
"Concatenate the byte representation of each extension (including extension id 
and length) and copy it to the output".  It's not clear to me if that explicit 
language is intended to be part of the "Finally" step only, or if it's intended 
to apply to all of the steps.

My attempt to clarify things: 
https://github.com/dennisjackson/draft-jackson-tls-cert-abridge/pull/9.


From: TLS  on behalf of Dennis Jackson 

Sent: 14 July 2023 11:30
To: TLS List 
Subject: Re: [TLS] Abridged Certificate Compression


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


On 13/07/2023 10:13, Rob Stradling wrote:

How about also including in the shared dictionary the SHA-256 hashes of the 
public keys of all the known CTv1 logs, so that the 32-byte LogID field of each 
SCT will be compressed?

This is already step 2 of the shared dictionary construction :-) 
(link).


Best,
Dennis

FWIW, RFC9162 (CTv2) tackles the same SCT bloat by changing the LogID type from 
a (32-byte) SHA-256 hash of the log's public key to a (minimum 4-byte) 
DER-encoded OID (excluding the tag and length octets).


From: TLS  on behalf of Tim 
Hollebeek 

Sent: 12 July 2023 19:29
To: Kampanakis, Panos 
;
 Dennis Jackson 
;
 TLS List 
Subject: Re: [TLS] Abridged Certificate Compression

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


SCTs have always seemed surprisingly large to me, and it has always seemed
like there should be a more compact representation that has the same security
properties, but I've never found the time to look more closely at it.  If 
someone
does have the time, figuring out how to reduce the size of SCTs would be quite
helpful.

-Tim

> -Original Message-
> From: TLS  On Behalf Of 
> Kampanakis, Panos
> Sent: Wednesday, July 12, 2023 2:23 PM
> To: Dennis Jackson 
> ;
>  TLS List
> 
> Subject: Re: [TLS] Abridged Certificate Compression
>
> > The performance benefit isn't purely in the ~1KB saved, its whether it 
> > brings
> the chain under the QUIC amplification limit or shaves off an additional 
> packet
> and so avoids a loss+retry. There's essentially no difference in 
> implementation
> complexity, literally just a line of code, so the main tradeoff is the 
> required disk
> space on the client & server.
>
> Fair. I would add one more tradeoff which is pulling the end-entity certs in 
> the
> CT window for pass 2. This is an one time cost for each dictionary version, so
> maybe not that bad.
>
> Regardless, would compressing the leaf bring us below the QUIC 3.6KB
> threshold for Dilithium 2 or 3 certs whereas not suppressing would keep us
> above? I think it is not even close if we are talking WebPKI. Without SCTs,
> maybe compressing could keep us below 4KB for Dilithium 2 leaf certs. But
> even then, if we add the CertVerify signature size we will be well over 4KB.
>
> Additionally, would compressing the leaf bring us below the 9-10KB threshold
> that Bas had tested to be an important inflection point? For WebPKI, it may
> the 8-9KB cert below 9KB if we add the CertVerify signature size. Maybe not. 
> It
> would need to tested. For Dilithium 3, maybe compression could render the
> 11-12KB cert below 9KB if we got lucky, maybe not, but if we add the
> CertVerify signature we won’t make it. For non-WebPKI, they will already be
> below 9-10KB.
>
> So, I am arguing that we can't remain below the QUIC threshold by
> compressing the leaf Dilithium cert. And we could remain below the 9-10KB
> only for Dilithium2 leaves.  I could be proven wrong if you have implemented
> it.
>
> One more argument for making pass 2 optional or allowing for just pass 1
> dictionaries is that if we are not talking about WebPKI we don't have the
> luxury of CT logs. But we would still want to option of compressing / omitting
> the ICAs by using CCADB.
>
>
>
>
> 

Re: [TLS] Abridged Certificate Compression (dictionary versioning)

[Dennis Jackson]

On 13/07/2023 02:31, Kampanakis, Panos wrote:


Btw, in 3.1.1 I noticed
- "Remove all intermediate certificates which are not signed by root certificates 
still in the listing."

That could eliminate some 2+ ICA cert chains. Any reason why?
Whoops, that's a good spot. The intent here was just to remove any 
intermediates which no longer chained back to trusted roots, so I'll fix 
the wording.___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

On 13/07/2023 10:13, Rob Stradling wrote:

How about also including in the shared dictionary the SHA-256 hashes 
of the public keys of all the known CTv1 logs, so that the 32-byte 
LogID field of each SCT will be compressed?


This is already step 2 of the shared dictionary construction :-) (link 
). 




Best,
Dennis



FWIW, RFC9162 (CTv2) tackles the same SCT bloat by changing the LogID 
type from a (32-byte) SHA-256 hash of the log's public key to a 
(minimum 4-byte) DER-encoded OID (excluding the tag and length octets).



*From:* TLS  on behalf of Tim Hollebeek 


*Sent:* 12 July 2023 19:29
*To:* Kampanakis, Panos ; Dennis 
Jackson ; TLS List 

*Subject:* Re: [TLS] Abridged Certificate Compression
CAUTION: This email originated from outside of the organization. Do 
not click links or open attachments unless you recognize the sender 
and know the content is safe.



SCTs have always seemed surprisingly large to me, and it has always seemed
like there should be a more compact representation that has the same 
security
properties, but I've never found the time to look more closely at it.  
If someone
does have the time, figuring out how to reduce the size of SCTs would 
be quite

helpful.

-Tim

> -Original Message-
> From: TLS  On Behalf Of Kampanakis, Panos
> Sent: Wednesday, July 12, 2023 2:23 PM
> To: Dennis Jackson ; TLS List
> 
> Subject: Re: [TLS] Abridged Certificate Compression
>
> > The performance benefit isn't purely in the ~1KB saved, its 
whether it brings
> the chain under the QUIC amplification limit or shaves off an 
additional packet
> and so avoids a loss+retry. There's essentially no difference in 
implementation
> complexity, literally just a line of code, so the main tradeoff is 
the required disk

> space on the client & server.
>
> Fair. I would add one more tradeoff which is pulling the end-entity 
certs in the
> CT window for pass 2. This is an one time cost for each dictionary 
version, so

> maybe not that bad.
>
> Regardless, would compressing the leaf bring us below the QUIC 3.6KB
> threshold for Dilithium 2 or 3 certs whereas not suppressing would 
keep us
> above? I think it is not even close if we are talking WebPKI. 
Without SCTs,
> maybe compressing could keep us below 4KB for Dilithium 2 leaf 
certs. But
> even then, if we add the CertVerify signature size we will be well 
over 4KB.

>
> Additionally, would compressing the leaf bring us below the 9-10KB 
threshold
> that Bas had tested to be an important inflection point? For WebPKI, 
it may
> the 8-9KB cert below 9KB if we add the CertVerify signature size. 
Maybe not. It
> would need to tested. For Dilithium 3, maybe compression could 
render the

> 11-12KB cert below 9KB if we got lucky, maybe not, but if we add the
> CertVerify signature we won’t make it. For non-WebPKI, they will 
already be

> below 9-10KB.
>
> So, I am arguing that we can't remain below the QUIC threshold by
> compressing the leaf Dilithium cert. And we could remain below the 
9-10KB
> only for Dilithium2 leaves.  I could be proven wrong if you have 
implemented

> it.
>
> One more argument for making pass 2 optional or allowing for just pass 1
> dictionaries is that if we are not talking about WebPKI we don't 
have the
> luxury of CT logs. But we would still want to option of compressing 
/ omitting

> the ICAs by using CCADB.
>
>
>
>
> -Original Message-
> From: Dennis Jackson 
> Sent: Wednesday, July 12, 2023 12:39 PM
> To: Kampanakis, Panos ; TLS List 
> Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression
>
> CAUTION: This email originated from outside of the organization. Do 
not click

> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> On 12/07/2023 04:34, Kampanakis, Panos wrote:
>
> > Thanks Dennis. Your answers make sense.
> >
> > Digging a little deeper on the benefit of compressing (a la Abridged
> > Certs draft) the leaf cert or not. Definitely this draft improves vs
> > plain certificate compression, but I am trying to see if it is worth
> > the complexity of pass 2. So, section 4 shows a 2.5KB improvement over
> > plain compression which would be even more significant for Dilithium
> > certs, but I am trying to find if the diff between ICA
> > suppression/Compression vs ICA suppression/Compression+leaf
> > compression is significant. [/n]
> >
> > I am arguing that the table 4 numbers would be much different when
> > talking about Dilithium certs because all of these numbers would be
> > inflated and any compression would have a small impact. Replacing a CA
> > cert (no SCTs) with a dictionary index would save us ~4KB (Dilithium2)
> > or 5.5KB (Dilithium3). That is significant. [/n]
> >
> > Compressing the leaf (of size 8-9KB (Dilithium2) or 11-12 KB 
(Dilithium 3))

> using any mechanism would 

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

On 12/07/2023 19:23, Kampanakis, Panos wrote:


One more argument for making pass 2 optional or allowing for just pass 1 
dictionaries is that if we are not talking about WebPKI we don't have the 
luxury of CT logs. But we would still want to option of compressing / omitting 
the ICAs by using CCADB.


Using the CT logs to extract the end-entity extensions is a bit of a 
stop-gap measure. I think in the long run we'd like to add a field to 
the CCADB where CAs could provide their own compression data (up to some 
budget).


Whilst I think pass 2 has a marked improvement for classical cert chains 
- in some cases fitting the entirety of the server's response in one 
packet - I agree we should measure carefully before deciding whether it 
be mandatory for PQ certs.


Best,
Dennis






-Original Message-
From: Dennis Jackson 
Sent: Wednesday, July 12, 2023 12:39 PM
To: Kampanakis, Panos ; TLS List 
Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.



On 12/07/2023 04:34, Kampanakis, Panos wrote:


Thanks Dennis. Your answers make sense.

Digging a little deeper on the benefit of compressing (a la Abridged
Certs draft) the leaf cert or not. Definitely this draft improves vs
plain certificate compression, but I am trying to see if it is worth
the complexity of pass 2. So, section 4 shows a 2.5KB improvement over
plain compression which would be even more significant for Dilithium
certs, but I am trying to find if the diff between ICA
suppression/Compression vs ICA suppression/Compression+leaf
compression is significant. [/n]

I am arguing that the table 4 numbers would be much different when
talking about Dilithium certs because all of these numbers would be
inflated and any compression would have a small impact. Replacing a CA
cert (no SCTs) with a dictionary index would save us ~4KB (Dilithium2)
or 5.5KB (Dilithium3). That is significant. [/n]

Compressing the leaf (of size 8-9KB (Dilithium2) or 11-12 KB (Dilithium 3)) 
using any mechanism would trim down ~0.5-1KB compared to not compressing. That 
is because the PK and Sig can't be compressed and these account for most of the 
PQ leaf cert size. So, I am trying to see if pass 2 and compression of the leaf 
cert benefit us much.

I think there's a fairly big difference between suppressing CA certs in SCA and 
compressing CA certs with pass 1 of this draft. But I do agree its fair to ask 
if pass 2 is worth the extra effort.

The performance benefit isn't purely in the ~1KB saved, its whether it brings the 
chain under the QUIC amplification limit or shaves off an additional packet and so 
avoids a loss+retry. There's essentially no difference in implementation 
complexity, literally just a line of code, so the main tradeoff is the required 
disk space on the client & server.

Best,
Dennis



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

Re: [TLS] WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Peter Gutmann]

Viktor Dukhovni  writes:

>What benefit do we expect from forcing weaker security (RSA key exchange or
>cleartext in the case of SMTP) on the residual servers that don't do either
>TLS 1.3 or ECDHE?

This already happens a lot in wholesale banking, the admins have dutifully
disabled DH because someone said so and so all keyex falls back to RSA circa
1995, and worst possible situation to be in.

There needs to be clear text in there to say that if you can't do ECC then do
DH but never RSA, or even just "keep using DH because it's still vastly better
than the alternative of RSA".  At the moment the blanket "don't do DH" is in
effect saying "use RSA keyex" to a chunk of the market.

Peter.

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