Re: [TLS] Working Group Last Call for ECH

[Sean Turner]

Just a reminder that this WGLC ends soon!

spt

> On Mar 11, 2024, at 18:00, Joseph Salowey  wrote:
> 
> This is the working group last call for TLS Encrypted Client Hello [1].  
> Please indicate if you think the draft is ready to progress to the IESG and 
> send any comments to the list by 31 March 2024.  The comments sent by Watson 
> Ladd to the list [2] on 17 February 2024 will be considered last call 
> comments.
> 
> Thanks,
> 
> Joe, Deirdre, and Sean
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
> [2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/
> 
> 
> ___
> 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] Working Group Last Call for SSLKEYLOG File

[Sean Turner]

Just a reminder that this WGLC ends soon!

spt

> On Mar 12, 2024, at 10:57, Sean Turner  wrote:
> 
> This is the working group last call for the SSLKEYLOGFILE Format for TLS 
> Internet-Draft [1]. Please indicate if you think the I-D is ready to progress 
> to the IESG and send any comments to the list by 31 March 2024.
> 
> The GH repo for the I-D can be found at [2].
> 
> Thanks,
> 
> Joe, Deirdre, and Sean
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/
> [2] https://github.com/tlswg/sslkeylogfile

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

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

[Sean Turner]

Minor suggestion to refer to -rfc84446bis:
https://github.com/tlswg/sslkeylogfile/pull/8
aka let’s make a cluster!

spt

> On Mar 12, 2024, at 10:57, Sean Turner  wrote:
> 
> This is the working group last call for the SSLKEYLOGFILE Format for TLS 
> Internet-Draft [1]. Please indicate if you think the I-D is ready to progress 
> to the IESG and send any comments to the list by 31 March 2024.
> 
> The GH repo for the I-D can be found at [2].
> 
> Thanks,
> 
> Joe, Deirdre, and Sean
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/
> [2] https://github.com/tlswg/sslkeylogfile

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

[TLS] -draft8447bis: rename Support Group Elliptic curve groups space

[Sean Turner]

**WARNING: Potential bikeshed**

-connolly-tls-mlkem-key-agreement has suggested that code points for the NIST 
PQ be registered in the TLS Supported Groups IANA registry [1].  Currently [2], 
the registry is carved up into three blocks as follows:

Range: 0-255, 512-65535
Registration Procedures: Specification Required
Note: Elliptic curve groups

Range 256-511
Registration Procedures: Specification Required
Note: Finite Field Diffie-Hellman groups

Assuming that the proposal in -connolly-tls-mlkem-key-agreement is the path for 
PQ KEM algorithms (and maybe regardless of whether this is the path), we should 
really replace the “Elliptic curve groups” note in the 0-255, 512-65535 range 
row with something else.  I am open to suggestions, but would like to propose 
“unallocated”. I have submitted the following issue:
https://github.com/tlswg/rfc8447bis/issues/54
and this PR:
https://github.com/tlswg/rfc8447bis/pull/55
to address this.

spt

[1] 
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8

[2] Originally, RFC 8442 defined the name of the registry as "EC Named Curve 
Registry” and then RFC 7919 re-named it “Supported Groups” and carved out the 
FFDH space.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks

[John Mattsson]

Hi,

I looked into what RFC 8446(bis) says about Raw Public Keys. As correctly 
stated in RFC 8446, TLS 1.3 with signatures and certificates is an 
implementation of SIGMA-I:

SIGMA does however require that the identities of the endpoints (called A and B 
in [SIGMA]) are included in the messages. This is not true for TLS 1.3 with 
RPKs and TLS 1.3 with RPKs is therefore not SIGMA. TLS 1.3 with RPKs is 
vulnerable to what Krawczyk’s SIGMA paper calls misbinding attacks:

“This attack, to which we refer as an “identity misbinding attack”, applies to 
many seemingly natural and intuitive protocols. Avoiding this form of attack 
and guaranteeing a consistent binding between a session key and the peers to 
the session is a central element in the design of SIGMA.”

“Even more significantly we show here that the misbinding attack applies to 
this protocol in any scenario where parties can register public keys without 
proving knowledge of the corresponding signature key.”

As stated in Appendix E.1, at the completion of the handshake, each side 
outputs its view of the identities of the communicating parties. On of the TLS 
1.3 security properties are “Peer Authentication”, which says that the client’s 
and server’s view of the identities match. TLS 1.3 with PRKs does not fulfill 
this unless the out-of-band mechanism to register public keys proved knowledge 
of the private key. RFC 7250 does not say anything about this either.

I think this needs to be clarified in RFC8446bis. The only reason to ever use 
an RPK is in constrained IoT environments. Otherwise a self-signed certificate 
is a much better choice. TLS 1.3 with self-signed certificates is SIGMA-I.

It is worrying to find comments like this:

“I'd like to be able to use wireguard/ssh-style authentication for my app. This 
is possible currently with self-signed certificates, but the proper solution is 
RFC 7250, which is also part of TLS 1.3.”
https://github.com/openssl/openssl/issues/6929

RPKs are not the proper solution.

(Talking about misbinding, does RFC 8446 say anything about how to avoid selfie 
attacks where an entity using PSK authentication ends up talking to itself?)

Cheers,
John Preuß Mattsson

[SIGMA] https://link.springer.com/chapter/10.1007/978-3-540-45146-4_24

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

Re: [TLS] -draft8447bis: rename Support Group Elliptic curve groups space

[John Mattsson]

Hi,

It would actually be good to change the name of the registry from “Supported 
Groups” as the new PQC key exchange algorithms are not groups.

Cheers,
John Preuß Mattsson

From: TLS  on behalf of Sean Turner 
Date: Thursday, 28 March 2024 at 15:53
To: TLS List 
Subject: [TLS] -draft8447bis: rename Support Group Elliptic curve groups space


**WARNING: Potential bikeshed**

-connolly-tls-mlkem-key-agreement has suggested that code points for the NIST 
PQ be registered in the TLS Supported Groups IANA registry [1].  Currently [2], 
the registry is carved up into three blocks as follows:

Range: 0-255, 512-65535
Registration Procedures: Specification Required
Note: Elliptic curve groups

Range 256-511
Registration Procedures: Specification Required
Note: Finite Field Diffie-Hellman groups

Assuming that the proposal in -connolly-tls-mlkem-key-agreement is the path for 
PQ KEM algorithms (and maybe regardless of whether this is the path), we should 
really replace the “Elliptic curve groups” note in the 0-255, 512-65535 range 
row with something else.  I am open to suggestions, but would like to propose 
“unallocated”. I have submitted the following issue:
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftlswg%2Frfc8447bis%2Fissues%2F54&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C0a5a0e0174b640b9535508dc4f36c377%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638472343825594155%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=FKpJyM8%2BPLS7Wd1zNGlZoqhFFEQuLNNRzY8bsUQxegA%3D&reserved=0
and this PR:
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftlswg%2Frfc8447bis%2Fpull%2F55&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C0a5a0e0174b640b9535508dc4f36c377%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638472343825602619%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=nMQWHlYdoSNn9yNstiB2wNLQw5IZl%2BfHtf14UvOInd8%3D&reserved=0
to address this.

spt

[1] 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Ftls-parameters%2Ftls-parameters.xhtml%23tls-parameters-8&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C0a5a0e0174b640b9535508dc4f36c377%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638472343825608404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=f3oRbu1I2ThwoKYyK%2BlyO1SDPOrsc3mXShCT%2BeBM3ls%3D&reserved=0

[2] Originally, RFC 8442 defined the name of the registry as "EC Named Curve 
Registry” and then RFC 7919 re-named it “Supported Groups” and carved out the 
FFDH space.
___
TLS mailing list
TLS@ietf.org
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C0a5a0e0174b640b9535508dc4f36c377%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638472343825613044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=EPub%2F4QhJkK3loRgrjTRvpvJ%2FHD7V2qMujI%2FUQW5HAo%3D&reserved=0
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] -draft8447bis: rename Support Group Elliptic curve groups space

[Salz, Rich]

> we should really replace the “Elliptic curve groups” note in the 0-255, 
> 512-65535 range row with something else. I am open to suggestions, but would 
> like to propose “unallocated”. 

Short and to the point; +1

The only alternative I can see is constantly adding things, and eventually we 
get to "curves and lattices and heffalumps oh me..."


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

Re: [TLS] -draft8447bis: rename Support Group Elliptic curve groups space

[David Benjamin]

+1 to removing the "Elliptic curve groups" note. That partition came out of
RFC 7919's (unfortunate
)
decision to repurpose the existing DHE cipher suites (see RFC 7919, section
4), so we're stuck treating 256-511 as special. But I don't believe we need
to treat the remainder as special.

Regarding renaming, I'm torn. "Group" was a truly horrible rename. The
names we pick make their way into APIs and even sometimes UI surfaces for
developers. Every time I've plumbed TLS named groups into another system,
I've been met with confusion about what in the world a "group" is, and I've
had to embarrassingly explain that yes, it is a term of art, short for
"Diffie-Hellman group", no, it doesn't even make sense with PQC, and I'm
truly very sorry that TLS chose such a needlessly confusing name, but it's
the name we've got. Sometimes I just give up on the TLSWG's naming and just
saying "key exchange" or "key agreement", but that gets a little tricky
because that can also mean the left half of a TLS 1.2 cipher suite
(ECDHE_RSA / ECDHE_ECDSA / RSA). At one point, we tried "key exchange
group" to avoid that, but that's also problematic as one needs to explain
to translators that this does not mean "primary trade collection".

This name is bad enough that I needed to make a pre-written explanation for
this, so I can save time and link to it every time it comes up.

At the same time, we've already renamed this once. These names we pick make
their way everywhere, each rename we do is costly. All the old "curve" APIs
had to be doubled up and deprecated in systems, with the old ones forever
stuck around. And then some systems (probably correctly) decided to stick
with the old "curve" name. Renaming again will add a third, and repeat this
costly cycle.

Had we not renamed, I would say we just keep it at "curves". While "curves"
is also wrong for PQC, it is less generic of a name than "group" and, in my
experience, reads more clearly as a random term of art. It's a pity that we
then changed it to one of the most overloaded words in English imaginable.
:-(

David

On Thu, Mar 28, 2024 at 11:32 AM John Mattsson  wrote:

> Hi,
>
>
>
> It would actually be good to change the name of the registry from
> “Supported Groups” as the new PQC key exchange algorithms are not groups.
>
>
>
> Cheers,
>
> John Preuß Mattsson
>
>
>
> *From: *TLS  on behalf of Sean Turner <
> s...@sn3rd.com>
> *Date: *Thursday, 28 March 2024 at 15:53
> *To: *TLS List 
> *Subject: *[TLS] -draft8447bis: rename Support Group Elliptic curve
> groups space
>
> 
>
> **WARNING: Potential bikeshed**
>
> -connolly-tls-mlkem-key-agreement has suggested that code points for the
> NIST PQ be registered in the TLS Supported Groups IANA registry [1].
> Currently [2], the registry is carved up into three blocks as follows:
>
> Range: 0-255, 512-65535
> Registration Procedures: Specification Required
> Note: Elliptic curve groups
>
> Range 256-511
> Registration Procedures: Specification Required
> Note: Finite Field Diffie-Hellman groups
>
> Assuming that the proposal in -connolly-tls-mlkem-key-agreement is the
> path for PQ KEM algorithms (and maybe regardless of whether this is the
> path), we should really replace the “Elliptic curve groups” note in the
> 0-255, 512-65535 range row with something else.  I am open to suggestions,
> but would like to propose “unallocated”. I have submitted the following
> issue:
>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftlswg%2Frfc8447bis%2Fissues%2F54&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C0a5a0e0174b640b9535508dc4f36c377%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638472343825594155%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=FKpJyM8%2BPLS7Wd1zNGlZoqhFFEQuLNNRzY8bsUQxegA%3D&reserved=0
> 
> and this PR:
>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftlswg%2Frfc8447bis%2Fpull%2F55&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C0a5a0e0174b640b9535508dc4f36c377%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638472343825602619%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=nMQWHlYdoSNn9yNstiB2wNLQw5IZl%2BfHtf14UvOInd8%3D&reserved=0
> 
> to address this.
>
> spt
>
> [1]
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Ftls-parameters%2Ftls-parameters.xhtml%23tls-parameters-8&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C0a5a0e0174b640b9535508dc4f36c377%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638472343825608404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=f3oRbu1I2ThwoKYyK%2BlyO1SDPOrsc3mXShCT%2BeBM3ls%3D&reserved=0
> 

Re: [TLS] -draft8447bis: rename Support Group Elliptic curve groups space

[Loganaden Velvindron]

Agreed.

On Thu, Mar 28, 2024, 19:50 Salz, Rich 
wrote:

> > we should really replace the “Elliptic curve groups” note in the 0-255,
> 512-65535 range row with something else. I am open to suggestions, but
> would like to propose “unallocated”.
>
> Short and to the point; +1
>
> The only alternative I can see is constantly adding things, and eventually
> we get to "curves and lattices and heffalumps oh me..."
>
>
> ___
> 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 1.3, Raw Public Keys, and Misbinding Attacks

[Bas Westerbaan]

On Thu, Mar 28, 2024 at 4:22 PM John Mattsson  wrote:

> Hi,
>
>
>
> I looked into what RFC 8446(bis) says about Raw Public Keys. As correctly
> stated in RFC 8446, TLS 1.3 with signatures and certificates is an
> implementation of SIGMA-I:
>
>
>
> SIGMA does however require that the identities of the endpoints (called A
> and B in [SIGMA]) are included in the messages. This is not true for TLS
> 1.3 with RPKs and TLS 1.3 with RPKs is therefore not SIGMA. TLS 1.3 with
> RPKs is vulnerable to what Krawczyk’s SIGMA paper calls misbinding attacks:
>
>
>
> “This attack, to which we refer as an “identity misbinding attack”,
> applies to many seemingly natural and intuitive protocols. Avoiding this
> form of attack and guaranteeing a consistent binding between a session key
> and the peers to the session is a central element in the design of SIGMA.”
>
>
>
> “Even more significantly we show here that the misbinding attack applies
> to this protocol in any scenario where parties can register public keys
> without proving knowledge of the corresponding signature key.”
>

With a bit more context (emphasis my own):

Yet, no proof of security of the *STS protocol*
exists (see more on this below). Even more significantly we show here that
the
misbinding attack applies to this protocol in any scenario where parties can
register public keys without proving knowledge of the corresponding
signature
key. (We note that while such “proof of possession” is required by some CAs
for
issuing a certificate, this is not a universal requirement for public key
certificates;
in particular it is not satisfied in many “out-of-band distribution”
scenarios, webs
of trust, etc.) In this case Eve can register A’s public key as its own and
then
simply replace A’s identity (or certificate) in the third message of STS
with her
own. B verifies the incoming message and accepts it as coming from Eve.
Thus,
in this case the STS protocol fails to defend against the misbinding
attack. Thus,
for the STS to be secure one must assume that a secure external mechanism
for
proof of possession of signature keys is enforced. *As we will see both the
ISO*
*protocol discussed in Section 4 and the SIGMA protocols presented here do
not*
*require such a mechanism.*





>
>
> As stated in Appendix E.1, at the completion of the handshake, each side
> outputs its view of the identities of the communicating parties. On of the
> TLS 1.3 security properties are “Peer Authentication”, which says that the
> client’s and server’s view of the identities match. TLS 1.3 with PRKs does
> not fulfill this unless the out-of-band mechanism to register public keys
> proved knowledge of the private key. RFC 7250 does not say anything about
> this either.
>
>
>
> I think this needs to be clarified in RFC8446bis. The only reason to ever
> use an RPK is in constrained IoT environments. Otherwise a self-signed
> certificate is a much better choice. TLS 1.3 with self-signed certificates
> is SIGMA-I.
>
>
>
> It is worrying to find comments like this:
>
>
>
> “I'd like to be able to use wireguard/ssh-style authentication for my app.
> This is possible currently with self-signed certificates, but the proper
> solution is RFC 7250, which is also part of TLS 1.3.”
>
> https://github.com/openssl/openssl/issues/6929
>
>
>
> RPKs are not the proper solution.
>
>
>
> (Talking about misbinding, does RFC 8446 say anything about how to avoid
> selfie attacks where an entity using PSK authentication ends up talking to
> itself?)
>
>
>
> Cheers,
>
> John Preuß Mattsson
>
>
>
> [SIGMA] https://link.springer.com/chapter/10.1007/978-3-540-45146-4_24
>
>
> ___
> 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 1.3, Raw Public Keys, and Misbinding Attacks

[Viktor Dukhovni]

On Thu, Mar 28, 2024 at 03:22:05PM +, John Mattsson wrote:

> I looked into what RFC 8446(bis) says about Raw Public Keys. As
> correctly stated in RFC 8446, TLS 1.3 with signatures and certificates
> is an implementation of SIGMA-I:

Assuming certificates are issued with strong assurance, which, with DV
certificates, is perhaps somewhat questionable.

> SIGMA does however require that the identities of the endpoints
> (called A and B in [SIGMA]) are included in the messages. This is not
> true for TLS 1.3 with RPKs and TLS 1.3 with RPKs is therefore not
> SIGMA. TLS 1.3 with RPKs is vulnerable to what Krawczyk’s SIGMA paper
> calls misbinding attacks:

The SNI extension in TLS allows servers that are the targets of
misbinding attacks to detect that the client was trying to communicate
with a different system, and in the case of HTTPS, there is also the
required "Host:" host header, which again will alert the server to the
fact that the client is requesting an unsupported resource.

Many operators obtain wildcard certificates, again a server should take
measures to ensure that among all the hosts sharing the same DNS suffix,
the session was actually intended for it, and not another service
endpoint, though in the case of multiple application services on the
same machine, that isn't always possible, because SNI conveys just
the hostname.

> “Even more significantly we show here that the misbinding attack
> applies to this protocol in any scenario where parties can register
> public keys without proving knowledge of the corresponding signature
> key.”

Note, that, for example, with SMTP the simplest way to direct traffic to
someone else's MX host is to publish MX records for one's own domain
that specify that MX host.  So "misbinding" attacks are not
"interesting" in this context.  Furthermore, because there are no
"cross-origin" issues in SMTP, there is nothing to be gained by
misleading a client that it is connected to a service endpoint for which
one can control the expected public key binding, when in fact it is
connecting to a "victim" service endpoint.

And of course how clients learn the association between and endpoint,
and the expected raw public key is a rather separate matter from whether
public keys or certificates happen to be used.  The public key might
be pre-shared out of band over a pre-existing bilateral trusted channel
between client and server, and proof of possession could be part of
that exchange if desired and useful.

> TLS 1.3 with PRKs does not fulfill this unless the out-of-band
> mechanism to register public keys proved knowledge of the private key.
> RFC 7250 does not say anything about this either.

If the server rejects unexpected SNI (including absence of SNI), that
should close the gap.

> I think this needs to be clarified in RFC8446bis. The only reason to
> ever use an RPK is in constrained IoT environments.

This is much too narrow a use-case.  There are other valid scenarios.

> self-signed certificate is a much better choice. TLS 1.3 with
> self-signed certificates is SIGMA-I.

Assuming the client looks at the name in the certificate, which isn't
always the case. And that the certificate isn't a wildcard certificate,
and the there aren't multiple TLS service endpoints at the same
hostname, where redirection from one application service to another,
might be a concern...

> It is worrying to find comments like this:
> 
> “I'd like to be able to use wireguard/ssh-style authentication for my
> app. This is possible currently with self-signed certificates, but the
> proper solution is RFC 7250, which is also part of TLS 1.3.”
> https://github.com/openssl/openssl/issues/6929

There are legitimate use-cases for RPKs, including at least some where
UKS attacks are not applicable.

> RPKs are not the proper solution.

RPKs are a solution when obtained from a trusted party, e.g. for
connections between machines controlled by the same operator, or
SMTP (given MX indirection described above), or in applications where
cross-origin attacks don't apply, ...

> (Talking about misbinding, does RFC 8446 say anything about how to
> avoid selfie attacks where an entity using PSK authentication ends up
> talking to itself?)

PSKs are not generally symmetric.

-- 
Viktor.

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

Re: [TLS] -draft8447bis: rename Support Group Elliptic curve groups space

[Loganaden Velvindron]

Clarification: I agree on the need to rename the group space. However, I
don't support using only mlkem as a curve for tls. However, mlkem as a
hybrid makes sense.

On Thu, Mar 28, 2024, 20:28 Loganaden Velvindron 
wrote:

> Agreed.
>
> On Thu, Mar 28, 2024, 19:50 Salz, Rich 
> wrote:
>
>> > we should really replace the “Elliptic curve groups” note in the 0-255,
>> 512-65535 range row with something else. I am open to suggestions, but
>> would like to propose “unallocated”.
>>
>> Short and to the point; +1
>>
>> The only alternative I can see is constantly adding things, and
>> eventually we get to "curves and lattices and heffalumps oh me..."
>>
>>
>> ___
>> 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 1.3, Raw Public Keys, and Misbinding Attacks

[Dennis Jackson]

Hi John,

It depends what you mean by an identity. TLS1.3 ensures the peers agree 
on the used RPKs and it doesn't rely on any external proof of possession 
to achieve that property.


How the peers come to trust the RPKs or their corresponding identity is 
of necessity left to the application - not dissimilar to how the 
application has to decide which root certificates to trust and whether 
the leaf certificate is appropriate for the intended connection (e.g. 
browsers extract the valid identities from the SAN).


Best,
Dennis

On 28/03/2024 15:22, John Mattsson wrote:


Hi,

I looked into what RFC 8446(bis) says about Raw Public Keys. As 
correctly stated in RFC 8446, TLS 1.3 with signatures and certificates 
is an implementation of SIGMA-I:


SIGMA does however require that the identities of the endpoints 
(called A and B in [SIGMA]) are included in the messages. This is not 
true for TLS 1.3 with RPKs and TLS 1.3 with RPKs is therefore not 
SIGMA. TLS 1.3 with RPKs is vulnerable to what Krawczyk’s SIGMA paper 
calls misbinding attacks:


“This attack, to which we refer as an “identity misbinding attack”, 
applies to many seemingly natural and intuitive protocols. Avoiding 
this form of attack and guaranteeing a consistent binding between a 
session key and the peers to the session is a central element in the 
design of SIGMA.”


“Even more significantly we show here that the misbinding attack 
applies to this protocol in any scenario where parties can register 
public keys without proving knowledge of the corresponding signature key.”


As stated in Appendix E.1, at the completion of the handshake, each 
side outputs its view of the identities of the communicating parties. 
On of the TLS 1.3 security properties are “Peer Authentication”, which 
says that the client’s and server’s view of the identities match. TLS 
1.3 with PRKs does not fulfill this unless the out-of-band mechanism 
to register public keys proved knowledge of the private key. RFC 7250 
does not say anything about this either.


I think this needs to be clarified in RFC8446bis. The only reason to 
ever use an RPK is in constrained IoT environments. Otherwise a 
self-signed certificate is a much better choice. TLS 1.3 with 
self-signed certificates is SIGMA-I.


It is worrying to find comments like this:

“I'd like to be able to use wireguard/ssh-style authentication for my 
app. This is possible currently with self-signed certificates, but the 
proper solution is RFC 7250, which is also part of TLS 1.3.”


https://github.com/openssl/openssl/issues/6929

RPKs are not the proper solution.

(Talking about misbinding, does RFC 8446 say anything about how to 
avoid selfie attacks where an entity using PSK authentication ends up 
talking to itself?)


Cheers,

John Preuß Mattsson

[SIGMA] https://link.springer.com/chapter/10.1007/978-3-540-45146-4_24


___
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] -draft8447bis: rename Support Group Elliptic curve groups space

[Russ Housley]

Sean:

I observe that ML-KEM is not a Elliptic curve group or a Finite Field 
Diffie-Hellman group.  I really think we want to include sepport for KEMs. but 
a separate range is needed.  I assume it will be carved out of the Elliptic 
curve group range.

KEMs are not "key agreement" algorithms as suggested by this draft name.  In a 
key agreement algorithm, both parties contribute to the shared secret.  With a 
KEM, only one party generates the the shared secreat value.

Russ

> On Mar 28, 2024, at 10:52 AM, Sean Turner  wrote:
> 
> 
> 
> **WARNING: Potential bikeshed**
> 
> -connolly-tls-mlkem-key-agreement has suggested that code points for the NIST 
> PQ be registered in the TLS Supported Groups IANA registry [1].  Currently 
> [2], the registry is carved up into three blocks as follows:
> 
> Range: 0-255, 512-65535
> Registration Procedures: Specification Required
> Note: Elliptic curve groups
> 
> Range 256-511
> Registration Procedures: Specification Required
> Note: Finite Field Diffie-Hellman groups
> 
> Assuming that the proposal in -connolly-tls-mlkem-key-agreement is the path 
> for PQ KEM algorithms (and maybe regardless of whether this is the path), we 
> should really replace the “Elliptic curve groups” note in the 0-255, 
> 512-65535 range row with something else.  I am open to suggestions, but would 
> like to propose “unallocated”. I have submitted the following issue:
> https://github.com/tlswg/rfc8447bis/issues/54
> and this PR:
> https://github.com/tlswg/rfc8447bis/pull/55
> to address this.
> 
> spt
> 
> [1] 
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
> 
> [2] Originally, RFC 8442 defined the name of the registry as "EC Named Curve 
> Registry” and then RFC 7919 re-named it “Supported Groups” and carved out the 
> FFDH space.

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

Re: [TLS] -draft8447bis: rename Support Group Elliptic curve groups space

[David Benjamin]

I don't believe we need a separate range, just to unmark the elliptic
curve range. TLS does not usually ascribe meaning to ranges of codepoints
because TLS implementations do not need to categorize codepoints they don't
understand.

The only reason supported groups was partitioned was because of a goofy
thing RFC 7919 did for FFDH. That goofy thing also was what made RFC 7919
undeployable anyway, so it didn't work out. :-)

On Thu, Mar 28, 2024 at 5:08 PM Russ Housley  wrote:

> Sean:
>
> I observe that ML-KEM is not a Elliptic curve group or a Finite Field
> Diffie-Hellman group.  I really think we want to include sepport for KEMs.
> but a separate range is needed.  I assume it will be carved out of the
> Elliptic curve group range.
>
> KEMs are not "key agreement" algorithms as suggested by this draft name.
> In a key agreement algorithm, both parties contribute to the shared
> secret.  With a KEM, only one party generates the the shared secreat value.
>
> Russ
>
> > On Mar 28, 2024, at 10:52 AM, Sean Turner  wrote:
> >
> > 
> >
> > **WARNING: Potential bikeshed**
> >
> > -connolly-tls-mlkem-key-agreement has suggested that code points for the
> NIST PQ be registered in the TLS Supported Groups IANA registry [1].
> Currently [2], the registry is carved up into three blocks as follows:
> >
> > Range: 0-255, 512-65535
> > Registration Procedures: Specification Required
> > Note: Elliptic curve groups
> >
> > Range 256-511
> > Registration Procedures: Specification Required
> > Note: Finite Field Diffie-Hellman groups
> >
> > Assuming that the proposal in -connolly-tls-mlkem-key-agreement is the
> path for PQ KEM algorithms (and maybe regardless of whether this is the
> path), we should really replace the “Elliptic curve groups” note in the
> 0-255, 512-65535 range row with something else.  I am open to suggestions,
> but would like to propose “unallocated”. I have submitted the following
> issue:
> > https://github.com/tlswg/rfc8447bis/issues/54
> > and this PR:
> > https://github.com/tlswg/rfc8447bis/pull/55
> > to address this.
> >
> > spt
> >
> > [1]
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
> >
> > [2] Originally, RFC 8442 defined the name of the registry as "EC Named
> Curve Registry” and then RFC 7919 re-named it “Supported Groups” and carved
> out the FFDH space.
>
> ___
> 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] -draft8447bis: rename Support Group Elliptic curve groups space

[Bob Beck]

On Fri, Mar 29, 2024 at 2:59 AM David Benjamin  wrote:

> Regarding renaming, I'm torn. "Group" was a truly horrible rename. The names 
> we pick make their way into APIs and even sometimes UI surfaces for 
> developers. Every time I've plumbed TLS named groups into another system, 
> I've been met with confusion about what in the world a "group" is, and I've 
> had to embarrassingly explain that yes, it is a term of art, short for 
> "Diffie-Hellman group", no, it doesn't even make sense with PQC, and I'm 
> truly very sorry that TLS chose such a needlessly confusing name, but it's 
> the name we've got. Sometimes I just give up on the TLSWG's naming and just 
> saying "key exchange" or "key agreement", but that gets a little tricky 
> because that can also mean the left half of a TLS 1.2 cipher suite (ECDHE_RSA 
> / ECDHE_ECDSA / RSA). At one point, we tried "key exchange group" to avoid 
> that, but that's also problematic as one needs to explain to translators that 
> this does not mean "primary trade collection".
>
> This name is bad enough that I needed to make a pre-written explanation for 
> this, so I can save time and link to it every time it comes up.
>
> At the same time, we've already renamed this once. These names we pick make 
> their way everywhere, each rename we do is costly. All the old "curve" APIs 
> had to be doubled up and deprecated in systems, with the old ones forever 
> stuck around. And then some systems (probably correctly) decided to stick 
> with the old "curve" name. Renaming again will add a third, and repeat this 
> costly cycle.

This would be why in spite of the fact that I dislike the "group"
name, I would lean more to the "no do not rename" - We already deal
with "group" and "curve" for this and the names are scattered through
API and implementations, and we already have to deal with explaining
it's not really a group, and not really a curve, and it was renamed.
IMO Renaming this a third time will simply add more such confusion to
this area and make the "explaining" david alludes to above even longer
to add a third case to make people aware of the rough equivalency of
the third name in the saga, since the old names will not go away soon
or easily.

> Had we not renamed, I would say we just keep it at "curves". While "curves" 
> is also wrong for PQC, it is less generic of a name than "group" and, in my 
> experience, reads more clearly as a random term of art. It's a pity that we 
> then changed it to one of the most overloaded words in English imaginable. :-(

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

[TLS] [Errata Held for Document Update] RFC8446 (6401)

[RFC Errata System]

The following errata report has been held for document update 
for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". 

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

--
Status: Held for Document Update
Type: Technical

Reported by: Eric Covener 
Date Reported: 2021-01-20
Held by: Paul Wouters (IESG)

Section: 4.6.2

Original Text
-
When the client has sent the "post_handshake_auth" extension (see
Section 4.2.6), a server MAY request client authentication at any
time after the handshake has completed by sending a
CertificateRequest message.  

Corrected Text
--
When the client has sent the "post_handshake_auth" extension (see
Section 4.2.6), a server MAY request client authentication during the 
main handshake and/or at any time after the handshake has completed by 
sending a CertificateRequest message.  



Notes
-
4.6.2 is ambiguous as to whether it forbids "main handshake" (mid-handshake) 
client 
authentication when the client has sent  the "post_handshake_auth" extension. I 
think 
the language would be stronger if it were really forbidden, and openssl 
s_server permits 
this behavior and rfc8740 implies it as well.

The "main handshake" language is adopted from 4.3.2 but "main" could be dropped 
as 
"handshake" is not ambiguous in 1.3 due to no renegotiation.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

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

[TLS] [Errata Verified] RFC8446 (5483)

[RFC Errata System]

The following errata report has been verified for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3". 

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

--
Status: Verified
Type: Technical

Reported by: Patrick Kelsey 
Date Reported: 2018-08-28
Verified by: Paul Wouters (IESG)

Section: 4.2.8.2

Original Text
-
For X25519 and X448, the contents of the public value are the byte
string inputs and outputs of the corresponding functions defined in
[RFC7748]: 32 bytes for X25519 and 56 bytes for X448.

Corrected Text
--
For X25519 and X448, the contents of the public value are the byte
string outputs of the corresponding functions defined in [RFC7748]: 32
bytes for X25519 and 56 bytes for X448.

Notes
-
Per Section 7.4.2 of this RFC and Section 6 of RFC7748, the byte string inputs 
to the corresponding ECDH scalar multiplication function are the private key 
and the u-coordinate of the standard public base point, the former of which of 
course must not be transmitted and the latter of which is a known constant.

Paul Wouters (AD): Resolved but with the following Corrected Text:

For X25519 and X448, the contents of the public value is the K_A or
K_B value described in Section 6 of [RFC7748].  This is 32 bytes for
X25519 and 56 bytes for X448.

>From another perspective, including the byte string inputs in the contents of 
>the public value would contradict the resulting content sizes given at the end 
>of the cited paragraph as well as the statement in Section 7.4.2 that the 
>public key put into the KeyShareEntry is the output of ECDH scalar 
>multiplication function.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

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

[TLS] [Errata Verified] RFC8446 (6123)

[RFC Errata System]

The following errata report has been verified for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3". 

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

--
Status: Verified
Type: Technical

Reported by: Ben Smyth 
Date Reported: 2020-04-24
Verified by: Paul Wouters (IESG)

Section: 2

Original Text
-
The handshake protocol allows peers to negotiate a protocol version, select 
cryptographic algorithms, optionally authenticate each other, and establish 
shared secret keying material.

Corrected Text
--


Notes
-
Only client authentication is optional (albeit, server authentication is 
implicit for PSK-only key exchange mode)

Paul Wouters(AD): corrected with the following text:

The handshake protocol allows peers to negotiate a protocol version, select 
cryptographic algorithms, authenticate each other (with client authentication 
being optional), and establish shared secret keying material.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

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

[TLS] [Errata Verified] RFC8446 (7303)

[RFC Errata System]

The following errata report has been verified for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3". 

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

--
Status: Verified
Type: Technical

Reported by: Eric Lawrence 
Date Reported: 2023-01-12
Verified by: Paul Wouters (IESG)

Section: 6.1

Original Text
-
This alert notifies the recipient that the sender will not send any more 
messages on this connection. 

Corrected Text
--
This alert notifies the recipient that the sender will not send any more 
messages on this connection. close_notify alerts should be sent with a severity 
level of WARNING.

Notes
-
Apparently, TLS/1.0 specified these should be set to WARNING, not FATAL, but 
this text got lost somewhere along the way. 
https://github.com/pion/dtls/issues/195

OpenSSL/NSS both send as WARNING, and servers that have tried sending as FATAL 
have encountered compatibility problems with clients which treat FATAL alerts 
differently than WARNING alerts: e.g. 
https://source.chromium.org/chromium/chromium/src/+/main:third_party/boringssl/src/ssl/tls_record.cc;l=591;drc=c0872c02015009bf3dbab0a83c0452d141e8e9cf?q=tls_open_record&ss=chromium%2Fchromium%2Fsrc

Paul Wouters(AD): Resolved but with the following Corrected Text:

close_notify:  This alert notifies the recipient that the sender will not send 
any more messages on this connection.  Any data received after a closure alert 
has been received MUST be ignored. This alert MUST be sent with 
AlertLevel=warning.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

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

[TLS] [Errata Verified] RFC8446 (7250)

[RFC Errata System]

The following errata report has been verified for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3". 

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

--
Status: Verified
Type: Technical

Reported by: Alan DeKok 
Date Reported: 2022-11-14
Verified by: Paul Wouters (IESG)

Section: 4.6.1

Original Text
-
   The client MAY use this PSK for future handshakes by including the
   ticket value in the "pre_shared_key" extension in its ClientHello
   (Section 4.2.11).

Corrected Text
--
(to add)

  Where the client does not support session tickets, this extension MUST be 
ignored.

Notes
-
I've seen a TLS implementation which doesn't implement session tickets.  That's 
fine, but the implementation doesn't *ignore* session tickets it receives.  
Instead, it treats reception of the ticket as un recoverable error, and drops 
the TLS connection.

It's also worth adding a note to section 4.2 at the bottom of page 38.  To note 
that in general, f an extension isn't supported AND doesn't materially affect 
the TLS exchange, THEN it should be ignored.

i.e. there's nothing in the spec which mentions Postel's law "be conservative 
in what you send, be liberal in what you accept".  So implementors reading this 
document are free to do all kinds of odd things.

In addition, the text in Section 4.2 at the bottom of page 38 says:

"
  Designers
  and implementors should be aware of the fact that until the
  handshake has been authenticated, active attackers can modify
  messages and insert, remove, or replace extensions.
"

The implicit conclusion here is that an implementation receiving extensions 
must sanity check them.  e.g. an attacker adding an undefined / unknown 
extension should not cause the entire session to be torn down.

Paul Wouters(AD): Resolved but with the Corrected Text:

The client MAY use this PSK for future handshakes by including the ticket value 
in the "pre_shared_key" extension in its ClientHello (Section 4.2.11). Clients 
which receive a NewSessionTicket message but do not support resumption MUST 
silently ignore this message.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

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

[TLS] [Errata Verified] RFC8446 (6139)

[RFC Errata System]

The following errata report has been verified for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3". 

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

--
Status: Verified
Type: Editorial

Reported by: Ben Smyth 
Date Reported: 2020-04-29
Verified by: Paul Wouters (IESG)

Section: 4.4.2.2.

Original Text
-
As servers MAY require the presence of the "server_name" extension, clients
SHOULD send this extension, when applicable.

Corrected Text
--
As servers MAY require the presence of the "server_name" extension, client
SHOULD send this extension.

Notes
-
Since it is unclear when it is applicable for a server to send the extension, 
dropping "when applicable"
seems appropriate. Alternatively, giving some extra guidance would be useful.

Paul Wouters(AD): Resolved with alternative Corrected Text:

As servers MAY require the presence of the "server_name" extension, clients 
SHOULD send this extension when the server is identified by name.


--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

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

[TLS] [Errata Held for Document Update] RFC8446 (6204)

[RFC Errata System]

The following errata report has been held for document update 
for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". 

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

--
Status: Held for Document Update
Type: Editorial

Reported by: Chris Wood 
Date Reported: 2020-06-03
Held by: Paul Wouters (IESG)

Section: E.1

Original Text
-
Implementations MUST NOT combine external PSKs with certificate-based 
authentication of either the client or the server unless negotiated by some 
extension.

Corrected Text
--
Implementations MUST NOT combine external PSKs with certificate-based 
authentication of either client or the server. Future specifications MAY 
provide an extension to permit this. 

Notes
-
The existing text can be misread as permitting this combination upon 
negotiation of the "post_handshake_auth" extension, which would be incorrect. 
[1] describes an attack that can occur based on this misinterpretation. The 
proposed text aims to make clear that a *new* extension is required for this 
combination. 

Paul Wouters(AD): See 
https://mailarchive.ietf.org/arch/msg/tls/uDjERicvcTimiecyhiSrYA0H1Sc/
[1] https://link.springer.com/article/10.1007%2Fs11416-020-00352-0

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

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

[TLS] [Errata Held for Document Update] RFC8446 (5717)

[RFC Errata System]

The following errata report has been held for document update 
for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". 

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

--
Status: Held for Document Update
Type: Editorial

Reported by: Daniel Migault 
Date Reported: 2019-05-03
Held by: Paul Wouters (IESG)

Section: 2.2.

Original Text
-
 Figure 3 shows a pair of handshakes in which the first handshake
   establishes a PSK and the second handshake uses it:
 
  Client   Server
 
   Initial Handshake:
  ClientHello
  + key_share   >
  ServerHello
  + key_share
{EncryptedExtensions}
{CertificateRequest*}
   {Certificate*}
 {CertificateVerify*}
   {Finished}
< [Application Data*]
  {Certificate*}
  {CertificateVerify*}
  {Finished}>
<  [NewSessionTicket]
  [Application Data]<--->  [Application Data]
 
 
   Subsequent Handshake:
  ClientHello
  + key_share*
  + pre_shared_key  >
  ServerHello
 + pre_shared_key
 + key_share*
{EncryptedExtensions}
   {Finished}
< [Application Data*]
  {Finished}>
  [Application Data]<--->  [Application Data]
 
   Figure 3: Message Flow for Resumption and PSK


Corrected Text
--
 Figure 3 shows a pair of handshakes in which the first handshake
   establishes a PSK and the second handshake uses it:
 
  Client   Server
 
   Initial Handshake:
  ClientHello
  + key_share   >
  ServerHello
  + key_share
{EncryptedExtensions}
{CertificateRequest*}
   {Certificate*}
 {CertificateVerify*}
   {Finished}
< [Application Data*]
  {Certificate*}
  {CertificateVerify*}
  {Finished}>
<  [NewSessionTicket]
  [Application Data]<--->  [Application Data]
 
 
   Subsequent Handshake:
  ClientHello
  + key_share*
  + psk_key_exchange_modes
  + pre_shared_key  >

  ServerHello
 + pre_shared_key
 + key_share*
{EncryptedExtensions}
   {Finished}
< [Application Data*]
  {Finished}>
  [Application Data]<--->  [Application Data]
 
   Figure 3: Message Flow for Resumption and PSK


Notes
-
The pre_shared_key requires the pre_share_key extension.

This Issue and PR should address this erratum:
https://github.com/tlswg/tls13-spec/issues/1344
https://github.com/tlswg/tls13-spec/pull/1345


--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

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

Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks

[Martin Thomson]

Dennis beat me to making the key point about identity :)

There are cases where identity misbinding is possible in similar systems.  RFC 
8844 describes one such case.  However, this is not an inherent failing in TLS, 
but in the usage context.  That weakness was not the result of using raw public 
keys though.

What TLS *says* about this risk is really what we should be considering.  It 
might be enough to say that where TLS does not carry all of the relevant 
identification information, there is a risk of identity misbinding attacks.  
This can be mitigated by including additional information about identity in the 
transcript and checking it for consistency (as RFC 8844 does).

On Fri, Mar 29, 2024, at 05:27, Dennis Jackson wrote:
> Hi John, 
>
> It depends what you mean by an identity. TLS1.3 ensures the peers agree 
> on the used RPKs and it doesn't rely on any external proof of 
> possession to achieve that property.
>
> How the peers come to trust the RPKs or their corresponding identity is 
> of necessity left to the application - not dissimilar to how the 
> application has to decide which root certificates to trust and whether 
> the leaf certificate is appropriate for the intended connection (e.g. 
> browsers extract the valid identities from the SAN). 
>
> Best,
> Dennis
>
> On 28/03/2024 15:22, John Mattsson wrote:
>> Hi,
>>  
>> I looked into what RFC 8446(bis) says about Raw Public Keys. As correctly 
>> stated in RFC 8446, TLS 1.3 with signatures and certificates is an 
>> implementation of SIGMA-I: 
>>  
>> SIGMA does however require that the identities of the endpoints (called A 
>> and B in [SIGMA]) are included in the messages. This is not true for TLS 1.3 
>> with RPKs and TLS 1.3 with RPKs is therefore not SIGMA. TLS 1.3 with RPKs is 
>> vulnerable to what Krawczyk’s SIGMA paper calls misbinding attacks:
>>  
>> “This attack, to which we refer as an “identity misbinding attack”, applies 
>> to many seemingly natural and intuitive protocols. Avoiding this form of 
>> attack and guaranteeing a consistent binding between a session key and the 
>> peers to the session is a central element in the design of SIGMA.”
>>  
>> “Even more significantly we show here that the misbinding attack applies to 
>> this protocol in any scenario where parties can register public keys without 
>> proving knowledge of the corresponding signature key.”
>>  
>> As stated in Appendix E.1, at the completion of the handshake, each side 
>> outputs its view of the identities of the communicating parties. On of the 
>> TLS 1.3 security properties are “Peer Authentication”, which says that the 
>> client’s and server’s view of the identities match. TLS 1.3 with PRKs does 
>> not fulfill this unless the out-of-band mechanism to register public keys 
>> proved knowledge of the private key. RFC 7250 does not say anything about 
>> this either. 
>>  
>> I think this needs to be clarified in RFC8446bis. The only reason to ever 
>> use an RPK is in constrained IoT environments. Otherwise a self-signed 
>> certificate is a much better choice. TLS 1.3 with self-signed certificates 
>> is SIGMA-I.
>>  
>> It is worrying to find comments like this:
>>  
>> “I'd like to be able to use wireguard/ssh-style authentication for my app. 
>> This is possible currently with self-signed certificates, but the proper 
>> solution is RFC 7250, which is also part of TLS 1.3.”
>> https://github.com/openssl/openssl/issues/6929
>>  
>> RPKs are not the proper solution.
>>  
>> (Talking about misbinding, does RFC 8446 say anything about how to avoid 
>> selfie attacks where an entity using PSK authentication ends up talking to 
>> itself?)
>>  
>> Cheers,
>> John Preuß Mattsson
>>  
>> [SIGMA] https://link.springer.com/chapter/10.1007/978-3-540-45146-4_24
>>  
>> 
>> ___
>> 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

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