Subject: [Uta] WGLC for draft-ietf-uta-rfc7525bis-04

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 7 Dec 2021 15:59:50 +0300

Hi,

this message starts a Working Group Last Call for draft-ietf-uta-rfc7525bis-04:
https://datatracker.ietf.org/doc/draft-ietf-uta-rfc7525bis/

The WGLC will last for two weeks and will end on December the 21st.
Please send your comments to the list before this date.

Regards,
Leif & Valery.

---

From: Julien ÉLIE <[email-masked]>
Date: Thu, 9 Dec 2021 22:11:12 +0100

Hi all,

> Please send your comments to the list before this date.

Great job!

I've only one minor remark about wording difference between:

    *  Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to
       negotiate TLS version 1.2 over earlier versions of TLS.

    *  Implementations SHOULD support TLS 1.3 [RFC8446] and if
       implemented, MUST prefer to negotiate TLS 1.3 over earlier
       versions of TLS.

and:

    *  Implementations MUST support and (unless a higher version is
       available) MUST prefer to negotiate DTLS version 1.2 [RFC6347]

    *  Implementations SHOULD support and, if available, MUST prefer to
       negotiate DTLS version 1.3 as specified in [I-D.ietf-tls-dtls13].

I think both could be homogenized (like the "unless a higher version is 
available" part, or "over earlier versions of (D)TLS").
Unless there is a subtlety, and if that is the case, it should be more 
emphasized.

Note that I-D.ietf-tls-dtls13 is RFC 9147 (though still in AUTH48).

Also:

       NOTE: This recommendation has been changed from SHOULD NOT to MUST
       NOT on the assumption that [I-D.ietf-tls-oldversions-deprecate]
       will be published as an RFC before this document.

=> Now published as RFC 8996.  This paragraph can be removed.
More explanation about the deprecation of TLS 1.1 could be given (as TLS 
1.0 does).  Currently, there's only:

       Rationale: TLS 1.1 (published in 2006) is a security improvement
       over TLS 1.0 but still does not support certain stronger cipher
       suites.

I suggest adding what is present in the introduction of RFC 8996: TLS 
1.1 "lacks of support for current recommended cipher suites, especially 
authenticated encryption with associated data (AEAD) ciphers".

Happy feasts of end of year,

-- 
Julien ÉLIE

« Il buvait toutes mes paroles, et comme je parlais beaucoup, à un
   moment, je le vois qui titubait… » (Raymond Devos)

---

From: Sean Turner <[email-masked]>
Date: Fri, 10 Dec 2021 13:40:13 -0500

> On Dec 9, 2021, at 16:11, Julien ÉLIE <[email-masked]> wrote:
> 

On the DTLS1.3 I-D’s status: there were two late stage changes 1) the narrow epoch for long-lived connections, and 2) the ambiguous message_hash construction. The WG has settled on the way forward for #1, but it is out for review from the security researchers. We are just waiting on a response. On #2, we still need the PR, but ekr knows it is on his plate.

Cheers,
spt

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 11 Dec 2021 13:14:48 +0200

> Please send your comments to the list before this date.

- Section 3.1.1:

Obsolete NOTE should be removed.

- Section 3.4:

The recommendations given are not sufficient for security.

To actually give any forward security, with any timeframe, an server
implementation supporting TLS 1.2 session tickets MUST:

1) Rotate ticket keys periodically, AND
2) Securely destroy the old ticket keys, AND
3) Refuse to resume too old sessions.

Failure to do so does not just expose resumed connections to
compromise, it exposes all connections where client sent the session
ticket extension to compromise, regardless of if the sessions were
ever resumed or not.

The last one is about age of session, not age of ticket. Session can be
older than the ticket. These requirements follow from rather nasty
interaction of the following properties of TLS 1.2 session tickets:

1) Client can initiate handshake without proof-of-possession of the
   session ticket key.
2) The ticket is returned unencrypted.
3) The server can update the ticket.
4) There is no ratcheting of keys.

TLS 1.3 session tickets do not have three of these properties. As
consequence, e.g.:

1) Sending session ticket never compromises the connection.
2) Even without DH, only connections using ticket with compromised
   session ticket encryption key are compromised.

- Section 3.5:

This needs to be strengthened to that all TLS 1.2 implementations
MUST implement renegotiation_info, regardless of if renegotiation is
implemented or not.

It is not safe for client to connect to TLS 1.2 server that does not
support renegotiation_info, regardless of if either endpoint actually
implements renegotiation.

- Section 3.7:

It is not possible for server to acknowledge different SNI hostname.
The server version of server_name extension always has an empty payload.

- Section 3.9:

I do not think the recommendation is in agreement with TLS 1.3. TLS
absolutely requires application profile for 0-RTT (section E.5).

- Section 4:

What is "targeted security services" in context of cipher suites?
Maybe "targeted security level"?

- Section 6.4:

Reusing ECDH exponents is insecure unless one either:

1) Checks for point validity, or
2) Uses montgomery ladder with twist-secure curve.

Currently the only curves in TLS satsifying 2) are x25519 and x448. For
any other elliptic curve, reusing exponents without validating points
is insecure. Few thoursand connection attempts at most is sufficient
for recovering the ECDH private key, which compromises any connection
that used it.

- Section 6.5:

It seems that status_request_v2 is rather poorly supported.

Furthermore in context of WebPKI, the support for CA OCSP is really
poor. Major intermediates lack OCSP entierely, or the responses have
really long lifetimes (up to the 1 year maximum). Effective revocation
of WebPKI CAs basically requires propiteriary mechanisms.

-Ilari

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 16 Dec 2021 17:52:45 +0200

Here’s a quick reminder to those who have not reviewed the document yet, there’s still a few days until the WGLC deadline. Thanks to those who already responded with comments, and we are looking forward to more.

Best,

Yaron

On 12/7/21, 15:00, "Valery Smyslov" <[email-masked]> wrote:

Hi,

Regards,

Leif & Valery.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 16 Dec 2021 19:43:22 +0000

I am reading this now.  It’s good, I like it.

One nit; should Section 4.2 be titled “Cipher Suites for TLS 1.2” ?

In section 6.4, the “(e.g., even more than a few hours)” should probably replace it with “(in some cases, even as little as a few hours)” but it would be REALLY helpful for guidance on picking the time.

In section 6.5, doesn’t the stapling reference need additions for “cert status” for TLS 1.3?  And okay if you don’t want to mention certificate transparency, but either include that or make explicit that for XXX reasons you’re not doing so.

Hope this helps.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 17 Dec 2021 12:17:24 -0700

P.S. Following the authors' usual practice, we've opened GitHub issues 
for all the feedback received so far and will discuss amongst ourselves 
before posting to the list:

https://github.com/yaronf/I-D/issues?q=is%3Aissue+is%3Aopen+label%3ABCP195

On 12/16/21 8:52 AM, Yaron Sheffer wrote:
> Here’s a quick reminder to those who have not reviewed the document yet, 
> there’s still a few days until the WGLC deadline. Thanks to those who 
> already responded with comments, and we are looking forward to more.
> 
> Best,
> 
>                  Yaron
> 
> <https://datatracker.ietf.org/doc/draft-ietf-uta-rfc7525bis/>
>