Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

[Achim Kraus]

Hi Viktor,

using a compression format comes with savings, but in my experience, one
of the other issues, which comes with pain for constraint IoT, is the
amount of "parameters" sent in the ClientHello. For DTLS 1.2, that's
even sent twice, if a HelloVerifyRequest is used.
A macro to enable the set recommended by Thomas and Hannes (RFC 7925,
draft-ietf-uta-tls13-iot-profile-05) helps as well.

best regards
Achim


Am 23.01.23 um 23:47 schrieb Viktor Dukhovni:

On Mon, Jan 23, 2023 at 09:04:40PM +, John Mattsson wrote:


RFC 7250 states that "The SubjectPublicKeyInfo structure is defined in
Section 4.1 of RFC 5280".

The encoding of secp256r1 public keys in X.509 is defined in RFC 5480
which says that: "MUST support the uncompressed form and MAY support
the compressed form".

My reading is that point compressed X.509 and RPK are allowed in TLS
and that this follows from X.509. I don't think RFC 8422 applies here.


I find that reading surprising, because at least when the point formats
extension is used:

 https://www.rfc-editor.org/rfc/rfc4492#section-5.3 (bottom of page 16)

...   If the client has used
a Supported Point Formats Extension, both the server's public key
point and (in the case of an explicit curve) the curve's base point
MUST respect the client's choice of point formats.  (A server that
cannot satisfy these requirements MUST NOT choose an ECC cipher suite
in its ServerHello message.)

which rather indicates that in *TLS* supported point formats is supposed
to cover not just the key exchange, but also the certificates.

With point formats other than "uncompressed" (or default for curve in
TLS 1.3) now deprecated, it sure seems like RPK would need to comply.

Any comments from the usual suspects (ekr, et. al.)?

Of course on the receiving side, of some implementation is more liberal
and accepts compressed there's probably little harm (provided TLSA
records or whatever the peer uses to match the expected key when/if
validating also match the compressed SPKI).

On the sending side, my reading is that the sender should probably
ensure that the transmitted form is "uncompressed" (default for
curve).  In practice, the sender's private key is likely already
in the default point format, so the "right thing" happens most
of the time, but perhaps implementations should be prepared to
DTRT in the rare case that the configured key material is in
some non-default point form.



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

Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

[Achim Kraus]

Hi John,

>  I don't think RFC 8422 applies here.

maybe, if one of that authors are reading the list, we can get an
statement, what the intention of was.

A RFC7250 handshake takes about 1500 bytes "on the wire".
Saving 32 bytes twice is not that great improvement.
If someone want to be "better off" and uses DTLS 1.2,
then considering RFC9146 improves much more, it reduces
the number of handshake.

best regards
Achim



Am 23.01.23 um 22:04 schrieb John Mattsson:

RFC 7250 states that "The SubjectPublicKeyInfo structure is defined in
Section 4.1 of RFC 5280".

The encoding of secp256r1 public keys in X.509 is defined in RFC 5480
which says that: "MUST support the uncompressed form and MAY support the
compressed form".

My reading is that point compressed X.509 and RPK are allowed in TLSand
that this follows from X.509. I don't think RFC 8422 applies here.


Should there be some code to make sure that the uncompressed format is used?


If you do something, it should probably be for all SubjectPublicKeyInfo,
not just in RPKs.

The numbers I posted beforewas wrong, I think the correct sizes are:

- Uncompressed secp256r1 RPKs are 91 bytes.

- Point compressed secp256r1 RPKs are 59 bytes

- Ed25519 RPKs are 44 bytes

Cheers,

John

*From: *TLS  on behalf of Viktor Dukhovni

*Date: *Monday, 23 January 2023 at 16:36
*To: *tls@ietf.org 
*Subject: *Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in
OpenSSL ~3.2

On Mon, Jan 23, 2023 at 07:01:38AM +, John Mattsson wrote:

Hi Viktor,

Are point compressed secp256r1 RPKs supported?

- Uncompressed secp256r1 RPKs are 91 bytes.
- Point compressed secp256r1 RPKs are 59 bytes
- Ed25519 RPKs are 58 bytes


It looks to me like EC keys will be sent in their default point format,
which is set when the key pair is loaded.

I don't see any text in RFC7250 that describes how the TLS supported
point formats extension relates to EC raw public keys.  On the other
hand:

https://www.rfc-editor.org/rfc/rfc8422.html#section-5.1.2
<https://www.rfc-editor.org/rfc/rfc8422.html#section-5.1.2>

seems to say that only the uncompressed format is to be used in TLS.

If so what is the right question now?  Should there be some code to make
sure that the uncompressed format is used?  (Rather than rely on the
private key passed through i2d_PUBKEY() to output that form by default).

--
     Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
<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

Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

[Viktor Dukhovni]

On Mon, Jan 23, 2023 at 09:04:40PM +, John Mattsson wrote:

> RFC 7250 states that "The SubjectPublicKeyInfo structure is defined in
> Section 4.1 of RFC 5280".
> 
> The encoding of secp256r1 public keys in X.509 is defined in RFC 5480
> which says that: "MUST support the uncompressed form and MAY support
> the compressed form".
> 
> My reading is that point compressed X.509 and RPK are allowed in TLS
> and that this follows from X.509. I don't think RFC 8422 applies here.

I find that reading surprising, because at least when the point formats
extension is used:

https://www.rfc-editor.org/rfc/rfc4492#section-5.3 (bottom of page 16)

   ...   If the client has used
   a Supported Point Formats Extension, both the server's public key
   point and (in the case of an explicit curve) the curve's base point
   MUST respect the client's choice of point formats.  (A server that
   cannot satisfy these requirements MUST NOT choose an ECC cipher suite
   in its ServerHello message.)

which rather indicates that in *TLS* supported point formats is supposed
to cover not just the key exchange, but also the certificates.

With point formats other than "uncompressed" (or default for curve in
TLS 1.3) now deprecated, it sure seems like RPK would need to comply.

Any comments from the usual suspects (ekr, et. al.)?

Of course on the receiving side, of some implementation is more liberal
and accepts compressed there's probably little harm (provided TLSA
records or whatever the peer uses to match the expected key when/if
validating also match the compressed SPKI).

On the sending side, my reading is that the sender should probably
ensure that the transmitted form is "uncompressed" (default for
curve).  In practice, the sender's private key is likely already
in the default point format, so the "right thing" happens most
of the time, but perhaps implementations should be prepared to
DTRT in the rare case that the configured key material is in
some non-default point form.

-- 
Viktor.

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

Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

[John Mattsson]

RFC 7250 states that "The SubjectPublicKeyInfo structure is defined in Section 
4.1 of RFC 5280".

The encoding of secp256r1 public keys in X.509 is defined in RFC 5480 which 
says that: "MUST support the uncompressed form and MAY support the compressed 
form".

My reading is that point compressed X.509 and RPK are allowed in TLS and that 
this follows from X.509. I don't think RFC 8422 applies here.

>Should there be some code to make sure that the uncompressed format is used?
If you do something, it should probably be for all SubjectPublicKeyInfo, not 
just in RPKs.

The numbers I posted before was wrong, I think the correct sizes are:
- Uncompressed secp256r1 RPKs are 91 bytes.
- Point compressed secp256r1 RPKs are 59 bytes
- Ed25519 RPKs are 44 bytes

Cheers,
John

From: TLS  on behalf of Viktor Dukhovni 

Date: Monday, 23 January 2023 at 16:36
To: tls@ietf.org 
Subject: Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL 
~3.2
On Mon, Jan 23, 2023 at 07:01:38AM +, John Mattsson wrote:
> Hi Viktor,
>
> Are point compressed secp256r1 RPKs supported?
>
> - Uncompressed secp256r1 RPKs are 91 bytes.
> - Point compressed secp256r1 RPKs are 59 bytes
> - Ed25519 RPKs are 58 bytes

It looks to me like EC keys will be sent in their default point format,
which is set when the key pair is loaded.

I don't see any text in RFC7250 that describes how the TLS supported
point formats extension relates to EC raw public keys.  On the other
hand:

https://www.rfc-editor.org/rfc/rfc8422.html#section-5.1.2

seems to say that only the uncompressed format is to be used in TLS.

If so what is the right question now?  Should there be some code to make
sure that the uncompressed format is used?  (Rather than rely on the
private key passed through i2d_PUBKEY() to output that form by default).

--
Viktor.

___
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] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

[Viktor Dukhovni]

On Mon, Jan 23, 2023 at 07:01:38AM +, John Mattsson wrote:
> Hi Viktor,
> 
> Are point compressed secp256r1 RPKs supported?
> 
> - Uncompressed secp256r1 RPKs are 91 bytes.
> - Point compressed secp256r1 RPKs are 59 bytes
> - Ed25519 RPKs are 58 bytes

It looks to me like EC keys will be sent in their default point format,
which is set when the key pair is loaded.

I don't see any text in RFC7250 that describes how the TLS supported
point formats extension relates to EC raw public keys.  On the other
hand:

https://www.rfc-editor.org/rfc/rfc8422.html#section-5.1.2

seems to say that only the uncompressed format is to be used in TLS.

If so what is the right question now?  Should there be some code to make
sure that the uncompressed format is used?  (Rather than rely on the
private key passed through i2d_PUBKEY() to output that form by default).

-- 
Viktor.

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

Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

[Viktor Dukhovni]

On Mon, Jan 23, 2023 at 09:56:05AM -0500, Viktor Dukhovni wrote:

> On Mon, Jan 23, 2023 at 02:51:45PM +, Salz, Rich wrote:
> 
> > > Assuming OpenSSL's d2i_PUBKEY(3) can decode these, they'll be
> > > accepted. I don't recall seeing any code to transmit point
> > > compressed public keys *to* the peer, but may have missed it,
> > > wasn't looking at the codec that closely.
> > 
> > Looking at the file tls`.h, it appears RFC 4492 point formats are supported.
> 
> It seems the sending side will does not presently send compressed forms:
> 
> 
> https://github.com/tmshort/openssl/blob/master-rpk/ssl/statem/extensions.c#L1802-L1812
> 

I may have confused compressed EC point formats with certificate
compression...  Sorry about the noise.

-- 
Viktor.

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

Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

[Viktor Dukhovni]

On Mon, Jan 23, 2023 at 02:51:45PM +, Salz, Rich wrote:

> > Assuming OpenSSL's d2i_PUBKEY(3) can decode these, they'll be
> > accepted. I don't recall seeing any code to transmit point
> > compressed public keys *to* the peer, but may have missed it,
> > wasn't looking at the codec that closely.
> 
> Looking at the file tls`.h, it appears RFC 4492 point formats are supported.

It seems the sending side will does not presently send compressed forms:


https://github.com/tmshort/openssl/blob/master-rpk/ssl/statem/extensions.c#L1802-L1812

If support for compressed public key forms is a common feature of other
implementations, perhaps it should be included...

-- 
Viktor.

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

Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

[Salz, Rich]

> Assuming OpenSSL's d2i_PUBKEY(3) can decode these, they'll be
accepted. I don't recall seeing any code to transmit point
compressed public keys *to* the peer, but may have missed it,
wasn't looking at the codec that closely.

Looking at the file tls`.h, it appears RFC 4492 point formats are supported.

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

Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

[Viktor Dukhovni]

On Mon, Jan 23, 2023 at 07:01:38AM +, John Mattsson wrote:

> Are point compressed secp256r1 RPKs supported?

There is no RPK-specific code that either accepts or rejects point
compression in ECDSA public keys received from the peer:

https://www.rfc-editor.org/rfc/rfc5480#section-2.2

Assuming OpenSSL's d2i_PUBKEY(3) can decode these, they'll be
accepted.  I don't recall seeing any code to transmit point
compressed public keys *to* the peer, but may have missed it,
wasn't looking at the codec that closely.

> - Uncompressed secp256r1 RPKs are 91 bytes.
> - Point compressed secp256r1 RPKs are 59 bytes
> - Ed25519 RPKs are 58 bytes

The

-- 
Viktor.

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

Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

[John Mattsson]

Hi Viktor,

Are point compressed secp256r1 RPKs supported?

- Uncompressed secp256r1 RPKs are 91 bytes.
- Point compressed secp256r1 RPKs are 59 bytes
- Ed25519 RPKs are 58 bytes

Cheers,
John

From: TLS  on behalf of Achim Kraus 
Date: Sunday, 22 January 2023 at 22:02
To: tls@ietf.org , Viktor Dukhovni 
Subject: Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL 
~3.2
Hello Viktor,

 > Thanks to Todd Short, RFC7250 raw public keys should be available in
 > OpenSSL ~3.2.  Applications that use unauthenticated opportunistic TLS,

Sounds great. Especially for IoT/constraint use-cases that's a real
benefit.

Just in the case, someone is interested, I asked a couple of months ago,
if https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10 has
some considerations about certificate types without a validation date.
See 
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-1d6e8c010f9a9db6=1=45adec37-94c0-453e-b42c-80479cc77e30=https%3A%2F%2Fgithub.com%2Ftlswg%2Ftls-subcerts%2Fissues%2F107

 > The pull request 
 > <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-66e352cf1acf4bf8=1=45adec37-94c0-453e-b42c-80479cc77e30=https%3A%2F%2Fgithub.com%2Fopenssl%2Fopenssl%2Fpull%2F18185>
 >  is
 > still a work in progress, but complete enough for application
 > integration testing.

I will try to test next week the DTLS interoperability with

Eclipse/tinydtls
Eclipse/Californium

best regards
Achim


Am 22.01.23 um 21:41 schrieb Viktor Dukhovni:
> Thanks to Todd Short, RFC7250 raw public keys should be available in
> OpenSSL ~3.2.  Applications that use unauthenticated opportunistic TLS,
> employ DANE or have other ways to avoid X.509 certificates and make do
> with raw peer public keys can avoid the overhead of receiving and
> processing certificate chains.
>
> The pull request 
> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-66e352cf1acf4bf8=1=45adec37-94c0-453e-b42c-80479cc77e30=https%3A%2F%2Fgithub.com%2Fopenssl%2Fopenssl%2Fpull%2F18185>
>  is
> still a work in progress, but complete enough for application
> integration testing.  Likely too late for OpenSSL 3.1 (in beta now), but
> seems likely to land by 3.2.  The TODO items on the OpenSSL side are
> at this point IMHO minor.  Review eyeballs of course always appreciated.
>
> I have a Postfix branch with a reasonably complete implementation:
>
>  # posttls-finger -c 
>  posttls-finger: [192.0.2.1]:25: raw public key fingerprint=<...>
>  posttls-finger: [192.0.2.1]:25: Matched DANE raw public key: 3 1 
> 1 <...>
>  posttls-finger: Verified TLS connection established to 
> [192.0.2.1]:25:
>  TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
>  key-exchange X25519
>  server-signature RSA-PSS (2048 bits)
>  server-digest SHA256
>
> based on the the current state of the pull request.
>

___
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] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

[Achim Kraus]

Hello Viktor,

> Thanks to Todd Short, RFC7250 raw public keys should be available in
> OpenSSL ~3.2.  Applications that use unauthenticated opportunistic TLS,

Sounds great. Especially for IoT/constraint use-cases that's a real
benefit.

Just in the case, someone is interested, I asked a couple of months ago,
if https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10 has
some considerations about certificate types without a validation date.
See https://github.com/tlswg/tls-subcerts/issues/107

> The pull request  is
> still a work in progress, but complete enough for application
> integration testing.

I will try to test next week the DTLS interoperability with

Eclipse/tinydtls
Eclipse/Californium

best regards
Achim


Am 22.01.23 um 21:41 schrieb Viktor Dukhovni:

Thanks to Todd Short, RFC7250 raw public keys should be available in
OpenSSL ~3.2.  Applications that use unauthenticated opportunistic TLS,
employ DANE or have other ways to avoid X.509 certificates and make do
with raw peer public keys can avoid the overhead of receiving and
processing certificate chains.

The pull request  is
still a work in progress, but complete enough for application
integration testing.  Likely too late for OpenSSL 3.1 (in beta now), but
seems likely to land by 3.2.  The TODO items on the OpenSSL side are
at this point IMHO minor.  Review eyeballs of course always appreciated.

I have a Postfix branch with a reasonably complete implementation:

 # posttls-finger -c 
 posttls-finger: [192.0.2.1]:25: raw public key fingerprint=<...>
 posttls-finger: [192.0.2.1]:25: Matched DANE raw public key: 3 1 1 
<...>
 posttls-finger: Verified TLS connection established to 
[192.0.2.1]:25:
 TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519
 server-signature RSA-PSS (2048 bits)
 server-digest SHA256

based on the the current state of the pull request.



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

[TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

[Viktor Dukhovni]

Thanks to Todd Short, RFC7250 raw public keys should be available in
OpenSSL ~3.2.  Applications that use unauthenticated opportunistic TLS,
employ DANE or have other ways to avoid X.509 certificates and make do
with raw peer public keys can avoid the overhead of receiving and
processing certificate chains.

The pull request  is
still a work in progress, but complete enough for application
integration testing.  Likely too late for OpenSSL 3.1 (in beta now), but
seems likely to land by 3.2.  The TODO items on the OpenSSL side are
at this point IMHO minor.  Review eyeballs of course always appreciated.

I have a Postfix branch with a reasonably complete implementation:

# posttls-finger -c 
posttls-finger: [192.0.2.1]:25: raw public key fingerprint=<...>
posttls-finger: [192.0.2.1]:25: Matched DANE raw public key: 3 1 1 
<...>
posttls-finger: Verified TLS connection established to 
[192.0.2.1]:25:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519
server-signature RSA-PSS (2048 bits)
server-digest SHA256

based on the the current state of the pull request.

-- 
Viktor.

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