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=05%7C02%7Cjohn.mattsson%40ericsson.com%7C0a5a0e0174b640b9535508dc4f36c377%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638472343825594155%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=FKpJyM8%2BPLS7Wd1zNGlZoqhFFEQuLNNRzY8bsUQxegA%3D=0
and this PR:
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftlswg%2Frfc8447bis%2Fpull%2F55=05%7C02%7Cjohn.mattsson%40ericsson.com%7C0a5a0e0174b640b9535508dc4f36c377%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638472343825602619%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=nMQWHlYdoSNn9yNstiB2wNLQw5IZl%2BfHtf14UvOInd8%3D=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=05%7C02%7Cjohn.mattsson%40ericsson.com%7C0a5a0e0174b640b9535508dc4f36c377%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638472343825608404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=f3oRbu1I2ThwoKYyK%2BlyO1SDPOrsc3mXShCT%2BeBM3ls%3D=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=05%7C02%7Cjohn.mattsson%40ericsson.com%7C0a5a0e0174b640b9535508dc4f36c377%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638472343825613044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=EPub%2F4QhJkK3loRgrjTRvpvJ%2FHD7V2qMujI%2FUQW5HAo%3D=0
___
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] Next steps for Large Record Sizes for TLS and DTLS

[John Mattsson]

Sounds good to me. That makes the solution very simple.

The new extension would then work very similar to RFC 8449.

The ExtensionData of the "large_record_size" extension is

  uint32 LargeRecordSizeLimit;

When negotiated, all records protected with application_traffic_secret are 
changed:

OLD:
  struct {
  ContentType opaque_type = application_data; /* 23 */
  ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
  uint16 length;
  opaque encrypted_record[TLSCiphertext.length];
  } TLSCiphertext;

NEW:
  struct {
  uint32 length;
  opaque encrypted_record[TLSCiphertext.length];
  } TLSLargeCiphertext;

OLD:
  0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |0|0|1|C|S|L|E E|
   +-+-+-+-+-+-+-+-+
   | Connection ID |   Legend:
   | (if any,  |
   /  length as/   C   - Connection ID (CID) present
   |  negotiated)  |   S   - Sequence number length
   +-+-+-+-+-+-+-+-+   L   - Length present
   |  8 or 16 bit  |   E   - Epoch
   |Sequence Number|
   +-+-+-+-+-+-+-+-+
   | 16 bit Length |
   | (if present)  |
   +-+-+-+-+-+-+-+-+
NEW
  0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |0|0|1|C|S|L|E E|
   +-+-+-+-+-+-+-+-+
   | Connection ID |   Legend:
   | (if any,  |
   /  length as/   C   - Connection ID (CID) present
   |  negotiated)  |   S   - Sequence number length
   +-+-+-+-+-+-+-+-+   L   - Length present
   |  8 or 16 bit  |   E   - Epoch
   |Sequence Number|
   +-+-+-+-+-+-+-+-+
   | 32 bit Length |
   | (if present)  |
   +-+-+-+-+-+-+-+-+

From: TLS  on behalf of Martin Thomson 

Date: Wednesday, 20 March 2024 at 13:47
To: tls@ietf.org 
Subject: Re: [TLS] Next steps for Large Record Sizes for TLS and DTLS
In offline discussion l was convinced that a bigger change might be needed.  
The shifting is cute, but we might be able to do better.

This won't be wire compatible with the existing protocol, so maybe just embrace 
that and change the record header.  This would happen when switching from 
handshake protection to application data protection.  We can drop the version 
and content type and reclaim some of the savings for a longer length field.

On Wed, Mar 20, 2024, at 13:42, John Mattsson wrote:
> Hi,
>
> My summary from the TLS WG session yesterday:
>
> - Let’s adopt and figure out the final details later.
> - Show performance data.
> - Should be new extension, i.e., not used together with "record size
> limit".
> - The new extension should redefine the meaning of the uint16 length
> field in the TLSCiphertext to allow records larger than 2^16 bytes.
>
> Simple suggestion:
>
> In the new extension the client and server negotiate an uint8 value n.
> Client suggest a value n_max. Server selects n where 0 <= n <= n_max or
> rejects the extension. Agreeing on a value n means:
>
> - The length field in the record means 2^n * length bytes instead of
> length bytes. I.e., left shifted similar to the TCP window scale option.
> - The client and server are willing to receive records of size 2^n *
> (2^16 - 1) bytes.
> - Up to 2^n - 1 bytes of padding might be required.
> - AEAD limits are reduced with a factor 2^(n+2).
>
> Thought?
>
> Cheers,
> John Preuß Mattsson
>
> *From: *internet-dra...@ietf.org 
> *Date: *Tuesday, 5 March 2024 at 06:16
> *To: *John Mattsson , Michael Tüxen
> , Hannes Tschofenig ,
> Hannes Tschofenig , John Mattsson
> , Michael Tuexen 
> *Subject: *New Version Notification for
> draft-mattsson-tls-super-jumbo-record-limit-02.txt
> A new version of Internet-Draft
> draft-mattsson-tls-super-jumbo-record-limit-02.txt has been successfully
> submitted by John Preuß Mattsson and posted to the
> IETF repository.
>
> Name: draft-mattsson-tls-super-jumbo-record-limit
> Revision: 02
> Title:Large Record Sizes for TLS and DTLS
> Date: 2024-03-04
> Group:Individual Submission
> Pages:6
> URL:
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-mattsson-tls-super-jumbo-record-limit-02.txt=05%7C02%7Cjohn.mattsson%40ericsson.com%7C162b752f6c2948a0998a08dc48907011%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638465032406539633%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=OMjrxOxbWsSB2PBCpAi83OzLPPdnJEP%2F1lyBB1EvFLM%3D=0<https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-02.txt>
> Status:
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mattsson-tls-super-jumbo-record-limit%2F=05%7C02%7Cjohn.mattsson%40ericsson.com%7C162b752f6c2948a0998a08dc48907011%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C63846503240654

[TLS] Next steps for Large Record Sizes for TLS and DTLS

[John Mattsson]

Hi,

My summary from the TLS WG session yesterday:

- Let’s adopt and figure out the final details later.
- Show performance data.
- Should be new extension, i.e., not used together with "record size limit".
- The new extension should redefine the meaning of the uint16 length field in 
the TLSCiphertext to allow records larger than 2^16 bytes.

Simple suggestion:

In the new extension the client and server negotiate an uint8 value n. Client 
suggest a value n_max. Server selects n where 0 <= n <= n_max or rejects the 
extension. Agreeing on a value n means:

- The length field in the record means 2^n * length bytes instead of length 
bytes. I.e., left shifted similar to the TCP window scale option.
- The client and server are willing to receive records of size 2^n * (2^16 - 1) 
bytes.
- Up to 2^n - 1 bytes of padding might be required.
- AEAD limits are reduced with a factor 2^(n+2).

Thought?

Cheers,
John Preuß Mattsson

From: internet-dra...@ietf.org 
Date: Tuesday, 5 March 2024 at 06:16
To: John Mattsson , Michael Tüxen 
, Hannes Tschofenig , Hannes 
Tschofenig , John Mattsson 
, Michael Tuexen 
Subject: New Version Notification for 
draft-mattsson-tls-super-jumbo-record-limit-02.txt
A new version of Internet-Draft
draft-mattsson-tls-super-jumbo-record-limit-02.txt has been successfully
submitted by John Preuß Mattsson and posted to the
IETF repository.

Name: draft-mattsson-tls-super-jumbo-record-limit
Revision: 02
Title:Large Record Sizes for TLS and DTLS
Date: 2024-03-04
Group:Individual Submission
Pages:6
URL:  
https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-02.txt
Status:   
https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/
HTML: 
https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-02.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-mattsson-tls-super-jumbo-record-limit
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-super-jumbo-record-limit-02

Abstract:

   RFC 8449 defines a record size limit extension for TLS and DTLS
   allowing endpoints to negotiate a record size limit smaller than the
   protocol-defined maximum record size, which is around 2^14 bytes.
   This document specifies a TLS flag extension to be used in
   combination with the record size limit extension allowing endpoints
   to use a record size limit larger than the protocol-defined maximum
   record size, but not more than about 2^16 bytes.



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

Re: [TLS] Feedback on draft-tschofenig-tls-extended-key-update-01

[John Mattsson]

Hi,

I thought the old version was a quite good starting point. This new version 
seems significantly worse. I think it has three major problems:

1. It uses the application layer and therefore requires changes in the 
application layer. For many uses of TLS, it is not acceptable to change the 
application layer. I also don't think it makes sense to do the TLS key exchange 
on the application layer. As Dennis Jacksson writes: " This seems rather 
complex and likely to go wrong. The original version of this draft where the 
key exchange was carried in the extended key update message seems much simpler 
to implement and easier to analyse". I would add that I would not want my keys 
to leave the TLS library. Authentication on the application layer makes sense 
for web applications using HTTP/2 and QUIC where the endpoints might need to 
correlate the certificate request with the application-level event that 
triggered it. For infrastructure use of TLS/DTLS/QUIC I think reauthentication 
on the transport layer is a must.

2. As pointed out by Dennis Jacksson, it uses static-ephemeral key exchange 
instead of ephemeral-ephemeral key exchange, which does not at all give the 
same security properties. I think all requests have been for 
ephemeral-ephemeral key exchange.

3. I don't see the need for HPKE. All discussions, specifications, and 
deployments of PQC KEMs in TLS 1.3 and DTLS 1.3 uses the ordinary 
"KeyShareEntry". Replacing the existing key exchange mechanism in TLS with the 
public key encryption mechanism HPKE. This seems to add a lot of code to an TLS 
implementation already doing quantum-resistant key exchange in the initial 
handshake.

I think a solution to do post-handshake ephemeral-ephemeral key exchange as 
well as mutual post-handshake authentication on the TLS/DTLS/QUIC layer would 
be very welcome. I think ephemeral-ephemeral key exchange as well as not using 
the application layer should be requirements.

I think frequent rekeying with ephemeral-ephemeral key exchange is a must for 
long-lived interfaces. This has for a long time been an established 
requirement. Typical requirements are 1 hour of 100 GB in IPsec and 1 hour or 1 
GB in SSH. Note that there is no problem with TLS 1.3 when you can frequently 
setup new connection with psk_dhe_ke. Discussing with Eric Rescorla and Martin 
Thomson in the past, they suggested that this was the way forward. It would be 
interesting to hear if there are more use cases than RFC 6083 where frequently 
setting up a new connection with psk_dhe_ke is problematic. I expect there is.

Long-term, I think QUIC is much more important than TLS and DTLS. The telecom 
sector work in 10-year generation (4G, 5G, 6G). In 6G, expected to be 
standardized in 2029, I expect most use of TCP, SCTP, TLS, and DTLS to be 
replaced by QUIC.

The citation (R13) from ANSSI only talks about rekeying. Equally important is 
R12 which says that

"If available, one shall activate the PFS property in IKEv2 second phase" 
(a.k.a “quick mode”) using a Diffie-Hellman key exchange or its elliptic curve 
variant."

Cheers,
John Preuß Mattsson

From: TLS  on behalf of Dennis Jackson 

Date: Tuesday, 19 March 2024 at 02:38
To: TLS List 
Subject: [TLS] Feedback on draft-tschofenig-tls-extended-key-update-01
A new version of this draft was published a few weeks ago with an
entirely new design. Unless I missed it, the new version hasn't yet been
discussed on the TLS list and I was unaware of the changes until I came
to prepare for the meeting. I have quite a few concerns - I'm sorry to
bring them up so close to the meeting.

Firstly, the draft as specified does not achieve the claimed security goal:

> Security Considerations:
>
> To perform public key encryption the sender needs to have access to
> the public key of the recipient. This document makes the assumption
> that the public key in the exchanged end-entity certificate can be
> used with the HPKE KEM. The use of HPKE, and the recipients long-term
> public key, in the ephemeral-static Diffie-Hellman exchange provides
> perfect forward secrecy of the ongoing connection and demonstrates
> possession of the long-term secret key.

An ephemeral-static Diffie-Hellman exchange does not provide forward
secrecy. If the attacker can compromise the endpoint with the static
public key, they can decrypt all previously transmitted ciphertexts to
this peer and so recover all past keys, violating forward secrecy. This
wasn't an issue in the old draft where ephemeral-ephemeral DH exchanges
were used.

Secondly, I think there is some confusion about what forward secrecy is.
Forward secrecy means that compromise in the future will not enable the
decryption of past messages. The existing KeyUpdate mechanism in TLS1.3
achieves forward secrecy by ratcheting forwards the used keys and
throwing away the old ones. So no changes are required to TLS1.3 to
enjoy forward secrecy in long-lived connections, just do the existing
key update and be sure to 

Re: [TLS] Working Group Last Call for ECH

[John Mattsson]

Hi,

   "ECH is not in itself sufficient to protect the identity of the
   server.  The target domain may also be visible through other
   channels, such as plaintext client DNS queries or visible server IP
   addresses.  However, DoH [RFC8484] and DPRIVE [RFC7858] [RFC8094]
   provide mechanisms for clients to conceal DNS lookups from network
   inspection, and many TLS servers host multiple domains on the same IP
   address.  Private origins may also be deployed behind a common
   provider, such as a reverse proxy.  In such environments, the SNI
   remains the primary explicit signal used to determine the server's
   identity."

This text only discusses that the identity of the server may be revealed by
"other channels". I strongly think the document needs to mention that the
identity of the server may also be reveled by the unencrypted information
in the ServerHello. In particular a reused KeyShare is problematic.

Suggested addition:

The identity of the server may also be reveled by the unencrypted information
in the ServerHello. Most of the current information in ServerHello is not 
unique.
The exception is KeyShare, which if reused provides a unique identifier of the 
server.

Cheers,
John Preuß Mattsson
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[John Mattsson]

Ship it.

From: TLS  on behalf of Salz, Rich 

Date: Tuesday, 12 March 2024 at 16:00
To: Sean Turner , TLS List 
Subject: Re: [TLS] Working Group Last Call for SSLKEYLOG File
> 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.

No notes.

Ship it.

___
TLS mailing list
TLS@ietf.org
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=05%7C02%7Cjohn.mattsson%40ericsson.com%7C4d888a8f3f29471ae23d08dc42a52bbd%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638458524368830039%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=sLCz0150gmqtACov7UYrMN07ya%2FzW89ZCvtFM9spdg4%3D=0
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ML-KEM key agreement for TLS 1.3

[John Mattsson]

True, Classic McEliece is not possible with the current length restrictions. 
FrodoKEM does not seem to get any open-access standard. Cryptographic algorithm 
standards behind paywalls are a cybersecurity risk. I have seen several 
implementations that claim to follow a paywalled standard but in reality seem 
to have been implemented from Wikipidia and skip essential security 
considerations and requirements. If any European country want to use FrodoKEM, 
they should drive FrodoKEM in CFRG, or publish the specification themselves. An 
alternative conservative solution would be to combine ML-KEM with HQC/BIKE and 
x25519.

Secret and propriatary security protocols are much much worse. Rob Sayre 
mentioned iMessage in an earlier post. I think Apple is the worst offender of 
deploying secret and propriatary protocols to billions of users. The distance 
between their privacy marketing (privacy is a human right) and what is 
delivered by the secret iMessage are AirDrop protocols is astonishing to say 
the least.
https://www.rollingstone.com/politics/politics-features/whatsapp-imessage-facebook-apple-fbi-privacy-1261816/
https://arstechnica.com/security/2024/01/hackers-can-id-unique-apple-airdrop-users-chinese-authorities-claim-to-do-just-that/

Cheers,
John Preuß Mattsson

From: TLS  on behalf of Ilari Liusvaara 

Date: Wednesday, 6 March 2024 at 17:46
To: TLS@ietf.org 
Subject: Re: [TLS] ML-KEM key agreement for TLS 1.3
On Wed, Mar 06, 2024 at 04:25:16PM +, John Mattsson wrote:
> I think TLS should register all algorithm variants standardized by
> NIST. That means ML-KEM-512, ML-KEM-768, and ML-KEM-1024. And in
> the future a subset of HQC/BIKE/Classic McEliece.

Just as note, supporting Classic McEliece is not possible at all due to
the key size exceeding hard TLS 1.3 limit.

Even FrodoKEM, which seems to be quite widely viewed as "next step up"
from likes of ML-KEM, has painfully large keys. But at least those do
not bust any hard limits.




-Ilari

___
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] ML-KEM key agreement for TLS 1.3

[John Mattsson]

Hi,

Bas Westerbaan wrote:
>I think it'd very bad if we'd have a codepoint for pure ML-KEM before we have 
>a codepoint for an ML-KEM
>hybrid. I think that's up to the designated experts of the IANA registry.

Agree. We plan to use hybrid key exchange as the default, but would like to 
offer pure ML-KEM to customers that want that. As Deirdre states hybrid are a 
big 'maybe' at best for 'hybrid solutions'. Being able to offer CNSA 2.0 
compliant TLS is essential for many companies. I weould like to see standards 
track ML-KEM as well as standards track ML-DSA just like in IPSECME and LAMPS.

Deirdre Connolly wrote:
>My current draft does not include ML-KEM-512, mostly because there seems to be 
>alignment around
>ML-KEM-768 being ~equivalent to say X25519 or P-256 ECDH in terms of security 
>level. I'm not married
>strongly to excluding it but that was kind of the thinking.

I don't think there is any such alignment. NIST latest assessment is that “the 
most plausible values for the practical security of Kyber512 against known 
attacks are significantly higher than that of AES128”. Ericsson agrees with 
that assessment and so do Sophie Schmieg (Google).
https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/faq/Kyber-512-FAQ.pdf
https://keymaterial.net/2023/11/18/kyber512s-security-level/

Cheers,
John Preuß Mattsson

From: TLS  on behalf of Deirdre Connolly 

Date: Thursday, 7 March 2024 at 05:37
To: Orie Steele 
Cc: Bas Westerbaan , TLS@ietf.org 

Subject: Re: [TLS] ML-KEM key agreement for TLS 1.3
> Isn't support for the component mandatory to support the hybrid anyway?

Strictly speaking, not necessarily: I could see support for X-Wing or another 
hybrid key agreement as a standalone unit, both from a software dependency 
perspective and protocol API perspective. Whether that works in the long term 
that also supports the standalone component algorithms, that's another question

On Wed, Mar 6, 2024, 11:30 PM Orie Steele  wrote:
Does the argument about hybrid code points first generalize to all PQ Code 
points?

Is it equally true of hybrid signatures?

I don't understand why registering composite components first wouldn't be 
assumed.

Isn't support for the component mandatory to support the hybrid anyway?

Let's assume CRQC drops tomorrow, why did we not register ML-KEM first?

Assume it never drops, you still needed to implement ML-KEM to use the hybrid.

If the goal is to prohibit ML-KEM without a traditional component, just 
register it as prohibited.

OS

On Wed, Mar 6, 2024, 10:10 PM Bas Westerbaan 
mailto:40cloudflare@dmarc.ietf.org>> 
wrote:
Back to the topic at hand. I think it'd very bad if we'd have a codepoint for 
pure ML-KEM before we have a codepoint for an ML-KEM hybrid. Process wise, I 
think that's up to the designated experts of the IANA registry.

Best,

 Bas


On Wed, Mar 6, 2024 at 3:16 AM Deirdre Connolly 
mailto:durumcrustu...@gmail.com>> wrote:
I have uploaded a preliminary version of ML-KEM for TLS 
1.3  
and have a more fleshed 
out
 version to be uploaded when datatracker opens. It is a straightforward new 
`NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a very 
similar style to 
-hybrid-design.

It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0 compatible) 
ready to go when users are ready to use them.

Cheers,
Deirdre
___
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

Re: [TLS] ML-KEM key agreement for TLS 1.3

[John Mattsson]

I think TLS should register all algorithm variants standardized by NIST. That 
means ML-KEM-512, ML-KEM-768, and ML-KEM-1024. And in the future a subset of 
HQC/BIKE/Classic McEliece.

I think the TLS discussions are way too focused on a single ephemeral key 
exchange. A growing use of TLS is for mutually authenticated interfaces. When 
IPsec is used, rekeying is typically done with ephemeral key exchange every 1 
hour or 100 GB following ANSSI requirements. The telecom industry would like to 
keep that practice when TLS/DTLS/QUIC is used instead. In TLS 1.3 that means 
resumption with psk_dhe_ke. I don’t think you need to use the same algorithm in 
the initial handshake and the resumption. You can e.g., use ML-KEM-1024 + 
x25519 in the initial handshake and then ML-KEM-512 in resumption. You could 
also use McEliece initially and then ML-KEM. I think you could even use ML-KEM 
+ x25519 in the initial handshake and then x25519 during resumption. I think 
these choices should be left to the application.

Cheers,
John Preuß Mattson

Sent from Outlook for iOS<https://aka.ms/o0ukef>

From: TLS  on behalf of John Mattsson 

Sent: Wednesday, March 6, 2024 4:57:10 PM
To: Deirdre Connolly 
Cc: TLS@ietf.org 
Subject: Re: [TLS] ML-KEM key agreement for TLS 1.3


Thanks Deirdre,



I would like to use hybrid but I strongly believe that registering things as 
standalone NamedGroups and then let TLS negotiate which combinations to  use is 
the right one long-term. This is the approch chosen be IKEv2.



- As EKR pointed out the word "fully" would need explanation.



- We align with [hybrid] except that instead of joining ECDH options

  with a KEM, we just have the KEM as a NamedGroup.



  I don't understand. We align with hybrid by not being hybrid?



- encapsulated shared secret ciphertext



Maybe shared secret encapsulated in the ciphertext?



Cheers,

John



From: TLS  on behalf of Eric Rescorla 
Date: Wednesday, 6 March 2024 at 16:12
To: Deirdre Connolly 
Cc: TLS@ietf.org 
Subject: Re: [TLS] ML-KEM key agreement for TLS 1.3

Deirdre, thanks for submitting this. Can you say what the motivation is for 
being "fully post-quantum" rather than hybrid?



Thanks,

-Ekr







On Tue, Mar 5, 2024 at 6:16 PM Deirdre Connolly 
mailto:durumcrustu...@gmail.com>> wrote:

I have uploaded a preliminary version of ML-KEM for TLS 
1.3<https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/>  
and have a more fleshed 
out<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-864093ca9ffba626=1=c11b4b5f-f194-49c4-a720-c34e25cc52c2=https%3A%2F%2Fgithub.com%2Fdconnolly%2Fdraft-tls-mlkem-key-agreement>
 version to be uploaded when datatracker opens. It is a straightforward new 
`NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a very 
similar style to 
-hybrid-design<https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/>.



It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0 compatible) 
ready to go when users are ready to use them.



Cheers,

Deirdre

___
TLS mailing list
TLS@ietf.org<mailto: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] ML-KEM key agreement for TLS 1.3

[John Mattsson]

Thanks Deirdre,

I would like to use hybrid but I strongly believe that registering things as 
standalone NamedGroups and then let TLS negotiate which combinations to  use is 
the right one long-term. This is the approch chosen be IKEv2.

- As EKR pointed out the word "fully" would need explanation.

- We align with [hybrid] except that instead of joining ECDH options
  with a KEM, we just have the KEM as a NamedGroup.

  I don't understand. We align with hybrid by not being hybrid?

- encapsulated shared secret ciphertext

Maybe shared secret encapsulated in the ciphertext?

Cheers,
John

From: TLS  on behalf of Eric Rescorla 
Date: Wednesday, 6 March 2024 at 16:12
To: Deirdre Connolly 
Cc: TLS@ietf.org 
Subject: Re: [TLS] ML-KEM key agreement for TLS 1.3
Deirdre, thanks for submitting this. Can you say what the motivation is for 
being "fully post-quantum" rather than hybrid?

Thanks,
-Ekr



On Tue, Mar 5, 2024 at 6:16 PM Deirdre Connolly 
mailto:durumcrustu...@gmail.com>> wrote:
I have uploaded a preliminary version of ML-KEM for TLS 
1.3  
and have a more fleshed 
out
 version to be uploaded when datatracker opens. It is a straightforward new 
`NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a very 
similar style to 
-hybrid-design.

It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0 compatible) 
ready to go when users are ready to use them.

Cheers,
Deirdre
___
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] FW: New Version Notification for draft-mattsson-tls-super-jumbo-record-limit-01.txt

[John Mattsson]

Thanks Ben,

>I confess that my first impression was "eww, extensions with side effects on
>other extensions, that sounds super finicky to implement correctly".
>
>But actually reading in further, it seems more that the guiding principle is
>instead "only have one way to do a thing", in this case to communicate
>the maximum record size an endpoint is prepared to receive.
>That said, it's still changing the semantics of an existing field, which
>incurs a requirement to survey the compatibility with existing
>implementations.  I see that RFC 8449 does carve out a way for endpoints
>to send larger values if "explicitly allowed by such a future version or
>extension.  A server MUST NOT enforce this restriction" so in theory we
>should be okay, but we still need to actually check.

That is indeed a good thing to check and discuss. The alternative is of course 
to define a new extension instead.

>I also note that the semantics of record_size_limit per RFC 8449 are to
>apply to the plaintext length, so I think it actually is weird and
>overly complicated for your draft to propose that the negotiated length
>will now be of the ciphertext length.

Thanks for spotting this. That is just a mistake caused by the extension in the 
-00 version of the draft having the meaning “I am prepared records with 
ciphertexts of length 2^16 - 1”. If RFC 8449 is used, the semantics should not 
be changed. We will fix this in the next version.

Cheers,
John Preuß Mattsson

From: Benjamin Kaduk 
Date: Friday, 1 March 2024 at 20:42
To: John Mattsson 
Cc: TLS@ietf.org 
Subject: Re: [TLS] FW: New Version Notification for 
draft-mattsson-tls-super-jumbo-record-limit-01.txt
Hi John,

I confess that my first impression was "eww, extensions with side effects on
other extensions, that sounds super finicky to implement correctly".

But actually reading in further, it seems more that the guiding principle is
instead "only have one way to do a thing", in this case to communicate
the maximum record size an endpoint is prepared to receive.
That said, it's still changing the semantics of an existing field, which
incurs a requirement to survey the compatibility with existing
implementations.  I see that RFC 8449 does carve out a way for endpoints
to send larger values if "explicitly allowed by such a future version or
extension.  A server MUST NOT enforce this restriction" so in theory we
should be okay, but we still need to actually check.

I also note that the semantics of record_size_limit per RFC 8449 are to
apply to the plaintext length, so I think it actually is weird and
overly complicated for your draft to propose that the negotiated length
will now be of the ciphertext length.

-Ben

On Mon, Feb 26, 2024 at 08:59:20AM +, John Mattsson wrote:
>Hi,
>
>
>
>We just submitted version -01 of “Large Record Sizes for TLS and DTLS”.
>Michael Tüxen is a new co-author, the extension has been renamed to the
>more mundane “large_record_size" and is now a flag extension. The flag
>extension is now used together with "record_size_limit" to allow
>negotiation of maximum record size, not just a fixed 2^16 – 1 bytes.
>
>
>
>The use for record sizes larger than 2^14 has been discussed in TSVWG for
>use in DTLS over SCTP and DTLS in SCTP. Large record sizes would be
>beneficial in several of the discussed solutions to remove limitation or
>to increase performance.
>
>
>
>We would like to present draft-mattsson-tls-super-jumbo-record-limit-01 in
>Brisbane.
>
>
>
>Cheers,
>
>    John Preuß Mattsson
>
>
>
>From: internet-dra...@ietf.org 
>Date: Monday, 26 February 2024 at 09:34
>To: John Mattsson , Michael Tüxen
>, Hannes Tschofenig ,
>Hannes Tschofenig , John Mattsson
>, Michael Tuexen 
>Subject: New Version Notification for
>draft-mattsson-tls-super-jumbo-record-limit-01.txt
>
>A new version of Internet-Draft
>draft-mattsson-tls-super-jumbo-record-limit-01.txt has been successfully
>submitted by John Preuß Mattsson and posted to the
>IETF repository.
>
>Name: draft-mattsson-tls-super-jumbo-record-limit
>Revision: 01
>Title:Large Record Sizes for TLS and DTLS
>Date: 2024-02-26
>Group:Individual Submission
>Pages:6
>URL:
>
> [1]https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.txt
>Status:
>
> [2]https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/
>HTML:
>
> [3]https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.html
>HTMLized:
>
> [4]https://datatracker.ietf.org/doc/html/draft-mat

[TLS] FW: New Version Notification for draft-mattsson-tls-super-jumbo-record-limit-01.txt

[John Mattsson]

Hi,

We just submitted version -01 of “Large Record Sizes for TLS and DTLS”. Michael 
Tüxen is a new co-author, the extension has been renamed to the more mundane 
“large_record_size" and is now a flag extension. The flag extension is now used 
together with "record_size_limit" to allow negotiation of maximum record size, 
not just a fixed 2^16 – 1 bytes.

The use for record sizes larger than 2^14 has been discussed in TSVWG for use 
in DTLS over SCTP and DTLS in SCTP. Large record sizes would be beneficial in 
several of the discussed solutions to remove limitation or to increase 
performance.

We would like to present draft-mattsson-tls-super-jumbo-record-limit-01 in 
Brisbane.

Cheers,
John Preuß Mattsson

From: internet-dra...@ietf.org 
Date: Monday, 26 February 2024 at 09:34
To: John Mattsson , Michael Tüxen 
, Hannes Tschofenig , Hannes 
Tschofenig , John Mattsson 
, Michael Tuexen 
Subject: New Version Notification for 
draft-mattsson-tls-super-jumbo-record-limit-01.txt
A new version of Internet-Draft
draft-mattsson-tls-super-jumbo-record-limit-01.txt has been successfully
submitted by John Preuß Mattsson and posted to the
IETF repository.

Name: draft-mattsson-tls-super-jumbo-record-limit
Revision: 01
Title:Large Record Sizes for TLS and DTLS
Date: 2024-02-26
Group:Individual Submission
Pages:6
URL:  
https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.txt
Status:   
https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/
HTML: 
https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-mattsson-tls-super-jumbo-record-limit
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-super-jumbo-record-limit-01

Abstract:

   RFC 8449 defines a record size limit extension for TLS and DTLS
   allowing endpoints to negotiate a record size limit smaller than the
   protocol-defined maximum record size, which is around 2^14 bytes.
   This document specifies a TLS flag extension to be used in
   combination with the record size limit extension allowing endpoints
   to use a record size limit larger than the protocol-defined maximum
   record size, but not more than about 2^16 bytes.



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

[TLS] FW: New Version Notification for draft-mattsson-tls-compact-ecc-06.txt

[John Mattsson]

Hi,

I recently posted -06 to keep the document alive. The only thing that has 
happened since I posted 
https://mailarchive.ietf.org/arch/msg/tls/H3k8oMzu023qgniSPY3P7cspDME/
is that Hannes has been added as co-author. When this was presented, the 
comments were that this should be adopted iff someone plans to implement, I 
agree with that.

Cheers,
John Preuß Mattsson

From: internet-dra...@ietf.org 
Date: Friday, 23 February 2024 at 13:40
To: John Mattsson , Hannes Tschofenig 
, John Mattsson 
Subject: New Version Notification for draft-mattsson-tls-compact-ecc-06.txt
A new version of Internet-Draft draft-mattsson-tls-compact-ecc-06.txt has been
successfully submitted by John Preuß Mattsson and posted to the
IETF repository.

Name: draft-mattsson-tls-compact-ecc
Revision: 06
Title:Compact ECDHE and ECDSA Encodings for TLS 1.3
Date: 2024-02-23
Group:Individual Submission
Pages:9
URL:  https://www.ietf.org/archive/id/draft-mattsson-tls-compact-ecc-06.txt
Status:   https://datatracker.ietf.org/doc/draft-mattsson-tls-compact-ecc/
HTML: https://www.ietf.org/archive/id/draft-mattsson-tls-compact-ecc-06.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-mattsson-tls-compact-ecc
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-compact-ecc-06

Abstract:

   The encodings used in the ECDHE groups secp256r1, secp384r1, and
   secp521r1 and the ECDSA signature algorithms ecdsa_secp256r1_sha256,
   ecdsa_secp384r1_sha384, and ecdsa_secp521r1_sha512 have significant
   overhead and the ECDSA encoding produces variable-length signatures.
   This document defines new optimal fixed-length encodings and
   registers new ECDHE groups and ECDSA signature algorithms using these
   new encodings.  The new encodings reduce the size of the ECDHE groups
   with 33, 49, and 67 bytes and the ECDSA algorithms with an average of
   7 bytes.  These new encodings also work in DTLS 1.3 and are
   especially useful in cTLS.



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

Re: [TLS] New Liaison Statement, "Quantum Safe Cryptographic Protocol Inventory"

[John Mattsson]

Hi,
Even if JOSE WG is not included in the recipients, I looked at this LS and TR 
103 619 that the LS refer to. In addition to the requested information, I think 
IETF should send ETSI CYBER comments on TR 103 619 that the LS is based on. My 
suggestions:

---
IETF kindly suggests that ETSI CYBER makes the following updates/corrections in 
the next revision of TR 103 619:

  *   IETF suggests that ETSI CYBER uses the established term Cryptanalytically 
Relevant Quantum Computers (CRQCs). It is important that readers understand 
that there is a huge difference between current quantum computers and CRQCs.

  *   IETF suggests that ETSI CYBER uses another term than “classical 
cryptography”. Quantum-resistant cryptography like ML-KEM and ML-DSA runs on 
classical computers and code-based cryptography and hash-based cryptography was 
invented in the late 1970s.

  *   As ETSI CYBER mentions that Quantum Key Distribution is not vulnerable to 
attacks from CRQCs, ETSI CYBER should also mention that Quantum Key 
Distribution is neither a practical nor a secure solution [1-2].



  *   IETF advice ETSI CYBER to update and correct the information regarding 
symmetric cryptography. The idea that symmetric cryptography will be 
practically affected by CRQCs is now seen as a misconception. The “bits of 
security” concept does not work with algorithms that are not parallelizable and 
NIST is therefore transitioning to quantum-resistant security levels based on 
symmetric algorithms where level 1 is equivalent with AES-128, level 2 is 
SHA-256, etc. [3]. UK government assesses that “symmetric algorithms with at 
least 128-bit keys (such as AES) can continue to be used” [4]. While classical 
supercomputers might be able to brute force AES-128 around the year 2090 [5-6], 
a huge cluster of one billion CRQCs (according to one estimate costing one 
billion USD each) would take a million years of uninterrupted calculation to 
find a single AES-128 key. Algorithms with quadratic (푛2) speedup like Grover’s 
algorithm (which is proven to be optimal) will not provide any practical 
quantum advantage for breaking symmetric cryptography and likely not for any 
other problems [7-8].



  *   The name of the X.509 field is “Subject Public Key Info”, not “Subject 
Key Info”.

[1] ANSSI, BSI, Netherlands NCSA, Swedish NCSA, “Position Paper on Quantum Key 
Distribution”
https://cyber.gouv.fr/actualites/uses-and-limits-quantum-key-distribution
[2] NSA, “Quantum Key Distribution (QKD) and Quantum Cryptography (QC)”
https://www.nsa.gov/Cybersecurity/Quantum-Key-Distribution-QKD-and-Quantum-Cryptography-QC/
[3] NIST, “Comments Requested on Three Draft FIPS for Post-Quantum Cryptography”
https://csrc.nist.gov/news/2023/three-draft-fips-for-post-quantum-cryptography
[4] UK NCSC, “Next steps in preparing for post-quantum cryptography”
https://www.ncsc.gov.uk/whitepaper/next-steps-preparing-for-post-quantum-cryptography
[5] CRYPTEC, ”Cryptographic Technology Evaluation Committee Activity Report”
https://www.cryptrec.go.jp/symposium/2023_cryptrec-eval.pdf
[6] CRYPTEC, ”Japan CRYPTREC Activities on PQC”
https://events.btq.li/Japan_CRYPTREC_Activities_on_PQC_Shiho_Moriai.pdf
[7] Hoefler, Häner, Troyer, “Disentangling Hype from Practicality: On 
Realistically Achieving Quantum Advantage”
https://cacm.acm.org/magazines/2023/5/272276-disentangling-hype-from-practicality-on-realistically-achieving-quantum-advantage/fulltext
[8] Babbush, McClean, Newman, Gidney, Boixo, Neven, “Focus beyond Quadratic 
Speedups for Error-Corrected Quantum Advantage”
https://arxiv.org/pdf/2011.04149.pdf
---
Cheers,
John Preuß Mattsson
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-keylogfile-00.txt

[John Mattsson]

Hi,

I just reviwed the whole document and I agree it is ready for WGLC. I just 
found very minor things.

I think it would be good to inform the reader that with knowledge of 
"_TRAFFIC_SECRET_N", all subsequent application data traffic secret can be 
derived without any additional information. Otherwise reader might think they 
need to log all the traffic secrets.

I made a PR while revieing. Use as you wish.

https://github.com/tlswg/sslkeylogfile/pull/6

Cheers,
John Preuß Mattsson

From: TLS  on behalf of Martin Thomson 

Date: Monday, 29 January 2024 at 22:59
To: Salz, Rich , tls@ietf.org 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-keylogfile-00.txt
On Fri, Jan 26, 2024, at 02:36, Salz, Rich wrote:
>> Internet-Draft draft-ietf-tls-keylogfile-00.txt is now available. It is a 
>> work
>> item of the Transport Layer Security (TLS) WG of the IETF.
>
> I assume this just documents the current format and that therefore
> existing implementations (OpenSSL and Wireshark come to mind) just work.

That's exactly right.  I'm not looking to add features.

> If that assumption is true, this seems ready for WGLC.

I agree.

___
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] NIST: Addressing Visibility Challenges with TLS 1.3 within the Enterprise

[John Mattsson]

Thank you for sharing, Rich!

I must express my profound disappointment regarding the project's failure to 
publish received comments even after 8 months (to the best of my knowledge). 
It's concerning that while the project's status indicates "Soliciting 
Comments," it has proceeded to publish another specification. This not only 
questions the validity of the project but also reflects very poorly on NIST. Is 
the project merely a marketing ploy for the collaborating vendors?

I want to emphasize that this critique is not directed at the entirety of NIST. 
I think the cryptography division of NIST is doing a good job of transparency 
and openness, and I have often defended their practices in online forums.

GSMA and 3GPP have engaged in discussions regarding TLS visibility, reaching a 
consensus that encryption with ephemeral key exchange is imperative. Any 
visibility requirements must be addressed within the endpoints themselves. 
Furthermore, the telecom industry has initiated talks on standardizing virtual 
taps within endpoints. It is crucial that any visibility measures are 
authenticated, and the scope of accessible data is minimized.

Cheers,
John Preuß Mattsson

From: TLS  on behalf of Salz, Rich 

Date: Wednesday, 31 January 2024 at 16:22
To: tls@ietf.org 
Subject: [TLS] NIST: Addressing Visibility Challenges with TLS 1.3 within the 
Enterprise
Some may find this useful.  “The National Cybersecurity Center of Excellence 
(NCCoE) invites you to 
share your 
feedback on 
preliminary draft Special Publication 1800-37, Addressing Visibility Challenges 
with TLS 1.3 within the 
Enterprise. 
The public comment period is open now until April 1, 2024.  “

https://content.govdelivery.com/accounts/USNIST/bulletins/380cbe4


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

Re: [TLS] I-D Action: draft-ietf-tls-semistatic-dh-01.txt

[John Mattsson]

Hi,

The use of the semi-static in this document seems strange to me. The term 
"semi-static" is just describing the lifetime of the key, which could be 
measured in time or in the number of times the key is used.

Krawczyk defines a semi-static key as a short term cachable key
"These choices mainly refer to the properties of g s , such as specifying the 
method for authenticating this key and whether it is static, semi-static or 
non-static key (roughly correspond to a long-term g s as in the case of DH 
certificate, a short term cacheable key, or a one-time key as discussed in the 
optimization section above and in more detail in Section 4.4)."
https://eprint.iacr.org/2015/978.pdf

Madded describes semi-static as the same thing as semi-ephemeral
"Signal adopts a middle ground and has Bob publish a “semi-static” (or 
“semi-ephemeral” depending on your point of view) signed prekey along with a 
bundle of normal prekeys."
https://neilmadden.blog/2021/04/08/from-kems-to-protocols/

Semi-static in draft-ietf-tls-semistatic-dh seems to describe how the key is 
used. Also the keys in draft-ietf-tls-semistatic-dh seems to be as static as 
the RSA/ECDSA keys used for authentication in TLS. I think the terminology 
should be changed.

The term "semi-ephemeral" used by Madden would be a better term for the key 
shares in TLS 1.3 if TLS continues to allow reuse of key shares.

Cheers,
John Preuß Mattsson

From: TLS  on behalf of Christopher Wood 

Date: Sunday, 8 March 2020 at 00:57
To: tls@ietf.org 
Cc: i-d-annou...@ietf.org 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-semistatic-dh-01.txt
Among editorial changes, this update removes key schedule injection. The
resulting design still requires formal analysis, though we don’t
expect much more to change at this point. Please have a look and provide
feedback.

Thanks!
Chris (no hat)

On 7 Mar 2020, at 15:45, internet-dra...@ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Transport Layer Security WG of the
> IETF.
>
> Title   : Semi-Static Diffie-Hellman Key Establishment
> for TLS 1.3
> Authors : Eric Rescorla
>   Nick Sullivan
>   Christopher A. Wood
>Filename: draft-ietf-tls-semistatic-dh-01.txt
>Pages   : 7
>Date: 2020-03-07
>
> Abstract:
>TLS 1.3 [RFC8446] specifies a signed Diffie-Hellman exchange
> modelled
>after SIGMA [SIGMA].  This design is suitable for endpoints whose
>certified credential is a signing key, which is the common
> situation
>for current TLS servers.  This document describes a mode of TLS 1.3
>in which one or both endpoints have a certified DH key which is
> used
>to authenticate the exchange.
>
> Note to Readers
>
>Source for this draft and an issue tracker can be found at
>
> https://protect2.fireeye.com/v1/url?k=a6a7efb5-fa2dcd5f-a6a7af2e-0cc47ad93e32-303b324aa958a9d1=1=d0bed61a-0ab1-4148-8d7b-c1a8b402b327=https%3A%2F%2Fgithub.com%2Fekr%2Fdraft-rescorla-tls13-semistatic-dh
>
> (https://protect2.fireeye.com/v1/url?k=b5703be7-e9fa190d-b5707b7c-0cc47ad93e32-757125fb0f4def0a=1=d0bed61a-0ab1-4148-8d7b-c1a8b402b327=https%3A%2F%2Fgithub.com%2Fekr%2Fdraft-rescorla-tls13-semistatic-dh).
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-semistatic-dh/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tls-semistatic-dh-01
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-semistatic-dh-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-semistatic-dh-01
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> 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

Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?

[John Mattsson]

On Wed, Nov 29, 2023, at 11:21, Eric Rescorla wrote:
> I agree that it would be good to require replay protection at this
> time. Perhaps we should just publish a short RFC requiring it.

I think that is a good idea and I would be happy to help with such an RFC. 
Either one mandating DTLS replay protection or one mandating replay protection 
at some layer.

I think it would maybe make most sense to mandate DTLS replay protection. 
Applications wanting to turn off DTLS replay protection should be required to 
register an extension.

I made a PR to RFC8446bis that shortly describes that 0-RTT replay can be used 
for server tracking.
https://github.com/tlswg/tls13-spec/pull/1334/files

Cheers,
John Preuß Mattsson

From: Martin Thomson 
Date: Wednesday, 29 November 2023 at 06:02
To: Eric Rescorla , John Mattsson 
Cc: tls@ietf.org 
Subject: Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?
One thing that I observed when we were doing QUIC was that the canonical 
reference for how to do this sort of anti-replay is a section that is buried 
deep in an IPsec RFC.  Perhaps that short RFC is an opportunity to also 
document the process in a way that can be a reference to other documents.  
(That's a slightly longer RFC, but still fairly short; Section 3.4.3 of RFC 
4303 is just two pages in the old measure.)

On Wed, Nov 29, 2023, at 11:21, Eric Rescorla wrote:
> I agree that it would be good to require replay protection at this
> time. Perhaps we should just publish a short RFC requiring it.
>
> -Ekr
>
>
> On Tue, Nov 28, 2023 at 3:00 PM John Mattsson
>  wrote:
>> Hi,
>> __ __
>> Lack of replay also enables tracking of client and server. If the client or 
>> server is a device moving together with a person this enables tracking of 
>> the person.
>> __ __
>> An attacker can store a message from one location and then replay it to the 
>> client or server in another location. If the client or server accept the 
>> replayed message, the attacker knows that the device in the two locations 
>> are one and the same. It is best practice to assume that an attacker can 
>> always detect if a message was accepted. If the client or server send a 
>> response to the replayed message (like a replayed client authentication 
>> request) this is trivial.
>> __ __
>> This is different from the attack described in Section C.4 “Client and 
>> Server Tracking Prevention” of RFC8446bis, which describes the client 
>> reusing a ticket. A network attacker mounting a replay attack are described 
>> in Section 8 of RFC8446bis. I think a sentence or two should be added to 
>> Section C.4 to describe that a network attacker mounting a replay attack can 
>> be used for server tracking and that the mitigations in Section 8 help.
>> https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/
>> __ __
>> Cheers,
>> John Preuß Mattsson
>> __ __
>> *From: *TLS  on behalf of John Mattsson 
>> 
>> *Date: *Tuesday, 28 November 2023 at 09:30
>> *To: *TLS@ietf.org 
>> *Subject: *Re: [TLS] DTLS 1.3 replay protection of post-handshake 
>> messages?
>> Hi,
>>  
>> Reading RFC 9147 (DTLS 1.3) I cannot find any other interpretation than that 
>> replay protection may be disabled for all records. This is not a problem for 
>> the initial lock-step handshake, alerts, KeyUpdate, and ACKs. It seems to be 
>> a major problem for NewSessionTicket, NewConnectionId, RequestConnectionId, 
>> and Post-handshake client authentication as the lack of replay protection 
>> might significantly affect availability. It seems to me that DTLS 1.3 forgot 
>> to update replay protection based on the new post-handshake messages. Let me 
>> know if I miss something.
>>  
>> It is a bit surprising that DTLS 1.3 published in 2022 allows the 
>> application to turn off replay protection at all. This very far from current 
>> best practice for security protocols. There are very good reasons why 
>> Datagram QUIC mandates replay protection and why TLS 1.3 has several pages 
>> discussing security considerations for 0-RTT data, which lacks replay 
>> protection. In general, turning off replay protection (even just for 
>> application data) might lead to loss of confidentiality, integrity, and 
>> availability, i.e., the whole CIA triad.
>>  
>> Applications cannot be expected to understand the severe consequences of not 
>> having replay protection or understand how to fix it on the application 
>> layer. I also don't see any need for turning off replay protection except 
>> RFC 6083 which is a bit of a special case, and which turned out to have 
>> replay

Re: [TLS] Privacy and PSK identifiers (was Re: Call to Move RFC 8773 from Experimental to Standards Track)

[John Mattsson]

Hi Christian,

I made a PR for RFC8446bis adding the missing information that you can use a 
mechanism external to TLS that encrypt the PSK identity.
https://github.com/tlswg/tls13-spec/pulls

OLD: “mechanisms external to TLS that rotate the PSK identity”
NEW: “mechanisms external to TLS that rotate or encrypt the PSK identity”

The encryption could be:

  *   Asymmetric using the public key of the server
  *   Symmetric using a group key
  *   Symmetric using pairwise keys and trial decryption

Maybe that info should be added?

I think it is important to get more focus on the fields in TLS that can be used 
for tracking. Using the same PSK identifier for a long-term is not an 
acceptable solution in general.

Cheers,
John Preuß Mattsson

From: John Mattsson 
Date: Monday, 11 December 2023 at 17:03
To: Christian Huitema , John Mattsson 
, Russ Housley 
Cc: IETF TLS 
Subject: Re: [TLS] Privacy and PSK identifiers (was Re: Call to Move RFC 8773 
from Experimental to Standards Track)
Thanks Christian,

I think all of the suggested solutions are viable with different tradeoffs. 
Actually, I think it is hard to find special cases where none of the solutions 
work.

>One approach is to encrypt the PSK identifier using the public key of
>the destination. That works nicely if we suppose that the clients have
>somehow acquired that public key, maybe using a setup similar to ECH.
>But it supposes that the encrypted result is reasonably short so it can
>fit in the Client Hello without blowing its size. I am concerned that
>this will not work well using post quantum public keys.

If you distribute the external PSK, I think you can distribute a public key as 
well. If the external PSK is derived that is trickier as the client has to 
fetch it from e.g., DNS. The size of ECIES is 32 bytes for the public key + 
overhead for the tag and a few bytes for any encoding overhead. I don't think 
quantum-resistance should be a excuse to not do anything. Using ECIES is much 
much better than sending the psk identifier in cleartext.

>Another approach would be to use symmetric key cryptography. Of course,
>we cannot really assume that random clients will have access to the
>encryption key chosen by the server. But we could have a system in which
>clients are provisioned with a set of equivalent encrypted identifiers.
>That approach works for Session Resumption Tickets. They are provisioned
>by the server, and the best practice is for client to use them only
>once. The downside is that this encryption typically uses Session Ticket
>Encryption Keys that are short lived and frequently rotated. That's a
>good fit for session resumption, but not so much for long term PSK.

In many systems you can replace the external PSK quite often. In 3GPP the 
external PSK used in TLS are refreshed every week.

>If neither STEK nor public keys are adequate, we could use trial
>encryption. Encrypt the PSK-ID using the PSK, and let the server do
>trial decryption by going through the list of provisioned PSK. Your
>guess as to whether this is acceptable is as good as mine.

You can trial decrypt (symmetic crypto) quite many PSK-ID using the same number 
of cycles as an asymmetric signature. But if the server needs to fetch the PSKs 
from a database it might be problematic.

I think mentioning that you can encrypt the PSK identifier and that the server 
can do trial decryption would be very good additions to Section C.4 of 
RFC8446bis that discusses tracking.

Cheers,
John Preuß Mattsson

From: TLS  on behalf of Christian Huitema 

Date: Friday, 8 December 2023 at 21:25
To: John Mattsson , Russ Housley 

Cc: IETF TLS 
Subject: [TLS] Privacy and PSK identifiers (was Re: Call to Move RFC 8773 from 
Experimental to Standards Track)
On 12/8/2023 6:57 AM, John Mattsson wrote:
> That seems like a good start. I think it would be good the TLS WG came
> up with additional guidelines/mechanisms/requirements for doing External
>   PSK in a secure way that does not enable tracking. Using the same
> External PSK identifier for a long time should be discouraged. Maybe ECH
>   is the solution. That would however be outside the scope of RFC 8773.

I spent a lot of time studying a related problem with DNSSD. It is very
hard, and we could only find partial solutions.

One approach is to encrypt the PSK identifier using the public key of
the destination. That works nicely if we suppose that the clients have
somehow acquired that public key, maybe using a setup similar to ECH.
But it supposes that the encrypted result is reasonably short so it can
fit in the Client Hello without blowing its size. I am concerned that
this will not work well using post quantum public keys.

Another approach would be to use symmetric key cryptography. Of course,
we cannot really assume that random clients will have access to the
encryption key chosen by the server. But we could have a system in which
clients are provisi

Re: [TLS] Privacy and PSK identifiers (was Re: Call to Move RFC 8773 from Experimental to Standards Track)

[John Mattsson]

Thanks Christian,

I think all of the suggested solutions are viable with different tradeoffs. 
Actually, I think it is hard to find special cases where none of the solutions 
work.

>One approach is to encrypt the PSK identifier using the public key of
>the destination. That works nicely if we suppose that the clients have
>somehow acquired that public key, maybe using a setup similar to ECH.
>But it supposes that the encrypted result is reasonably short so it can
>fit in the Client Hello without blowing its size. I am concerned that
>this will not work well using post quantum public keys.

If you distribute the external PSK, I think you can distribute a public key as 
well. If the external PSK is derived that is trickier as the client has to 
fetch it from e.g., DNS. The size of ECIES is 32 bytes for the public key + 
overhead for the tag and a few bytes for any encoding overhead. I don't think 
quantum-resistance should be a excuse to not do anything. Using ECIES is much 
much better than sending the psk identifier in cleartext.

>Another approach would be to use symmetric key cryptography. Of course,
>we cannot really assume that random clients will have access to the
>encryption key chosen by the server. But we could have a system in which
>clients are provisioned with a set of equivalent encrypted identifiers.
>That approach works for Session Resumption Tickets. They are provisioned
>by the server, and the best practice is for client to use them only
>once. The downside is that this encryption typically uses Session Ticket
>Encryption Keys that are short lived and frequently rotated. That's a
>good fit for session resumption, but not so much for long term PSK.

In many systems you can replace the external PSK quite often. In 3GPP the 
external PSK used in TLS are refreshed every week.

>If neither STEK nor public keys are adequate, we could use trial
>encryption. Encrypt the PSK-ID using the PSK, and let the server do
>trial decryption by going through the list of provisioned PSK. Your
>guess as to whether this is acceptable is as good as mine.

You can trial decrypt (symmetic crypto) quite many PSK-ID using the same number 
of cycles as an asymmetric signature. But if the server needs to fetch the PSKs 
from a database it might be problematic.

I think mentioning that you can encrypt the PSK identifier and that the server 
can do trial decryption would be very good additions to Section C.4 of 
RFC8446bis that discusses tracking.

Cheers,
John Preuß Mattsson

From: TLS  on behalf of Christian Huitema 

Date: Friday, 8 December 2023 at 21:25
To: John Mattsson , Russ Housley 

Cc: IETF TLS 
Subject: [TLS] Privacy and PSK identifiers (was Re: Call to Move RFC 8773 from 
Experimental to Standards Track)
On 12/8/2023 6:57 AM, John Mattsson wrote:
> That seems like a good start. I think it would be good the TLS WG came
> up with additional guidelines/mechanisms/requirements for doing External
>   PSK in a secure way that does not enable tracking. Using the same
> External PSK identifier for a long time should be discouraged. Maybe ECH
>   is the solution. That would however be outside the scope of RFC 8773.

I spent a lot of time studying a related problem with DNSSD. It is very
hard, and we could only find partial solutions.

One approach is to encrypt the PSK identifier using the public key of
the destination. That works nicely if we suppose that the clients have
somehow acquired that public key, maybe using a setup similar to ECH.
But it supposes that the encrypted result is reasonably short so it can
fit in the Client Hello without blowing its size. I am concerned that
this will not work well using post quantum public keys.

Another approach would be to use symmetric key cryptography. Of course,
we cannot really assume that random clients will have access to the
encryption key chosen by the server. But we could have a system in which
clients are provisioned with a set of equivalent encrypted identifiers.
That approach works for Session Resumption Tickets. They are provisioned
by the server, and the best practice is for client to use them only
once. The downside is that this encryption typically uses Session Ticket
Encryption Keys that are short lived and frequently rotated. That's a
good fit for session resumption, but not so much for long term PSK.

If neither STEK nor public keys are adequate, we could use trial
encryption. Encrypt the PSK-ID using the PSK, and let the server do
trial decryption by going through the list of provisioned PSK. Your
guess as to whether this is acceptable is as good as mine.

-- Christian Huitema

___
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] Call to Move RFC 8773 from Experimental to Standards Track

[John Mattsson]

Hi Russ,

Seem like good suggested updates.

Russ Housley wrote:
>Can you point me to the 3GPP document that makes use of RFC 8773?  It should 
>probably be referenced in Section 3.1 >as another example along with 
>[I-D.ietf-emu-bootstrapped-tls].

Hi, Section 5.3 of TS 33.222 specifies "Shared key-based UE authentication with 
certificate-based NAF authentication". Other sections specified “Shared 
key-based mutual authentication” and “Certificate based mutual”. It was 
recently discussed in 3GPP if 5.3 should be updated to refer to RFC 8773.

But now when I look at TS 33.222 personally, I see that Section 5.3 actually 
uses HTTP Digest for the Shared key-based client authentication, not TLS PSK 
authentication. Must have been some misunderstanding. 3GPP does not use RFC 
8773.

Cheers,
John Preuß Mattsson

From: Russ Housley 
Date: Friday, 8 December 2023 at 20:08
To: John Mattsson 
Cc: IETF TLS 
Subject: Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
John:

Thanks for you thoughtful review.

Russ Housley wrote:
>   Appendix E.6 of [RFC8446] discusses identity-exposure attacks on
>   PSKs.  Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses
>   tracking prevention.  The guidance in these sections remain relevant.
>
>   If an external PSK identity is used for multiple connections, then an
>   observer will generally be able track clients and/or servers across
>   connections.  The rotation of the external PSK identity or the use of
>   the Encrypted Client Hello extension [I-D.ietf-tls-esni] can mitigate
>   this risk.

That seems like a good start. I think it would be good the TLS WG came up with 
additional guidelines/mechanisms/requirements for doing External PSK in a 
secure way that does not enable tracking. Using the same External PSK 
identifier for a long time should be discouraged. Maybe ECH is the solution. 
That would however be outside the scope of RFC 8773.

Some additional comments on RFC8773(bis):

- I think the abstact and introduction should talk about client authentication 
as well. Right now it only talks about server authentication. The external PSK 
provides both client and server authentication. The 3GPP use case for RFC 8773 
is to use certificates for the server authentication and PSK for the client 
authentication.

Can you point me to the 3GPP document that makes use of RFC 8773?  It should 
probably be referenced in Section 3.1 as another example along with 
[I-D.ietf-emu-bootstrapped-tls].

Suggested Abstract update:

   This document specifies a TLS 1.3 extension that allows TLS clients
   and servers to authenticate with a combination of a certificate and
   an external pre-shared key (PSK).

Suggested Introduction update:

   The TLS 1.3 [RFC8446] handshake protocol provides two mutually
   exclusive forms of server authentication.  First, the server can be
   authenticated by providing a signature certificate and creating a
   valid digital signature to demonstrate that it possesses the
   corresponding private key.  Second, the server can be authenticated
   by demonstrating that it possesses a pre-shared key (PSK) that was
   established by a previous handshake.  A PSK that is established in
   this fashion is called a resumption PSK.  A PSK that is established
   by any other means is called an external PSK.

   A TLS 1.3 server that is authenticating with a certificate may
   optionally request a certificate from the TLS 1.3 client for
   authentication as described in Section 4.3.2 of [RFC8446].

   This document specifies a TLS 1.3 extension permitting certificate-
   based authentication to be combined with an external PSK as an input
   to the TLS 1.3 key schedule.


- When RFC 8773 was published, we did not have ML-KEM and ML-DSA, now we do. I 
think RFC8773bis should explain how and why the solution with External PSK is 
needed now that we have ML-KEM and ML-DSA. Is it needed when we get standard 
track ML-KEM and ML-DSA? CNSA 2.0 seems to indicate that ML-KEM and ML-DSA is 
enough for TOP SECRET, but I know that some european governments like to always 
combine External PSK with asymmetric crypto just to be on the safe side and to 
always get PFS.

I suggest an additional paragraph in Section 3.1:

   Quantum-resistant public-key cryptographic algorithms are becoming
   standards, but it will take many years for TLS 1.3 ciphersuites that
   use these algorithms to be developed and deployed.  In some
   environments, deployment of a strong external PSK provides protection
   until these quantum-resistant algorithms are deployed.

Russ



Cheers,
John Preuß Mattsson

From: Russ Housley mailto:hous...@vigilsec.com>>
Date: Wednesday, 6 December 2023 at 21:51
To: John Mattsson 
mailto:john.matts...@ericsson.com>>
Cc: IETF TLS mailto:tls@ietf.org>>
Subject: Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
John:

I respond to your three suggested ch

Re: [TLS] Design Rational for Key Exporter

[John Mattsson]

>An unhelpful answer is that the key exporter interface was already set by 
>prior versions of TLS and any TLS 1.3 key exporter needs to >remain analogous. 
>:-)

I think the opposite is true :) In TLS 1.2 rekeying (with renegotiation) does 
change the value returned by the key exporter, at least that is my 
understanding of the TLS 1.2 key exporter specification. By changing so that 
rekeying (key update) does not change the value returned by the key exporter, 
TLS 1.3 made a major change compared to earlier versions.

I think it would maybe be good if the TLS 1.2 functionality that was removed in 
TLS 1.3 was documented better. Removed things that have caused 
problems/surprises for me personally:

  *   Rekeying with Ephemeral Diffie-Hellman in a connection (this was used by 
DTLS/SCTP).
  *   Post-Handshake server authentication (this was used by DTLS/SCTP).
  *   Rekeying of the exporter secret (this was used by DTLS/SCTP).
  *   Flight #4 (this was used by EAP-TLS 1.2).
  *   Combining certificates with PSK (this was used by 3GPP)
  *   Providing a PSK hint (this was used by 3GPP)

(I am not saying these are necessary bad changes. They can be solved by setting 
up new connections and by using application data instead of flight #4, use RFC 
8773, and sending more psk identifiers…)

Cheers,
John Preuß Mattsson

From: TLS  on behalf of David Benjamin 

Date: Wednesday, 29 November 2023 at 18:37
To: Tschofenig, Hannes 
Cc: tls@ietf.org 
Subject: Re: [TLS] Design Rational for Key Exporter
An unhelpful answer is that the key exporter interface was already set by prior 
versions of TLS and any TLS 1.3 key exporter needs to remain analogous. :-)

A more helpful answer is that we cannot simultaneously believe that key update 
is a transparent feature of TLS, and that exporters are sensitive to key 
update. Every use of key exporters necessarily involves both client and server 
computing the value and doing something with it (otherwise you could have just 
generated random bytes and moved on). That means both sides need to sample it 
at an analogous point in the connection, so the application protocol needs to 
be very aware of when all the key updates happen, and take care that 
corresponding uses of the exporter are sampled at corresponding epochs.

That means, if we want to build an exporter update mechanism, it needs to be 
some operation exported to the application protocol and driven by the 
application. Key updates are not that.

But I also don't think we need to or should do anything to support that use 
case. It is sufficient to have a single API, discard exporter secret, for the 
application to tell TLS it is done calling the exporter (and thus discard the 
root exporter secret). That API requires no new protocol machinery. An 
application that wants a ratcheting behavior in the exporter would then simply 
do:

1. After the connection is established, export the initial secret for their 
application-specific use of exporters and save it somewhere.
2. Discard the exporter secret
3. At whatever points in the application protocol make sense, have both sides 
run their application-specific ratcheting operation on the application-specific 
running secret.

Not only that, we even intentionally designed the exporters to have a two-step 
label, then context derivation operation. This means "discard exporter secret" 
can instead be done by extracting label-specific exporters, in case one label 
wants to continue deriving values and another one is done and wants to ratchet. 
If there were some exporter-wide update operation, this would require 
coordination across all uses of exporters across the entire connection. So 
leaving the protocol as-is is the best way to meet this use case.

On Wed, Nov 29, 2023 at 3:31 AM Tschofenig, Hannes 
mailto:40siemens@dmarc.ietf.org>>
 wrote:
Hi all,

I was wondering why the design of the key exporter is such that it is based on 
the early_exporter_master_secret or the exporter_master_secret and no new key 
export is triggered at a later point in time, for example when a key update is 
performed. RFC 5705, which is used as a basis for the key exporter design in 
TLS 1.3, just states that there are protocols that want to obtain keying 
material from the TLS exchange. RFC 5705 nor the TLS 1.3 spec indicate the 
design rational of why no later events (e.g. post-handshake authentication or 
key updates) trigger a new key export. Was this done on purpose or was there 
just no use case for it at that time?

Ciao
Hannes

___
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] Call to Move RFC 8773 from Experimental to Standards Track

[John Mattsson]

Hi Russ,

Russ Housley wrote:
>   Appendix E.6 of [RFC8446] discusses identity-exposure attacks on
>   PSKs.  Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses
>   tracking prevention.  The guidance in these sections remain relevant.
>
>   If an external PSK identity is used for multiple connections, then an
>   observer will generally be able track clients and/or servers across
>   connections.  The rotation of the external PSK identity or the use of
>   the Encrypted Client Hello extension [I-D.ietf-tls-esni] can mitigate
>   this risk.

That seems like a good start. I think it would be good the TLS WG came up with 
additional guidelines/mechanisms/requirements for doing External PSK in a 
secure way that does not enable tracking. Using the same External PSK 
identifier for a long time should be discouraged. Maybe ECH is the solution. 
That would however be outside the scope of RFC 8773.

Some additional comments on RFC8773(bis):

- I think the abstact and introduction should talk about client authentication 
as well. Right now it only talks about server authentication. The external PSK 
provides both client and server authentication. The 3GPP use case for RFC 8773 
is to use certificates for the server authentication and PSK for the client 
authentication.

- When RFC 8773 was published, we did not have ML-KEM and ML-DSA, now we do. I 
think RFC8773bis should explain how and why the solution with External PSK is 
needed now that we have ML-KEM and ML-DSA. Is it needed when we get standard 
track ML-KEM and ML-DSA? CNSA 2.0 seems to indicate that ML-KEM and ML-DSA is 
enough for TOP SECRET, but I know that some european governments like to always 
combine External PSK with asymmetric crypto just to be on the safe side and to 
always get PFS.

Cheers,
John Preuß Mattsson

From: Russ Housley 
Date: Wednesday, 6 December 2023 at 21:51
To: John Mattsson 
Cc: IETF TLS 
Subject: Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
John:

I respond to your three suggested changes below:

(1) How about a title of "TLS 1.3 Extension for Using Certificates with an 
External Pre-Shared Key"

(2) None of the normative references are paywalled.  Two references are not 
RFCs or RFC errata or I-Ds or IANA web pages:

[GGM1986] is free access at 
https://dl.acm.org/doi/10.1145/6490.6503<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-aef859da111c15a9=1=8b806035-f71c-4c87-ae4f-a3492b6bc616=https%3A%2F%2Fdl.acm.org%2Fdoi%2F10.1145%2F6490.6503>

[K2016] I found the same paper at https://eprint.iacr.org/2016/711.  I'll point 
here.<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-6e0c9e24a3cecc9b=1=8b806035-f71c-4c87-ae4f-a3492b6bc616=https%3A%2F%2Feprint.iacr.org%2F2016%2F711>

(3) The privacy considerations already talk about Appendix E.6 of [RFC8446].  I 
am please to add a pointer to ECH, but I do not think that ECH use should not 
be mandated.

I suggest:

   Appendix E.6 of [RFC8446] discusses identity-exposure attacks on
   PSKs.  Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses
   tracking prevention.  The guidance in these sections remain relevant.

   If an external PSK identity is used for multiple connections, then an
   observer will generally be able track clients and/or servers across
   connections.  The rotation of the external PSK identity or the use of
   the Encrypted Client Hello extension [I-D.ietf-tls-esni] can mitigate
   this risk.

Russ



On Dec 6, 2023, at 11:51 AM, John Mattsson 
 wrote:

Hi,

I am quite convinced that the security properties are not worse than a mixture 
of PSK authentication, PSK key exchange, (EC)DHE key exchange, and signature 
authentication.

In some cases, this is very good. You get the quantum-resistance of the PSK 
together with the PFS of ECDHE, and the entity authentication and security 
policies of certificates. In other cases, it is not so good as the reuse of a 
PSK identifier enables tracking and potentially identification of both the 
client and the server. I don’t think that such a field enabling tracking 
belongs in modern TLS, but reuse of a PSK identifier is already in RFC 8446 so 
this document does theoretically not make the worst-case worse.

If RFC 8773 is updated. I think the following things should be updated:
- The title and abstract only talks about PSK authentication. The key exchange 
is likely more important to make quantum-resistant than the authentication. I 
think the title and abstract should talk about PSK key exchange.
- I think the paywalled references should be removed. I think paywalled 
references are both a cybersecurity risk and a democracy problem [1]. I don’t 
think they belong in RFCs unless absolutely necessary. RFC 8446bis recently 
removed all paywalled references.
- The document should refer to section C.4 of RFC8446bis that now includes a 
short discussion on that reuse of an PSK identi

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[John Mattsson]

Hi,

A comment on the draft that should be updated in the next version:

OLD: ”Quantum computers, once available, will have a huge impact on TLS.”

A lot of people already have small, error prone, and currently quite useless 
quantum computers. I suggest changing to Cryptographically Relevant Quantum 
Computers (CRQC). It is still unclear if and when CRQCs will be constructed. 
The goal is that TLS will change to quantum-resistant algorithms and that CRQC 
when/if they are constructed will not have a huge impact on TLS.

I suggest that you correct this sentence to say one of:
NEW1: ”The threat of Cryptographically relevant quantum computers, once 
available, will have a huge impact on TLS.”

NEW2: ” Cryptographically relevant quantum computers, once available, will have 
a huge impact on RSA, FFDH, ECC which are currently used in TLS.”

Cheers,
John Preuß Mattsson

From: TLS  on behalf of Chris Barber 

Date: Thursday, 7 December 2023 at 21:41
To: TLS@ietf.org 
Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'
I've reviewed the document and endorse its adoption.

It's not worth spending more time on TLS < 1.3, and the draft can help to 
improve TLS 1.3 adoption.

It isn't worthwhile to invest additional time in TLS versions earlier than 1.3, 
and the draft can contribute to enhancing the adoption of TLS 1.3.

On Wed, Dec 6, 2023 at 6:34 AM Deirdre Connolly 
mailto:durumcrustu...@gmail.com>> wrote:
At the TLS meeting at IETF 118 there was significant support for the draft 'TLS 
1.2 is in Feature Freeze' 
(https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This call is 
to confirm this on the list.  Please indicate if you support the adoption of 
this draft and are willing to review and contribute text. If you do not support 
adoption of this draft please indicate why.  This call will close on December 
20, 2023.

Thanks,
Deirdre, Joe, and Sean
___
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] "Notes" column in draft-ietf-tls-rfc8447bis?

[John Mattsson]

Hi Valery,

>First, the rekeying is not per-packet, but per n packets,
>where n depends on the suite and varies from 1 to 8192
>(as per table 1, Section 4.1, RFC 9367, constant C_3).

Thanks for the clarification. So, if I understand correctly, the rekeying 
frequency is 2^64 – C_3 and is fixed per cipher suite.

>And second, the packet protection key
>depends only on the corresponding application traffic secret
>and on the packet number, it can always be calculated
>if the packet number is known. Both DTLS and QUIC
>bear sequence numbers in packets, so
>there seem to be no major obstacles for using GOST suites in them
>(I didn’t evaluate their use myself, but similar construction
>is used for GOST ciphers in ESP, RFC 9227, and it works).


I think the ESP approach would work for GOST suites in DTLS 1.2. The difference 
is that sequence numbers are always encrypted in DTLS 1.3 and QUIC. With 
rekeying every 8192 records (TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L) I think 
you could update the epoch every time and things would work. With rekeying 
every record (TLS_GOSTR341112_256_WITH_MAGMA_MGM_S) you would not be able to 
rely on epoch for out of order records and I think the receiver might need to 
try several keys before finding the correct one.



Cheers,

John Preuß Mattsson

From: Valery Smyslov 
Date: Friday, 8 December 2023 at 13:24
To: John Mattsson , 'Sean Turner' , 
'Salz, Rich' 
Cc: 'TLS List' 
Subject: RE: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?
Hi John,

two more clarifications regarding GOST suites.

First, the rekeying is not per-packet, but per n packets,
where n depends on the suite and varies from 1 to 8192
(as per table 1, Section 4.1, RFC 9367, constant C_3).

And second, the packet protection key
depends only on the corresponding application traffic secret
and on the packet number, it can always be calculated
if the packet number is known. Both DTLS and QUIC
bear sequence numbers in packets, so
there seem to be no major obstacles for using GOST suites in them
(I didn’t evaluate their use myself, but similar construction
is used for GOST ciphers in ESP, RFC 9227, and it works).

Regards,
Valery.



From: John Mattsson [mailto:john.matts...@ericsson.com]
Sent: Friday, December 08, 2023 12:31 PM
To: Valery Smyslov; 'Sean Turner'; 'Salz, Rich'
Cc: 'TLS List'
Subject: Re: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?

Hi,

Valery Smyslov wrote:
>No, they include only hash (GOSTR341112) and AEAD cipher (MAGMA_MGM or 
>KUZNYECHIK_MGM).
>Their order in the names is unusual (hash first, cipher second).

Yes, my misunderstanding based on the weird naming order. So nothing weird 
technically.


Ilari Liusvaara wrote:
>Also,
>
>0x00,0xC6 TLS_SM4_GCM_SM3
>0x00,0xC7 TLS_SM4_CCM_SM3
>
>Both are explicitly flagged as not OK for DTLS. However, using GCM/CCM
>in usual way, so not difficult to define how those would work in DTLS
>or QUIC (just copy what AES-128 does there).

Yes, I agree that would be straightforward. But it has not been done yet.

Ilari Liusvaara wrote:
>If the _ECCPWD_ ones work for TLS 1.3, why wouldn't those work for DTLS
>1.3 or QUIC? Those ciphersuites use AES in standard way, and DTLS/QUIC
>do serialize the flights.

Yes, you are correct that they should work. DTLS 1.3 and QUIC defined header 
protection for all cipher suites that use AES.

Ilari Liusvaara wrote:
>Well, _ECCPWD_ is just special snowflake as it modifies the key
>exchange (I haven't checked if what it does actually works).

Feels to me like it would have been good if _ECCPWD_ TLS 1.3 cipher suites had 
never been registered. What should have been done is to register 
TLS_AES_256_CCM_SHA384 together with some new key exchange or extentions

Below is an updated table of TLS 1.3 cipher suites based on Ilari’s comments. 
One day I hope most of this info will be easy to extract from the IANA registry.
Value
Description
DTLS 1.3
QUIC
Comment
0x00,0xC6
TLS_SM4_GCM_SM3
N
N
Would be straightforward to specify use in DTLS 1.3 and QUIC
0x00,0xC7
TLS_SM4_CCM_SM3
N
N
Would be straightforward to specify use in DTLS 1.3 and QUIC
0x13,0x01
TLS_AES_128_GCM_SHA256
Y
Y
0x13,0x02
TLS_AES_256_GCM_SHA384
Y
Y
0x13,0x03
TLS_CHACHA20_POLY1305_SHA256
Y
Y
0x13,0x04
TLS_AES_128_CCM_SHA256
Y
Y
0x13,0x05
TLS_AES_128_CCM_8_SHA256
Y
N
QUIC RFC states MUST NOT use
0x13,0x06
TLS_AEGIS_256_SHA512
Y
Y
0x13,0x07
TLS_AEGIS_128L_SHA256
Y
Y
0xC0,0xB0
TLS_ECCPWD_WITH_AES_128_GCM_SHA256
Y
Y
0xC0,0xB1
TLS_ECCPWD_WITH_AES_256_GCM_SHA384
Y
Y
0xC0,0xB2
TLS_ECCPWD_WITH_AES_128_CCM_SHA256
Y
Y
0xC0,0xB3
TLS_ECCPWD_WITH_AES_256_CCM_SHA384
Y
Y
0xC0,0xB4
TLS_SHA256_SHA256
N
N
Impossible to use in DTLS 1.3 and QUIC as NULL encryption is used.
0xC0,0xB5
TLS_SHA384_SHA384
N
N
Impossible to use in DTLS 1.3 and QUIC as NULL encryption is used.
0xC1,0x03
TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L
N
N
Not straightforward to specify use in DTLS 1.3 and QU

Re: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?

[John Mattsson]

Hi,

Valery Smyslov wrote:
>No, they include only hash (GOSTR341112) and AEAD cipher (MAGMA_MGM or 
>KUZNYECHIK_MGM).
>Their order in the names is unusual (hash first, cipher second).

Yes, my misunderstanding based on the weird naming order. So nothing weird 
technically.


Ilari Liusvaara wrote:
>Also,
>
>0x00,0xC6 TLS_SM4_GCM_SM3
>0x00,0xC7 TLS_SM4_CCM_SM3
>
>Both are explicitly flagged as not OK for DTLS. However, using GCM/CCM
>in usual way, so not difficult to define how those would work in DTLS
>or QUIC (just copy what AES-128 does there).

Yes, I agree that would be straightforward. But it has not been done yet.

Ilari Liusvaara wrote:
>If the _ECCPWD_ ones work for TLS 1.3, why wouldn't those work for DTLS
>1.3 or QUIC? Those ciphersuites use AES in standard way, and DTLS/QUIC
>do serialize the flights.

Yes, you are correct that they should work. DTLS 1.3 and QUIC defined header 
protection for all cipher suites that use AES.

Ilari Liusvaara wrote:
>Well, _ECCPWD_ is just special snowflake as it modifies the key
>exchange (I haven't checked if what it does actually works).

Feels to me like it would have been good if _ECCPWD_ TLS 1.3 cipher suites had 
never been registered. What should have been done is to register 
TLS_AES_256_CCM_SHA384 together with some new key exchange or extentions

Below is an updated table of TLS 1.3 cipher suites based on Ilari’s comments. 
One day I hope most of this info will be easy to extract from the IANA registry.


Value
Description
DTLS 1.3
QUIC
Comment
0x00,0xC6
TLS_SM4_GCM_SM3
N
N
Would be straightforward to specify use in DTLS 1.3 and QUIC
0x00,0xC7
TLS_SM4_CCM_SM3
N
N
Would be straightforward to specify use in DTLS 1.3 and QUIC
0x13,0x01
TLS_AES_128_GCM_SHA256
Y
Y
0x13,0x02
TLS_AES_256_GCM_SHA384
Y
Y
0x13,0x03
TLS_CHACHA20_POLY1305_SHA256
Y
Y
0x13,0x04
TLS_AES_128_CCM_SHA256
Y
Y
0x13,0x05
TLS_AES_128_CCM_8_SHA256
Y
N
QUIC RFC states MUST NOT use
0x13,0x06
TLS_AEGIS_256_SHA512
Y
Y
0x13,0x07
TLS_AEGIS_128L_SHA256
Y
Y
0xC0,0xB0
TLS_ECCPWD_WITH_AES_128_GCM_SHA256
Y
Y
0xC0,0xB1
TLS_ECCPWD_WITH_AES_256_GCM_SHA384
Y
Y
0xC0,0xB2
TLS_ECCPWD_WITH_AES_128_CCM_SHA256
Y
Y
0xC0,0xB3
TLS_ECCPWD_WITH_AES_256_CCM_SHA384
Y
Y
0xC0,0xB4
TLS_SHA256_SHA256
N
N
Impossible to use in DTLS 1.3 and QUIC as NULL encryption is used.
0xC0,0xB5
TLS_SHA384_SHA384
N
N
Impossible to use in DTLS 1.3 and QUIC as NULL encryption is used.
0xC1,0x03
TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L
N
N
Not straightforward to specify use in DTLS 1.3 and QUIC due to per-packet 
rekeying
0xC1,0x04
TLS_GOSTR341112_256_WITH_MAGMA_MGM_L
N
N
Not straightforward to specify use in DTLS 1.3 and QUIC due to per-packet 
rekeying
0xC1,0x05
TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S
N
N
Not straightforward to specify use in DTLS 1.3 and QUIC due to per-packet 
rekeying
0xC1,0x06
TLS_GOSTR341112_256_WITH_MAGMA_MGM_S
N
N
Not straightforward to specify use in DTLS 1.3 and QUIC due to per-packet 
rekeying

Cheers,
John

From: Valery Smyslov 
Date: Wednesday, 6 December 2023 at 19:04
To: John Mattsson , 'Sean Turner' , 
'Salz, Rich' 
Cc: 'TLS List' 
Subject: RE: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?
Hi John,

just a clarification:


The _GOSTR341112_ seems to include authentication and key exchange…. I did not 
think this was how TLS 1.3 cipher suites were supposed to be used.

No, they include only hash (GOSTR341112) and AEAD cipher (MAGMA_MGM 
or KUZNYECHIK_MGM).
Their order in the names is unusual (hash first, cipher second).

Regards,
Valery.

Cheers,
John Preuß Mattsson

From: Sean Turner 
Date: Wednesday, 6 December 2023 at 14:55
To: Salz, Rich , John Mattsson 
Cc: TLS List 
Subject: Re: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?

> On Dec 6, 2023, at 08:02, Salz, Rich  
> wrote:
>
> Yes, I think information regarding if a cipher suite is for TLS 1.3 is very 
> needed to have.  I already asked for that in
> https://mailarchive.ietf.org/arch/msg/tls/0gDKfXJvAemFDm7MWcS1DTDVIe8/
>
> In addition, I would also like to information if the cipher suite can be used 
> in QUIC.
>
> The 8447bis draft added a notes column to every TLS registry. The “1.2 is 
> frozen” draft says to use it to indicate things like “for TLS 1.3 and later”. 
> It’s a free-form text field, so we can direct IANA to put anything we want. :)

Yep we added it via:
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-cc6bdfdfb39824c6=1=9148a29f-ecfe-46e0-869e-33ffd8475127=https%3A%2F%2Fgithub.com%2Ftlswg%2Frfc8447bis%2Fpull%2F48

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

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[John Mattsson]

Hi,

I am quite convinced that the security properties are not worse than a mixture 
of PSK authentication, PSK key exchange, (EC)DHE key exchange, and signature 
authentication.

In some cases, this is very good. You get the quantum-resistance of the PSK 
together with the PFS of ECDHE, and the entity authentication and security 
policies of certificates. In other cases, it is not so good as the reuse of a 
PSK identifier enables tracking and potentially identification of both the 
client and the server. I don’t think that such a field enabling tracking 
belongs in modern TLS, but reuse of a PSK identifier is already in RFC 8446 so 
this document does theoretically not make the worst-case worse.

If RFC 8773 is updated. I think the following things should be updated:
- The title and abstract only talks about PSK authentication. The key exchange 
is likely more important to make quantum-resistant than the authentication. I 
think the title and abstract should talk about PSK key exchange.
- I think the paywalled references should be removed. I think paywalled 
references are both a cybersecurity risk and a democracy problem [1]. I don’t 
think they belong in RFCs unless absolutely necessary. RFC 8446bis recently 
removed all paywalled references.
- The document should refer to section C.4 of RFC8446bis that now includes a 
short discussion on that reuse of an PSK identifier enables tracking. I think 
RFC8773bis should have a warning early that the privacy properties are much 
worse than the normal certificate-based authentication. This could be 
completely solved by mandating ECH. Alternatively, it could be solved by 
sending the PSK identifier after flight #1 when things are encrypted.

3GPP specified the use of server certificate authentication combined with PSK 
authentication and key exchange for TLS 1.2. As that mode was not available in 
RFC 8446, 3GPP does not specify this mode for TLS 1.3 but there have recently 
been discussions in 3GPP about adding RFC 8773. I think the really bad privacy 
properties of PSK in TLS 1.3 is a significant problem for 3GPP. The bad privacy 
properties of TLS 1.3 with PSK have also been discussed several times in EMU 
WG. I think a mode that sends the PSK identifier encrypted would make a lot 
more sense for standard track.

I am not supportive of standard track unless the tracking problem is solved. If 
the privacy problems are solved, I am however very supportive. Adding an extra 
roundtrip is a small price to pay for privacy. Adding a field (psk identifier) 
that can be used for tracking to current certificate-based TLS is making 
privacy worse. I don’t think that is a good idea or worthy of standards track.

Cheers,
John Preuß Mattsson

[1] 
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/W2VOzy0wz_E/m/6pgf5tFaAAAJ

From: TLS  on behalf of Dan Harkins 
Date: Wednesday, 6 December 2023 at 14:50
To: TLS@ietf.org 
Subject: Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

   Hi,

   I approve of this transition to standards track and I am implementing
this as well.

   regards,

   Dan.

On 11/29/23 7:51 AM, Joseph Salowey wrote:
> RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with
> an External Pre-Shared Key) was originally published as experimental
> due to lack of implementations. As part of implementation work for the
> EMU workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there
> is ongoing implementation work. Since the implementation status of RFC
> 8773 is changing, this is a consensus call to move RFC 8773 to
> standards track as reflected in
> [RFC8773bis](https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis).
> This will also help avoid downref for the EMU draft.  Please indicate
> if you approve of or object to this transition to standards track
> status by December 15, 2023.
>
> Thanks,
>
> Joe, Sean, and Deirdre
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

___
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] Adoption call for 'TLS 1.2 Feature Freeze'

[John Mattsson]

I support adoption. I also support making TLS 1.2 not recommended, discouraged, 
and deprecated. TLS 1.2 can be anything from quite good to very bad depending 
on configuration. Any work on TLS 1.2 is just delaying deployment of TLS 1.3.

Cheers,
John Preuß Mattsson

From: TLS  on behalf of Christopher Patton 

Date: Wednesday, 6 December 2023 at 17:03
To: Deirdre Connolly 
Cc: TLS@ietf.org 
Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'
I support adoption.
Chris P.

On Tue, Dec 5, 2023 at 9:34 PM Deirdre Connolly 
mailto:durumcrustu...@gmail.com>> wrote:
At the TLS meeting at IETF 118 there was significant support for the draft 'TLS 
1.2 is in Feature Freeze' 
(https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This call is 
to confirm this on the list.  Please indicate if you support the adoption of 
this draft and are willing to review and contribute text. If you do not support 
adoption of this draft please indicate why.  This call will close on December 
20, 2023.

Thanks,
Deirdre, Joe, and Sean
___
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] "Notes" column in draft-ietf-tls-rfc8447bis?

[John Mattsson]

That sounds great.

Who is doing the work of adding “for TLS 1.3 and later”?

My understanding is that the currently registered TLS 1.3 cipher suites are:

Value
Description
DTLS 1.3
QUIC
0x13,0x01
TLS_AES_128_GCM_SHA256
Y
Y
0x13,0x02
TLS_AES_256_GCM_SHA384
Y
Y
0x13,0x03
TLS_CHACHA20_POLY1305_SHA256
Y
Y
0x13,0x04
TLS_AES_128_CCM_SHA256
Y
Y
0x13,0x05
TLS_AES_128_CCM_8_SHA256
Y
N
0x13,0x06
TLS_AEGIS_256_SHA512
Y
Y
0x13,0x07
TLS_AEGIS_128L_SHA256
Y
Y
0xC0,0xB0
TLS_ECCPWD_WITH_AES_128_GCM_SHA256
N
N
0xC0,0xB1
TLS_ECCPWD_WITH_AES_256_GCM_SHA384
N
N
0xC0,0xB2
TLS_ECCPWD_WITH_AES_128_CCM_SHA256
N
N
0xC0,0xB3
TLS_ECCPWD_WITH_AES_256_CCM_SHA384
N
N
0xC0,0xB4
TLS_SHA256_SHA256
N
N
0xC0,0xB5
TLS_SHA384_SHA384
N
N
0xC1,0x03
TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L
N
N
0xC1,0x04
TLS_GOSTR341112_256_WITH_MAGMA_MGM_L
N
N
0xC1,0x05
TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S
N
N
0xC1,0x06
TLS_GOSTR341112_256_WITH_MAGMA_MGM_S
N
N

(The DTLS 1.3 and QUIC information is my understanding. It is currently not in 
the IANA registry).

Note that “for TLS 1.3 and later” and “DTLS-OK” is not enough as some cipher 
suites (the _ECCPWD_ ones) seem to be valid for TLS 1.2, TLS 1.3, DTLS 1.2 but 
not DTLS 1.3….

I think the notes column should contain info on DTLS 1.3 and QUIC as well.

Do we need some guidance/requirements on naming and use of TLS 1.3 cipher 
suites?
The _ECCPWD_ ones seem to include authentication in the TLS 1.3. The 
_GOSTR341112_ seems to include authentication and key exchange…. I did not 
think this was how TLS 1.3 cipher suites were supposed to be used.

Cheers,
John Preuß Mattsson

From: Sean Turner 
Date: Wednesday, 6 December 2023 at 14:55
To: Salz, Rich , John Mattsson 
Cc: TLS List 
Subject: Re: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?

> On Dec 6, 2023, at 08:02, Salz, Rich  
> wrote:
>
> Yes, I think information regarding if a cipher suite is for TLS 1.3 is very 
> needed to have.  I already asked for that in
> https://mailarchive.ietf.org/arch/msg/tls/0gDKfXJvAemFDm7MWcS1DTDVIe8/
>
> In addition, I would also like to information if the cipher suite can be used 
> in QUIC.
>
> The 8447bis draft added a notes column to every TLS registry. The “1.2 is 
> frozen” draft says to use it to indicate things like “for TLS 1.3 and later”. 
> It’s a free-form text field, so we can direct IANA to put anything we want. :)

Yep we added it via:
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-cc6bdfdfb39824c6=1=9148a29f-ecfe-46e0-869e-33ffd8475127=https%3A%2F%2Fgithub.com%2Ftlswg%2Frfc8447bis%2Fpull%2F48

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

Re: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?

[John Mattsson]

Yes, I think information regarding if a cipher suite is for TLS 1.3 is very 
needed to have.  I already asked for that in
https://mailarchive.ietf.org/arch/msg/tls/0gDKfXJvAemFDm7MWcS1DTDVIe8/

In addition, I would also like to information if the cipher suite can be used 
in QUIC.

(It is very hard for someone to find out which cipher suites are usable for TLS 
1.3, DTLS 1.3, and QUIC)

Cheers,
John

From: TLS  on behalf of Salz, Rich 

Date: Thursday, 20 April 2023 at 21:17
To: tls@ietf.org 
Subject: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?
I’m starting to write the draft about TLS 1.2 being frozen.

It occurred to me that every TLS registry might need a “notes” column.  If 
someone defines a new crypto algorithm, sat AEGIS being considered in CFRG, we 
want to assign it a number but have a note saying “only for TLS 1.3 and later”
We could make it be a simple yes/no column, like “Pre-1.3?” but I think that’s 
needlessly terse.

Does that make sense?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?

[John Mattsson]

Hi,

Lack of replay also enables tracking of client and server. If the client or 
server is a device moving together with a person this enables tracking of the 
person.

An attacker can store a message from one location and then replay it to the 
client or server in another location. If the client or server accept the 
replayed message, the attacker knows that the device in the two locations are 
one and the same. It is best practice to assume that an attacker can always 
detect if a message was accepted. If the client or server send a response to 
the replayed message (like a replayed client authentication request) this is 
trivial.

This is different from the attack described in Section C.4 “Client and Server 
Tracking Prevention” of RFC8446bis, which describes the client reusing a 
ticket. A network attacker mounting a replay attack are described in Section 8 
of RFC8446bis. I think a sentence or two should be added to Section C.4 to 
describe that a network attacker mounting a replay attack can be used for 
server tracking and that the mitigations in Section 8 help.
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/

Cheers,
John Preuß Mattsson

From: TLS  on behalf of John Mattsson 

Date: Tuesday, 28 November 2023 at 09:30
To: TLS@ietf.org 
Subject: Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?
Hi,

Reading RFC 9147 (DTLS 1.3) I cannot find any other interpretation than that 
replay protection may be disabled for all records. This is not a problem for 
the initial lock-step handshake, alerts, KeyUpdate, and ACKs. It seems to be a 
major problem for NewSessionTicket, NewConnectionId, RequestConnectionId, and 
Post-handshake client authentication as the lack of replay protection might 
significantly affect availability. It seems to me that DTLS 1.3 forgot to 
update replay protection based on the new post-handshake messages. Let me know 
if I miss something.

It is a bit surprising that DTLS 1.3 published in 2022 allows the application 
to turn off replay protection at all. This very far from current best practice 
for security protocols. There are very good reasons why Datagram QUIC mandates 
replay protection and why TLS 1.3 has several pages discussing security 
considerations for 0-RTT data, which lacks replay protection. In general, 
turning off replay protection (even just for application data) might lead to 
loss of confidentiality, integrity, and availability, i.e., the whole CIA triad.

Applications cannot be expected to understand the severe consequences of not 
having replay protection or understand how to fix it on the application layer. 
I also don't see any need for turning off replay protection except RFC 6083 
which is a bit of a special case, and which turned out to have replay issues.
https://datatracker.ietf.org/meeting/115/materials/slides-115-tsvwg-sctp-auth-security-issues-00

I would strongly recommend all DTLS 1.3 libraries to completely remove the 
option to disable replay protection.

An easy fix for the post-handshake messages is to "clarify" that replay 
protection must not be turned off for anything else than application data. I 
you agree I can submit an “erratum” for RFC 9147. But this does not solve the 
general issue that turning off replay protection would be a major security 
problem in almost all applications.

Cheers,
John Preuß Mattsson

From: TLS  on behalf of John Mattsson 

Date: Friday, 24 November 2023 at 14:50
To: TLS@ietf.org 
Subject: [TLS] DTLS 1.3 replay protection of post-handshake messages?
Hi,

How does replay protection of Post-handshake messages work in DTLS 1.3 if the 
per-record replay-protection mechanism is turned off?

1. Is the post-handshake messages replay protected in some other way, which I 
miss?

2. Should RFC 9147 state that the per-record replay-protection mechanism can 
only be turned off for application data? (I could not find anything in RFC 9147 
stating something like this).

(things like post-handshake authentication need replay protection in some way)

Cheers,
John Preuß Mattsson
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?

[John Mattsson]

>I believe that the reason this exists is that some higher-layer protocols have 
>their own replay protection, such that as long as the datagram is authentic, 
>it is safe.
I agree that you theoretically do that. But I don’t see the problem in these 
cases. Replay protection is almost free. I do understand the use case in RFC 
6083 where DTLS is sent on top of SCTP and having DTLS replay protection turned 
on cause problems. But I also think that DTLS over SCTP is not a good design.

>NSS has no means to disable replay protection and I see no reason to add that 
>means.
That seems like the right approach to me.

Cheers,
John

From: TLS  on behalf of Martin Thomson 

Date: Tuesday, 28 November 2023 at 23:11
To: tls@ietf.org 
Subject: Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?
On Tue, Nov 28, 2023, at 19:29, John Mattsson wrote:
> I would strongly recommend all DTLS 1.3 libraries to completely remove
> the option to disable replay protection.

I believe that the reason this exists is that some higher-layer protocols have 
their own replay protection, such that as long as the datagram is authentic, it 
is safe.  However, I agree that if we are sending handshake messages that 
affect DTLS state, it is probably not good to have the DTLS layer fail to 
provide that protection.  I believe that you can operate DTLS 1.3 without 
post-handshake handshake/control messages, in which case you might manage to 
avoid exposure.

NSS has no means to disable replay protection and I see no reason to add that 
means.

___
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] DTLS 1.3 replay protection of post-handshake messages?

[John Mattsson]

Hi,

Reading RFC 9147 (DTLS 1.3) I cannot find any other interpretation than that 
replay protection may be disabled for all records. This is not a problem for 
the initial lock-step handshake, alerts, KeyUpdate, and ACKs. It seems to be a 
major problem for NewSessionTicket, NewConnectionId, RequestConnectionId, and 
Post-handshake client authentication as the lack of replay protection might 
significantly affect availability. It seems to me that DTLS 1.3 forgot to 
update replay protection based on the new post-handshake messages. Let me know 
if I miss something.

It is a bit surprising that DTLS 1.3 published in 2022 allows the application 
to turn off replay protection at all. This very far from current best practice 
for security protocols. There are very good reasons why Datagram QUIC mandates 
replay protection and why TLS 1.3 has several pages discussing security 
considerations for 0-RTT data, which lacks replay protection. In general, 
turning off replay protection (even just for application data) might lead to 
loss of confidentiality, integrity, and availability, i.e., the whole CIA triad.

Applications cannot be expected to understand the severe consequences of not 
having replay protection or understand how to fix it on the application layer. 
I also don't see any need for turning off replay protection except RFC 6083 
which is a bit of a special case, and which turned out to have replay issues.
https://datatracker.ietf.org/meeting/115/materials/slides-115-tsvwg-sctp-auth-security-issues-00

I would strongly recommend all DTLS 1.3 libraries to completely remove the 
option to disable replay protection.

An easy fix for the post-handshake messages is to "clarify" that replay 
protection must not be turned off for anything else than application data. I 
you agree I can submit an “erratum” for RFC 9147. But this does not solve the 
general issue that turning off replay protection would be a major security 
problem in almost all applications.

Cheers,
John Preuß Mattsson

From: TLS  on behalf of John Mattsson 

Date: Friday, 24 November 2023 at 14:50
To: TLS@ietf.org 
Subject: [TLS] DTLS 1.3 replay protection of post-handshake messages?
Hi,

How does replay protection of Post-handshake messages work in DTLS 1.3 if the 
per-record replay-protection mechanism is turned off?

1. Is the post-handshake messages replay protected in some other way, which I 
miss?

2. Should RFC 9147 state that the per-record replay-protection mechanism can 
only be turned off for application data? (I could not find anything in RFC 9147 
stating something like this).

(things like post-handshake authentication need replay protection in some way)

Cheers,
John Preuß Mattsson
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TurboTLS: handshaking over UDP to remove 1 round trip

[John Mattsson]

>I would like to see examples of these use cases where using QUIC is 
>impossible, but using >TurboTLS is.

+1

QUIC is the obvious future replacement for TCP, (D)TLS, SCTP, and RTP. I think 
IETF should focus on QUIC. I think people staying on TLS/TCP need to live with 
an extra roundtrip. Visibility is likely not a very convincing argument for the 
TLS WG. Visibility needs to be solved in the endpoints. The sooner people 
understand this the better. TurboTLS would just delay this transition.

Cheers,
John

From: TLS  on behalf of Bas Westerbaan 

Date: Monday, 27 November 2023 at 11:40
To: David Joseph 
Cc: tls@ietf.org 
Subject: Re: [TLS] TurboTLS: handshaking over UDP to remove 1 round trip
I would like to see examples of these use cases where using QUIC is impossible, 
but using TurboTLS is.

Best,

 Bas

On Wed, Nov 15, 2023 at 6:37 PM David Joseph 
mailto:d...@sandboxaq.com>> wrote:
Hi everyone,

We wanted to speak about this draft on TurboTLS at 118 but didn't manage to 
squeeze into the packed session.

Forwarding a new draft here that describes an idea for UDP handshaking in 
parallel to setting up the TCP stream, then switching back to TLS-over-TCP for 
the session portion. This enables removing one round trip from all TLS versions 
in the best case, and in the worst case scenario, falling back to TLS-over-TCP 
with an extremely small latency boost.

TurboTLS doesn't change the contents of any TLS messages, only how some 
handshake messages are delivered over UDP instead of TCP. This technique 
supports transparent proxying, whereby standard TLS requests can be intercepted 
and turbo charged, by sitting one proxy in front of both client and server. 
First client requests are intercepted, translated to UDP, received by the 
server proxy, translated back to TCP, and sent back without client nor server 
being aware that their exchange has been turbo charged.

Proxying enables legacy systems using all versions of TLS to obtain faster 
connection establishment without touching their network stack. TurboTLS has 
most potential where migration to QUIC is not possible in the near term due to 
legacy servers, or due to firewall visibility/deep packet inspection concerns, 
yet for systems which handle many short-lived TLS connections per second with 
non-trivial network latency.

We managed to speak with a few of you privately about your thoughts on the 
benefits and drawbacks of this technique, and would like you to share any more 
opinions with us below so that we can understand whether it is worth developing 
this draft further.

If this sounds like it might be useful to you/your use case, please get in 
touch!

Kind regards,
David

-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: Sun, Nov 5, 2023 at 12:43 AM
Subject: New Version Notification for draft-joseph-tls-turbotls-00.txt
To: Carlos Aguilar-Melchor 
mailto:carlos.agui...@sandboxaq.com>>, David 
Joseph mailto:d...@sandboxaq.com>>, Douglas Stebila 
mailto:dsteb...@uwaterloo.ca>>, Jason Goertzen 
mailto:jason.goert...@sandboxquantum.com>>


A new version of Internet-Draft draft-joseph-tls-turbotls-00.txt has been
successfully submitted by Deirdre Connolly and posted to the
IETF repository.

Name: draft-joseph-tls-turbotls
Revision: 00
Title:TurboTLS for faster connection establishment
Date: 2023-11-05
Group:Individual Submission
Pages:16
URL:  https://www.ietf.org/archive/id/draft-joseph-tls-turbotls-00.txt
Status:   https://datatracker.ietf.org/doc/draft-joseph-tls-turbotls/
HTML: https://www.ietf.org/archive/id/draft-joseph-tls-turbotls-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-joseph-tls-turbotls


Abstract:

   This document provides a high level protocol description for
   handshaking over UDP in the Transport Layer Security (TLS) protocol
   (version independent).  In parallel, a TCP session is established,
   and once this is done, the TLS session reverts to TCP.  In the event
   that the UDP handshaking portion fails, TurboTLS falls back to TLS-
   over-TCP as is usually done, resulting in negligible latency cost in
   the case of failure.

   Discussion of this work is encouraged to happen on the TLS IETF
   mailing list tls@ietf.org or on the GitHub repository 
which contains
   the draft: 
https://github.com/PhDJsandboxaq/draft-ietf-turbotls-design



The IETF Secretariat

___
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] DTLS 1.3 replay protection of post-handshake messages?

[John Mattsson]

Hi,

How does replay protection of Post-handshake messages work in DTLS 1.3 if the 
per-record replay-protection mechanism is turned off?

1. Is the post-handshake messages replay protected in some other way, which I 
miss?

2. Should RFC 9147 state that the per-record replay-protection mechanism can 
only be turned off for application data? (I could not find anything in RFC 9147 
stating something like this).

(things like post-handshake authentication need replay protection in some way)

Cheers,
John Preuß Mattsson
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

[John Mattsson]

Scott Fluhrer wrote:
>We had that argument several IETF’s ago (IETF 105?), and the clear consensus 
>of the working group was that explicit named hybrid combinations (e.g. one for 
>ML-KEM-512 + X25519) was the way to go.

I think it is bit problematic that the discussion was so long ago before any 
KEM standards were even close to ready and interest in deploying 
quantum-resistant KEMs was limited. The cluster Deirdre mention are all 
non-recommended parameters that I personally don’t care about and don’t want to 
use. I want standards track RFCs. We will likely have FIPS standards for ML-KEM 
and ML-DSA before IETF 119 and it worries me that TLS WG has not even started 
any work (which is equally much my fault). I would like to make ML-KEM and 
ML-DSA mandatory to support in all 3GPP systems that use TLS, DTLS, and QUIC, 
which are many and growing. Current 3GPP policy is to only use “recommended” 
parameters.

The discussion at IETF 105 was 10 min discussion about a specific proposal that 
included complex client preferences and gave the impression that it 
significantly changes the key schedule. I don’t think any client preferences 
would be needed except the group order. The server can determine the most 
preferred PQC KEM and the most preferred ECC group and make a choice based on 
its own policy. The client should not advertise groups that it does not want to 
use. The presentation from IETF 105 gives the impression that the key schedule 
changes. I don’t think a split key PRF changes the key schedule, you just 
exchange one PRF (HKDF-Extract) with another PRF, in fact I think it was wrong 
to hard-code HKDF in TLS 1.3, HMAC and HKDF are constructions to mitigate the 
weaknesses in SHA-2.

https://datatracker.ietf.org/meeting/105/materials/slides-105-tls-sessa-hybrid-key-exchange-in-tls-13-00
https://datatracker.ietf.org/meeting/105/materials/minutes-105-tls-00

>Do we want to reopen that argument?
I guess I already did, but unless people support the idea in this thread, we 
don’t need to discuss it in a meeting. Registering hybrids as code points 
clearly work and it’s anybody’s guess how many hybrids will be registered and 
for how long they will be used. I think the time required for discussing which 
hybrids to register (or not to register) might be the biggest problem.

Cheers,
John Preuß Mattsson

From: Deirdre Connolly 
Date: Thursday, 9 November 2023 at 12:28
To: Scott Fluhrer (sfluhrer) 
Cc: John Mattsson , Sophie Schmieg 
, tls@ietf.org 
Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?
There are several documents in a cluster that define new hybrid `NamedGroup`s 
and how those operate / are combined, abstracted away from the rest of the TLS 
handshake. Treating hybrid schemes (key establishment, signatures) as /separate 
and distinct from their component algorithms/ is a good idea.

https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-09.html
https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-03.html
https://www.ietf.org/archive/id/draft-kwiatkowski-tls-ecdhe-kyber-01.html

I am aware of multiple 
implementations<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-3e8580b6be3fe97e=1=68363486-341d-4e6c-a177-7f30845c9f18=https%3A%2F%2Fgithub.com%2Faws%2Fs2n-tls%2Fissues%2F4132>
 and at least one 
deployment<https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html>
 of the proposed `NamedGroup` `X25519Kyber768Draft00`, so


On Thu, Nov 9, 2023 at 12:01 PM Scott Fluhrer (sfluhrer) 
mailto:40cisco@dmarc.ietf.org>> wrote:
We had that argument several IETF’s ago (IETF 105?), and the clear consensus of 
the working group was that explicit named hybrid combinations (e.g. one for 
ML-KEM-512 + X25519) was the way to go.

Do we want to reopen that argument?  Now, I was on the other side (and I still 
think it would be a better engineering decision, given the right negotiation 
mechanism), but if it delays actual deployment, I would prefer if we didn’t.

From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of John 
Mattsson
Sent: Thursday, November 9, 2023 3:48 AM
To: Sophie Schmieg 
mailto:40google@dmarc.ietf.org>>; 
tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

Hi,

Everybody seem to agree that hybrids should be specified. Looking in my crystal 
ball, I predict that registering hybrids as code points will be a big mess with 
way too many opinions and registrations similar to the TLS 1.2 cipher suites. 
The more I think about it, the more I think TLS 1.3 should standardize a 
generic solution for combining two or more key shares.

My understanding of what would be needed:

- New "split_key_PRF" extension indicating that client supports split-key PRF.

- When "split_key_PRF" is negotiated the server may chose more than one 
group/key s

Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

[John Mattsson]

Hi,

Everybody seem to agree that hybrids should be specified. Looking in my crystal 
ball, I predict that registering hybrids as code points will be a big mess with 
way too many opinions and registrations similar to the TLS 1.2 cipher suites. 
The more I think about it, the more I think TLS 1.3 should standardize a 
generic solution for combining two or more key shares.

My understanding of what would be needed:

- New "split_key_PRF" extension indicating that client supports split-key PRF.

- When "split_key_PRF" is negotiated the server may chose more than one 
group/key share.

  struct {
  NamedGroup selected_groups<0..2^16-1>;
  } KeyShareHelloRetryRequest;

 struct {
  KeyShareEntry server_shares<0..2^16-1>;
  } KeyShareServerHello;

- When "split_key_PRF" is negotiated HKDF-Expand(Secret, HkdfLabel, Length) is 
replaced by a split-key PRF(Secret1, Secret2, ... , HkdfLabel, Length)

I think the current structure that the TLS server makes the decisions on 
“groups” and “key shares” should be kept.

There was a short discussion earlier on the list
https://mailarchive.ietf.org/arch/msg/tls/Z-s8A0gZsRudZ9hW4VoCsNI9YUU/


Sophie Schmieg sschm...@google.com wrote:
”Our stated intention is to move to Kyber once NIST releases the standard”
“I do not think it makes a lot of sense to have multiple schemes based on 
structured lattices in TLS, and Kyber is in my opinion the superior algorithm.”

I agree with that.

Cheers,
John Preuß Mattsson



From: TLS  on behalf of Sophie Schmieg 

Date: Thursday, 9 November 2023 at 08:40
To: tls@ietf.org 
Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?
> > On 8 Nov 2023, at 8:34, Loganaden Velvindron 
> > mailto:logana...@gmail.com>> wrote:
> >
> > I support moving forward with hybrids as a proactively safe deployment
> > option. I think that supporting
> > only Kyber for KEX  is not enough. It would make sense to have more options.
> >
> > Google uses NTRU HRSS internally:
> > https://cloud.google.com/blog/products/identity-security/why-google-now-uses-post-quantum-cryptography-for-internal-comms
> >
> > If Google decides to use this externally, how easy would it be to get
> > a codepoint for TLS ?
> As easy as writing it up in a stable document (may or may not be an 
> Internet-draft) and asking IANA for a code point assignment.
>
> It can be done in days, if needed.
>
>  Yoav

Just to clarify a few things about our internal usage of NTRU-HRSS: This is for 
historic reasons.

Our stated intention is to move to Kyber once NIST releases the standard, see 
e.g. my talk at PQCrypto [1], where I go into some detail on this topic.
Long story short, we had to choose a candidate well before even NIST's round 3 
announcement, and haven't changed since changing a ciphersuite, while 
relatively straightforward is not free, so we would like to avoid doing it 
twice in a year.
The only security consideration that went into the decision for NTRU was that 
we wanted to use a structured lattice scheme, with NTRU being chosen for 
non-security related criteria that have since materially changed.
I do not think it makes a lot of sense to have multiple schemes based on 
structured lattices in TLS, and Kyber is in my opinion the superior algorithm.

[1] https://www.youtube.com/watch?v=8PYYM3G7_GY


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

Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

[John Mattsson]

D. J. Bernstein wrote:
>as far as I know there was only one other cryptographer on record
>recommending against using SIKE.

I am on record multiple times recommending against using _any_ non-standard or 
paywalled algorithms. That includes Kyber, Dilithium, FrodoKEM, Falcon, 
Sphinx+, Classic McEliece, NewHope, NTRU, NTRU Prime, and SIKE….

Sometimes NSA has very good advice:

”NSS customers are reminded that NSA does not recommend and policy does not 
allow implementing or using unapproved, non-standard or experimental 
cryptographic algorithms.”
https://media.defense.gov/2021/Aug/04/2002821837/-1/-1/1/Quantum_FAQs_20210804.PDF

I think it is very sad that deploying a lot of non-standard and experimental 
cryptographic algorithms gives a lot of positive media attention…

NIST does not deserve any criticism for continuing to evaluate SIKE. I would 
also like to see more evaluation of CSIDH where you according to this paper 
don’t agree that the “conservative parameters” suggested by other researchers 
are needed.
https://thomwiggers.nl/publication/secsidh/secsidh.pdf

Cheers,
John

From: TLS  on behalf of D. J. Bernstein 
Date: Wednesday, 8 November 2023 at 01:07
To: tls@ietf.org 
Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?
Yoav Nir writes:
> To justify a hybrid key exchange you need people who are both worried
> about quantum computers and worried about cryptanalysis or the new
> algorithms, but are willing to bet that those things won’t happen at
> the same time. Or at least, within the time where the generated key
> still matters.

Google and Cloudflare encrypted quite a bit of actual user data using
SIKE:

   https://blog.cloudflare.com/the-tls-post-quantum-experiment/

The only reason this didn't give the user data away to today's attackers
is that Google and Cloudflare had the common sense to insist that any
post-quantum algorithm be added as a second layer of encryption on top
of the existing X25519 layer, rather than removing the existing layer.

That was in 2019. For anyone who thinks a few years of subsequent study
were enough for the public to identify which post-quantum cryptosystems
are breakable, it's useful to look at NIST's official report

   
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-20e9e0536295785e=1=5d9194af-1af7-4655-94f5-fbb34782df29=https%3A%2F%2Fweb.archive.org%2Fweb%2F20220705160405%2Fhttps%3A%2F%2Fnvlpubs.nist.gov%2Fnistpubs%2Fir%2F2022%2FNIST.IR.8413.pdf

in July 2022 saying that

   * SIKE is "being considered for future standardization";

   * regarding NIST deciding to throw away FrodoKEM: "While NIST intends
 to select at least one additional KEM not based on structured
 lattices for standardization after the fourth round, three other
 KEM alternates (BIKE, HQC, and SIKE) are better suited than
 FrodoKEM for this role";

   * "SIKE remains an attractive candidate for standardization because
 of its small key and ciphertext sizes";

   * regarding NIST delaying a decision on Classic McEliece: "For
 applications that need a very small ciphertext, SIKE may turn out
 to be more attractive";

   * regarding torsion-point attacks: "there has been no impact on
 SIKE".

SIKE had been advertised in 2021 
(https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-0d78d4ebd1667da1=1=5d9194af-1af7-4655-94f5-fbb34782df29=https%3A%2F%2Feprint.iacr.org%2F2021%2F543)
 as
"A decade unscathed". I think I was the only person speaking up to
object (https://twitter.com/hashbreaker/status/1387779717370048518), and
as far as I know there was only one other cryptographer on record
recommending against using SIKE.

---D. J. Bernstein


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

Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

[John Mattsson]

Hi Bas,

Thanks for adding some structure.

1. Do we want rfc describing the final NIST standards? And for which? I'm

ok with that — in this order of priority: ml-kem, ml-dsa, slh-dsa.

I would definitely want standard track RFCs for ML-KEM and ML-DSA. I think 
other standards using TLS (IETF and other SDOs like 3GPP) might be hesitant to 
commit to quantum-resistant TLS based on just code point. I don’t care much for 
early code points, for me the code points could actually wait until we have 
standard track RFCs. I

I think the use of major algorithms like ML-KEM and ML-DSA should be specified 
in standard track RFCs. There are also quite a lot of technical considerations 
here, TLS has never had any KEMs (a new thing is for example that the server 
cannot reuse its key share, which I think is a great privacy feature), TLS has 
never had hybrid algorithms, and the large sizes might need consideration as 
well. That said, I think the non-hybrid case is relatively simple.

I personally don’t see a strong need for SLH-DSA in TLS. I think the use case 
for that would mostly be root keys.


2. For which algorithms do we want to assign codepoints once the NIST

standards are out? Codepoints are cheap and use cases/rules are different,

but especially with the hybrids, I'd encourage us to try to be disciplined

and keep the list as short as we can for now, so that early adopters for

which it doesn't matter, all choose the same thing. The DNS mechanism

of draft-davidben-tls-key-share-prediction helps on the performance side,

but it doesn't solve the duplicate engineering/validation if there are a

dozen essentially equivalent KEMs.

I would like non-hybrid code points for all ML-KEM and ML-DSA algorithms NIST 
standardized. Very likely that will be ML-KEM-512, ML-KEM-768, ML-KEM-1024, 
ML-DSA-44, ML-DSA-65, and ML-DSA-87. I think that is a likely end state.

Any algorithms specified in the future would either be backup algorithms for 
cryptographic agility (BIKE, HQC), more conservative algorithms (FrodoKEM, 
Classic McEliece), or algorithms with smaller sizes (MAYO, SQISign). The trust 
in any algorithm with smaller sizes would likely be less than in ML-KEM and 
ML-DSA. I think ML-KEM and ML-DSA are here to stay.

I would strongly want ML-KEM-512 and ML-KEM-1024 in TLS. NIST’s current 
assesment is that the cost of breaking ML-KEM-512 is higher than the cost to 
break AES-128 (I agree with that) and UK government just stated that ML-KEM-512 
is approved for UK government use. If I want performance, I would use 
ML-KEM-512. ML-KEM-1024 is absolutely needed for CNSA 2.0 compliance.

If hybrids are specified as single code points, I agree that we should keep the 
list relatively short. I agree with Bas that the P-curves are not needed. I 
would go for X25519 and X448 only.


3. Do we want to standardise non-hybrid KEMs for TLS? I don't care for them

yet, but others might.

I agree with Uri, absolutely yes. . I think ML-KEM and ML-DSA is a likely end 
state.

4. Do we need hybrid signatures for the TLS handshake? I don't see the use,
but could be convinced otherwise.

I don’t see the need for hybrid signatures in the TLS handshake. I can see the 
need in other use cases.

5. What is the future of AuthKEM? That's definitely a different e-mail
thread.

Yes. AuthKEM is definitly a different discussion (which I think is interesting 
to have). AuthKEM is a BIG change. It is not really “TLS 1.3” anymore… If such 
a mode is added I think that should probably be as part of TLS 1.4. And given 
that KEM keys require changes to certificate issuance, I think a SIGMA-I mode 
with signatures would still be needed.

Cheers,
John

From: Bas Westerbaan 
Date: Monday, 6 November 2023 at 12:37
To: John Mattsson 
Cc: TLS@ietf.org 
Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?
Thanks for bringing this up. There are a bunch of (implicit) questions in your 
e-mail.

1. Do we want rfc describing the final NIST standards? And for which? I'm ok 
with that — in this order of priority: ml-kem, ml-dsa, slh-dsa.

2. For which algorithms do we want to assign codepoints once the NIST standards 
are out? Codepoints are cheap and use cases/rules are different, but especially 
with the hybrids, I'd encourage us to try to be disciplined and keep the list 
as short as we can for now, so that early adopters for which it doesn't matter, 
all choose the same thing. The DNS mechanism of 
draft-davidben-tls-key-share-prediction helps on the performance side, but it 
doesn't solve the duplicate engineering/validation if there are a dozen 
essentially equivalent KEMs.

3. Do we want to standardise non-hybrid KEMs for TLS? I don't care for them 
yet, but others might.

4. Do we need hybrid signatures for the TLS handshake? I don't see the use, but 
could be convinced otherwise.

5. What is the future of AuthKEM? That's definitely a different e-mail thread.

Concretely, after ML-KEM is finished, I was planning to update

[TLS] What is the TLS WG plan for quantum-resistant algorithms?

[John Mattsson]

Hi,

NIST has released draft standards for ML-KEM, ML-DSA, and ML-SLH. Final 
standards are expected in Q1 2024.
https://csrc.nist.gov/news/2023/three-draft-fips-for-post-quantum-cryptography

I would like to have standard track TLS (and DTLS, QUIC) RFCs for ML-KEM and 
ML-DSA (all security levels standardized by NIST) as soon as possible after the 
final NIST standards are ready. 3GPP is relying almost exclusively on IETF RFCs 
for uses of public key cryptography (the exception is ECIES for IMSI encryption 
but that will likely use HPKE with ML-KEM in the future).

Looking at the TLS document list, it seems severely lacking when it comes to 
ML-KEM, ML-DSA…

The adopted draft-ietf-tls-hybrid-design is an informal draft dealing with the 
pre-standard Kyber.
https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/

AuthKEM is a quite big change to TLS
https://datatracker.ietf.org/doc/draft-wiggers-tls-authkem-psk/

This is not adopted, informal, and dealing with the pre-standard Kyber.
https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-kyber/

What is the TLS WG plan for quantum-resistant algorithms? My current view is 
that I would like ML-KEM-512, ML-KEM-768, ML-KEM-1024, ML-DSA-44, ML-DSA-65, 
and ML-DSA-87 registered asap. For hybrid key exchange I think X25519 and X448 
are the only options that make sense. For hybrid signing, ECDSA, EdDSA, and RSA 
could all make sense.

Cheers,
John

From: TLS  on behalf of internet-dra...@ietf.org 

Date: Friday, 8 September 2023 at 02:48
To: i-d-annou...@ietf.org 
Cc: tls@ietf.org 
Subject: [TLS] I-D Action: draft-ietf-tls-hybrid-design-09.txt
Internet-Draft draft-ietf-tls-hybrid-design-09.txt is now available. It is a
work item of the Transport Layer Security (TLS) WG of the IETF.

   Title:   Hybrid key exchange in TLS 1.3
   Authors: Douglas Stebila
Scott Fluhrer
Shay Gueron
   Name:draft-ietf-tls-hybrid-design-09.txt
   Pages:   23
   Dates:   2023-09-07

Abstract:

   Hybrid key exchange refers to using multiple key exchange algorithms
   simultaneously and combining the result with the goal of providing
   security even if all but one of the component algorithms is broken.
   It is motivated by transition to post-quantum cryptography.  This
   document provides a construction for hybrid key exchange in the
   Transport Layer Security (TLS) protocol version 1.3.

   Discussion of this work is encouraged to happen on the TLS IETF
   mailing list tls@ietf.org or on the GitHub repository which contains
   the draft: 
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-c404f4af2592f2f4=1=367fabf2-370b-4cec-b657-05a8499decf6=https%3A%2F%2Fgithub.com%2Fdstebila%2Fdraft-ietf-tls-hybrid-design.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-09.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-hybrid-design-09

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
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] cTLS and P-256

[John Mattsson]

Hi,

My current understanding is that cTLS is not planning to embrace any optimized 
encodings for P-256 key shares and signatures and instead focus on x25519 and 
ed25519. Earlier versions of cTLS had examples of (unspecified) optimized P-256 
encodings, but this has been removed in the last version.

It would be good if the authors could confirm. We will then remove the 
following sentence from draft-ietf-iotops-security-protocol-comparison.

   Editor's note: The protocol and algorithm encoding in cTLS is
   currently not stable and the number might change in the final
   version.  This version of the document analyses the -08 version of
   cTLS.  It is uncertain if the TLS WG will adopt more compact encoding
   for P-256 and ECDSA such as secp256r1_compact and
   ecdsa_secp256r1_sha256_compact [I-D.mattsson-tls-compact-ecc].

https://datatracker.ietf.org/doc/draft-ietf-iotops-security-protocol-comparison/

I don't plan to any updated version of draft-mattsson-tls-compact-ecc unless 
someone actually wants to implement and use it. I will also not pursue code 
point registration as the consensus in the TLS WG was that this should go 
through the WG if pursued. Something like draft-mattsson-tls-compact-ecc could 
always be done later if needed.
https://datatracker.ietf.org/doc/draft-mattsson-tls-compact-ecc/

I have personally tried to push hard for x25519 and ed25519 in the past but 
they are sometimes problematic. Some IoT devices/libraries does not have 
support for x25519/ed25519, some devices only have HW acceleration of SHA-256, 
and the deterministic nature of ed25519 makes it vulnerable to side-channel 
attacks.

Cheers,
John

From: TLS  on behalf of internet-dra...@ietf.org 

Date: Monday, 13 March 2023 at 23:30
To: i-d-annou...@ietf.org 
Cc: tls@ietf.org 
Subject: [TLS] I-D Action: draft-ietf-tls-ctls-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Transport Layer
Security (TLS) WG of the IETF.

   Title   : Compact TLS 1.3
   Authors : Eric Rescorla
 Richard Barnes
 Hannes Tschofenig
 Benjamin M. Schwartz
   Filename: draft-ietf-tls-ctls-08.txt
   Pages   : 24
   Date: 2023-03-13

Abstract:
   This document specifies a "compact" version of TLS 1.3 and DTLS 1.3.
   It saves bandwidth by trimming obsolete material, tighter encoding, a
   template-based specialization technique, and alternative
   cryptographic techniques. cTLS is not directly interoperable with TLS
   1.3 or DTLS 1.3 since the over-the-wire framing is different.  A
   single server can, however, offer cTLS alongside TLS or DTLS.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-ctls/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-ctls-08.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-ctls-08

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
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] NIST Draft comments period: Addressing Visibility Challenges with TLS 1.3

[John Mattsson]

I think IETF should state in the LS that:

The IETF maintains copyright and change control for TLS specifications. Having 
a separate, different, protocol named "TLS" but developed by another SDO is a 
recipe for confusion among developers, implementers, and users alike. Reuse of 
key shares violate the design and operational assumptions of TLS 1.3 and render 
this NIST profile as a qualitatively different protocol that should be named 
accordingly. We therefore formally request that NIST alter the name of its work 
on a protocol with key share reuse so that implementors, users, and governments 
are not confused about its properties or the properties of TLS.

Where the above text is more or less copy pasted from the LSs to ETSI.

Cheers,
John


On 2023-05-17, 20:43, "Stephen Farrell"  wrote:

Hiya,

On 17/05/2023 18:49, John Mattsson wrote:
> Hi,
>
> Should IETF / SEC / TLS send an LS to NIST as was done with ESTI-TC-CYBER?

Yes. Other relevant bodies defining ways to weaken the
hard-won security of IETF protocols really ought always
be (nicely) told they're doing a bad thing.

I sent NIST my own comments (also with an attempt at
"nicely":-) and would encourage others to do similarly,
even though it's not that likely they'll take much notice
I suspect (on the basis that they even started this IMO
bad-idea-factory activity).

Cheers,
S.

>
> https://datatracker.ietf.org/liaison/1538/
> https://datatracker.ietf.org/liaison/1616/
>
> A lot of the comments in the LSs to ESTI-TC-CYBER also apply to the NIST work.
>
> "Our foremost concern is the use of the name Transport Layer Security (TLS), 
> a well-known protocol which has been developed by the IETF for over twenty 
> years. The IETF maintains copyright and change control for TLS 
> specifications. Having a separate, different, protocol named "TLS" but 
> developed by another SDO is a recipe for confusion among developers, 
> implementers, and users alike."
>
> "The IETF remains strongly committed to fostering end-to-end security, and 
> the properties of TLS enable that for key IETF protocols. We believe the ETSI 
> work to proceed from a different design goal: to enable third-party 
> monitoring. Because applications using TLS expect its end-to-end security 
> properties, the re-use of the name will create misunderstandings. We 
> therefore formally request that ETSI alter the name of its work enabling 
> third-party monitoring so that implementors, users, and governments are not 
> confused about its properties or the properties of TLS."
>
> "the main area of divergence from TLS 1.3 to this MSP profile is the 
> replacement of the server’s "ephemeral" DH key with a "static" DH key, which 
> suffices to violate the design and operational assumptions of TLS 1.3 and 
> render this MSP profile as a qualitatively different protocol that should be 
> named accordingly."
>
> My feeling is that the IETF community is much more against reuse of key 
> shares now than in 2017. At IETF 116 there seemed to be consensus to 
> discourage psk_ke. RFC8446bis and RFC9325 now have strong normative text 
> discouraging key share reuse.
>
> I personally think it is problematic and not very constructive if IETF states 
> that all visibility solutions are bad. It would in my view be more pragmatic 
> to state that some technical solutions are better than other.
>
> Cheers,
> John
>
> From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
> John Mattsson 
> mailto:40ericsson@dmarc.ietf.org>>
> Date: Tuesday, 16 May 2023 at 15:59
> To: Salz, Rich 
> mailto:40akamai@dmarc.ietf.org>>, 
> tls@ietf.org<mailto:tls@ietf.org> mailto:tls@ietf.org>>
> Subject: Re: [TLS] NIST Draft comments period: Addressing Visibility 
> Challenges with TLS 1.3
> Hi Rich,
>
> Good that you inform the TLS WG. I was planning to do that but forgot. 
> Ericsson is likely to provide the comments in the link below. We think it is 
> good that NIST is doing this project, visibility is a problem, but our 
> position is that reuse of key shares is not an acceptable solution.
>
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-0709a0af3bfcfd71=1=572ebc85-77e0-4e77-bfd3-3dc82a21c3bf=https%3A%2F%2Fgithub.com%2Femanjon%2FPublications%2Fblob%2Fmain%2FEricsson%2520comments%2520on%2520NIST%2520SP%25201800-37A%2520May%252013.pdf<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-7d2441a08db5bc25=1=aaabd95a-d6a9-4af8-9292-dd48d0908491=https%3A%2F%2Fgithub.com%2Femanjon%2FPublications%2Fblob%2Fmain%2FEricsson%2520comments%2520on%2520NIST%2520SP%25201800-37A%2520May%252013.pdf><https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454447

Re: [TLS] NIST Draft comments period: Addressing Visibility Challenges with TLS 1.3

[John Mattsson]

Hi,

Should IETF / SEC / TLS send an LS to NIST as was done with ESTI-TC-CYBER?

https://datatracker.ietf.org/liaison/1538/
https://datatracker.ietf.org/liaison/1616/

A lot of the comments in the LSs to ESTI-TC-CYBER also apply to the NIST work.

"Our foremost concern is the use of the name Transport Layer Security (TLS), a 
well-known protocol which has been developed by the IETF for over twenty years. 
The IETF maintains copyright and change control for TLS specifications. Having 
a separate, different, protocol named "TLS" but developed by another SDO is a 
recipe for confusion among developers, implementers, and users alike."

"The IETF remains strongly committed to fostering end-to-end security, and the 
properties of TLS enable that for key IETF protocols. We believe the ETSI work 
to proceed from a different design goal: to enable third-party monitoring. 
Because applications using TLS expect its end-to-end security properties, the 
re-use of the name will create misunderstandings. We therefore formally request 
that ETSI alter the name of its work enabling third-party monitoring so that 
implementors, users, and governments are not confused about its properties or 
the properties of TLS."

"the main area of divergence from TLS 1.3 to this MSP profile is the 
replacement of the server’s "ephemeral" DH key with a "static" DH key, which 
suffices to violate the design and operational assumptions of TLS 1.3 and 
render this MSP profile as a qualitatively different protocol that should be 
named accordingly."

My feeling is that the IETF community is much more against reuse of key shares 
now than in 2017. At IETF 116 there seemed to be consensus to discourage 
psk_ke. RFC8446bis and RFC9325 now have strong normative text discouraging key 
share reuse.

I personally think it is problematic and not very constructive if IETF states 
that all visibility solutions are bad. It would in my view be more pragmatic to 
state that some technical solutions are better than other.

Cheers,
John

From: TLS  on behalf of John Mattsson 

Date: Tuesday, 16 May 2023 at 15:59
To: Salz, Rich , tls@ietf.org 
Subject: Re: [TLS] NIST Draft comments period: Addressing Visibility Challenges 
with TLS 1.3
Hi Rich,

Good that you inform the TLS WG. I was planning to do that but forgot. Ericsson 
is likely to provide the comments in the link below. We think it is good that 
NIST is doing this project, visibility is a problem, but our position is that 
reuse of key shares is not an acceptable solution.

https://github.com/emanjon/Publications/blob/main/Ericsson%20comments%20on%20NIST%20SP%201800-37A%20May%2013.pdf<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-7d2441a08db5bc25=1=aaabd95a-d6a9-4af8-9292-dd48d0908491=https%3A%2F%2Fgithub.com%2Femanjon%2FPublications%2Fblob%2Fmain%2FEricsson%2520comments%2520on%2520NIST%2520SP%25201800-37A%2520May%252013.pdf>

Cheers,
John


From: TLS  on behalf of Salz, Rich 

Date: Tuesday, 16 May 2023 at 13:19
To: tls@ietf.org 
Subject: [TLS] NIST Draft comments period: Addressing Visibility Challenges 
with TLS 1.3
Public comment period open until June 26.

Quoting from https://content.govdelivery.com/accounts/USNIST/bulletins/359534b

This project builds on our earlier work, 
“https://www.nccoe.nist.gov/tls-server-certificate-management,” which showed 
organizations how to centrally monitor and manage their TLS certificates. We 
are now focusing on protocol enhancements such as TLS 1.3 which have helped 
organizations boost performance and address security concerns. These same 
enhancements have also reduced enterprise visibility into internal traffic 
flows within the organizations' environment. This project aims to change 
that--and has two main objectives:
• Provide security and IT professionals practical approaches and tools to help 
them gain more visibility into the information being exchanged on their 
organizations’ servers.
• Help users fully adopt TLS 1.3 in their private data centers and in hybrid 
cloud environments—while maintaining regulatory compliance, security, and 
operations.


___
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] NIST Draft comments period: Addressing Visibility Challenges with TLS 1.3

[John Mattsson]

Hi Rich,

Good that you inform the TLS WG. I was planning to do that but forgot. Ericsson 
is likely to provide the comments in the link below. We think it is good that 
NIST is doing this project, visibility is a problem, but our position is that 
reuse of key shares is not an acceptable solution.

https://github.com/emanjon/Publications/blob/main/Ericsson%20comments%20on%20NIST%20SP%201800-37A%20May%2013.pdf

Cheers,
John

From: TLS  on behalf of Salz, Rich 

Date: Tuesday, 16 May 2023 at 13:19
To: tls@ietf.org 
Subject: [TLS] NIST Draft comments period: Addressing Visibility Challenges 
with TLS 1.3
Public comment period open until June 26.

Quoting from https://content.govdelivery.com/accounts/USNIST/bulletins/359534b

This project builds on our earlier work, 
“https://www.nccoe.nist.gov/tls-server-certificate-management,” which showed 
organizations how to centrally monitor and manage their TLS certificates. We 
are now focusing on protocol enhancements such as TLS 1.3 which have helped 
organizations boost performance and address security concerns. These same 
enhancements have also reduced enterprise visibility into internal traffic 
flows within the organizations' environment. This project aims to change 
that--and has two main objectives:
• Provide security and IT professionals practical approaches and tools to help 
them gain more visibility into the information being exchanged on their 
organizations’ servers.
• Help users fully adopt TLS 1.3 in their private data centers and in hybrid 
cloud environments—while maintaining regulatory compliance, security, and 
operations.


___
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] Weakly authenticated ciphers (was about draft-mattsson-cfrg-aes-gcm-sst)

[John Mattsson]

Martin Thompson wrote:
> I like the idea that we might have a more efficient cipher in this particular 
> way.  I've been a
> fan of OCB for that reason for some time.

OCB has several nice properties, but also several limitation

- It requires a block cipher (which is fine if you only want to use AES)
- It requires both the encrypt and decrypt engine
- Integrity bound is quadratic instead of linear
- Integrity bound depends on q instead of v
  (using the terminology from draft-irtf-cfrg-aead-limits)

For QUIC with l = 2^12:
- IA_OCB  <≈ q^2 / 2^104
- IA_GCM  <≈ v   / 2^115
- IA_POLY <≈ v   / 2^91

I don't know exactly what you consider a "weak" cipher, but the advantage in 
OCB quickly becomes larger than GCM and POLY1305 which are already far 2^-128.

Cheers,
John

From: TLS  on behalf of John Mattsson 

Date: Tuesday, 9 May 2023 at 07:29
To: Martin Thomson , q...@ietf.org , 
tls@ietf.org 
Subject: Re: [TLS] Weakly authenticated ciphers (was about 
draft-mattsson-cfrg-aes-gcm-sst)
Hi Martin,

It is true that with the current construction, the short tags would be used 
also in the TLS 1.3 handshake, but it is worth noting that the TLS 1.3 
handshake is built on SIGMA-I where the security proof is done without the 
AEAD. The AEAD in the SIGMA-I handshake is for confidentiality. TLS 1.3 have 
giant (256- and 384-bit) MACs in the finished messages and the tickets have 
their own independent security. I don't see any big impact looking at it 
quickly.

That said, I don't have any interest in driving short tags for general 
applications. I think it would be useful in specialized use cases like MoQ 
only. It is a bit uncertain which protocols will be used in the future. 
Long-term, QUIC might replace not only most use of TLS and DTLS, but also SCTP 
and SRTP.

Martin Thompson wrote:
>It might be possible to build a QUIC extension that allowed some data to
>be protected differently than other (perhaps using connection IDs; a >popular 
>technique).
That seems like a good idea and a requirement if you are also sending 
application data with higher security requirements.

Cheers,
John

From: TLS  on behalf of Martin Thomson 

Date: Tuesday, 9 May 2023 at 02:25
To: q...@ietf.org , tls@ietf.org 
Subject: [TLS] Weakly authenticated ciphers (was about 
draft-mattsson-cfrg-aes-gcm-sst)
I like the idea that we might have a more efficient cipher in this particular 
way.  I've been a fan of OCB for that reason for some time.

However, I don't think that QUIC or TLS integration is necessarily a good idea 
for this cipher.  SRTP is one thing, but QUIC and TLS have an entirely 
different structure that might make short tags more risky than otherwise.

DTLS-SRTP has a split structure, with the important key agreement piece being 
done with a full (D)TLS handshake.  The handshake is typically protected with 
ciphers that have strong protections against forgery.  In a context where you 
have signaling or data transfer (like WebRTC data channels), that data is also 
protected by the stronger cipher.  Individual media streams are then protected 
with a different cipher, in SRTP.  For instance, you might protect audio with 
one of the truncated HMAC modes.

Now, setting aside the bit where it is ridiculous to insist on shaving a few 
bytes off packets when you have a multi-megabit video flow alongside, weaker 
protections can be useful.  Authentication is a non-trivial proportion of the 
overall cost of sending audio, especially when you want to keep packet rates 
high to reduce latency.  More so when you consider the potential to have 
multiple layers of protection (SFrame), potentially with different tolerance to 
forgery on each.

Choosing a weak cipher (and we should not pretend that this is anything but 
that) means that any weakness affects everything on a connection.  That isn't 
good for QUIC or TLS.

It might be possible to build a QUIC extension that allowed some data to be 
protected differently than other (perhaps using connection IDs; a popular 
technique).  For me, I'd need something like that for this cipher to find a 
role in QUIC.  To that end, I have no interest in negotiating this cipher for 
use in TLS proper.

Cheers,
Martin

On Tue, May 9, 2023, at 06:53, John Mattsson wrote:
> Hi Christian,
>
> Yes, sending to the quic list is a good idea. I think QUIC is likely to
> be used in a huge number of future use cases. Secure short tags might
> be interesting for more use cases than Media over QUIC.
>
> Christian Huitema wrote:
>>If the "short tags" can save per packet overhead while maintaining security 
>>properties
>
> The short tags do increase the forgery probability. The security is only
> ideal with respect to the tag length. For general applications like HTTP/3
> I think you would like to keep the forgery probability per packet close to
> the current level.
>
> In QUIC my understanding is that the maximu

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[John Mattsson]

Agree with Scott. And I think this applies to all NIST PQC code points IETF is 
assigning now. Most of the final standards will change and you cannot have a 
single code point for two different algorithms. Very good that there is a 
comment stating “pre-standards version of Kyber768”.

John

From: TLS  on behalf of Scott Fluhrer (sfluhrer) 

Date: Thursday, 11 May 2023 at 16:23
To: Kampanakis, Panos , Bas Westerbaan 
, Christopher Wood 
Cc: tls@ietf.org 
Subject: Re: [TLS] Consensus call on codepoint strategy for 
draft-ietf-tls-hybrid-design
My opinion: since NIST has announced that “Kyber768 Rounds 3 != The final NIST 
approved version”, we should keep codepoint 0x6399 with its current meaning, 
and allocate a fresh one when NIST does public the Kyber FIPS draft (which is 
likely, but not certainly, what will be the final FIPS approved version…)

From: TLS  On Behalf Of Kampanakis, Panos
Sent: Thursday, May 11, 2023 10:16 AM
To: Bas Westerbaan ; Christopher Wood 

Cc: tls@ietf.org
Subject: Re: [TLS] Consensus call on codepoint strategy for 
draft-ietf-tls-hybrid-design

Great!

So to clarify, when Kyber gets ratified as MLWE_KEM or something like that, 
will we still be using 0x6399 in the keyshare when we are negotiating? Or is  
0x6399 just a temporary codepoint for Kyber768 Round 3 combined with X25519?


From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of Bas 
Westerbaan
Sent: Wednesday, May 10, 2023 3:09 PM
To: Christopher Wood mailto:c...@heapingbits.net>>
Cc: tls@ietf.org
Subject: RE: [EXTERNAL][TLS] Consensus call on codepoint strategy for 
draft-ietf-tls-hybrid-design


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

FYI IANA has added the following entry to the TLS Supported Groups registry:

Value: 25497
Description: X25519Kyber768Draft00
DTLS-OK: Y
Recommended: N
Reference: [draft-tls-westerbaan-xyber768d00-02]
Comment: Pre-standards version of Kyber768

Please see
https://www.iana.org/assignments/tls-parameters

On Mon, May 1, 2023 at 11:59 AM Christopher Wood 
mailto:c...@heapingbits.net>> wrote:
It looks like we have consensus for this strategy. We’ll work to remove 
codepoints from draft-ietf-tls-hybrid-design and then get experimental 
codepoints allocated based on draft-tls-westerbaan-xyber768d00.

Best,
Chris, for the chairs

> On Mar 28, 2023, at 9:49 PM, Christopher Wood 
> mailto:c...@heapingbits.net>> wrote:
>
> As discussed during yesterday's meeting, we would like to assess consensus 
> for moving draft-ietf-tls-hybrid-design forward with the following strategy 
> for allocating codepoints we can use in deployments.
>
> 1. Remove codepoints from draft-ietf-tls-hybrid-design and advance this 
> document through the process towards publication.
> 2. Write a simple -00 draft that specifies the target variant of 
> X25519+Kyber768 with a codepoint from the standard ranges. (Bas helpfully did 
> this for us already [1].) Once this is complete, request a codepoint from 
> IANA using the standard procedure.
>
> The intent of this proposal is to get us a codepoint that we can deploy today 
> without putting a "draft codepoint" in an eventual RFC.
>
> Please let us know if you support this proposal by April 18, 2023. Assuming 
> there is rough consensus, we will move forward with this proposal.
>
> Best,
> Chris, Joe, and Sean
>
> [1] https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-00

___
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] Weakly authenticated ciphers (was about draft-mattsson-cfrg-aes-gcm-sst)

[John Mattsson]

Hi Martin,

It is true that with the current construction, the short tags would be used 
also in the TLS 1.3 handshake, but it is worth noting that the TLS 1.3 
handshake is built on SIGMA-I where the security proof is done without the 
AEAD. The AEAD in the SIGMA-I handshake is for confidentiality. TLS 1.3 have 
giant (256- and 384-bit) MACs in the finished messages and the tickets have 
their own independent security. I don't see any big impact looking at it 
quickly.

That said, I don't have any interest in driving short tags for general 
applications. I think it would be useful in specialized use cases like MoQ 
only. It is a bit uncertain which protocols will be used in the future. 
Long-term, QUIC might replace not only most use of TLS and DTLS, but also SCTP 
and SRTP.

Martin Thompson wrote:
>It might be possible to build a QUIC extension that allowed some data to
>be protected differently than other (perhaps using connection IDs; a >popular 
>technique).
That seems like a good idea and a requirement if you are also sending 
application data with higher security requirements.

Cheers,
John

From: TLS  on behalf of Martin Thomson 

Date: Tuesday, 9 May 2023 at 02:25
To: q...@ietf.org , tls@ietf.org 
Subject: [TLS] Weakly authenticated ciphers (was about 
draft-mattsson-cfrg-aes-gcm-sst)
I like the idea that we might have a more efficient cipher in this particular 
way.  I've been a fan of OCB for that reason for some time.

However, I don't think that QUIC or TLS integration is necessarily a good idea 
for this cipher.  SRTP is one thing, but QUIC and TLS have an entirely 
different structure that might make short tags more risky than otherwise.

DTLS-SRTP has a split structure, with the important key agreement piece being 
done with a full (D)TLS handshake.  The handshake is typically protected with 
ciphers that have strong protections against forgery.  In a context where you 
have signaling or data transfer (like WebRTC data channels), that data is also 
protected by the stronger cipher.  Individual media streams are then protected 
with a different cipher, in SRTP.  For instance, you might protect audio with 
one of the truncated HMAC modes.

Now, setting aside the bit where it is ridiculous to insist on shaving a few 
bytes off packets when you have a multi-megabit video flow alongside, weaker 
protections can be useful.  Authentication is a non-trivial proportion of the 
overall cost of sending audio, especially when you want to keep packet rates 
high to reduce latency.  More so when you consider the potential to have 
multiple layers of protection (SFrame), potentially with different tolerance to 
forgery on each.

Choosing a weak cipher (and we should not pretend that this is anything but 
that) means that any weakness affects everything on a connection.  That isn't 
good for QUIC or TLS.

It might be possible to build a QUIC extension that allowed some data to be 
protected differently than other (perhaps using connection IDs; a popular 
technique).  For me, I'd need something like that for this cipher to find a 
role in QUIC.  To that end, I have no interest in negotiating this cipher for 
use in TLS proper.

Cheers,
Martin

On Tue, May 9, 2023, at 06:53, John Mattsson wrote:
> Hi Christian,
>
> Yes, sending to the quic list is a good idea. I think QUIC is likely to
> be used in a huge number of future use cases. Secure short tags might
> be interesting for more use cases than Media over QUIC.
>
> Christian Huitema wrote:
>>If the "short tags" can save per packet overhead while maintaining security 
>>properties
>
> The short tags do increase the forgery probability. The security is only
> ideal with respect to the tag length. For general applications like HTTP/3
> I think you would like to keep the forgery probability per packet close to
> the current level.
>
> In QUIC my understanding is that the maximum plaintext is 2^12 128-bit
> blocks and the length of the associated data is negligible. The
> security level of the 128-bit AES-GCM tags is therefore t – log2(n + m
> + 1) ≈ 128 - 12 = 116 bits.
>
> With AES-GCM-SST in QUIC you would get ideal forgery probability ≈ 2^-t
> for tags of length t <= 14 bytes.
>
> Cheers,
> John
>
> *From: *CFRG  on behalf of Christian Huitema
> 
> *Date: *Sunday, 7 May 2023 at 20:07
> *To: *John Mattsson , IRTF
> CFRG , sfr...@ietf.org , m...@ietf.org
> 
> *Subject: *Re: [CFRG] [Moq] FW: New Version Notification for
> draft-mattsson-cfrg-aes-gcm-sst-00.txt
> John,
>
> You should probably send this to the QUIC list as well. Media over QUIC
> is just one application of QUIC. If the "short tags" can save per packet
> overhead while maintaining security properties, then they are
> interesting for many QUIC applications.
>
> -- Christian Huitema
>
> On 5/5/2023 7:45 AM, John Mattsson 

[TLS] Fwd: WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

[John Mattsson]

Hi,

I think RFC8447bis need to say something about at least DTLS 1.3 Record Number 
Encryption

The two AEGIS algorithms recently got code points and DTLS-OK = Y even if there 
was no specification on how to do DTLS 1.3 Record Number Encryption
https://datatracker.ietf.org/doc/draft-irtf-cfrg-aegis-aead/
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

Both DTLS 1.3 Record Number Encryption and QUIC Header Protection will be added 
in the next version of the AEGIS draft. It is already merged to main.
https://github.com/jedisct1/draft-aegis-aead

Given that TLS WG is discussing deprecating (D)TLS 1.2 I don’t think you should 
get DTLS-OK = Y unless you specify how to do DTLS 1.3 Record Number Encryption.

At a minimum I think people should be reminded to specify QUIC and DTLS 1.3 
Header Protection. I also think it need to be clear that you don’t get DTLS-OK 
= Y unless you specify how to do DTLS 1.3 Record Number Encryption.

My preference would be a new column “Protocols” specifying which protocols the 
cipher suite can be used in. After the update the value for the AEGIS 
algorithms in that column would be “TLS 1.3, DTLS 1.3, QUIC”

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

Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

[John Mattsson]

>However, the IETF standardizing any TLS MITM/visibility options would be a 
>>net negative, from my perspective. That would increase the (already 
>>significant) pressure on TLS stack implementors to provide these “visibility” 
>>solutions. This pressure already comes from a lot of different angles.

I agree, what I think IETF should do is to say what NOT to do. It is great that 
UTA already says MUST NOT negotiate NULL encryption. NULL encryption has no 
legitimate use cases. I think IETF should also take a strong stand against 
reuse of key shares. Reuse of key shares is a minor optimization that has a 
large number of problems:
- It is a very bad way to do visibility as you lose “Forward secret with 
respect to long-term keys”. I don’t think it is acceptable at all.
- It enables identification and tracking of clients and servers.
- To enable resuse you need random numbers which significantly increases the 
size of cTLS. Without reuse you don’t need separate randoms. Except for psk_ke 
which should not be used anyway.
- random numbers can be used by attackers as shown by 
draft-rescorla-tls-extended-random.

Cheers,
John

From: Rob Sayre 
Date: Saturday, 8 April 2023 at 00:03
To: Andrei Popov 
Cc: John Mattsson , Christopher Wood 
, Sean Turner , TLS@ietf.org 

Subject: Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile
On Fri, Apr 7, 2023 at 2:19 PM Rob Sayre 
mailto:say...@gmail.com>> wrote:
Hi,

I think this concern is really reasonable.

I would suggest publishing it on the independent stream, not AD sponsorship. 
It's not an end-run around any IETF activity, but it should be documented.

thanks,
Rob

And, just in case anyone reading this is not a standards dork (like me), here 
is why this path exists:

https://www.rfc-editor.org/about/independent/

"The Independent Submission Stream allows RFC publication for some documents 
that are outside the official processes of the IETF, IAB, and IRTF but are 
relevant to the Internet community and achieve reasonable levels of technical 
and editorial quality."

This example seems like a textbook case. The only thing that I disagree with 
the chairs on is "IETF change control". I think that is radioactive and the 
IETF shouldn't touch it.

Reasonable people can disagree,
Rob





On Fri, Apr 7, 2023 at 11:19 AM Andrei Popov 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:

  *   That seems way to soft and does not say anything about reusing a key 
share in an _ECDHE_ cipher suite for a long time making it static. But 
RFC8446bis now has added SHOULD NOT reuse key share which is very welcome. My 
preference would be MUST NOT reuse.
Agreed, and I also generally agree with your analysis of options 1-4.

However, the IETF standardizing any TLS MITM/visibility options would be a net 
negative, from my perspective. That would increase the (already significant) 
pressure on TLS stack implementors to provide these “visibility” solutions. 
This pressure already comes from a lot of different angles.

Cheers,

Andrei

From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of John 
Mattsson
Sent: Friday, April 7, 2023 8:25 AM
To: Andrei Popov 
mailto:40microsoft@dmarc.ietf.org>>;
 John Mattsson 
mailto:40ericsson@dmarc.ietf.org>>;
 Christopher Wood mailto:c...@heapingbits.net>>; Sean 
Turner mailto:s...@sn3rd.com>>
Cc: TLS@ietf.org<mailto:TLS@ietf.org>
Subject: [EXTERNAL] Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile


Thanks!

>“Implementations MUST NOT negotiate the cipher suites with NULL encryption.”
I will add a link to RFC 9325 in the next version of 
draft-mattsson-tls-psk-ke-dont-dont-don’t

>“Implementations SHOULD NOT negotiate cipher suites based on non-ephemeral 
>(static) finite-field Diffie-Hellman (DH) key agreement.”
That seems way to soft and does not say anything about reusing a key share in 
an _ECDHE_ cipher suite for a long time making it static. But RFC8446bis now 
has added SHOULD NOT reuse key share which is very welcome. My preference would 
be MUST NOT reuse.
Cheers,
John

From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
Andrei Popov 
mailto:Andrei.Popov=40microsoft@dmarc.ietf.org>>
Date: Thursday, 6 April 2023 at 20:08
To: John Mattsson 
mailto:john.mattsson=40ericsson@dmarc.ietf.org>>,
 Christopher Wood mailto:c...@heapingbits.net>>, Sean 
Turner mailto:s...@sn3rd.com>>
Cc: TLS@ietf.org<mailto:TLS@ietf.org> mailto:TLS@ietf.org>>
Subject: Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

  *   Maybe IETF (e.g., UTA) could say what organizations should definitely not 
do (like NULL encryption).
This is already done. UTA BCPs prohibit NULL encryption and static DH: 
https://www.rfc-editor.org/rfc/rfc9325.html
“Implementations MUST NOT negotiate the cipher suites with NULL encryption.”
“Implementations SHOULD NOT negotiate cipher suites based on non-ephe

Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

[John Mattsson]

Thanks!

>“Implementations MUST NOT negotiate the cipher suites with NULL encryption.”
I will add a link to RFC 9325 in the next version of 
draft-mattsson-tls-psk-ke-dont-dont-don’t

>“Implementations SHOULD NOT negotiate cipher suites based on non-ephemeral 
>(static) finite-field Diffie-Hellman (DH) key agreement.”
That seems way to soft and does not say anything about reusing a key share in 
an _ECDHE_ cipher suite for a long time making it static. But RFC8446bis now 
has added SHOULD NOT reuse key share which is very welcome. My preference would 
be MUST NOT reuse.

Cheers,
John

From: TLS  on behalf of Andrei Popov 

Date: Thursday, 6 April 2023 at 20:08
To: John Mattsson , Christopher 
Wood , Sean Turner 
Cc: TLS@ietf.org 
Subject: Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

  *   Maybe IETF (e.g., UTA) could say what organizations should definitely not 
do (like NULL encryption).
This is already done. UTA BCPs prohibit NULL encryption and static DH: 
https://www.rfc-editor.org/rfc/rfc9325.html
“Implementations MUST NOT negotiate the cipher suites with NULL encryption.”
“Implementations SHOULD NOT negotiate cipher suites based on non-ephemeral 
(static) finite-field Diffie-Hellman (DH) key agreement.”

Cheers,

Andrei

From: TLS  On Behalf Of John Mattsson
Sent: Thursday, April 6, 2023 7:41 AM
To: Christopher Wood ; Sean Turner 
Cc: TLS@ietf.org
Subject: [EXTERNAL] Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

Hi,

So, what should people do regarding visibility? There are obviously 
organizations that think they need visibility. I see the topic popping up 
frequently in a lot of different places. Both in IETF and outside.

I see four ways to achieve visibility.

  1. Do things in the endpoints.
  2. Use NULL encryption
  3. Use a static DH key instead of ephemeral. Share static DH key.
  4. Export session keys to intermediate node.

I don't see 2 and 3 are not viable solutions at all, ever.

Regarding 2. it violates several of the TLS security properties. NIST states as 
the first basic assumption for network connectivity for any organization that 
utilizes zero trust is that:

"The entire enterprise private network is not considered an implicit trust 
zone. Assets should always act as if an attacker is present on the enterprise 
network, and communication should be done in the most secure manner available. 
This entails actions such as authenticating all connections and encrypting all 
traffic."

Regarding 3. it violates one of the fundamental TLS 1.3 security properties 
namely "Forward secret with respect to long-term keys". It also violates zero 
trust principles. Two essential zero trust principles according to NIST and NSA 
are to assume that breach is inevitable or has likely already occurred and to 
minimize the impact when breach occur. One type of breach is key compromise. 
Using PFS is a must to limit the impact of key compromise and therefore to 
follow zero trust principles.

The only viable solutions I see are therefore 1 or 4:

1. do things in the endpoints

4. export sessions keys to the intermediary and making sure that the 
intermediary does not store the keys long term. Storing the session keys long 
term violates the TLS security properties and the zero trust principles 
described above.

Regarding 4. there are many different solutions.

- SSLKEYLOGFILE is a de facto standard for exporting TLS key material.

- ETSI CYBER has standardized Middlebox Security Protocol.
https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/01.01.01_60/ts_10352303v010101p.pdf

- Proprietary solutions such as
https://www.nubeva.com/pillar/get-session-keys<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-5f34a1d271355f52=1=f3aeeac6-dde5-492c-8992-c755e6a13aca=https%3A%2F%2Fwww.nubeva.com%2Fpillar%2Fget-session-keys>

If IETF cannot say that anything is recommended. Maybe IETF (e.g., UTA) could 
say what organizations should definitely not do (like NULL encryption). Seems 
like a lot of organizations are deploying different kinds of solutions right 
now. They will likely do less secure things than necessary...

Cheers,
John

From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
Christopher Wood mailto:c...@heapingbits.net>>
Date: Thursday, 19 January 2023 at 15:57
To: Sean Turner mailto:s...@sn3rd.com>>
Cc: TLS@ietf.org<mailto:TLS@ietf.org> mailto:tls@ietf.org>>
Subject: Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile
Hi folks,

Apologies for the delay in concluding this adoption call. To close the loop 
here, it doesn’t look like we have sufficient support to adopt the document as 
a WG item.

The chairs would like to recommend AD sponsorship as a viable path forward for 
this document. This should achieve the desired end goal of moving change 
control from the fine folks maintaining NSS to the IETF while also nailing down 
the now widely supported for

Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

[John Mattsson]

Hi,

So, what should people do regarding visibility? There are obviously 
organizations that think they need visibility. I see the topic popping up 
frequently in a lot of different places. Both in IETF and outside.

I see four ways to achieve visibility.
  1. Do things in the endpoints.
  2. Use NULL encryption
  3. Use a static DH key instead of ephemeral. Share static DH key.
  4. Export session keys to intermediate node.
I don't see 2 and 3 are not viable solutions at all, ever.

Regarding 2. it violates several of the TLS security properties. NIST states as 
the first basic assumption for network connectivity for any organization that 
utilizes zero trust is that:
"The entire enterprise private network is not considered an implicit trust 
zone. Assets should always act as if an attacker is present on the enterprise 
network, and communication should be done in the most secure manner available. 
This entails actions such as authenticating all connections and encrypting all 
traffic."

Regarding 3. it violates one of the fundamental TLS 1.3 security properties 
namely "Forward secret with respect to long-term keys". It also violates zero 
trust principles. Two essential zero trust principles according to NIST and NSA 
are to assume that breach is inevitable or has likely already occurred and to 
minimize the impact when breach occur. One type of breach is key compromise. 
Using PFS is a must to limit the impact of key compromise and therefore to 
follow zero trust principles.

The only viable solutions I see are therefore 1 or 4:

1. do things in the endpoints

4. export sessions keys to the intermediary and making sure that the 
intermediary does not store the keys long term. Storing the session keys long 
term violates the TLS security properties and the zero trust principles 
described above.

Regarding 4. there are many different solutions.

- SSLKEYLOGFILE is a de facto standard for exporting TLS key material.

- ETSI CYBER has standardized Middlebox Security Protocol.
https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/01.01.01_60/ts_10352303v010101p.pdf

- Proprietary solutions such as
https://www.nubeva.com/pillar/get-session-keys

If IETF cannot say that anything is recommended. Maybe IETF (e.g., UTA) could 
say what organizations should definitely not do (like NULL encryption). Seems 
like a lot of organizations are deploying different kinds of solutions right 
now. They will likely do less secure things than necessary...

Cheers,
John

From: TLS  on behalf of Christopher Wood 

Date: Thursday, 19 January 2023 at 15:57
To: Sean Turner 
Cc: TLS@ietf.org 
Subject: Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile
Hi folks,

Apologies for the delay in concluding this adoption call. To close the loop 
here, it doesn’t look like we have sufficient support to adopt the document as 
a WG item.

The chairs would like to recommend AD sponsorship as a viable path forward for 
this document. This should achieve the desired end goal of moving change 
control from the fine folks maintaining NSS to the IETF while also nailing down 
the now widely supported format used in production.

Best,
Chris, for the chairs

> On Nov 28, 2022, at 1:41 PM, Sean Turner  wrote:
>
> Hi!
>
> At TLS@IETF115, the sense of the room was that there was WG support to adopt 
> draft-thomson-tls-keylogfile [1].  This message is to judge consensus on 
> whether the WG should adopt draft-thomson-tls-keylogfile. Please indicate 
> whether you do or do not support adoption of this I-D by 2359UTC on 12 
> December 2022. If do not support adoption, please indicate why.
>
> Cheers,
> Chris, Joe, and Sean
>
> [1] https://datatracker.ietf.org/doc/draft-thomson-tls-keylogfile/
> ___
> 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

Re: [TLS] I-D Action: draft-ietf-tls-deprecate-obsolete-kex-02.txt

[John Mattsson]

Hi,

5.  IANA Considerations

This document requests IANA to mark the cipher suites listed in Appendix C as 
not recommended in the "TLS Cipher Suites" registry. Note that all cipher 
suites listed in Appendix A and in Appendix D are already marked as not 
recommended in the registry.


How do we split the IANA actions for cipher suites between this document, 
RFC8447, and draft-mattsson-tls-psk-ke-dont-dont-dont?

”N” seems highly inappropriate for TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
that is very clearly a “D”

What about TLS_DHE_RSA_WITH_AES_128_GCM_SHA256. Is that a ”N”? The definition 
of discourage is clear with RFC8447bis. The definition of deprecated is not as 
clear.

Cheers,
John


From: TLS  on behalf of internet-dra...@ietf.org 

Date: Sunday, 26 March 2023 at 00:54
To: i-d-annou...@ietf.org 
Cc: tls@ietf.org 
Subject: [TLS] I-D Action: draft-ietf-tls-deprecate-obsolete-kex-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Transport Layer
Security (TLS) WG of the IETF.

   Title   : Deprecating Obsolete Key Exchange Methods in TLS 1.2
   Authors : Carrick Bartle
 Nimrod Aviram
   Filename: draft-ietf-tls-deprecate-obsolete-kex-02.txt
   Pages   : 20
   Date: 2023-03-25

Abstract:
   This document deprecates the use of RSA key exchange and Diffie
   Hellman over a finite field in TLS 1.2, and discourages the use of
   static elliptic curve Diffie Hellman cipher suites.

   Note that these prescriptions apply only to TLS 1.2 since TLS 1.0 and
   1.1 are deprecated by [RFC8996] and TLS 1.3 either does not use the
   affected algorithm or does not share the relevant configuration
   options.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-02.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-deprecate-obsolete-kex-02

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
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] New Version Notification for draft-mattsson-tls-compact-ecc-04.txt

[John Mattsson]

This version just fixes a few nits.

- I think the new encodings make sense for cTLS where my understanding is that 
people likely want to keep using P-256 key share. Then the new encodings save 
80 bytes per mutually authenticated handshake.
- The new encodings are not needed for non-constrained TLS. There x25519 rules 
and the new ECDSA encoding in a handshake where only the server is 
authenticated saves 7 bytes.
- I think new code points should only be registered if people want to use this 
in cTLS.

Cheers,
John

From: internet-dra...@ietf.org 
Date: Wednesday, 29 March 2023 at 13:20
To: John Mattsson , John Mattsson 

Subject: New Version Notification for draft-mattsson-tls-compact-ecc-04.txt

A new version of I-D, draft-mattsson-tls-compact-ecc-04.txt
has been successfully submitted by John Preuß Mattsson and posted to the
IETF repository.

Name:   draft-mattsson-tls-compact-ecc
Revision:   04
Title:  Compact ECDHE and ECDSA Encodings for TLS 1.3
Document date:  2023-03-29
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/archive/id/draft-mattsson-tls-compact-ecc-04.txt
Status: https://datatracker.ietf.org/doc/draft-mattsson-tls-compact-ecc/
Html:   
https://www.ietf.org/archive/id/draft-mattsson-tls-compact-ecc-04.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-mattsson-tls-compact-ecc
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-compact-ecc-04

Abstract:
   The encodings used in the ECDHE groups secp256r1, secp384r1, and
   secp521r1 and the ECDSA signature algorithms ecdsa_secp256r1_sha256,
   ecdsa_secp384r1_sha384, and ecdsa_secp521r1_sha512 have significant
   overhead and the ECDSA encoding produces variable-length signatures.
   This document defines new optimal fixed-length encodings and
   registers new ECDHE groups and ECDSA signature algorithms using these
   new encodings.  The new encodings reduce the size of the ECDHE groups
   with 33, 49, and 67 bytes and the ECDSA algorithms with an average of
   7 bytes.  These new encodings also work in DTLS 1.3 and are
   especially useful in cTLS.




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

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

[John Mattsson]

On Sun, Jan 29, 2023, at 10:46, Joseph Salowey wrote:
> I think the current working group consensus for the policy of the
> recommended column is reflected in the following statement:

I can live with that. I definitely don’t want Rich to quit.

Martin Thomson:
>"Y" and "D" are both effective statements because they come with the 
>"authority" of the IETF (for what that
> is worth). To require any lesser process than consensus would undermine the 
> value of the label.

That is a good point.

Cheers,
John

From: TLS  on behalf of Martin Thomson 

Date: Monday, 30 January 2023 at 00:25
To: tls@ietf.org 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt
On Sun, Jan 29, 2023, at 10:46, Joseph Salowey wrote:
> I think the current working group consensus for the policy of the
> recommended column is reflected in the following statement:
>
> Setting a value to "Y" or "D" in the "Recommended" column requires IETF
> Standards Action [RFC8126
> ].
> Any state transition to or from a "Y" or "D" value requires IESG
> Approval."

This is my position, so don't change it :)  John wants to mark a ton of things 
with "D".  I think that a good number of the things he asks for should be 
marked "D", but I wouldn't want an expert to be put in that position.  "Y" and 
"D" are both effective statements because they come with the "authority" of the 
IETF (for what that is worth). To require any lesser process than consensus 
would undermine the value of the label.

___
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] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

[John Mattsson]

Hi Rich,

New suggestion for specification required: Items violating the security 
properties shall be marked as D. Otherwise N.

It is not hard to see that e.g., NULL encryption violates the properties.

The alternative is that someone afterwards need to write a standards track 
draft and progress that through IETF. As an author of such a draft I would 
rather not have do that work. I would much rather help evaluating if an item 
violates the properties before registration.

https://datatracker.ietf.org/doc/draft-mattsson-tls-psk-ke-dont-dont-dont/

Cheers,
John

Sent from Outlook for iOS<https://aka.ms/o0ukef>

From: Salz, Rich 
Sent: Saturday, January 28, 2023 6:17 PM
To: John Mattsson ; TLS@ietf.org 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

As one of the designated experts, I would rather not make that judgement call.  
It’s enough to verify that there is documentation and it is possible to 
implement from that documentation.

From: John Mattsson 
Date: Saturday, January 28, 2023 at 11:57 AM
To: "tls@ietf.org" 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

Hi,

The current document states that setting the Recommended item to "D" requires 
Standards Action. I think the designated experts should be given the ability to 
mark specification required registrations as “D” Discouraged. In particular, I 
think the designated experts should mark anything that violates the security 
properties described in Appendix F of RFC 8446 as Discouraged, but I think the 
experts should be given the ability to mark anything they think “might result 
in problems if they are used, such as a weak cryptographic algorithm or a 
mechanism that might cause interoperability problems in deployment.” as “D” 
Discouraged.



Cheers,

John

From: TLS  on behalf of John Mattsson 

Date: Thursday, 12 January 2023 at 07:09
To: tls@ietf.org 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt
Hi,

I really like the updates to the Recommended column. Making "Y" normative 
RECOMMENDED and introducing "D" seems like great changes. Good job!


Some high level comments/questions/suggestions
-

- It is very hard to understand from the TLS Cipher Suites registry which 
cipher suites that can be used in TLS 1.3. I think it would be good to 
introduce a TLS 1.3 column.

- Should TLS versions (0x0304, 0x303, ...) and their Recommended status be 
added as a new registry? I think that would be good.

- Maybe rename "DTLS-OK" to "DTLS"? md5 can be e.g. be used in DTLS but is not 
ok to use in DTLS.

- How do one find information on which parameters are QUIC-OK?


Comments on current text:
-

- "undertaken as part of the TLS 1.3 development process."
The abstract should be updated. The part above could be removed.

I think the IANA policies need more work. See some examples below:

- "Setting the Recommended item to "Y" or "D" or changing a item whose
current value is "Y" or "D" requires Standards Action [RFC8126]."
This seems redundant as there is a sentence below it that say the same thing in 
a much better way: “Changing the Recommended status of an item in a Standards 
Track RFC requires Standards Action [RFC8126].”

- "Adding a value Y to the "Recommended" column requires Standards Action 
{{RFC8126}}."
Seems to be different from the general rule above.

- "IESG Approval is REQUIRED for a Y->N transition."
Also Y->D I assume

Cheers,
John

From: TLS  on behalf of internet-dra...@ietf.org 

Date: Monday, 24 October 2022 at 18:32
To: i-d-annou...@ietf.org 
Cc: tls@ietf.org 
Subject: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : IANA Registry Updates for TLS and DTLS
Authors : Joe Salowey
  Sean Turner
  Filename: draft-ietf-tls-rfc8447bis-02.txt
  Pages   : 22
  Date: 2022-10-23

Abstract:
   This document describes a number of changes to TLS and DTLS IANA
   registries that range from adding notes to the registry all the way
   to changing the registration policy.  These changes were mostly
   motivated by WG review of the TLS- and DTLS-related registries
   undertaken as part of the TLS 1.3 development process.

   This document obsoletes RFC 8447 and updates the following RFCs:
   3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/__;!!GjvTz_vk!QqPr9x6IrhEPWJfLGVqNYz3rfCaztfoH4JpYD5iw106aYZ

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

[John Mattsson]

Hi,

The current document states that setting the Recommended item to "D" requires 
Standards Action. I think the designated experts should be given the ability to 
mark specification required registrations as “D” Discouraged. In particular, I 
think the designated experts should mark anything that violates the security 
properties described in Appendix F of RFC 8446 as Discouraged, but I think the 
experts should be given the ability to mark anything they think “might result 
in problems if they are used, such as a weak cryptographic algorithm or a 
mechanism that might cause interoperability problems in deployment.” as “D” 
Discouraged.



Cheers,

John

From: TLS  on behalf of John Mattsson 

Date: Thursday, 12 January 2023 at 07:09
To: tls@ietf.org 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt
Hi,

I really like the updates to the Recommended column. Making "Y" normative 
RECOMMENDED and introducing "D" seems like great changes. Good job!


Some high level comments/questions/suggestions
-

- It is very hard to understand from the TLS Cipher Suites registry which 
cipher suites that can be used in TLS 1.3. I think it would be good to 
introduce a TLS 1.3 column.

- Should TLS versions (0x0304, 0x303, ...) and their Recommended status be 
added as a new registry? I think that would be good.

- Maybe rename "DTLS-OK" to "DTLS"? md5 can be e.g. be used in DTLS but is not 
ok to use in DTLS.

- How do one find information on which parameters are QUIC-OK?


Comments on current text:
-

- "undertaken as part of the TLS 1.3 development process."
The abstract should be updated. The part above could be removed.

I think the IANA policies need more work. See some examples below:

- "Setting the Recommended item to "Y" or "D" or changing a item whose
current value is "Y" or "D" requires Standards Action [RFC8126]."
This seems redundant as there is a sentence below it that say the same thing in 
a much better way: “Changing the Recommended status of an item in a Standards 
Track RFC requires Standards Action [RFC8126].”

- "Adding a value Y to the "Recommended" column requires Standards Action 
{{RFC8126}}."
Seems to be different from the general rule above.

- "IESG Approval is REQUIRED for a Y->N transition."
Also Y->D I assume

Cheers,
John

From: TLS  on behalf of internet-dra...@ietf.org 

Date: Monday, 24 October 2022 at 18:32
To: i-d-annou...@ietf.org 
Cc: tls@ietf.org 
Subject: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : IANA Registry Updates for TLS and DTLS
Authors : Joe Salowey
  Sean Turner
  Filename: draft-ietf-tls-rfc8447bis-02.txt
  Pages   : 22
  Date: 2022-10-23

Abstract:
   This document describes a number of changes to TLS and DTLS IANA
   registries that range from adding notes to the registry all the way
   to changing the registration policy.  These changes were mostly
   motivated by WG review of the TLS- and DTLS-related registries
   undertaken as part of the TLS 1.3 development process.

   This document obsoletes RFC 8447 and updates the following RFCs:
   3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-02.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc8447bis-02


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
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] about hash and post-quantum ciphers

[John Mattsson]

Hi Ilari,

>Why wait for those? It seems to me that one could add the SHA-3
>ciphersuites already, as SHA-3 has been standardized years ago.

Good idea, I will start wring on a draft doing that just that.

>Well, duplex mode is a bit special-purpose thing, for cases where one
>wants to reduce number of primitives to reduce code size, or has
>hardware acceleration to make it much faster than AES-GCM.

That is also a good idea. NIST stated a long time ago that they would
standardize an AEAD based on Keccak, but that has not happened so far.
I was thinking that Keccak duplex mode could be used in the key schedule. It 
feels
high level like a more natural construct for a key schedule. You cen see it
as a generalization of the running hash interface.

Running hash:
init(), update(Mi), digest = finalize()

Duplex:
init(), digest = update(Mi, length)

But it might too much changes and too little gain to do.

Cheers,
John


From: TLS  on behalf of Ilari Liusvaara 

Date: Friday, 27 January 2023 at 19:15
To: tls@ietf.org 
Subject: Re: [TLS] about hash and post-quantum ciphers
On Fri, Jan 27, 2023 at 11:24:59AM +, John Mattsson wrote:
> Hi,
>
> I don't think non-standardized algorithms should be adopted by the
> WG. Even for just assigning a number, a good first step would be CFRG.

Well, getting adopted by the WG isn't a requirement for those to wind up
with a number... There is expert review process as well.

I think it might be time for experimental PQC codepoints for final
round of testing before the final PQC algorithms. Recommended=N of
course.


> But this mail got me thinking:
>
> - NIST is expected to exclusively use SHA3 in the lattice-based PQC
>   algorithms. I think it would make very much sense to include SHA3
>   (the SHAKE variants) at the same time as the standardized NIST PQC
>   algorithms.

Why wait for those? It seems to me that one could add the SHA-3
ciphersuites already, as SHA-3 has been standardized years ago.

- TLS_AES_128_GCM_SHA3_32
- TLS_AES_256_GCM_SHA3_48
- TLS_CHACHA20_POLY1305_SHA3_32
- TLS_KECCAK_DUPLEX_SHA3_48

I think all could use 256-level SHA-3, I don't think dropping to
128-level for AES-128 is worth it.


> - TLS 1.3 hardcodes use of the quite outdated HMAC and HDKF
>   constructions that only exists because SHA2 is fixed-length and
>   suffers badly from length-extension attacks. Modern hash algorithm
>   like SHAKE/KMAC are variable-length and does not suffer from
>   length-extension attacks. If SHA3 is added in the future, I think
>   it would make sense to use KMAC instead of HMAC and HKDF. Might also
>   be nice to use the duplex construction whose security can be shown
>   to be equivalent to the sponge construction.

Well, duplex mode is a bit special-purpose thing, for cases where one
wants to reduce number of primitives to reduce code size, or has
hardware acceleration to make it much faster than AES-GCM.

One might want to design padding in duplex mode so that each data block
is 128 octets... And another trick is only supporting plaintext sizes
multiple of 8 octets (TLS 1.3 record layer can pad to it anyway).


And TLS 1.3 uses hash function in four ways:

- Raw hash (Transcript-Hash).
- Raw HMAC (verify_data).
- KDF extraction (HKDF-Extract). Which actually turns out to be raw
  HMAC under the hood.
- KDF expansion (HKDF-Expand-Label).

To actually use SHA3 to full capacity, one would have to weird stuff
by redefining HKDF-Extract and HKDF-Expand-Label to be something else
than HKDF.

One could optimize a bit by using SHAKE256 instead of KMAC256 for the
last three. I think all the standard stuff would then be doable with
only one Keccak-F per MAC/KDF (maximum 135 octets in, 136 out). This
would save a few Keccak-F computations.



-Ilari

___
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] Security of using same cert for TLS client and server

[John Mattsson]

Thanks Ilari for that very fast and detailed answer. I a made a PR to 
RFC8446bis to suggest adding “A node MAY use the same certificate as both 
server and client certificate.”, I don’t know if there should be more 
restrictions. The real practical problems seem to be cross-protocol attacks on 
the application layer where TLS is used for several application layer protocols.

Cheers,
John

From: TLS  on behalf of Ilari Liusvaara 

Date: Friday, 27 January 2023 at 19:53
To: tls@ietf.org 
Subject: Re: [TLS] Security of using same cert for TLS client and server
On Fri, Jan 27, 2023 at 06:01:04PM +, John Mattsson wrote:
> Hi,
>
> - Using the same signature key or PSK for TLS and another protocol is
>   obviously unsecure in the worst case. But probably practically
>   secure in many cases even if nobody has proved it.

Well, looking at the signatures:

- TLS 1.2 client signatures start with 0x01 (client hello message
  type).
- TLS 1.2 server signatures are messy, as the first 32 octets are
  from client (client random)!
- TLS 1.3 signatures start with 0x20 (explicit padding).
- JOSE signatures start with 0x65 (base64url of '{').
- COSE signatures start with 0x84 or 0x85 (Countersignatures can
  also start with 0x86); (Array of 4, 5 or 6 elements).
- X.509 signatures (S/MIME, PKIX, etc...) typically start with 0x30
  (SEQUENCE type).
- SSH pubkey signatures start with 0x00 (session id is <16MB).
- SSH hostkey signatures are a bit messy, as those seem to be over a
  raw hash.
- SSH signatures start with 0x53 (explicit magic).


So looks like none of those can interact badly with others, except
for TLS 1.2 server signatures and SSH hostkey signatures (and even
those probably don't interact badly in practice)


> - Did any of the formal analysis prove that using the same key for
>   TLS client and server is secure? It is quite common that the same
>   node is a TLS server and client.

For TLS 1.3, it is secure (the signatures have context). For TLS 1.2,
things are more complicated (but it is probably still secure).



-Ilari

___
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] [Pqc] Did TLS AuthKEM die?

[John Mattsson]

Blumenthal, Uri wrote:

>Without getting into details – EDHOC is still more “verbose” than CAKE-HI, 
>thus – not >“minimalistic” (which was one of our design goals). 

The overhead except key shares and MACs in EDHOC is typically 21 bytes. If your 
protocol uses the NIST PQC algorithms with their large public keys and 
encapsulation sizes, I have a hard time to see that this “verbosity” (EDHOC has 
type and length for all fields so that it can be parsed without an agreed 
template) would matter much in practice :)

John 

From: Blumenthal, Uri - 0553 - MITLL 
Date: Friday, 27 January 2023 at 16:09
To: loic.ferre...@orange.com , Thom Wiggers 

Cc: John Mattsson , Mike Ounsworth 
, p...@ietf.org , 
tls@ietf.org 
Subject: Re: [Pqc] [TLS] Did TLS AuthKEM die? 

Thank you Uri. 

My pleasure. 

Then what about CAKE-HI vs. EDHOC? 

Ah, a good question – with a less-technical answer. 

Without getting into details – EDHOC is still more “verbose” than CAKE-HI, thus 
– not “minimalistic” (which was one of our design goals). At this point, EDHOC 
is not PQ, which precludes it from being evaluated and considered in our use 
cases. If DH in EDHOC is replaced by a PQ KEM – the numbers will start favoring 
CAKE-HI, but at this time is doesn’t look like there’s interest to make EDHOC 
Quantum-Resistant. 

I’d say CAKE-HI could replace EDHOC, if and when Quantum Resistance is needed 
(and the channel can tolerate larger packet/message sizes), and when 
template-based approach is preferred to online negotiations. 

By the way is there any specification of CAKE-HI available? 

In the process of “release review”. ;-) 

Thanks! 


Orange Restricted 
De : Blumenthal, Uri - 0553 - MITLL  
Envoyé : jeudi 26 janvier 2023 21:08
À : FERREIRA Loïc INNOV/IT-S ; Thom Wiggers 

Cc : John Mattsson ; Mike Ounsworth 
; p...@ietf.org; tls@ietf.org
Objet : Re: [Pqc] [TLS] Did TLS AuthKEM die? 



How would you compare CAKE-HI and cTLS? 

Loïc, an excellent question. Naturally, there are similarities and differences. 

Similarities: 
1. Both strive to reduce unnecessary communications; 
2. Both strive to avoid unnecessary negotiations; 
3. Both embrace “template-based specialization” that allows avoiding 
negotiations altogether (if I understood this part of cTLS correctly). 

Differences: 
4. Different purpose: 
1. cTLS is a compact Transport Layer Security that protects user data , and 
includes key exchange (as one of the mechanisms it utilizes to achieve its 
goal). 
2. CAKE-HI is a Key Exchange protocol that provides session keys (shared 
secret(s)) to other protocols that handle user data. 
5. Different degree of “minimization”, as CAKE-HI is much more minimalistic 
than cTLS: 
1. cTLS tries to create a “leaner TLS” by paring the “fat” of TLS, 
backward-compatibility with TLS 1.2, etc. But quite a bit of TLS details 
remains there. 
2. CAKE-HI has nothing in common with the TLS handshaking, options, syntax, 
fields, and such. It has a set of cryptographic primitives that it employs to 
generate symmetric shared secret and satisfy security properties listed below. 
6. Thus, CAKE-HI cannot replace cTLS, (among other reasons) because by itself 
it does not provide user data protection (and requires another protocol, like 
SCIP to handle that), nor can cTLS “replace” CAKE-HI because it does a lot of 
things unnecessary for “pure” key exchange and carries more overhead than a 
truly minimalistic AKE needs. 

On the sad part, CAKE-HI specification (actually, we’ll most likely present 
CHAKE-HI, aka – Compact Hybrid Authenticated Key Exchange Hiding Identities) 
lags behind in details that have been provided in cTLS ID 
(https://www.ietf.org/archive/id/draft-ietf-tls-ctls-07.html 
<https://www.ietf.org/archive/id/draft-ietf-tls-ctls-07.html>). But we’ll get 
there. ;-) 

I realize the above is rather sketchy – please feel free to ask more questions, 
and I’ll do my best to answer them. 

Thanks! 



Orange Restricted 
De : Pqc mailto:pqc-boun...@ietf.org>> De la part de 
Blumenthal, Uri - 0553 - MITLL
Envoyé : mercredi 25 janvier 2023 22:49
À : Thom Wiggers mailto:t...@thomwiggers.nl>>
Cc : John Mattsson mailto:john.matts...@ericsson.com>>; Mike Ounsworth 
mailto:Mike.Ounsworth=40entrust@dmarc.ietf.org>>; p...@ietf.org 
<mailto:p...@ietf.org>; tls@ietf.org <mailto:tls@ietf.org>
Objet : Re: [Pqc] [TLS] Did TLS AuthKEM die? 



I'll first ask the first question, and then try to clarify a few of the other 
things raised in this thread. 



> Is AuthKEM dead? 



I'd say it's hibernating. The draft has indeed expired: there was nothing 
significant to add since the last time we edited/updated it. I also couldn't 
make it to the last two IETF meetings (and due to conflict with Real World 
Crypto, I will most likely not be able to make IETF116 either). The TLS working 
group has seemed to want to focus on getting PQ key exchange out of the door, 
but if it's ready to continue the discussion

Re: [TLS] about hash and post-quantum ciphers

[John Mattsson]

Hi,

I don't think non-standardized algorithms should be adopted by the WG. Even for 
just assigning a number, a good first step would be CFRG.

But this mail got me thinking:

- I think the lack of hash algorithm crypto agility in TLS 1.3 is 
unsatisfactory. The _only_ option in TLS 1.3 is SHA2.

- NIST is expected to exclusively use SHA3 in the lattice-based PQC algorithms. 
I think it would make very much sense to include SHA3 (the SHAKE variants) at 
the same time as the standardized NIST PQC algorithms.

- TLS 1.3 hardcodes use of the quite outdated HMAC and HDKF constructions that 
only exists because SHA2 is fixed-length and suffers badly from 
length-extension attacks. Modern hash algorithm like SHAKE/KMAC are 
variable-length and does not suffer from length-extension attacks. If SHA3 is 
added in the future, I think it would make sense to use KMAC instead of HMAC 
and HKDF. Might also be nice to use the duplex construction whose security can 
be shown to be equivalent to the sponge construction.

Cheers,
John

From: TLS  on behalf of Salz, Rich 

Date: Thursday, 26 January 2023 at 20:42
To: hojarasca2022 , tls@ietf.org 

Subject: Re: [TLS] about hash and post-quantum ciphers
In TLS 1.3, AES256-SHA384 is not mandatory to implement.

If there is a freely available published specification of BLAKE3, you can 
request an assigned number for it in the TLS registry [1].


  *   Furthermore, NIST selected some post-quantum ciphers: 
https://nist.gov/pqcrypto

Hm, are you new here?  The archives have a couple hundred messages about 
post-quantum.

[1] 
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Did TLS AuthKEM die?

[John Mattsson]

Using ephemeral-static ECDH for implit authentication as in the Noise protocol 
has several benefits. The benefits of using KEMs instead of signatures seem 
more limited. The current proposal requires 3 full round-trips instead of 1.5 
round-trips for mutual authentication. If I understand correctly, the messages 
sizes are smaller than Kyber+Dilithium but similar to Kyber+Falcon (probably a 
bit larger in total).

If continued, I think Kyber KEMs makes a lot more sense than ECDH KEM. For ECDH 
KEM you can do something much more efficient.

Two comments on the document

- “these proposals require a non-interactive key exchange”
My understandaing of NIKE is that the parties do not have any interaction. One 
example of NIKE is static-static DH. OPTLS uses ephemeral-static DH. I don't 
think it is correct to describe that as NIKE.
https://eprint.iacr.org/2012/732.pdf

- The document could mentioned that to derive the application_traffic_secret, 
an attacker needs more than a single private key. Having a single ephemeral 
private key is no longer enough as it is the case in ordinary certificate based 
TLS 1.3.

Cheers,
John


From: TLS  on behalf of Blumenthal, Uri - 0553 - MITLL 

Date: Tuesday, 24 January 2023 at 19:15
To: Mike Ounsworth , p...@ietf.org 
, tls@ietf.org 
Subject: Re: [TLS] Did TLS AuthKEM die?
I truly hope AuthKEM is alive.

--
V/R,
Uri

There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare


From: TLS  on behalf of Mike Ounsworth 

Date: Tuesday, January 24, 2023 at 12:33
To: "p...@ietf.org" , "tls@ietf.org" 
Subject: [TLS] Did TLS AuthKEM die?

Thom, Sofía,

draft-celi-wiggers-tls-authkem is expired. Is that on purpose? Does it still 
have steam or is it dead?

---
Mike Ounsworth
Software Security Architect, Entrust

Any email and files/attachments transmitted with it are confidential and are 
intended solely for the use of the individual or entity to whom they are 
addressed. If this message has been sent to you in error, you must not copy, 
distribute or disclose of the information it contains. Please notify Entrust 
immediately and delete the message from your system.
___
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

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

[TLS] FW: New Version Notification for draft-mattsson-tls-psk-ke-dont-dont-dont-05.txt

[John Mattsson]

Hi,

I went through all the entries in the Cipher Suites, Supported Groups, and 
Signature Scheme registries including TLS 1.2 entries and found several more 
entries where the “Recommended” value should be downgraded and where the IANA 
downgrading is not currently done by RFC8447bis.


  *   rsa_pkcs1_sha1 and ecdsa_sha1 should be marked as discouraged.
  *   rsa_pkcs1_sha256_legacy, rsa_pkcs1_sha384_legacy, rsa_pkcs1_sha512_legacy 
which enables RSASSA-PKCS1-v1_5 in signed TLS 1.3 handshake messages should be 
marked as discouraged.
  *   In addition to ffdhe2048 there are a lot of TLS 1.2 groups (secp160k1, 
secp160r1, secp160r2, sect163k1, sect163r1, sect163r2, secp192k1, secp192r1, 
sect193r1, sect193r2, secp224k1, secp224r1m sect233k1, sect233r1, and 
sect239k1) with less than 128-bit security that should be marked as 
discouraged. For some reason there seems to be a common misunderstanding on 
requirements on 112-bit security. NIST and ANSSI only allow < 128-bit security 
if the application data does not have to be protected after 2030.
  *   RFC 9113 and draft-ietf-tls-deprecate-obsolete-kex lists a lot of TLS 1.2 
cipher suites like TLS_RSA_WITH_NULL_MD5 that should be marked as discouraged.

This document is now very much related to RFC8447bis and 
draft-ietf-tls-deprecate-obsolete-kex.

Cheers,
John

From: internet-dra...@ietf.org 
Date: Thursday, 19 January 2023 at 19:43
To: John Mattsson , John Mattsson 

Subject: New Version Notification for 
draft-mattsson-tls-psk-ke-dont-dont-dont-05.txt

A new version of I-D, draft-mattsson-tls-psk-ke-dont-dont-dont-05.txt
has been successfully submitted by John Preuß Mattsson and posted to the
IETF repository.

Name:   draft-mattsson-tls-psk-ke-dont-dont-dont
Revision:   05
Title:  NULL Encryption and Key Exchange Without Forward Secrecy are 
Discouraged
Document date:  2023-01-19
Group:  Individual Submission
Pages:  16
URL:
https://www.ietf.org/archive/id/draft-mattsson-tls-psk-ke-dont-dont-dont-05.txt
Status: 
https://datatracker.ietf.org/doc/draft-mattsson-tls-psk-ke-dont-dont-dont/
Html:   
https://www.ietf.org/archive/id/draft-mattsson-tls-psk-ke-dont-dont-dont-05.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-mattsson-tls-psk-ke-dont-dont-dont
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-psk-ke-dont-dont-dont-05

Abstract:
   Massive pervasive monitoring attacks using key exfiltration and made
   possible by key exchange without forward secrecy have been reported.
   If key exchange without Diffie-Hellman is used, static exfiltration
   of the long-term authentication keys enables passive attackers to
   compromise all past and future connections.  Malicious actors can get
   access to long-term keys in different ways: physical attacks,
   hacking, social engineering attacks, espionage, or by simply
   demanding access to keying material with or without a court order.
   Exfiltration attacks are a major cybersecurity threat.  If NULL
   encryption is used an on-path attacker can read all application data.
   The use of psk_ke and NULL encryption are not following zero trust
   principles of minimizing the impact of breach and governments have
   already made deadlines for their deprecation.  This document
   evaluates TLS pre-shared key exchange modes, (EC)DHE groups,
   signature algorithms, and cipher suites and downgrades many entries
   to "N" and "D" where "D" indicates that the entries are
   "Discouraged".




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

[TLS] FW: New Version Notification for draft-mattsson-tls-compact-ecc-03.txt

[John Mattsson]

Hi,

Changes:

  *   Clarified that point validation MUST be done as pointed out by Dan Brown 
and Scott Fluhrer
  *   Removed questionable statements in the security considerations after 
comments by Dan Brown
  *   Added an explanation of point compression and compact representation as 
suggested by Hannes Tschofenig.

The main use case for the draft is cTLS with P-256 and ECDSA, which is 
something I suspect that people want to do. As pointed out be Scott the same 
message sizes can already be achieved with x25519 and ed25519.

Cheers,
John

From: internet-dra...@ietf.org 
Date: Thursday, 19 January 2023 at 08:37
To: John Mattsson , John Mattsson 

Subject: New Version Notification for draft-mattsson-tls-compact-ecc-03.txt

A new version of I-D, draft-mattsson-tls-compact-ecc-03.txt
has been successfully submitted by John Preuß Mattsson and posted to the
IETF repository.

Name:   draft-mattsson-tls-compact-ecc
Revision:   03
Title:  Compact ECDHE and ECDSA Encodings for TLS 1.3
Document date:  2023-01-19
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/archive/id/draft-mattsson-tls-compact-ecc-03.txt
Status: https://datatracker.ietf.org/doc/draft-mattsson-tls-compact-ecc/
Html:   
https://www.ietf.org/archive/id/draft-mattsson-tls-compact-ecc-03.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-mattsson-tls-compact-ecc
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-compact-ecc-03

Abstract:
   The encodings used in the ECDHE groups secp256r1, secp384r1, and
   secp521r1 and the ECDSA signature algorithms ecdsa_secp256r1_sha256,
   ecdsa_secp384r1_sha384, and ecdsa_secp521r1_sha512 have significant
   overhead and the ECDSA encoding produces variable-length signatures.
   This document defines new optimal fixed-length encodings and
   registers new ECDHE groups and ECDSA signature algorithms using these
   new encodings.  The new encodings reduce the size of the ECDHE groups
   with 33, 49, and 67 bytes and the ECDSA algorithms with an average of
   7 bytes.  These new encodings also work in DTLS 1.3 and are
   especially useful in cTLS.




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

Re: [TLS] New Version Notification for draft-mattsson-tls-compact-ecc-00.txt

[John Mattsson]

Thanks Dan,

The intention was not to loosen the validation requirements. I will make that 
clearer in the next version. I will also remove the two questionable sentences 
with naturally and benign in the security considerations.

Safecurves states:
“An implementation that receives a compressed point, such as x and just one bit 
of y, will naturally detect invalid inputs when it reconstructs the missing 
coordinate. However, point compression costs some time and, more importantly, 
some implementation effort, again creating a conflict between simplicity and 
security.”
https://safecurves.cr.yp.to/twist.html <https://safecurves.cr.yp.to/twist.html>


The “benign malleability” as discussed in [SEC1] was supposed to refer on 
on-path flipping the sign of the y-coordinate in the key share, but TLS 1.3 
would detect such a change. I will remove this in the next update.


Cheers, 
John 

From: Dan Brown 
Date: Tuesday, 17 January 2023 at 19:04
To: Scott Fluhrer (sfluhrer) , John Mattsson 
, TLS@ietf.org 
Subject: RE: New Version Notification for draft-mattsson-tls-compact-ecc-00.txt 

Hi John and Scott, 

For even greater clarity, you might want to address these points: 

If the receiver uses an x-only ladder (e.g. Brier-Joye) and re-uses private ECC 
key, then, upon decoding the peer’s compress public key (represented via x), 
the receiver ought to check that x^3+ax+b is a square? [SafeCurves says to do 
check this, but, of course, also adds the twist secure can avoid this check.] 

Actually, it's a little bit tricky to find invalid x where y = 
(x^3+a+b)^((p+1)/4) gives (x,y) of low order. I mentioned this to CFRG: 
https://mailarchive.ietf.org/arch/msg/cfrg/nzxkGIo97GlIGszJirvS_TFUUio/ 
<https://mailarchive.ietf.org/arch/msg/cfrg/nzxkGIo97GlIGszJirvS_TFUUio/> 
Despite this extra wrinkle of difficulty, an attack is avoided by validating a 
decompressed point. (So, I’m not sure if the statement “the implementation will 
naturally detect invalid points when it …” is entirely realistic. [Safecurves 
say this where, by the way?] 

I’m a little confused by the sentence “As not even the sign of the y-coordinate 
is encoded, compact representation avoids ‘benign malleability’ where an 
attacker changes the sign”. Is this about the attack changing (r,s) to (r,p-s)? 
Since r and s are integers, there are no y coordinates in play, the change from 
(r,s) to (r,p-s) is possible regardless of y coordinates. (Ok, there is a 
connection to y coordinates: a point R, of which r is the x coordinate (mod p), 
does implicitly change by way of negating its y coordinate, but R is not sent 
in ECDSA, instead, ECDSA only sends x (via r). I.e. r is already a “compact” 
version of R.) 

Best regards, 
​ 
Dan 


From: TLS  On Behalf Of Scott Fluhrer (sfluhrer)
Sent: Tuesday, January 17, 2023 11:10 AM
To: John Mattsson ; TLS@ietf.org
Subject: Re: [TLS] New Version Notification for 
draft-mattsson-tls-compact-ecc-00.txt 



CAUTION - This email is from an external source. Please be cautious with links 
and attachments. (go/taginfo) 



It looks good; just one comment: 

The current draft says (section 3.2) 
A full validation according to Section 5.6.2.3.3 of 
[SP-800-56A] can be achieved by also checking that 0 ≤ x < p and that 
y^2 ≡ x^3 + a ⋅ x + b (mod p) 
(emphasis added). 

I believe such a validation check should be mandatory. For the curves listed in 
the draft, the corresponding twists are not of prime order; hence someone 
injecting an invalid curve point has some advantage at recovering the peer’s 
secret value (and hence if an implementation reuses ECDHE private values, that 
gives them some advantage at recovering the keys for other sessions). 

Yes, this is not a major point (this relies on the device under attack reusing 
private values, which they’re not supposed to do); on the other hand, the 
expense is fairly minimal (just computing y^2 (after all, you’ve already 
computed x^3+a+b), and the additional complexity needed to perform this check), 
hence I believe it is warranted. 

Alternatively, you can mandate a safe curve (e.g. X25519), which is immune to 
this sort of attack. 

From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of 
John Mattsson
Sent: Monday, January 16, 2023 4:45 PM
To: TLS@ietf.org <mailto:TLS@ietf.org>
Subject: [TLS] FW: New Version Notification for 
draft-mattsson-tls-compact-ecc-00.txt 



Hi, 

I wrote a draft specifying new optimal fixed-length encodings for ECDHE and 
ECDHA with the NIST P-curves. This seems to be exactly what is needed for cTLS. 
The new encodings are defined as a subset of the old encodings which hopefully 
makes them easy to implement.

Cheers,
John 

From: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Date: Monday, 16 January 2023 at 22:38
To: John Mattsson mailto:john.matts...@ericsson.com>>, John Mattsson mailto:john.matts...@ericsson.com>>
Subject: New Version Not

Re: [TLS] New Version Notification for draft-mattsson-tls-compact-ecc-00.txt

[John Mattsson]

Thanks Scott,

I agree that such a validation check should be mandatory. The intention was to 
keep all validation requirements from RFC 8422 and only change the encoding. I 
will make that clear in the next update.

The “can” was intended to mean that you can do the validation before using and 
API or you can let the API do the point validation. My understanding is that 
some libraries provide point validation, and some don’t.

>Alternatively, you can mandate a safe curve (e.g. X25519), which is immune to 
>this sort of attack.
I would personally be fine with that. I tried to make X25519 and EdDSA MTI in 
EDHOC but people really wanted P-256, ECDSA, and SHA-256. I would assume that 
the same is true for cTLS, which is the main focus of the draft. X25519 seems 
to already be the de facto standard for HTTPS.

Cheers,
John

From: Scott Fluhrer (sfluhrer) 
Date: Tuesday, 17 January 2023 at 17:13
To: John Mattsson , TLS@ietf.org 
Subject: RE: New Version Notification for draft-mattsson-tls-compact-ecc-00.txt
It looks good; just one comment:

The current draft says (section 3.2)
A full validation according to Section 5.6.2.3.3 of
   [SP-800-56A] can be achieved by also checking that 0 ≤ x < p and that
   y^2 ≡ x^3 + a ⋅ x + b (mod p)
(emphasis added).

I believe such a validation check should be mandatory.  For the curves listed 
in the draft, the corresponding twists are not of prime order; hence someone 
injecting an invalid curve point has some advantage at recovering the peer’s 
secret value (and hence if an implementation reuses ECDHE private values, that 
gives them some advantage at recovering the keys for other sessions).

Yes, this is not a major point (this relies on the device under attack reusing 
private values, which they’re not supposed to do); on the other hand, the 
expense is fairly minimal (just computing y^2 (after all, you’ve already 
computed x^3+a+b), and the additional complexity needed to perform this check), 
hence I believe it is warranted.

Alternatively, you can mandate a safe curve (e.g. X25519), which is immune to 
this sort of attack.

From: TLS  On Behalf Of John Mattsson
Sent: Monday, January 16, 2023 4:45 PM
To: TLS@ietf.org
Subject: [TLS] FW: New Version Notification for 
draft-mattsson-tls-compact-ecc-00.txt

Hi,

I wrote a draft specifying new optimal fixed-length encodings for ECDHE and 
ECDHA with the NIST P-curves. This seems to be exactly what is needed for cTLS. 
The new encodings are defined as a subset of the old encodings which hopefully 
makes them easy to implement.

Cheers,
John

From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Date: Monday, 16 January 2023 at 22:38
To: John Mattsson 
mailto:john.matts...@ericsson.com>>, John Mattsson 
mailto:john.matts...@ericsson.com>>
Subject: New Version Notification for draft-mattsson-tls-compact-ecc-00.txt

A new version of I-D, draft-mattsson-tls-compact-ecc-00.txt
has been successfully submitted by John Preuß Mattsson and posted to the
IETF repository.

Name:   draft-mattsson-tls-compact-ecc
Revision:   00
Title:  Compact ECDHE and ECDSA Encodings for TLS 1.3
Document date:  2023-01-16
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/archive/id/draft-mattsson-tls-compact-ecc-00.txt
Status: https://datatracker.ietf.org/doc/draft-mattsson-tls-compact-ecc/
Html:   
https://www.ietf.org/archive/id/draft-mattsson-tls-compact-ecc-00.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-mattsson-tls-compact-ecc


Abstract:
   The encodings used in the ECDHE groups secp256r1, secp384r1, and
   secp521r1 and the ECDSA signature algorithms ecdsa_secp256r1_sha256,
   ecdsa_secp384r1_sha384, and ecdsa_secp521r1_sha512 have significant
   overhead and the ECDSA encoding produces variable-length signatures.
   This document defines new optimal fixed-length encodings and
   registers new ECDHE groups and ECDSA signature algorithms using these
   new encodings.  The new encodings reduce the size of the ECDHE groups
   with 33, 49, and 67 bytes and the ECDSA algorithms with an average of
   7 bytes.  These new encodings also work in DTLS 1.3 and are
   especially useful in cTLS.




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

[TLS] Fw: New Version Notification for draft-mattsson-tls-compact-ecc-01.txt

[John Mattsson]

Hi,

As always when talking about ECC formats, I got a question about IPR. I am not 
aware of any IPR that applies to this draft.

IPRs regarding point compression have been discussed a lot in IETF in the past 
but SEC 1: Elliptic Curve Cryptography version 1 was published over 22 years 
ago so any IPR on that have expired.
https://www.secg.org/SEC1-Ver-1.0.pdf
https://en.wikipedia.org/wiki/ECC_patents

But more important is that compact representation is not at all the same as 
point compression. I have not seen any suggestions that there would be any 
alleged IPRs on compact representation.

Cheers,
John

From: internet-dra...@ietf.org 
Date: Tuesday, 17 January 2023 at 08:46
To: John Mattsson , John Mattsson 

Subject: New Version Notification for draft-mattsson-tls-compact-ecc-01.txt

A new version of I-D, draft-mattsson-tls-compact-ecc-01.txt
has been successfully submitted by John Preuß Mattsson and posted to the
IETF repository.

Name:   draft-mattsson-tls-compact-ecc
Revision:   01
Title:  Compact ECDHE and ECDSA Encodings for TLS 1.3
Document date:  2023-01-17
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/archive/id/draft-mattsson-tls-compact-ecc-01.txt
Status: https://datatracker.ietf.org/doc/draft-mattsson-tls-compact-ecc/
Html:   
https://www.ietf.org/archive/id/draft-mattsson-tls-compact-ecc-01.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-mattsson-tls-compact-ecc
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-compact-ecc-01

Abstract:
   The encodings used in the ECDHE groups secp256r1, secp384r1, and
   secp521r1 and the ECDSA signature algorithms ecdsa_secp256r1_sha256,
   ecdsa_secp384r1_sha384, and ecdsa_secp521r1_sha512 have significant
   overhead and the ECDSA encoding produces variable-length signatures.
   This document defines new optimal fixed-length encodings and
   registers new ECDHE groups and ECDSA signature algorithms using these
   new encodings.  The new encodings reduce the size of the ECDHE groups
   with 33, 49, and 67 bytes and the ECDSA algorithms with an average of
   7 bytes.  These new encodings also work in DTLS 1.3 and are
   especially useful in cTLS.




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

[TLS] FW: New Version Notification for draft-mattsson-tls-compact-ecc-00.txt

[John Mattsson]

Hi,

I wrote a draft specifying new optimal fixed-length encodings for ECDHE and 
ECDHA with the NIST P-curves. This seems to be exactly what is needed for cTLS. 
The new encodings are defined as a subset of the old encodings which hopefully 
makes them easy to implement.

Cheers,
John

From: internet-dra...@ietf.org 
Date: Monday, 16 January 2023 at 22:38
To: John Mattsson , John Mattsson 

Subject: New Version Notification for draft-mattsson-tls-compact-ecc-00.txt

A new version of I-D, draft-mattsson-tls-compact-ecc-00.txt
has been successfully submitted by John Preuß Mattsson and posted to the
IETF repository.

Name:   draft-mattsson-tls-compact-ecc
Revision:   00
Title:  Compact ECDHE and ECDSA Encodings for TLS 1.3
Document date:  2023-01-16
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/archive/id/draft-mattsson-tls-compact-ecc-00.txt
Status: https://datatracker.ietf.org/doc/draft-mattsson-tls-compact-ecc/
Html:   
https://www.ietf.org/archive/id/draft-mattsson-tls-compact-ecc-00.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-mattsson-tls-compact-ecc


Abstract:
   The encodings used in the ECDHE groups secp256r1, secp384r1, and
   secp521r1 and the ECDSA signature algorithms ecdsa_secp256r1_sha256,
   ecdsa_secp384r1_sha384, and ecdsa_secp521r1_sha512 have significant
   overhead and the ECDSA encoding produces variable-length signatures.
   This document defines new optimal fixed-length encodings and
   registers new ECDHE groups and ECDSA signature algorithms using these
   new encodings.  The new encodings reduce the size of the ECDHE groups
   with 33, 49, and 67 bytes and the ECDSA algorithms with an average of
   7 bytes.  These new encodings also work in DTLS 1.3 and are
   especially useful in cTLS.




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

Re: [TLS] I-D Action: draft-ietf-tls-ctls-07.txt

[John Mattsson]

Review of draft-ietf-tls-ctls-07

The template-based mechanism is a nice idea for TLS. A more compact version of 
TLS and DTLS is very welcome. My company has several times suggested the use of 
TLS or DTLS in different SDO but the SDO has often decided to design something 
new as both the handshake and record layer has been considered too large. The 
DTLS 1.3 record layer is _very_ slim (good job) and cTLS handshake is a nice 
improvement from the full (D)TLS handshake. The current sizes would increase 
the cases where TLS can be used even if it is still too large for very 
constrained IoT.


Comments:

- Abstract
How can it be "logically isomorphic" and use "alternative cryptographic 
techniques"?

- "Semi-static and point compression are never mentioned again."
If you just use x25519 you don't need point compression. For P-256 I think it 
would make more sense with compact representation. If you want to use P-256 it 
might be best to register a new group (I think this was suggested somewhere but 
I cannot find it). But just truncating the key share to 32 byte in this draft 
would also work.

I don't think semi-static is the right word here. I think OPTLS use the term 
semi-static for a key with a lifetime between ephemeral and static. What would 
make cTLS messages smaller is to use ephermeral-static ECDHE for implicit 
authentication. I don't think the lifetime of the key matters.

- "45 bytes over the minimum required by the cryptovariables"
Can be discussed if random, y-coordinate, signatures, double MACs etc. are 
"required". Suggestion: "45 bytes over the the cryptovariables"

- "Annotated handshake transcripts for these cases"
There is no transcripts for PSK...

- "Most of the other exchanges in TLS 1.3 are highly optimized"
TLS 1.3 with PSK is not "highly" optimized. PSK+ECDHE echange with P-256 in TLS 
1.3 takes a total of 370 bytes and such an AKE can be done in around 100 bytes.
https://datatracker.ietf.org/doc/draft-ietf-lwig-security-protocol-comparison/

- "an equivalent JSON dictionary format"
I think CBOR would make more sense for IoT applications. But I guess cTLS can 
reduce latence for TLS in general. For RFC 9140 the general conclusion seems to 
be that it was a mistake to use JSON instead of CBOR.

- "IMPORTANT: Using short Random values can lead to potential attacks."
If you anyway disable anti-downgrade mechanism, the problem I can see with 
using short or no Random is for the psk_ke mode, when reuseing key shares, or 
if the placement of random in the ClientHello and ServerHello would matter.

- "hashing ephemeral public keys and to use the result"
This seems like a good suggestion if the placement and random in the messages 
matters. Might be that this hashing is not needed.

- "More analysis is needed to know the minimum safe Finished size."
Such analysis could also incorporate the record layer MAC that he finished is 
sent in. TLS has two layers of MACs. Might even be that 0 byte Finished is 
secure.

Cheers,
John

From: TLS  on behalf of internet-dra...@ietf.org 

Date: Tuesday, 3 January 2023 at 17:58
To: i-d-annou...@ietf.org 
Cc: tls@ietf.org 
Subject: [TLS] I-D Action: draft-ietf-tls-ctls-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : Compact TLS 1.3
Authors : Eric Rescorla
  Richard Barnes
  Hannes Tschofenig
  Benjamin M. Schwartz
  Filename: draft-ietf-tls-ctls-07.txt
  Pages   : 25
  Date: 2023-01-03

Abstract:
   This document specifies a "compact" version of TLS and DTLS.  It is
   logically isomorphic to ordinary TLS, but saves space by trimming
   obsolete material, tighter encoding, a template-based specialization
   technique, and alternative cryptographic techniques. cTLS is not
   directly interoperable with TLS or DTLS, but it should eventually be
   possible for a single server port to offer cTLS alongside TLS or
   DTLS.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-ctls/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-ctls-07.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-ctls-07


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
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] Identify and mitigate tracking and fingerprinting vectors - How to progress

[John Mattsson]

Hi,

The charter from march 2022 states that one of the most important goal for the 
group is to identify and mitigate tracking and fingerprinting vectors.

I think this is an excellent goal. I can however not see any discussion or work 
except for ECH. Reading RFC8446bis it does not say much when it comes to 
tracking, fingerprinting, and privacy. As far as I can see the only thing that 
is discussed is client tracking based on ticket reuse.

There are a lot of additional tracking and fingerprinting vectors in the Client 
Hello and Server Hello.

- Tracking is also an issue for servers. IoT devices are often servers and by 
tracking the device you can often track the person owning the device.
- Ticket reuse is just one example of psk identifier reuse, all psk identifier 
reuse has the same client and server tracking considerations.
- Client reuse of key shares can be used to track the client. Server reuse of 
key shares can be used to track the server or to reveal the server name.
- SNI can be used to track a server and most SNI (except very common ones) can 
be used to track a client.
- Non-common values of max_fragment_length, supported_groups, 
signature_algorithms, application_layer_protocol_negotiation, etc. can be used 
to track a client with high probability.
- The set of extentions in CH or SH might be used to track client or server 
with high probability. The fingerprinting vector does not need to be globally 
unique. An attacker often looks in a specific location, in a specific network, 
and at a specific time. Can also be correlated with fingerprints at other 
layers.

ECH helps a bit by encrypting CH on the whole or part of the path but does not 
encrypt SH. Is there any possibility to also encrypt SH with ECH?

How do we progress with this important goal for the group? I think RFC8446bis 
needs to be updated, but maybe an additional document would also be good? I 
would be willing to help with that.

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

Re: [TLS] New Version Notification for draft-ietf-tls-esni-15.txt

[John Mattsson]

On 2023-01-07, 18:13, "Stephen Farrell"  wrote:


>Hiya, 
> 
>On 07/01/2023 15:46, John Mattsson wrote: 
>> My current understanding is that draft-ietf-tls-esni should require 
>> that the server MUST NOT reuse a key shares. Unless I miss something 
>> I suggest adding that and one or two of the above figures to the 
>> draft. An alternative solution would be to extend the ECH encryption 
>> to also cover ServerHello. If I understand ECH correctly, the 
>> ServerHello is still unencrypted. 
> 
>I'd support adding a requirement that key shares not be 
>re-used, either as a general thing or in an ECH-specific 
>manner. 

I made an issue and PR for RFC8446bis. For privacy reasons, I think this should 
be SHOULD NOT as a general thing. For servers using ECH, I think MUST NOT seems 
motivated. Does MUST NOT lead to DoS problems for servers using x25519? 

https://github.com/tlswg/tls13-spec/issues/1285 
<https://github.com/tlswg/tls13-spec/issues/1285> 
https://github.com/tlswg/tls13-spec/pull/1286 
<https://github.com/tlswg/tls13-spec/pull/1286> 

Cheers, 
John 




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

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

[John Mattsson]

Hi,

I really like the updates to the Recommended column. Making "Y" normative 
RECOMMENDED and introducing "D" seems like great changes. Good job!


Some high level comments/questions/suggestions
-

- It is very hard to understand from the TLS Cipher Suites registry which 
cipher suites that can be used in TLS 1.3. I think it would be good to 
introduce a TLS 1.3 column.

- Should TLS versions (0x0304, 0x303, ...) and their Recommended status be 
added as a new registry? I think that would be good.

- Maybe rename "DTLS-OK" to "DTLS"? md5 can be e.g. be used in DTLS but is not 
ok to use in DTLS.

- How do one find information on which parameters are QUIC-OK?


Comments on current text:
-

- "undertaken as part of the TLS 1.3 development process."
The abstract should be updated. The part above could be removed.

I think the IANA policies need more work. See some examples below:

- "Setting the Recommended item to "Y" or "D" or changing a item whose
current value is "Y" or "D" requires Standards Action [RFC8126]."
This seems redundant as there is a sentence below it that say the same thing in 
a much better way: “Changing the Recommended status of an item in a Standards 
Track RFC requires Standards Action [RFC8126].”

- "Adding a value Y to the "Recommended" column requires Standards Action 
{{RFC8126}}."
Seems to be different from the general rule above.

- "IESG Approval is REQUIRED for a Y->N transition."
Also Y->D I assume

Cheers,
John

From: TLS  on behalf of internet-dra...@ietf.org 

Date: Monday, 24 October 2022 at 18:32
To: i-d-annou...@ietf.org 
Cc: tls@ietf.org 
Subject: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : IANA Registry Updates for TLS and DTLS
Authors : Joe Salowey
  Sean Turner
  Filename: draft-ietf-tls-rfc8447bis-02.txt
  Pages   : 22
  Date: 2022-10-23

Abstract:
   This document describes a number of changes to TLS and DTLS IANA
   registries that range from adding notes to the registry all the way
   to changing the registration policy.  These changes were mostly
   motivated by WG review of the TLS- and DTLS-related registries
   undertaken as part of the TLS 1.3 development process.

   This document obsoletes RFC 8447 and updates the following RFCs:
   3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-02.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc8447bis-02


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
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] FW: New Version Notification for draft-mattsson-tls-psk-ke-dont-dont-dont-04.txt

[John Mattsson]

Hi Loganaden,

Thanks for the info! I think this shows that also under the old RFC8447 
definition of “generally recommended for implementations to support” the “Y” 
classification was wrong.

Cheers,
John

From: Loganaden Velvindron 
Date: Wednesday, 11 January 2023 at 20:31
To: John Mattsson 
Cc: TLS@ietf.org 
Subject: Re: [TLS] FW: New Version Notification for 
draft-mattsson-tls-psk-ke-dont-dont-dont-04.txt

Hi John,


On Wed, Jan 11, 2023, 21:49 John Mattsson 
mailto:40ericsson@dmarc.ietf.org>>
 wrote:
Hi,

Changes in -04:

- Eric Rescorla commented that we should ask whether it's time to deprecate or 
at least Discourage psk_ke. Changed the psk_ke suggestion from “N” to “D”

- Added that BoringSSL has chosen to not even implement psk_ke



I've also looked at LibreSSL quickly and it doesn't appear to support psk_ke in 
their TLS 1.3 stack.

- Eric Rescorla commented that he thinks the RFC 9150 algorithms should be 
marked as Discouraged. The document was updated with an evaluation and this 
suggestion.

- The x25519 performance section was rewritten after a comment from Paul Wouters

- Added evaluations and suggestions for the other TLS 1.3 parameters 
(ffdhe2048, rsa_pkcs1_sha256, rsa_pkcs1_sha384, and rsa_pkcs1_sha512) that BSI 
has introduced deadlines for.

- Changed to standards track as the suggested IANA actions require Standards 
Action

- Added introduction to explain RFC8447 and RFC8447bis

- Added details on exactly which zero trust principles that are intended 
(comment from Eric Rescorla)

Cheers,
John

From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Date: Wednesday, 11 January 2023 at 18:24
To: John Mattsson 
mailto:john.matts...@ericsson.com>>, John Mattsson 
mailto:john.matts...@ericsson.com>>
Subject: New Version Notification for 
draft-mattsson-tls-psk-ke-dont-dont-dont-04.txt

A new version of I-D, draft-mattsson-tls-psk-ke-dont-dont-dont-04.txt
has been successfully submitted by John Preuß Mattsson and posted to the
IETF repository.

Name:   draft-mattsson-tls-psk-ke-dont-dont-dont
Revision:   04
Title:  NULL Encryption and Key Exchange Without Forward Secrecy are 
Dicouraged
Document date:  2023-01-11
Group:  Individual Submission
Pages:  13
URL:
https://www.ietf.org/archive/id/draft-mattsson-tls-psk-ke-dont-dont-dont-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-mattsson-tls-psk-ke-dont-dont-dont/
Html:   
https://www.ietf.org/archive/id/draft-mattsson-tls-psk-ke-dont-dont-dont-04.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-mattsson-tls-psk-ke-dont-dont-dont
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-psk-ke-dont-dont-dont-04

Abstract:
   Massive pervasive monitoring attacks using key exfiltration and made
   possible by key exchange without forward secrecy have been reported.
   If key exchange without Diffie-Hellman is used, static exfiltration
   of the long-term authentication keys enables passive attackers to
   compromise all past and future connections.  Malicious actors can get
   access to long-term keys in different ways: physical attacks,
   hacking, social engineering attacks, espionage, or by simply
   demanding access to keying material with or without a court order.
   Exfiltration attacks are a major cybersecurity threat.  If NULL
   encryption is used an on-path attacker can read all application data.
   The use of psk_ke and NULL encryption are not following zero trust
   principles of minimizing the impact of breach and governments have
   already made deadlines for their deprecation.  This document sets the
   Recommended values of psk_ke, TLS_SHA256_SHA256, TLS_SHA384_SHA384,
   ffdhe2048 to "D" and the Recommended values of rsa_pkcs1_sha256,
   rsa_pkcs1_sha384, and rsa_pkcs1_sha512 to "N".




The IETF Secretariat
___
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] FW: New Version Notification for draft-mattsson-tls-psk-ke-dont-dont-dont-04.txt

[John Mattsson]

Hi,

Changes in -04:

- Eric Rescorla commented that we should ask whether it's time to deprecate or 
at least Discourage psk_ke. Changed the psk_ke suggestion from “N” to “D”

- Added that BoringSSL has chosen to not even implement psk_ke

- Eric Rescorla commented that he thinks the RFC 9150 algorithms should be 
marked as Discouraged. The document was updated with an evaluation and this 
suggestion.

- The x25519 performance section was rewritten after a comment from Paul Wouters

- Added evaluations and suggestions for the other TLS 1.3 parameters 
(ffdhe2048, rsa_pkcs1_sha256, rsa_pkcs1_sha384, and rsa_pkcs1_sha512) that BSI 
has introduced deadlines for.

- Changed to standards track as the suggested IANA actions require Standards 
Action

- Added introduction to explain RFC8447 and RFC8447bis

- Added details on exactly which zero trust principles that are intended 
(comment from Eric Rescorla)

Cheers,
John

From: internet-dra...@ietf.org 
Date: Wednesday, 11 January 2023 at 18:24
To: John Mattsson , John Mattsson 

Subject: New Version Notification for 
draft-mattsson-tls-psk-ke-dont-dont-dont-04.txt

A new version of I-D, draft-mattsson-tls-psk-ke-dont-dont-dont-04.txt
has been successfully submitted by John Preuß Mattsson and posted to the
IETF repository.

Name:   draft-mattsson-tls-psk-ke-dont-dont-dont
Revision:   04
Title:  NULL Encryption and Key Exchange Without Forward Secrecy are 
Dicouraged
Document date:  2023-01-11
Group:  Individual Submission
Pages:  13
URL:
https://www.ietf.org/archive/id/draft-mattsson-tls-psk-ke-dont-dont-dont-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-mattsson-tls-psk-ke-dont-dont-dont/
Html:   
https://www.ietf.org/archive/id/draft-mattsson-tls-psk-ke-dont-dont-dont-04.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-mattsson-tls-psk-ke-dont-dont-dont
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-psk-ke-dont-dont-dont-04

Abstract:
   Massive pervasive monitoring attacks using key exfiltration and made
   possible by key exchange without forward secrecy have been reported.
   If key exchange without Diffie-Hellman is used, static exfiltration
   of the long-term authentication keys enables passive attackers to
   compromise all past and future connections.  Malicious actors can get
   access to long-term keys in different ways: physical attacks,
   hacking, social engineering attacks, espionage, or by simply
   demanding access to keying material with or without a court order.
   Exfiltration attacks are a major cybersecurity threat.  If NULL
   encryption is used an on-path attacker can read all application data.
   The use of psk_ke and NULL encryption are not following zero trust
   principles of minimizing the impact of breach and governments have
   already made deadlines for their deprecation.  This document sets the
   Recommended values of psk_ke, TLS_SHA256_SHA256, TLS_SHA384_SHA384,
   ffdhe2048 to "D" and the Recommended values of rsa_pkcs1_sha256,
   rsa_pkcs1_sha384, and rsa_pkcs1_sha512 to "N".




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

Re: [TLS] New Version Notification for draft-ietf-tls-esni-15.txt

[John Mattsson]

Hi,

- I cannot find anything in RFC 8446 or draft-ietf-tls-esni-15 on reuse of key 
shares but my understanding from earlier discussions in the TLS WG is that this 
is allowed as summarized in draft-ietf-tls-hybrid-design: "TLS 1.3 does not 
require that ephemeral public keys be used only in a single key exchange 
session; some implementations may reuse them"

Server reuse of key shares seem very problematic with ECH and seems to leak the 
server identity to an passive or active attacker.

  Client Attacker   Server

  ClientHello
  + ech -->
   ServerHello
   + key_share
   <---
 (intercept)

...

 ClientHello  --->
   ServerHello
   + key_share
  <---
 (compare key shares)

  Figure X: Active attacker identifying server resuing key share


  Client1  Client2   Attacker   Server

  ClientHello
  + ech -->
   ServerHello
   + key_share
 (intercept)

...

 ClientHello
-->  (intercept SNI)
   ServerHello
   + key_share
 (compare key shares)

  Figure Y: Passive attacker identifying server resuing key share

My current understanding is that draft-ietf-tls-esni should require that the 
server MUST NOT reuse a key shares. Unless I miss something I suggest adding 
that and one or two of the above figures to the draft. An alternative solution 
would be to extend the ECH encryption to also cover ServerHello. If I 
understand ECH correctly, the ServerHello is still unencrypted.

- As a main goal of ECH is to hide the server name, I think the draft should 
explicitly mention padding of the server certificate message. Some web servers 
are using very large certificate messages. If padding is not used, they can be 
identified with a quite high probability just by looking at the size.

Cheers,
John

From: TLS  on behalf of Christopher Wood 

Date: Monday, 3 October 2022 at 16:12
To: TLS@ietf.org 
Subject: Re: [TLS] New Version Notification for draft-ietf-tls-esni-15.txt
This is mainly a keep-alive update, with some additional details summarizing 
the results from an upcoming paper to appear at ACM CCS 2022.

Best,
Chris, for the editors

On Mon, Oct 3, 2022, at 7:56 AM, internet-dra...@ietf.org wrote:
> A new version of I-D, draft-ietf-tls-esni-15.txt
> has been successfully submitted by Christopher Wood and posted to the
> IETF repository.
>
> Name: draft-ietf-tls-esni
> Revision: 15
> Title:TLS Encrypted Client Hello
> Document date:2022-10-03
> Group:tls
> Pages:48
> URL:
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-43f8a48e256f1fa7=1=665b2e5c-6b5e-43fa-8eaa-4cdc64ce6ae3=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-tls-esni-15.txt
> Status: 
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-d964cabe684fd6b8=1=665b2e5c-6b5e-43fa-8eaa-4cdc64ce6ae3=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tls-esni%2F
> Html:   
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-bd77e6206604f594=1=665b2e5c-6b5e-43fa-8eaa-4cdc64ce6ae3=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-tls-esni-15.html
> Htmlized:   
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-9a2e632545b77f65=1=665b2e5c-6b5e-43fa-8eaa-4cdc64ce6ae3=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-tls-esni
> Diff:   
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-cb651e94574b6bd5=1=665b2e5c-6b5e-43fa-8eaa-4cdc64ce6ae3=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-tls-esni-15
>
> Abstract:
>This document describes a mechanism in Transport Layer Security (TLS)
>for encrypting a ClientHello message under a server public key.
>
> Discussion Venues
>
>This note is to be removed before publishing as an RFC.
>
>Source for this draft and an issue tracker can be found at
>
> 

Re: [TLS] Published RFC 8446bis -05

[John Mattsson]

Illari wrote:

Should there be "SHOULD NOT reuse key shares between client hellos"?
I did't find such requirement (or maybe it is there but I just missed
it), which I think is odd, given that there is similar requirement for
tickets, and reusing key shares has similar impact as reusing tickets.

Such reuse is especially bad if SNI differs, or if the group is not
actually safe for key reuse.

(In case of hybrid key exchanges, implementations might reuse shares
within the same client hello. E.g., reusing the same X25519 key both
for x25519 and x25519+kyber768.)

I also thought about this when reading the text about tickets and created an 
issue, then I found this. I am surprised that this did not get any responses on 
the list. This is quite a big issue. I really hope that HTTP/2 and HTTP/3 
implementations are not doing this.
https://github.com/tlswg/tls13-spec/issues/1285

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

Re: [TLS] sslkeylogfile

[John Mattsson]

>This file doesn't have any extra information than what would be in a
>serialised
>session data used for session resumption. Something plenty of software
>already
>does.

I hope that is TLS 1.2 only. A TLS 1.3 implementation should not save any other 
keys than resumption_master_secret or PSKs derived from 
resumption_master_secret. If that is not clear in RFC 8446, I think that need 
to be made clear in RFC8446bis.

John

From: Hubert Kario 
Date: Wednesday, 21 December 2022 at 17:03
To: John Mattsson 
Cc: Martin Thomson , Peter Gutmann 
, tls@ietf.org 
Subject: Re: [TLS] sslkeylogfile
On Thursday, 24 November 2022 11:37:02 CET, John Mattsson wrote:
> Hi,
>
> Two high level comments:
>
>
> - OLD: "though use of earlier versions is strongly discouraged [RFC8996]"
>
> That is not what RFC 8996 says. RFC 8996 says
>
> - "TLS 1.1 MUST NOT be used."
> - "TLS 1.1 MUST NOT be used."
>
> Please change to something that aligns with RFC 8996 such as
>
> NEW: "though use of earlier versions is forbidden [RFC8996]"
>
>
> -  "Access to the content of a file in SSLKEYLOGFILE allows an attacker
>to break the confidentiality protection on any TLS connections that
>are included in the file."
>
> This is true but does not at all reflect the implications of
> the existence of a file for long-term storage of keys like this.
> Storing any of the keying material like this completely breaks
> the stated forward secrecy property of TLS 1.3 as it creates new
> long-term keys. It does not matter how well the file is
> protected i.e.,
>
>"Ensuring adequate access control on these files therefore becomes
>very important."
>
> is not enough. The theoretical security properties are still
> broken badly. I think this draft is problematic, but I can
> understand the need to standardize this existing format. I think
> the fact that SSLKEYLOGFILE breaks the security properties of
> TLS 1.3 needs to very clearly described. As a consequence, I
> think the only allowed use case standardized by TLS WG should be
> limited to non-production debugging. If governments and
> companies wanting visibility do other things, that would be
> outside of IETFs control.

This file doesn't have any extra information than what would be in a
serialised
session data used for session resumption. Something plenty of software
already
does.

> Cheers,
> John
>
> From: TLS  on behalf of Martin Thomson
> 
> Date: Wednesday, 26 October 2022 at 02:18
> To: Peter Gutmann , tls@ietf.org 
> Subject: Re: [TLS] sslkeylogfile
>
> On Tue, Oct 25, 2022, at 16:48, Peter Gutmann wrote:
>> But it's not the same thing, it only seems to cover some TLS
>> 1.3 extensions.
>> Thus my suggestion to call it "Extensions to the SSLKEYLOGFILE
>> Format for TLS
>> 1.3".
>
> That's not the intent.  Section 3.2 covers all you need for TLS 1.2.
>
> I did not describe the (deprecated) "RSA" key, is that in
> common usage?  Or, are there things that I have missed?  I got
> everything from
> https://firefox-source-docs.mozilla.org/security/nss/legacy/key_log_format/index.html
> but maybe that is no longer the best reference.
>

--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com<http://www.cz.redhat.com>
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] sslkeylogfile

[John Mattsson]

Thanks Martin,

That seems much better. That is sufficient to me.

John

From: Martin Thomson 
Date: Friday, 25 November 2022 at 08:21
To: John Mattsson , Peter Gutmann 
, tls@ietf.org 
Subject: Re: [TLS] sslkeylogfile
Thanks for the input John,

I agree on both points, the minor one and the substantive one.

https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-a9cf421cb99ab6e7=1=0ee2a1ca-4130-4e5f-8a35-f027f40b7759=https%3A%2F%2Fgithub.com%2Fmartinthomson%2Fsslkeylogfile%2Fpull%2F1
  is my attempt to put something stronger about usage/applicability up front.  
Do you think that is sufficient?

On Thu, Nov 24, 2022, at 21:37, John Mattsson wrote:
> Hi,
>
> Two high level comments:
>
>
> - OLD: "though use of earlier versions is strongly discouraged [RFC8996]"
>
> That is not what RFC 8996 says. RFC 8996 says
>
> - "TLS 1.1 MUST NOT be used."
> - "TLS 1.1 MUST NOT be used."
>
> Please change to something that aligns with RFC 8996 such as
>
> NEW: "though use of earlier versions is forbidden [RFC8996]"
>
>
> -  "Access to the content of a file in SSLKEYLOGFILE allows an attacker
>to break the confidentiality protection on any TLS connections that
>are included in the file."
>
> This is true but does not at all reflect the implications of the
> existence of a file for long-term storage of keys like this. Storing
> any of the keying material like this completely breaks the stated
> forward secrecy property of TLS 1.3 as it creates new long-term keys.
> It does not matter how well the file is protected i.e.,
>
>"Ensuring adequate access control on these files therefore becomes
>very important."
>
> is not enough. The theoretical security properties are still broken
> badly. I think this draft is problematic, but I can understand the need
> to standardize this existing format. I think the fact that
> SSLKEYLOGFILE breaks the security properties of TLS 1.3 needs to very
> clearly described. As a consequence, I think the only allowed use case
> standardized by TLS WG should be limited to non-production debugging.
> If governments and companies wanting visibility do other things, that
> would be outside of IETFs control.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] FW: New Version Notification for draft-mattsson-tls-psk-ke-dont-dont-dont-02.txt

[John Mattsson]

>discussion gets this time shorter.
Let’s hope so. I think quite a lot of things have happened since 2020. BSI 
decision that psk_ke can only be used until 2026, as well as a lot more 
discussion of exfiltration attacks and zero trust principles. I hope the 
working group can have a vote.

>Are there considerations how that affects similar simple OSCORE variants?
Yes, no difference there, OSCORE keyed without ECDHE or 3GPP AKA without ECDHE 
are equally bad security practice. In the case of OSCORE, the problem is rather 
the key management protocols like ACE rather than OSCORE, which is similar to 
the TLS record protocol. I have been equally critical of ACE. As soon as 
draft-ietf-ace-edhoc-oscore-profile is published I will write a contribution to 
3GPP suggesting that use of RFC 9203 should be phased out asap.

John

From: Achim Kraus 
Date: Friday, 30 December 2022 at 17:57
To: John Mattsson 
Cc: TLS@ietf.org 
Subject: Re: [TLS] FW: New Version Notification for 
draft-mattsson-tls-psk-ke-dont-dont-dont-02.txt
Hi John,

I'm not sure, are there any new arguments for this since this discussion

https://mailarchive.ietf.org/arch/msg/tls/WoBwUCqEMcFhvIHN6neo5W4Urg4/

in 2020?
Maybe, if the new arguments are highlighted, the discussion gets this
time shorter.

"Malicious actors can get access to long-term keys in different ways"

Are there considerations how that affects similar simple OSCORE variants?

best regards
Achim

Am 30.12.22 um 09:58 schrieb John Mattsson:
> Hi,
>
> I submitted a new version of draft-mattsson-tls-psk-ke-dont-dont-dont.
> psk_ke is likely the weakest part of TLS 1.3 and German BSI has already
> made a deadline for its deprecation. It is long overdue to change the
> "Recommended" value for psk_ke to "N".
>
> This is a major update to earlier versions and adds a lot of background
> and motivation. The earlier version was never posted to the list. I plan
> to request presentation time at IETF 116.
>
> Cheers,
>
> John
>
> *From: *internet-dra...@ietf.org 
> *Date: *Friday, 30 December 2022 at 09:47
> *To: *John Mattsson , John Mattsson
> 
> *Subject: *New Version Notification for
> draft-mattsson-tls-psk-ke-dont-dont-dont-02.txt
>
>
> A new version of I-D, draft-mattsson-tls-psk-ke-dont-dont-dont-02.txt
> has been successfully submitted by John Preuß Mattsson and posted to the
> IETF repository.
>
> Name:   draft-mattsson-tls-psk-ke-dont-dont-dont
> Revision:   02
> Title:  Key Exchange Without Forward Secrecy is NOT RECOMMENDED
> Document date:  2022-12-30
> Group:  Individual Submission
> Pages:  9
> URL:
> https://www.ietf.org/archive/id/draft-mattsson-tls-psk-ke-dont-dont-dont-02.txt
>  
> <https://www.ietf.org/archive/id/draft-mattsson-tls-psk-ke-dont-dont-dont-02.txt>
> Status:
> https://datatracker.ietf.org/doc/draft-mattsson-tls-psk-ke-dont-dont-dont/ 
> <https://datatracker.ietf.org/doc/draft-mattsson-tls-psk-ke-dont-dont-dont/>
> Html:
> https://www.ietf.org/archive/id/draft-mattsson-tls-psk-ke-dont-dont-dont-02.html
>  
> <https://www.ietf.org/archive/id/draft-mattsson-tls-psk-ke-dont-dont-dont-02.html>
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-mattsson-tls-psk-ke-dont-dont-dont
>  
> <https://datatracker.ietf.org/doc/html/draft-mattsson-tls-psk-ke-dont-dont-dont>
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-psk-ke-dont-dont-dont-02
>  
> <https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-psk-ke-dont-dont-dont-02>
>
> Abstract:
> Massive pervasive monitoring attacks using key exfiltration and made
> possible by key exchange without forward secrecy has been reported.
> If key exchange without Diffie-Hellman is used, static exfiltration
> of the long-term authentication keys enables passive attackers to
> compromise all past and future connections.  Malicious actors can get
> access to long-term keys in different ways: physical attacks,
> hacking, social engineering attacks, espionage, or by simply
> demanding access to keying material with or without a court order.
> Exfiltration attacks are a major cybersecurity threat.  The use of
> psk_ke is not following zero trust principles and governments have
> already made deadlines for its deprecation.  This document updates
> the IANA PskKeyExchangeMode registry by setting the "Recommended"
> value for psk_ke to "N".
>
>
>
>
> The IETF Secretariat
>
>
> ___
> 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] FW: New Version Notification for draft-ietf-lwig-security-protocol-comparison-06.txt

[John Mattsson]

Hi Achim,

Thanks. Good suggestions.

Last time I looked at the process behind the suggested CCM8 deprecation it 
seemed like nonsense (using a single-key limits to suggest rekeying which did 
not improve security). I have not been following this topic during my parental 
leave. I think I need to have a look at draft-irtf-cfrg-aead-limits again.

Right now, CCM with 8-byte tags seems to completely dominate IoT in general. 
draft-ietf-uta-tls13-iot-profile<https://datatracker.ietf.org/doc/draft-ietf-uta-tls13-iot-profile/>
 seems to still have it as the MUST implement cipher suite for (D)TLS 1.3 but 
it probably makes sense to add numbers for 16-bit tags as well. 
draft-ietf-uta-tls13-iot-profile<https://datatracker.ietf.org/doc/draft-ietf-uta-tls13-iot-profile/>
 seems to suggest TLS_CHACHA20_POLY1305_SHA256 as a potential future cipher 
suite but for this document only the tag length matters.

>I would appreciate, if the comparison DTLS vs. TLS mentions also the
>difference of UDP vs. TCP (8 vs. 24 bytes). And just a short sentence
>about some more bytes for additional messages used in TCP internally?

That’s a very good suggestion that it definitely missing from the document. We 
will add that to the next version.

Cheers,
John


From: Achim Kraus 
Date: Friday, 30 December 2022 at 17:34
To: John Mattsson 
Cc: TLS@ietf.org 
Subject: Re: [TLS] FW: New Version Notification for 
draft-ietf-lwig-security-protocol-comparison-06.txt
Hi John,

just to mention, the CCM8 is also considered to be not recommended in
the future (see
https://mailarchive.ietf.org/arch/msg/core/WnRInwF-j0uZmLggFh37ySljnwE/).
Wouldn't it make more sense to use then CCM
instead (16 bytes tag length)?

I would appreciate, if the comparison DTLS vs. TLS mentions also the
difference of UDP vs. TCP (8 vs. 24 bytes). And just a short sentence
about some more bytes for additional messages used in TCP internally?

best regards
Achim

Am 30.12.22 um 10:58 schrieb John Mattsson:
> Hi,
>
> We feel that draft-ietf-lwig-security-protocol-comparisonis getting
> quite ready now that the included protocols are published or at least
> stable.
>
> We would love to have more examples of cTLS. Are there any more examples
> available? We currently included the example in the draft.
>
> Review by people in the TLS WG would be great as the draft covers TLS
> 1.2, DTLS 1.2, TLS 1.3, DTLS 1.3, and cTLS.
>
> Cheers,
>
> John
>
> *From: *John Mattsson 
> *Date: *Sunday, 25 December 2022 at 20:19
> *To: *l...@ietf.org 
> *Subject: *Re: New Version Notification for
> draft-ietf-lwig-security-protocol-comparison-06.txt
>
> Hi,
>
> We submitted a new version of
> draft-ietf-lwig-security-protocol-comparison. This document has been
> dormant for a while as several of the referenced protocols were not
> stable, which lead to a lot of work in earlier versions. All of the
> protocols now seem to be stable and publishedor close to being
> published. This version fixes all the comments we have received. We
> think it is close to being ready for WGLC.
>
> This is obviously needed information for a lot of people. The draft
> already has 17 citations.
>
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-180c89c9eb242a8e=1=8969b10d-8a34-412a-a74e-44a29964cef8=https%3A%2F%2Fscholar.google.com%2Fscholar%3Fhl%3Den%26as_sdt%3D0%2C5%26cluster%3D11841781769013384442
>  
> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-180c89c9eb242a8e=1=8969b10d-8a34-412a-a74e-44a29964cef8=https%3A%2F%2Fscholar.google.com%2Fscholar%3Fhl%3Den%26as_sdt%3D0%2C5%26cluster%3D11841781769013384442>
>
> The need for compact formats and protocols has also gained attention
> outside of IoT. In the IAB workshop on Environmental Impact of Internet
> Applications and Systems, compact formats and protocols were discussed
> as a way to reduce the energy consumption of the Internet as a whole.
>
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-028386883e0a910d=1=8969b10d-8a34-412a-a74e-44a29964cef8=https%3A%2F%2Fwww.iab.org%2Factivities%2Fworkshops%2Fe-impact%2F
> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-028386883e0a910d=1=8969b10d-8a34-412a-a74e-44a29964cef8=https%3A%2F%2Fwww.iab.org%2Factivities%2Fworkshops%2Fe-impact%2F>
>
> Changes in -06:
>
> - Added more context to abstract and introduction
>
> - Added high level comparison of the number of bytes in TLS 1.2 and TLS
> 1.3 handshakes
>
> - Added Compact TLS 1.3 (cTLS)
>
> - Added some more clarification on (D)TLS choices
>
> - Added text that CoAP needs to be added to the EDHOC figures to be
> directly comparable to DTLS.
>
> - Added more DTLS and EDHOC alternatives to the summary table.
>
> - Added ECD

[TLS] FW: New Version Notification for draft-ietf-lwig-security-protocol-comparison-06.txt

[John Mattsson]

Hi,

We feel that draft-ietf-lwig-security-protocol-comparison is getting quite 
ready now that the included protocols are published or at least stable.

We would love to have more examples of cTLS. Are there any more examples 
available? We currently included the example in the draft.

Review by people in the TLS WG would be great as the draft covers TLS 1.2, DTLS 
1.2, TLS 1.3, DTLS 1.3, and cTLS.

Cheers,
John

From: John Mattsson 
Date: Sunday, 25 December 2022 at 20:19
To: l...@ietf.org 
Subject: Re: New Version Notification for 
draft-ietf-lwig-security-protocol-comparison-06.txt
Hi,

We submitted a new version of draft-ietf-lwig-security-protocol-comparison. 
This document has been dormant for a while as several of the referenced 
protocols were not stable, which lead to a lot of work in earlier versions. All 
of the protocols now seem to be stable and published or close to being 
published. This version fixes all the comments we have received. We think it is 
close to being ready for WGLC.

This is obviously needed information for a lot of people. The draft already has 
17 citations.
https://scholar.google.com/scholar?hl=en_sdt=0,5=11841781769013384442

The need for compact formats and protocols has also gained attention outside of 
IoT. In the IAB workshop on Environmental Impact of Internet Applications and 
Systems, compact formats and protocols were discussed as a way to reduce the 
energy consumption of the Internet as a whole.
https://www.iab.org/activities/workshops/e-impact/

Changes in -06:

- Added more context to abstract and introduction
- Added high level comparison of the number of bytes in TLS 1.2 and TLS 1.3 
handshakes
- Added Compact TLS 1.3 (cTLS)
- Added some more clarification on (D)TLS choices
- Added text that CoAP needs to be added to the EDHOC figures to be directly 
comparable to DTLS.
- Added more DTLS and EDHOC alternatives to the summary table.
- Added ECDSA keys without point compression as that does not seem to be 
supported.
- Corrected DTLS calculation where 10 was used instead of 12 (thanks to Stephan 
Koch for reporting this)
- Updated DTLS 1.3 records to align with the RFC.
- Updated EDHOC numbers to align with latest drafts.
- Added numbers for Group OSCORE pairwise mode.
- Added that DTLS and OSCORE numbers might not be directly comparable as 
requirements on CoAP Token reuse are different.
- Changed names to Unicode
- Added SVG figures and tables with the help of aasvg

Cheers,
John Preuß Mattsson

From: internet-dra...@ietf.org 
Date: Sunday, 25 December 2022 at 19:52
To: Mališa Vučinić , John Mattsson 
, Francesca Palombini 
, John Mattsson , 
Malisa Vucinic 
Subject: New Version Notification for 
draft-ietf-lwig-security-protocol-comparison-06.txt

A new version of I-D, draft-ietf-lwig-security-protocol-comparison-06.txt
has been successfully submitted by John Preuß Mattsson and posted to the
IETF repository.

Name:   draft-ietf-lwig-security-protocol-comparison
Revision:   06
Title:  Comparison of CoAP Security Protocols
Document date:  2022-12-25
Group:  lwig
Pages:  45
URL:
https://www.ietf.org/archive/id/draft-ietf-lwig-security-protocol-comparison-06.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-lwig-security-protocol-comparison/
Html:   
https://www.ietf.org/archive/id/draft-ietf-lwig-security-protocol-comparison-06.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-security-protocol-comparison
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-ietf-lwig-security-protocol-comparison-06

Abstract:
   This document analyzes and compares the sizes of key exchange flights
   and the per-packet message size overheads when using different
   security protocols to secure CoAP.  Small message sizes are very
   important for reducing energy consumption, latency, and time to
   completion in constrained radio network such as Low-Power Wide Area
   Networks (LPWANs).  The analyzed security protocols are DTLS 1.2,
   DTLS 1.3, TLS 1.2, TLS 1.3, cTLS, EDHOC, OSCORE, and Group OSCORE.
   The DTLS and TLS record layers are analyzed with and without 6LoWPAN-
   GHC compression.  DTLS is analyzed with and without Connection ID.




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

[TLS] FW: New Version Notification for draft-mattsson-tls-psk-ke-dont-dont-dont-02.txt

[John Mattsson]

Hi,

I submitted a new version of draft-mattsson-tls-psk-ke-dont-dont-dont. psk_ke 
is likely the weakest part of TLS 1.3 and German BSI has already made a 
deadline for its deprecation. It is long overdue to change the "Recommended" 
value for psk_ke to "N".

This is a major update to earlier versions and adds a lot of background and 
motivation. The earlier version was never posted to the list. I plan to request 
presentation time at IETF 116.

Cheers,
John

From: internet-dra...@ietf.org 
Date: Friday, 30 December 2022 at 09:47
To: John Mattsson , John Mattsson 

Subject: New Version Notification for 
draft-mattsson-tls-psk-ke-dont-dont-dont-02.txt

A new version of I-D, draft-mattsson-tls-psk-ke-dont-dont-dont-02.txt
has been successfully submitted by John Preuß Mattsson and posted to the
IETF repository.

Name:   draft-mattsson-tls-psk-ke-dont-dont-dont
Revision:   02
Title:  Key Exchange Without Forward Secrecy is NOT RECOMMENDED
Document date:  2022-12-30
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/archive/id/draft-mattsson-tls-psk-ke-dont-dont-dont-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-mattsson-tls-psk-ke-dont-dont-dont/
Html:   
https://www.ietf.org/archive/id/draft-mattsson-tls-psk-ke-dont-dont-dont-02.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-mattsson-tls-psk-ke-dont-dont-dont
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-psk-ke-dont-dont-dont-02

Abstract:
   Massive pervasive monitoring attacks using key exfiltration and made
   possible by key exchange without forward secrecy has been reported.
   If key exchange without Diffie-Hellman is used, static exfiltration
   of the long-term authentication keys enables passive attackers to
   compromise all past and future connections.  Malicious actors can get
   access to long-term keys in different ways: physical attacks,
   hacking, social engineering attacks, espionage, or by simply
   demanding access to keying material with or without a court order.
   Exfiltration attacks are a major cybersecurity threat.  The use of
   psk_ke is not following zero trust principles and governments have
   already made deadlines for its deprecation.  This document updates
   the IANA PskKeyExchangeMode registry by setting the "Recommended"
   value for psk_ke to "N".




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

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

[John Mattsson]

Decrecating _DHE_ cipher suites seems ok but sends a weird message. A more 
reasonable approach would be to deprecate all cipher suites without _ECDHE_. An 
essential zero trust principle is to minimize the impact of breach such as key 
compromize. Key exchange without forward secrecy should only be allowed in 
resumption.

While the WG is in deprecation mode, please deprecate all non-AEAD cipher 
suites as well. RFC 7540 did this 7.5 years ago...

It is a much bigger problem that IETF is legitimizing bad crypto and bad 
security practice than that TLS used in some small amount of deployed devices 
are labeled depracated.

Cheers,
John

From: TLS  on behalf of Hubert Kario 
Date: Wednesday, 21 December 2022 at 14:59
To: Martin Thomson 
Cc: tls@ietf.org 
Subject: Re: [TLS] consensus call: deprecate all FFDHE cipher suites
On Tuesday, 20 December 2022 23:56:22 CET, Martin Thomson wrote:
> On Tue, Dec 20, 2022, at 23:52, Hubert Kario wrote:
>> use of FFDHE with large key sizes is the best protection against
>> store-and-decrypt-later attacks
>
> This doesn't deprecate use of FFDHE in TLS 1.3, for which we
> have some ludicrously large named groups.  Is that not enough?

Not everybody has migrated to TLS 1.3 yet. Not everybody has migrated to
ECC.

For the people that still have the only options of RSA key exchange or
FFDHE
key exchange, both in TLS 1.2, we need to be crystal clear that they should
pick
FFDHE.

Telling people that they shouldn't use the only things they can use means
that
the advice is unactionable, thus will be ignored.

>> If anything, RSA key exchange should be deprecated first.
>> RFC 8446 deprecated only the DSA ciphersuites, not RSA.
>
> This is an odd statement.  TLS 1.3 ciphersuites no longer
> include the concept of key exchange or signing.

Ciphersuites, yes. Protocol itself, no. It still performs a key exchange.
And TLS 1.3 explicitly deprecates DSA, see below.

> If you are talking about the signing part, both were sort of
> deprecated.  RSASSA-PKCS1_v1.5 (ugh, I hate typing that) is only
> usable within the certificate chain, not in the protocol.  PSS
> was added back.

There's a difference between saying that a TLS 1.3 client MUST NOT
advertise
client hello with TLS_RSA_* ciphersuites listed, and just having TLS 1.3
not supporting RSA key exchange.

Both of them can be called "deprecated", but one is a clearer and stronger
condemnation than the other.

DSA is effectively treated with the former "deprecation":
RFC8446 Section 4.2.3:

>  They MUST NOT be offered or negotiated by any
>  implementation.  In particular, MD5 [SLOTH], SHA-224, and DSA
>  MUST NOT be used.

RSA key exchange has nothing like it.

For me "deprecated" means "You really shouldn't use it", not "You should
stop
using it at the earliest convenience". I.e. MUST NOT vs SHOULD NOT.

> However, for key exchange, which is more relevant to this
> conversation, RSA was indeed removed.  And the draft we're
> discussing does indeed say that RSA key exchange in TLS 1.2 is
> deprecated.
>
> Can you help me better understand the scope of your objection?

I guess my primary objection is with the subject of this thread:
"deprecate all FFDHE cipher suites". That I don't agree with.

As far as the "draft-ietf-tls-deprecate-obsolete-kex-01" text goes, I would
tweak some things, but the general description of FFDHE state I do agree
with:
"that you shouldn't use it in TLSv1.2, but if you have to, there are simple
things to do to make sure you're relatively secure".
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

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

Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-01.txt

[John Mattsson]

Hi,

I think this is great work and something the TLS WG should adopt and work on. 
Reducing the total number of bytes is very important not only in constrained 
IoT, but also in TLS based EAP methods, and in applications where handshake 
time to completion is important.

I quicky read the -02 draft. It seems to be in a good shape. Some comments:

- I think it would be good if the draft described how it works with 
draft-ietf-tls-subcerts. While the latest version of draft-ietf-tls-subcerts 
talks about “delegated credential” and not certifcates, they are commonly 
refered to as subcerts.
- I think draft-kampanakis-tls-scas-latest could considered allowing 
suppressing also the end-entity certificate for use cases when 
draft-ietf-tls-subcerts is used.

Cheers,
John

From: TLS  on behalf of Kampanakis, Panos 

Date: Friday, 4 March 2022 at 16:42
To: tls@ietf.org 
Cc: Bytheway, Cameron 
Subject: Re: [TLS] New Version Notification for 
draft-kampanakis-tls-scas-latest-01.txt
Hi all,

The updated -01 version fixes a couple of nits identified by Ilari, removes the 
needs for two different tlsflags, one each direction, and does not require an 
acknowledgement of the ICA suppression tlsflag based on discussions about the 
tlsflags draft 
https://mailarchive.ietf.org/arch/msg/tls/SIvCO_ZFmNfTEeyiuZOcdBzTdAo/

There are more issues we are tracking based on discussions in this list 
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-24c7ac234ac8e19f=1=76ac0dba-b0c6-4ac8-9538-5faabd060cb2=https%3A%2F%2Fgithub.com%2Fcsosto-pk%2Ftls-suppress-intermediates%2Fissues

-Original Message-
From: internet-dra...@ietf.org 
Sent: Friday, March 4, 2022 10:34 AM
To: Bas Westerbaan ; Bytheway, Cameron 
; Martin Thomson ; Kampanakis, Panos 

Subject: [EXTERNAL] New Version Notification for 
draft-kampanakis-tls-scas-latest-01.txt

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



A new version of I-D, draft-kampanakis-tls-scas-latest-01.txt
has been successfully submitted by Panos Kampanakis and posted to the IETF 
repository.

Name:   draft-kampanakis-tls-scas-latest
Revision:   01
Title:  Suppressing CA Certificates in TLS 1.3
Document date:  2022-03-04
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/archive/id/draft-kampanakis-tls-scas-latest-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-kampanakis-tls-scas-latest/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-kampanakis-tls-scas-latest
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-kampanakis-tls-scas-latest-01

Abstract:
   A TLS client or server that has access to the complete set of
   published intermediate certificates can inform its peer to avoid
   sending certificate authority certificates, thus reducing the size of
   the TLS handshake.




The IETF Secretariat


___
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] sslkeylogfile

[John Mattsson]

Hi,

Two high level comments:


- OLD: "though use of earlier versions is strongly discouraged [RFC8996]"

That is not what RFC 8996 says. RFC 8996 says

- "TLS 1.1 MUST NOT be used."
- "TLS 1.1 MUST NOT be used."

Please change to something that aligns with RFC 8996 such as

NEW: "though use of earlier versions is forbidden [RFC8996]"


-  "Access to the content of a file in SSLKEYLOGFILE allows an attacker
   to break the confidentiality protection on any TLS connections that
   are included in the file."

This is true but does not at all reflect the implications of the existence of a 
file for long-term storage of keys like this. Storing any of the keying 
material like this completely breaks the stated forward secrecy property of TLS 
1.3 as it creates new long-term keys. It does not matter how well the file is 
protected i.e.,

   "Ensuring adequate access control on these files therefore becomes
   very important."

is not enough. The theoretical security properties are still broken badly. I 
think this draft is problematic, but I can understand the need to standardize 
this existing format. I think the fact that SSLKEYLOGFILE breaks the security 
properties of TLS 1.3 needs to very clearly described. As a consequence, I 
think the only allowed use case standardized by TLS WG should be limited to 
non-production debugging. If governments and companies wanting visibility do 
other things, that would be outside of IETFs control.

Cheers,
John

From: TLS  on behalf of Martin Thomson 

Date: Wednesday, 26 October 2022 at 02:18
To: Peter Gutmann , tls@ietf.org 
Subject: Re: [TLS] sslkeylogfile
On Tue, Oct 25, 2022, at 16:48, Peter Gutmann wrote:
> But it's not the same thing, it only seems to cover some TLS 1.3 extensions.
> Thus my suggestion to call it "Extensions to the SSLKEYLOGFILE Format for TLS
> 1.3".

That's not the intent.  Section 3.2 covers all you need for TLS 1.2.

I did not describe the (deprecated) "RSA" key, is that in common usage?  Or, 
are there things that I have missed?  I got everything from 
https://firefox-source-docs.mozilla.org/security/nss/legacy/key_log_format/index.html
 but maybe that is no longer the best reference.

___
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] DTLS for Delegated Credentials (draft-ietf-tls-subcerts)?

[John Mattsson]

I see no reason to preclude DTLS. DTLS-OK should be Y.


Some quick comments on the document:

- "certificate key" seems undefined.


-  "Delegated credentials do not provide any additional form of early 
revocation."

I think this definitly require more security considerations. For systems doing 
frequent revocation checking this is a significant downgrade.

Is it correct that an expiry of an RFC 5280 cert is ”revocation”?


- "Since it is short lived, the expiry of the delegated credential revokes the 
credential."

This would be true also for long lived.

Is it correct that an expired RFC 5280 cert is "revoked"?


- "Revocation of the long term private key that signs the delegated credential 
(from the end-entity certificate) also implicitly revokes the delegated 
credential."

I think you revoke a certifice, not a private key.

Nothing says that the certificate is long lived. They could both be valid for 7 
days.

Revocation of the certificate is problematic as it revokes certificate and all 
the delegated credentials (there might be many). Should be given more 
considerations.


- Extended key usage is not discussed at all. That a cert with id-kp-serverAuth 
but not id-kp-clientAuth can be used to sign a delegated client cert seems 
strange.


- How does delegated credentials work in systems that use fingerprints like RFC 
4975 and RFC 5763. I think that need to be discussed/specified.


Cheers,
John

From: TLS  on behalf of Salz, Rich 

Date: Wednesday, 16 February 2022 at 21:31
To: Sean Turner , TLS List 
Subject: Re: [TLS] DTLS for Delegated Credentials (draft-ietf-tls-subcerts)?
>Right now the I-D exclusively mentions TLS. The fix might be as easy as a 
> global replace of TLS with (D)TLS. Can anybody think of a reason to preclude 
> DTLS?

I can't think of one. I wonder if this also extends to QUIC and NTP security, 
but that's up to those WG's or UTA I guess.



___
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] [Uta] OCSP in RFC7525bis

[John Mattsson]

> This might be overstating the case a little bit.

Yes, I agree that “not at all” is overstating things. Revocation is a very 
complex issue, most absolute statements are probably wrong. “Not a replacement 
in general” might be a better formulation. It might be a replacement in some 
use cases, but these use cases would then have quite low requirements on 
revocation.

I agree that in your example, OCSP stapling with a week-long lifetime for the 
end-certificate only and a certificate with a week-long lifetime give exactly 
the same security. But

-  Certificates with one-week lifetimes is not common and 
will maybe never be common. It also creates work for both the CA and the 
device. This is not practical for constrained IoT. CA systems in critical 
infrastructure often do not use OCSP at all due to the risk of 
denial-of-service attacks and rely purely on CRLs.

-  The OCSP stapling example you give is a quite specific 
example (Web/HTTPS). The level of revocation checking in the example is quite 
low. For many current IPsec deployments, revocation checking is done daily or 
several times per day. (D)TLS is often replacing IPsec in virtualized 
environments. One week is quite a long time and in your example revocation 
checking is only done for the end-entity certificate. Some systems check the 
revocation status of all the certificates in the chain. In cases with 
fraudulently issues certificates, they are often used immediately and a 
week-long lifetimes  (certificates or OCSP responses does not help).

-  And obviously short-term end-entity certificates do not 
protect against revoked intermediate or self-issued CA certificates.

John

From: Uta  on behalf of Daniel Kahn Gillmor 

Date: Monday, 24 January 2022 at 17:19
To: u...@ietf.org , tls@ietf.org 
Subject: Re: [Uta] [TLS] OCSP in RFC7525bis
On Mon 2022-01-24 13:06:13 +0000, John Mattsson wrote:
> I think another omission in RFC7525 that should be fixed in RFC7525 is
> a discussion on certificate life-times, which is often discussed
> together with revocation checking- Short-lived certificates is an
> improvement over long-lived certificates, but not at all a replacement
> for revocation checking.

This might be overstating the case a little bit.  If revocation checking
is done by OCSP stapling, then the OCSP validity window *is* in effect
the duration of a "short-lived certificate".  To the extent that a
short-lived certificate has the same validity period as an OCSP
response, it is indeed a replacement for revocation checking.

As an example, the validity window of the stapled OCSP response i see
according to the cert i get on port 443 of www.ietf.org<http://www.ietf.org> 
has this
validity window:

This Update: Fri Jan 21 01:21:02 UTC 2022
Next Update: Fri Jan 28 00:36:02 UTC 2022

But when i query the OCSP responder directly i get this validity window:

This Update: Mon Jan 24 01:21:00 UTC 2022
Next Update: Mon Jan 31 00:36:00 UTC 2022

The week-long range is pretty comon, and a week-long certificate would
offer just as much protection against certificate misuse (an adversary
misusing a certificate with stapled OCSP could cache the last "good"
OCSP response and continue stapling it until it expires).

So unless "revocation checking" is defined to mean "out-of-band
confirmation with the issuing authority" (which would introduce both
latency and privacy concerns, so let's not go there), then a short-lived
certificate is indeed a replacement for revocation checking.

However, under the current certificate transparency regime, short-lived
certificates pose a challenge to CT logs, which scale with the number of
certificates issued over a given time period.  Replacing every 3-month
certificate with a corresponding number of 1-week certificates would
increase the size of CT logs by a factor of at least 12 -- probably
more, since certificates are generally issued with some overlap to
account for server-side work at cert transition and client-side clock
skew.

So, arguably, the advantage of revocation checking via OCSP stapling
over short-lived certificates today has to do with keeping CT logs a
manageable size, not with any particular security gain in terms of
revocation functionality.

--dkg

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

Re: [TLS] OCSP in RFC7525bis

[John Mattsson]

Hi,

In EMU WG there was a stong consensus to mandate revocation checking in EAP-TLS 
1.3. Mandatory OCSP Stapling was suggested by someone as a way to achieve this. 
The transition from EAP-TLS 1.2 to EAP-TLS 1.3 made this possible. The 
mandatory to use OCSP Stapling was softened after comments from Hannes, which 
was good. I think the used mechanism should the choice of the application. I 
don't think there was much discussion regarding specific use cases. The current 
text is:

  "the revocation status of all the certificates in the certificate chains
   MUST be checked (except the trust anchor)."

  "EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status
   Requests (OCSP stapling) as specified in [RFC6066] and
   Section 4.4.2.1 of [RFC8446].  It is RECOMMENDED that EAP-TLS peers
   and EAP-TLS servers use OCSP stapling"

You probably already know this but NIST has introduced strong requirements on 
OCSP for TLS:

  "TLS servers shall be configured with certificates issued by a CA that 
publishes revocation information in Online Certificate Status Protocol (OCSP) 
[63] responses."

  "The server shall support the use of the following TLS extensions.
   5. Certificate Status Request extension"

   https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf

3GPP has also introduces requirements on OCSP and OCSP stapling:

   OSCP should be supported by CAs and "Certificate Status Request" should be 
supported by TLS clients and servers.

   
https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=2279
   
https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=2293

Both OCSP and OCSP Stapling are quite widely supported. According to Wikipedia, 
16/18 TLS implementations support OCSP. One of the two lacking implementations 
is from Ericsson, but I know that both OCSP and OCSP Stapling is in actively 
development right now.

https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations
https://github.com/erlang/otp/tree/5b6931f001a00bff730867fdf07a8580eb989e24/lib/ssl

I think it makes sense to strengthen recommendations and requirements on 
revocation, OCSP, and OCSP stapling and align RFC7525bis more with 
NIST.SP.800-52r2.

I think the one omission in RFC7525 that should be fixed in RFC7525 is a 
recommendation to do revocation checking. I think that is the most important 
thing, not how the revocation checking is done.

I think another omission in RFC7525 that should be fixed in RFC7525 is a 
discussion on certificate life-times, which is often discussed together with 
revocation checking- Short-lived certificates is an improvement over long-lived 
certificates, but not at all a replacement for revocation checking.

Cheers,
John

From: Uta  on behalf of Hannes Tschofenig 

Date: Monday, 24 January 2022 at 11:32
To: Yaron Sheffer , u...@ietf.org , 
tls@ietf.org 
Subject: Re: [Uta] OCSP in RFC7525bis
Hi Yaron,

That’s exactly my worry. I have seen OCSP being proposed in EMU (with EAP-TLS) 
and also in IoT environments where it just don’t make a lot of sense to me. 
Hence, I would like to understand the motivation behind it and the use cases.

Ciao
Hannes


From: Yaron Sheffer 
Sent: Thursday, January 20, 2022 3:18 PM
To: Hannes Tschofenig ; u...@ietf.org; tls@ietf.org
Subject: Re: OCSP in RFC7525bis

Hi Hannes,

This is not about my personal beliefs. RFC 7525 looks at certificate revocation 
in the context of TLS (and not only TLS for Web use but the broader ecosystem) 
and recommends OCSP and OCSP Stapling as the best available techniques to 
enable effective certificate revocation, but with caveats. It’s been more than 
6 years since the RFC was published, and we are reviewing our recommendations, 
which may or may not still be valid.

Thanks,
Yaron

From: Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>
Date: Thursday, January 20, 2022 at 12:00
To: Yaron Sheffer mailto:yaronf.i...@gmail.com>>, 
u...@ietf.org mailto:u...@ietf.org>>, 
tls@ietf.org mailto:tls@ietf.org>>
Subject: RE: OCSP in RFC7525bis
Hi Yaron,

Where do you believe OCSP will be a good fit and why?

Ciao
Hannes

From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of 
Yaron Sheffer
Sent: Wednesday, January 19, 2022 3:57 PM
To: u...@ietf.org; tls@ietf.org
Subject: [TLS] OCSP in RFC7525bis

Hi,

RFC 7525 (the TLS BCP) has a section [1] with “weak” recommendations to use 
OCSP and OCSP stapling. We are changing these recommendations [2] in view of 
OCSP stapling in TLS 1.3 and the obsolescence of RFC 6961.

But this raises a larger question: many client-side implementations soft-fail 
if they don’t get an OCSP response within the handshake, i.e. they just ignore 
the problem. As far as we understand, this makes OCSP stapling completely 
ineffective for what it’s trying to solve.

So for the new BCP, we have three options:

Re: [TLS] Up to date overview of TLS implementations?

[John Mattsson]

Thanks Achim,

My interest in DTLS Connection IDs is mainly for non-constrained use cases such 
as DTLS/SCTP (DTLS over SCTP) between nodes in the 5G core network.

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dtls-over-sctp-bis/

The current plan is to mandate use of connection IDs for both DTLS 1.2 and DTLS 
1.3.

Cheers,
John

From: Achim Kraus 
Date: Friday, 12 November 2021 at 10:32
To: John Mattsson 
Cc: TLS@ietf.org 
Subject: Re: [TLS] Up to date overview of TLS implementations?
Hi John,

for draft-ietf-tls-dtls-connection-id, I have some views ("overview" may
be something else).

Eclipse/Californium, Release 3.0 (3. November 2021), Java, CoAP + DTLS
1.2, supports/configurable both deprecated variants (old MAC and
deprecated extension code-point 53) and RFC9146 variant (new MAC and
extension code-point 54).

Eclipse/Leshan, Java, LwM2M, using Californium and current development
of leshan is updated to use Californium 3.0.

Eclipse/tinydtls, C, DTLS 1.2, on my list (but for now I'm still too
busy with Californium).

Mbedtls 3.0, C, ongoing, 
https://protect2.fireeye.com/v1/url?k=b8474e79-e7dc7745-b8470ee2-86b1886cfa64-2c1d54f96c0a9e76=1=c259a055-7f88-4bac-a4f8-bc722e69c000=https%3A%2F%2Fgithub.com%2FARMmbed%2Fmbedtls%2Fpull%2F5061

Tools:

Wireshark, implemented,
https://gitlab.com/wireshark/wireshark/-/issues/17695

Zephyr, waiting on mbedtls,
https://protect2.fireeye.com/v1/url?k=37e00812-687b312e-37e04889-86b1886cfa64-88e9e9f09c0d6a34=1=c259a055-7f88-4bac-a4f8-bc722e69c000=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F36738

best regards
Achim Kraus


Am 12.11.21 um 09:55 schrieb John Mattsson:
> Hi,
>
> Is there any up to date overwiew of which TLS libraries support or are
> working on support for new and upcoming stuff like:
>
> RFC 8879 TLS Certificate Compression
>
> draft-ietf-tls-dtls-connection-id
>
> draft-ietf-tls-ticketrequests
>
> draft-ietf-tls-subcerts
>
> draft-ietf-tls-dtls13
>
> draft-ietf-tls-esni
>
> Cheers,
>
> John
>
>
> ___
> 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] Up to date overview of TLS implementations?

[John Mattsson]

Hi,

Is there any up to date overwiew of which TLS libraries support or are working 
on support for new and upcoming stuff like:

RFC 8879 TLS Certificate Compression
draft-ietf-tls-dtls-connection-id
draft-ietf-tls-ticketrequests
draft-ietf-tls-subcerts
draft-ietf-tls-dtls13
draft-ietf-tls-esni

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

Re: [TLS] RFC8447bis

[John Mattsson]

Hi,

My biggest concern with the "Recommended" column that I raised some year ago is 
that most people I meet in other SDOs as well as developers using TLS tend to 
believe that "Recommended" means "Recommended to use". This is unfortunate as 
there is a huge difference between "recommended to support" and "recommended to 
use". The RFC8447bis authors and TLS chairs also made this mistake in their 
slides this week. It is a very easy mistake to make.

Can we plese rename the column to "Recommended to support". I would also 
suggest to change the text so in RFC8447 as well as the notes in the IANA 
registries to talk about "Recommended to support" instead of just "Recommended"

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

Re: [TLS] Flags Extension: why only for TLS 1.3?

[John Mattsson]

I think the term telecom is as obsolete as TLS 1.2 :) Mobile network are all 
IP, and voice communication is to a large degree provided by Internet 
companies. 3GPP operates in generations every 10 years (2G, 3G, 4G, 5G, 6G), 
half generations every 5 years (GPRS, HSPA, 4G LTE Advanced), as well as 
releases every 1-2 years. I think the cellular industry has been one of the 
quickest adopters of TLS 1.3:

- 3GPP Rel-15 (2018) mandated support of TLS 1.3 for all network nodes for all 
uses of TLS (3GPP standards and products have quite many uses of (D)TLS). 5G 
core networks rely on TLS 1.3 and HTTPS for the new SBA zero-trust architecture.
- 3GPP Rel-16 (2020) mandated support of TLS 1.3 for all UEs (mobile phones and 
IoT devices) as well as EAP-TLS 1.3 (if EAP-TLS is supported).
- 3GPP Rel-17 (2021) has an approved work item to mandate support of DTLS 1.3 
but due to it not being published as an RFC yet, that is likely to happen in 
Rel-18 (2023) instead.

In the dark ages of SSL 3.0, TLS 1.0, TLS 1.1, etc. it seems to have been 
considered acceptable to continue using obsolete versions of security protocols 
like TLS. I’m happy that NIST agrees that this is not acceptable anymore. 
Industries should have started with the TLS 1.3 transition many years ago, 
right now industries should start thinking about when support of TLS 1.2 can be 
turned off (which is likely not before 2030-ish).

Cheers,
John

From: Salz, Rich 
Date: Thursday, 4 November 2021 at 15:02
To: Hannes Tschofenig , John Mattsson 
, IETF TLS 
Subject: Re: [TLS] Flags Extension: why only for TLS 1.3?
I am amused to see a telecom person saying obsolete when it’s only 2-3 years 
old.  In my discussions I’ve found that they think in terms of at least 10 
years. ☺

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

Re: [TLS] Last Call: (Guidance for External PSK Usage in TLS) to Informational RFC

[John Mattsson]

Hi,

I think this is a great document with a lot of good information.


I think some things that should be more positive:

-- For both PSK authentication and PSK key exchange without (EC)DHE the bad 
security properties such as lack of identity protection and lack of forward 
secrecy can be overcome by using one-time PSKs. External PSKs with short 
lifetimes are quite common in many real deployments. I think this should be 
mentioned.

-- I think quantum resistance should be mentioned earlier in the document. 
Quantum resistance is a security property, not use a use case.


Some things that should be more negative:

-- In the list in 4.1 you can add
  "4.  Any group member can blame any other group member."


Other comments:

-- "then PSK-only key establishment modes are secure against both active and 
passive attack."
  I think this you need to describe the exact attacks you have in mind rather 
than use the work "secure". My view would be that acceptable security in 2021 
includes both identity protection and forward secrecy. But more on a system 
level, then necessarily by TLS itself.


-- "DH"
  I think it would be good to change all “DH” to “DHE” and all “Diffie-Hellman” 
to “ephemeral Diffie-Hellman” to avoid confusion with the static DH cipher 
suites in obsolete versions of TLS.


-- "As discussed in Section 6, there are use cases where it is desirable
   for multiple clients or multiple servers to share a PSK."

  "However, as discussed in Section 6, there are application scenarios
   that may rely on sharing the same PSK among multiple nodes."

Unless you have any real deployments to share, I think this should be 
reformulated. These are Gedankenexperiments used to illustrate the attack, not 
real-world applications. I would reformulate and remove "desirable", group PSKs 
should be very much discouraged. Suggestion:

"As discussed in Section 6, to illustrate their attack, [Akhmetzyanova] 
describes scenarios where multiple clients or multiple servers share a PSK."

Cheers,
John

From: TLS  on behalf of The IESG 
Date: Friday, 29 October 2021 at 18:18
To: IETF-Announce 
Cc: tls@ietf.org , draft-ietf-tls-external-psk-guida...@ietf.org 
, ka...@mit.edu , 
tls-cha...@ietf.org 
Subject: [TLS] Last Call:  
(Guidance for External PSK Usage in TLS) to Informational RFC

The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'Guidance for External PSK Usage in TLS'
   as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2021-11-19. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This document provides usage guidance for external Pre-Shared Keys
   (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446.
   This document lists TLS security properties provided by PSKs under
   certain assumptions, and then demonstrates how violations of these
   assumptions lead to attacks.  This document discusses PSK use cases
   and provisioning processes.  This document provides advice for
   applications to help meet these assumptions.  This document also
   lists the privacy and security properties that are not provided by
   TLS 1.3 when external PSKs are used.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-guidance/



No IPR declarations have been submitted directly on this I-D.





___
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] Flags Extension: why only for TLS 1.3?

[John Mattsson]

TLS 1.2 has been obsolete for over three years. Oxford dictionary defines 
obsolete as "no longer produced or used; out of date." NIST requires support of 
TLS 1.3 everywhere no later than Jan 2024, which at least in theory means no 
negotiation of TLS 1.2.

I think IETF, TLS WG, and TLS libraries should spend their time on TLS 1.3 
rather than giving the false idea it is ok to stay on TLS 1.2.

John

From: TLS  on behalf of Hannes Tschofenig 

Date: Monday, 25 October 2021 at 19:12
To: IETF TLS 
Subject: [TLS] Flags Extension: why only for TLS 1.3?
Hi all,

why is the flags extension only defined for TLS 1.3?

There is nothing in this extension that prevents us from using it also in TLS 
1.2.

Could we make it also available to TLS 1.2?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Question regarding RFC 7366

[John Mattsson]

I think the best way to think about AEAD from a protocol standpoint is as an 
interface. This is especially true for TLS where there are algorithms like 
TLS_SHA256_SHA256 for the AEAD interface that do not do encryption. A TLS 
cipher suite either use the AEAD interface or it does not.

Cheers,
John

From: TLS  on behalf of Peter Gutmann 

Date: Thursday, 4 November 2021 at 07:37
To: alex.sch...@gmx.de , tls@ietf.org 
Subject: Re: [TLS] Question regarding RFC 7366
alex.sch...@gmx.de  writes:

>I would really appreciate a response to get some clarification on what the
>intended interpretation is, i.e., when the extension should be used.

There's not really any contradiction, encrypt-then-MAC has nothing to do with
AEAD which is an all-in-one mode, so it doesn't apply to any AEAD cipher.

Peter.

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

[TLS] Open source implementation of CBOR Encoded X.509 Certificates (C509 Certificates)

[John Mattsson]

Hi,

There has been a lot requests from people in different working groups for souce 
code to try out C509 certificates. I just released my example implementation of 
a DER X509 to CBOR C509 encoder written in Rust.

CBOR encoded X509 (RFC 5280) is one of the main future work item for the COSE 
WG. C509 is specified as a CBOR encoding of the DER TBSCertificate sequence, 
which is then combined with a signature over the DER or CBOR encoding. C509 can 
be used as a compression mechanism complementing RFC 8879, or as a "natively 
signed" CBOR certificatice encoding still following RFC 5280.

The Rust implementation supports reading a certificate from file or downloading 
a certificate chain from a HTTPS server. The certificate chain is encoded to 
COSE_X509, COSE_C509, as well as TLS Certificate and CompressedCertificate 
messages with X509 and C509. Size comparisions can be found in the draft.

The Rust implementation can be found here:
https://github.com/cose-wg/CBOR-certificates/tree/master/c509

The latest version of the draft:
https://datatracker.ietf.org/doc/draft-ietf-cose-cbor-encoded-cert/

Please send comments and suggestions to c...@ietf.org only, which is where 
discussion should take place.

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

Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

[John Mattsson]

Brian Smith wrote:
>Deprecating FFDHE key exchange without deprecating RSA key exchange will 
>substantially increase the usage >of RSA key exchange and thus make server key 
>compromise more dangerous. At a minimum, RSA key >exchange should be 
>deprecated at the same time, in the same document. 

Deprecating static RSA and everything else that does not have PFS is long 
overdue. RFC 7540 did this 6 years ago, and it was not a day too late. Strange 
that the best TLS profiling was/is done by HTTPBIS.

Viktor Dukhovni wrote:
>In practice security improves more when you raise the ceiling, rather the 
>floor.

Let’s start with mandating support of TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for 
the remaining TLS 1.2 implementations. RFC 7540 did this 6 years ago, and it 
was not a day too late.

Cheers,
John

From: TLS  on behalf of Brian Smith 
Date: Tuesday, 9 March 2021 at 01:13
To: Martin Thomson 
Cc: "TLS@ietf.org" 
Subject: Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

It is sad that nobody is willing to discuss the obvious downsides of this 
proposal as written, which should at least be mentioned in the security 
considerations. Without discussing the downsides we're reducing engineering to 
politics. If we discuss the downsides then we can substantially improve the 
proposal.

Deprecating FFDHE key exchange without deprecating RSA key exchange will 
substantially increase the usage of RSA key exchange and thus make server key 
compromise more dangerous. At a minimum, RSA key exchange should be deprecated 
at the same time, in the same document. 

Look at Windows Server 2012 and similar legacy products that are in widespread 
use, which don't support any PFS cipher suites except FFDHE. Please deprecate 
RSA key exchange at the same time so that there is enough motivation for 
vendors of these legacy products to add safe alternatives and/or for users of 
these legacy implementations to upgrade to something new that implements a safe 
alternative. (Note that Windows Server 2012 did add a patch to enable 
increasing its FFDHE key size to safe sizes.)

It would be useful for the browser vendors that recently dropped FFDHE support 
to share their measurements for how much RSA key exchange usage increased after 
their changes. That would help us quantify the real-world impact of this change.

RSA key exchange uses flawed and error-prone cryptography that is prone to side 
channels as well, PKCS#1 encryption/decryption. Previous studies have found 
widespread flaws in implementations that are (AFAICT) even more easily 
exploitable than the Racoon attack is.

It is easy to imagine a perfect implementation of RSA key exchange that also 
perfectly protects the server's private key. It is unrealistic to expect 
implementations to actually live up to that ideal. When RSA key exchange is 
used, then a government that can effectively undo all the past encryption of a 
server if it can force the server operator to disclose the key, even for a 
perfect implementation of RSA key exchange.

Deprecating RSA key exchange at the same time as FFDHE will encourage adoption 
of newer products that also often support TLS 1.3.

Without creating a new, correct, way to use FFDHE key exchange, we're left with 
elliptic curve (ECDHE) key exchange as the only reasonable and 
widely-implemented key exchange mechanism.

Cheers,
Brian
(Speaking only for myself)

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

Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

[John Mattsson]

+1 for forbidding more old crap.

Lack of forward secrecy should imply at least NOT RECOMMENDED.

Does it make sense to forbid things for TLS 1.0 and TLS 1.1 when we soon have 
an RFC forbidding use of TLS 1.0 and TLS 1.1?

Cheers,
John


-Original Message-
From: TLS  on behalf of Martin Thomson 

Date: Monday, 8 March 2021 at 16:34
To: "TLS@ietf.org" 
Subject: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

Well overdue.  We should do this.

The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to match the 
document content.  I only see static or semi-static DH and ECDH key exchange 
being deprecated (in the document as non-ephemeral).

___
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