[TLS] Re: Secdir last call review of draft-ietf-tls-svcb-ech

[Ben Schwartz]

Hi Tiru,

Thanks for the review.  I've filed it as 
https://github.com/tlswg/draft-ietf-tls-svcb-ech/issues/21.

1. I've opened a PR to add examples: 
https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/22
2. This text was heavily debated in DNSOP: 
https://mailarchive.ietf.org/arch/msg/dnsop/zOx_7v4GShtMX0MMj5djSCxs7hk/.  
While I would love to have a stronger recommendation here, I would prefer not 
to reopen this issue.
3. The text makes the privacy properties clear.  I don't think it is 
appropriate or useful for us to instruct implementors about how to describe 
these properties to their users.
4. I've opened a PR to add a reference: 
https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/23
5. This seems like a topic that is related to ECH generally, not specific to 
the "ech" SVCB parameter, so I don't think it should be covered in this 
document.

--Ben Schwartz


From: tirumal reddy 
Sent: Tuesday, December 10, 2024 1:39 AM
To: draft-ietf-tls-svcb-ech@ietf.org 
;  ; Last 
Call 
Subject: Secdir last call review of draft-ietf-tls-svcb-ech

This Message Is From an External Sender

Reviewer: Tirumaleswar Reddy K
Review result: Ready with issues

I have reviewed this document as part of the SEC area directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Security area directors.
Document editors and WG chairs should treat these comments just like any other
last-call comments.

1. A SVCB RRSet containing some RRs with "ech" and some without is
   vulnerable to a downgrade attack: a network intermediary can block
   connections to the endpoints that support ECH, causing the client to
   fall back to a non-ECH endpoint.  This configuration is NOT
   RECOMMENDED.

Comment> Please mention scenarios where such mixed behavior may be acceptable. 
Highlighting the exceptions would be helpful.

2. ECH ensures that TLS does not disclose the SNI, but the same
   information is also present in the DNS queries used to resolve the
   server's hostname.  This specification does not conceal the server
   name from the DNS resolver.  If DNS messages are sent between the
   client and resolver without authenticated encryption, an attacker on
   this path can also learn the destination server name.  A similar
   attack applies if the client can be linked to a request from the
   resolver to a DNS authority.

Comment> While authenticated encryption provides protection against active 
attackers, the privacy benefits are negated if the DNS resolver itself is 
malicious. It may be useful to recommend using trusted DNS resolvers.

3. It will be helpful to provide recommendations to endpoint implementations 
not to mislead end-users that "ECH" would provide the same level of security 
fully anonymizing solutions like Tor,  "ECH" may not provide any privacy 
because of the reasons discussed in 2nd paragraph of Security Considerations 
Section.

4. The discussion on the anonymity set could benefit from examples or 
references that illustrate how traffic analysis might narrow it.

5. The behaviour recommendation for middleboxes acting as a TLS proxy should be 
discussed.

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

[TLS] Fwd: [pqc-forum] Recommendations for Key-Encapsulation Mechanisms | Draft SP 800-227 is Available for Comment

[Bas Westerbaan]

This might be of interest to some.

-- Forwarded message -
From: 'Moody, Dustin (Fed)' via pqc-forum 
Date: Tue, Jan 7, 2025 at 4:15 PM
Subject: [pqc-forum] Recommendations for Key-Encapsulation Mechanisms |
Draft SP 800-227 is Available for Comment
To: pqc-forum 


The initial public draft of NIST Special Publication (SP) 800-227,
*Recommendations
for Key-Encapsulation Mechanisms
*,
is now available for public comment.

NIST recently published Federal Information Process Standard (FIPS)
203, *Module-Lattice-Based
Key-Encapsulation Mechanism Standard
*,
to update its cryptographic standards with an algorithm designed to provide
protection from quantum attacks. In addition, NIST will select one or two
additional quantum-resistant key-encapsulation mechanisms (KEMs) for
standardization. To provide guidance on using KEMs, NIST is introducing SP
800-227, *Recommendations for Key-Encapsulation Mechanisms*. This draft
document describes the basic definitions, properties, and applications of
KEMs. It also provides recommendations for implementing and using KEMs in a
secure manner.

The public comment period is open through *March 7, 2025*. See the *publication
details
*
for
a copy of the draft and instructions for submitting comments.

NIST will also hold a *virtual Workshop on Guidance for KEMs
*
on
February 25-26, 2025, to gather additional feedback on SP 800-227.


Dustin Moody
NIST PQC

-- 
You received this message because you are subscribed to the Google Groups
"pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to pqc-forum+unsubscr...@list.nist.gov.
To view this discussion visit
https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/PH0PR09MB8667B8EBCD77C12889F5CA65E5112%40PH0PR09MB8667.namprd09.prod.outlook.com

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

[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448

[Filippo Valsorda]

2025-01-07 14:16 GMT+01:00 John Mattsson 
:
> Alicja Kario wrote:
> >Can you point to examples of people actually using x448 (TLS group ID 30) in 
> >practice?
>  
> I think that is the wrong question.

If no one deployed X448 I don't see why they would deploy X448MLKEM1024, so I 
see no reason to standardize it.

The reason to deploy SecP384r1MLKEM1024 is compliance. Like it or hate it.

The obvious set of hybrids to standardize and implement is:
 1. the one everyone should use;
 2. one that everyone who can't use (1) can use.
I personally liked SecP256r1MLKEM768 for (1) because I need to carry an 
optimized P-256 implementation for WebPKI certificates anyway, but 
X25519MLKEM768 is fine, too.

SecP384r1MLKEM1024 fits the bill for (2) while X448MLKEM1024 does not, both for 
compliance transition reasons, and for "many libraries don't offer a X448 
implementation" reasons.

(I *also* generally disagree with ephemeral ECDH over NIST P curves being "far 
from the state of the art," I actually think it's perfectly fine, but we don't 
have to resolve that disagreement: it's not an input to the argument above.)

> I think the right question is which hybrids do IETF recommend people to use 
> in the future. I think the answer is hybrids with X25519, X448, Ed25519, and 
> Ed448.
>  
> I don't think IETF should standardize much more P-256, P-384, P-521, ECDSA, 
> RSA, and SHA-2. For new products, Ericsson is currently asking all our 
> suppliers for X25519, X448, Ed25519, Ed448, and SHA-3 and we are willing to 
> pay for that. P-256, P-384, P-521, ECDSA, RSA, and SHA-2 were all quite good 
> algorithms when they were standardized decades ago, but today they are far 
> from state-of-the art.
>  
> Cheers,
> John
>  
> *From: *Alicja Kario 
> *Date: *Tuesday, 7 January 2025 at 13:52
> *To: *Loganaden Velvindron 
> *Cc: *tls@ietf.org 
> *Subject: *[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448
> (I originally proposed PR that added that codepoint, together with the
> secp384r1mlkem1024, so I'm really not against it, but...)
> 
> Can you point to examples of people actually using x448 (TLS group ID 30) 
> in
> practice?
> 
> If you want to experiment, then there's the whole private range, what would
> making a public ID add to that experiment?
> 
> On Tuesday, 7 January 2025 10:01:20 CET, Loganaden Velvindron wrote:
> > How about having x448mlkem1024 allocated as an experimental codepoint
> > for those who
> > wish to use it ?
> >
> >
> > On Mon, 6 Jan 2025 at 12:52, Viktor Dukhovni  wrote:
> >> On Mon, Jan 06, 2025 at 08:00:04AM +, Kris Kwiatkowski wrote: ...
> >
> 
> -- 
> Regards,
> Alicja (nee Hubert) Kario
> Principal Quality Engineer, RHEL Crypto team
> Web: 
> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cz.redhat.com%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cbbc800fcb3474cec48ed08dd2f1a1b11%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638718511346705932%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Dig7Bh9QRBv523MgDQnegB48hAQdcMpomAo64uZB5b0%3D&reserved=0
> Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
> 
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
> 
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448

[Loganaden Velvindron]

On Tue, 7 Jan 2025 at 17:16, John Mattsson  wrote:
>
> Alicja Kario wrote:
> >Can you point to examples of people actually using x448 (TLS group ID 30) in 
> >practice?
>
>
>
> I think that is the wrong question. I think the right question is which 
> hybrids do IETF recommend people to use in the future. I think the answer is 
> hybrids with X25519, X448, Ed25519, and Ed448.
>
What kind of hybrids of X448 are you working on ?

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

[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448

[John Mattsson]

Alicja Kario wrote:
>Can you point to examples of people actually using x448 (TLS group ID 30) in 
>practice?

I think that is the wrong question. I think the right question is which hybrids 
do IETF recommend people to use in the future. I think the answer is hybrids 
with X25519, X448, Ed25519, and Ed448.

I don't think IETF should standardize much more P-256, P-384, P-521, ECDSA, 
RSA, and SHA-2. For new products, Ericsson is currently asking all our 
suppliers for X25519, X448, Ed25519, Ed448, and SHA-3 and we are willing to pay 
for that. P-256, P-384, P-521, ECDSA, RSA, and SHA-2 were all quite good 
algorithms when they were standardized decades ago, but today they are far from 
state-of-the art.

Cheers,
John

From: Alicja Kario 
Date: Tuesday, 7 January 2025 at 13:52
To: Loganaden Velvindron 
Cc: tls@ietf.org 
Subject: [TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448
(I originally proposed PR that added that codepoint, together with the
secp384r1mlkem1024, so I'm really not against it, but...)

Can you point to examples of people actually using x448 (TLS group ID 30)
in
practice?

If you want to experiment, then there's the whole private range, what would
making a public ID add to that experiment?

On Tuesday, 7 January 2025 10:01:20 CET, Loganaden Velvindron wrote:
> How about having x448mlkem1024 allocated as an experimental codepoint
> for those who
> wish to use it ?
>
>
> On Mon, 6 Jan 2025 at 12:52, Viktor Dukhovni  wrote:
>> On Mon, Jan 06, 2025 at 08:00:04AM +, Kris Kwiatkowski wrote: ...
>

--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: 
https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cz.redhat.com%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cbbc800fcb3474cec48ed08dd2f1a1b11%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638718511346705932%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Dig7Bh9QRBv523MgDQnegB48hAQdcMpomAo64uZB5b0%3D&reserved=0
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

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

[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448

[Loganaden Velvindron]

On Tue, 7 Jan 2025 at 17:35, Filippo Valsorda  wrote:
>
> 2025-01-07 14:16 GMT+01:00 John Mattsson 
> :
>
> Alicja Kario wrote:
> >Can you point to examples of people actually using x448 (TLS group ID 30) in 
> >practice?
>
>
>
> I think that is the wrong question.
>
>
> If no one deployed X448 I don't see why they would deploy X448MLKEM1024, so I 
> see no reason to standardize it.
>
> The reason to deploy SecP384r1MLKEM1024 is compliance. Like it or hate it.
>
> The obvious set of hybrids to standardize and implement is:
>
> the one everyone should use;
> one that everyone who can't use (1) can use.
>
> I personally liked SecP256r1MLKEM768 for (1) because I need to carry an 
> optimized P-256 implementation for WebPKI certificates anyway, but 
> X25519MLKEM768 is fine, too.
>
> SecP384r1MLKEM1024 fits the bill for (2) while X448MLKEM1024 does not, both 
> for compliance transition reasons, and for "many libraries don't offer a X448 
> implementation" reasons.

There are a list of hybrids here:
https://www.ibm.com/docs/en/datapower-gateway/10.6.x?topic=commands-kem-alg-technology-preview

One of them is X448mlkem768.
Anybody from IBM can comment ?

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

[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448

[Loganaden Velvindron]

How about having x448mlkem1024 allocated as an experimental codepoint
for those who
wish to use it ?


On Mon, 6 Jan 2025 at 12:52, Viktor Dukhovni  wrote:
>
> On Mon, Jan 06, 2025 at 08:00:04AM +, Kris Kwiatkowski wrote:
> > On 06/01/2025 06:18, Viktor Dukhovni wrote:
> > > it would be very unlikey to get
> > > used.
> > The addition of that codepoint was previously discussed on this mailing
> > list, and as Victor says,
> > it is unlikely to be used.
>
> Sure, but for the record the same applies to SecP3841MLKEM1024, which is
> slower still and also not especially compelling.  A more complete table:
>
>keygenencapsdecaps keygens/s  encaps/s 
>  decaps/s
>  ML-KEM-768 0.27s 0.17s 0.27s   36852.5   57951.3 
>   36580.9
> ML-KEM-1024 0.42s 0.23s 0.36s   23865.3   43257.8 
>   27478.9
>  X25519MLKEM768 0.54s 0.71s 0.56s   18638.2   14051.3 
>   17725.6
>   SecP256r1MLKEM768 0.42s 0.76s 0.75s   23747.7   13224.7 
>   13406.0
>   X448MLKEM1024 0.000226s 0.000337s 0.000172s4427.62967.8 
>5807.0
>  SecP384r1MLKEM1024 0.000690s 0.001292s 0.000674s1449.2 773.9 
>1483.9
>
> Though it looks a bit  better with the GCC 128-bit arithmetic
> optimisations (OpenSSL's "enable-ec_nistp_64_gcc_128") enabled:
>
>  SecP384r1MLKEM1024 0.000176s 0.000495s 0.000362s5673.42022.1 
>2763.8
>
> --
> Viktor.
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org

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

[TLS] Re: [Uta] IoT certificate profile vs TLS SNI and subjectAltName

[Achim Kraus]

Hi Michael,

> TL;DR> Help us avoid stuffing non-DNS strings into
>SubjectAltName dNSName when doing device to device (D)TLS.

I may fail to understandiung your question or intention.
Maybe you clarify it.

Your initial question in "draft-tls13-iot" was:

"I was looking for a SN, or SAN that would encode EUI64, and I feel
surprised not to find one."

But, if you like to encode a EUI64 direct in x509 SN or SAN without
"translation", then I would guess, this is a question for
RFC 5280 [1] (and updates) and not for "draft-tls13-iot".

Or do you want to use NOT the EUI64 in device certificates?

Then in

"If the EUI-64 format is used to identify the subject of an end entity
certificate, it MUST be encoded in a subjectAltName of type DNS-ID as a
string of the form HH-HH-HH-HH-HH-HH-HH-HH where 'H' is one of the
symbols '0'-'9' or 'A'-'F'."

the leading "if" will help you to escape it.

So, please:
Is it about direct EUI64 support in x509?
Or about omit EUI64 in device certificates?

br
Achim

[1] https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.6



Am 06.01.25 um 20:29 schrieb Michael Richardson:


Please note and respect the Reply-To: u...@ietf.org.

TL;DR> Help us avoid stuffing non-DNS strings into SubjectAltName dNSName
when doing device to device (D)TLS.

In https://github.com/thomas-fossati/draft-tls13-iot/issues/65 I ask why
draft-ietf-uta-tls13-iot-profile suggests that IoT devices that have
certificates (probably IDevID) whose primary identity is an EUI64 are using
dNSName with a fabricated ascii representation of hex EUI64. (An EUI64 identity 
is
often common on 802.15.4 networks, which use 8-byte EUIs)

now at:
https://www.ietf.org/archive/id/draft-ietf-uta-tls13-iot-profile-11.html#name-subject-3

we say:

When the server identity is given by an EUI-64 format, then it MUST be
encoded in a subjectAltName of type DNS-ID {{RFC9525, Section 1.5}}, as a
string of the form `HH-HH-HH-HH-HH-HH-HH-HH` where 'H' is one of the
symbols '0'-'9' or 'A'-'F'.


and some of this goes back to RFC7925.  Section 4.4.1 says:
Note that there will be servers that are not provisioned for use with
DNS domain names, for example, IoT devices that offer resources to
nearby devices in a local area network, as shown in Figure 7.  When
such constrained servers are used, then the use of certificates as
described in Section 4.4.2 is applicable.  Note that the SNI
extension cannot be used in this case since SNI does not offer the
ability to convey a 64-bit Extended Unique Identifier (EUI-64)
[EUI64].  Note that this document does not recommend use of IP
addresses in certificates nor does it discuss the implications of
placing IP addresses in certificates.

and also:

4.4.2.  Certificates Used by Clients

For **client certificates**, the identifier used in the SubjectAltName or
in the leftmost CN component of subject name MUST be an EUI-64.

(I find the above very unclear btw.  So at least the text from the update is 
better)

 Note:

DNS-ID is not a SAN, but rather through indirection through RFC9525 section 1.5:
   DNS-ID:  A subjectAltName entry of type dNSName as defined in
  [PKIX].

I really don't want to encode new sillyness into dNSName!!!

We really *ought* to be using otherName.  Some years ago I wrote code that
did that, using a PEN OID in otherName with mbedtls.{I suspect that any 
savings from
encoding the 8-byte EUI64 in binary (vs 16+7 ascii bytes) is probably lost
due to the OID needed in the otherName. But I didn't count yet}

I think that otherName: ought to be fine for all uses
where a certificate is used for client-side TLS authentication to a "cloud"
service.  Such a service will be referenced by (DNS) name, and so an SNI
belongs.

Where we get into trouble is when we want to do device to device communication
such as with COAPS (CoAP over DTLS).  If there has not been an onboarding
process that has deployed an LDevID, then we miight wind up using that same
IDevID certificate.

This all assumes:
1) the IoT device is acting as a (D)TLS endpoint. {such as CoAPS!}
2) the IoT device is using EUI-64 as it's identity (vs having an LDevID 
assigned)
3) there are more than one (D)TLS endpoint on the device, making an accurate 
SNI important

while for class 2 or lower devices, the odds of the device having more than
one valid TLS endpoint is low, for class 4,10,15[RPI] devices, it seems
entirely reasonable that there could be multiple end-points distinguished by
SNI.

options that I see are:

1. hold my nose (and yours) and standardize this.

2. declare multiple end-points requiring SNI to be out-of-scope, and so
(D)TLS servers on such devices should ignore SNI, and clients shouldn't
bother putting in anything that isn't a real name.
(It could well be "printer.local"!)

3. declare that multiple end-points would require an onboarding process
(BRSKI, Matter, OPC-UA, EAP-TEAP-BRSKI, ...) to replace any IDevID with
ot

[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448

[Alicja Kario]

(I originally proposed PR that added that codepoint, together with the
secp384r1mlkem1024, so I'm really not against it, but...)

Can you point to examples of people actually using x448 (TLS group ID 30) 
in

practice?

If you want to experiment, then there's the whole private range, what would
making a public ID add to that experiment?

On Tuesday, 7 January 2025 10:01:20 CET, Loganaden Velvindron wrote:

How about having x448mlkem1024 allocated as an experimental codepoint
for those who
wish to use it ?


On Mon, 6 Jan 2025 at 12:52, Viktor Dukhovni  wrote:

On Mon, Jan 06, 2025 at 08:00:04AM +, Kris Kwiatkowski wrote: ...




--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

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

[TLS] Re: [Ace] IoT certificate profile vs TLS SNI and subjectAltName

[Eric Rescorla]

On Mon, Jan 6, 2025 at 9:31 PM Watson Ladd  wrote:

> On Mon, Jan 6, 2025 at 6:14 PM Eric Rescorla  wrote:
> >
> >
> >
> > On Mon, Jan 6, 2025 at 11:31 AM Michael Richardson <
> mcr+i...@sandelman.ca> wrote:
> >>
> >>
> >> Please note and respect the Reply-To: u...@ietf.org.
> >>
> >>
> >>
> >> 4. Find a sensible way to extend RFC6066 to accomodote other forms of
> SNI.
> >> There isn't an IANA registry for this.
> >
> >
> > Just as a technical matter, it's not really possible to extend RFC 6066
> because there
> > is no way to skip past unknown name types. This is a bug, but it's a bug
> we're stuck
> > with.
> >
> >   struct {
> >   NameType name_type;
> >   select (name_type) {
> >   case host_name: HostName;
> >   } name;
> >   } ServerName;
> >
> >   enum {
> >   host_name(0), (255)
> >   } NameType;
> >
> >   opaque HostName<1..2^16-1>;
> >
> >   struct {
> >   ServerName server_name_list<1..2^16-1>
> >   } ServerNameList;
> >
> > Note that the only length field is in HostName, which means that you
> don't know how
> > long the length field is in other NameTypes, so you can't ignore them.
> If this is
> > the general route you want to take, you'll need a new extension.
>
> Implementations might choke on any new name type alas, but there's no
> reason from a wire perspective we couldn't say all names are
> <1..2^16-1>
>

We could have in the past, but we can't really now, because existing
servers don't
know that we've done it, so it will not be safe to send other variants in
SNI. I agree
it's unfortunate, but it's not really expensive to mint a new extension.

-Ekr


> >
> > -Ekr
> >
> > ___
> > TLS mailing list -- tls@ietf.org
> > To unsubscribe send an email to tls-le...@ietf.org
>
>
>
> --
> Astra mortemque praestare gradatim
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org