[TLS] Re: I-D Action: draft-ietf-tls-8773bis-10.txt

> > Title: TLS 1.3 Extension for Using Certificates with an External > Pre-Shared Key > Author: Russ Housley > Name:draft-ietf-tls-8773bis-10.txt > Pages: 16 > Dates: 2025-07-29 > > Abstract: > > This document specifies a TLS 1.3 extensi

[TLS] Re: [Last-Call] draft-ietf-tls-8773bis-09 ietf last call Secdir review

Brian: Thanks for the review, > Document: draft-ietf-tls-8773bis > Title: TLS 1.3 Extension for Using Certificates with an External Pre-Shared > Key > Reviewer: Brian Weis > Review result: Ready > > I have reviewed this document as part of the security directorate's > ongoing effort to review a

[TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3

I support adoption with the additional applicability statement. Russ > On Jul 14, 2025, at 6:05 PM, Sean Turner wrote: > > We kicked off an adoption call for Use of SLH-DSA in TLS 1.3; see [0]. We > called consensus [1], and that decision was appealed. We have reviewed the > messages and agre

[TLS] Re: I-D Action: draft-ietf-tls-8773bis-09.txt

TLS 1.3 Extension for Using Certificates with an External > Pre-Shared Key > Author: Russ Housley > Name:draft-ietf-tls-8773bis-09.txt > Pages: 16 > Dates: 2025-07-06 > > Abstract: > > This document specifies a TLS 1.3 extension that allows TLS

[TLS] Re: AD review of draft-ietf-tls-8773bis

Paul: > The draft looks mostly okay. It should fix a few small issues: > > The document needs to Obsolete: 8773 Indeed. Fixed. > Please also mark this so in the datatracker, so reviews can more easily diff > 8773 against the latest 8773bis draft. I do not think this is something that I can d

[TLS] Re: I-D: Certificate Transparency Pages Extension

Is anyone using RFC 9162? I thought this was supposed to be the future direction of CT. Russ > On Jun 29, 2025, at 1:16 PM, Deirdre Connolly > wrote: > > There is also active discussion of new certificate transparency designs on > ct-pol...@chromium.org > On

[TLS] draft-ietf-tls-dtls-rrc-18 telechat Artart review

Document: draft-ietf-tls-dtls-rrc Title: Return Routability Check for DTLS 1.2 and DTLS 1.3 Reviewer: Russ Housley Review result: Ready I am the assigned ART-ART reviewer for this draft. Please treat these comments just like any other last call comments. Document: draft-ietf-tls-dtls-rrc-18

[TLS] Re: [Last-Call] draft-ietf-tls-dtls-rrc-16 telechat Artart review

That resolves my concern. Russ > On Jun 20, 2025, at 4:16 AM, Thomas Fossati wrote: > > Hi Russ, > > On Thu, 19 Jun 2025 at 18:54, Russ Housley via Datatracker > wrote: >> Summary: Almost Ready >> >> Thanks for address the vast bulk of my co

[TLS] draft-ietf-tls-dtls-rrc-16 telechat Artart review

Document: draft-ietf-tls-dtls-rrc Title: Return Routability Check for DTLS 1.2 and DTLS 1.3 Reviewer: Russ Housley Review result: Almost Ready I am the assigned ART-ART reviewer for this draft. Please treat these comments just like any other last call comments. Document: draft-ietf-tls-dtls-rrc

[TLS] Re: draft-ietf-tls-dtls-rrc-14 ietf last call Artart review

gt; On Tue, Jun 03, 2025 at 10:08:04AM +0100, Russ Housley via Datatracker > wrote: >> [...] >> >> Nits: >> >> Figure 4: The difference between a dash and a dot is unclear. > > Sorry, which dash? > >> Figures 4, 5 and 6: The purpose of lines with

[TLS] draft-ietf-tls-dtls-rrc-14 ietf last call Artart review

Document: draft-ietf-tls-dtls-rrc Title: Return Routability Check for DTLS 1.2 and DTLS 1.3 Reviewer: Russ Housley Review result: Almost Ready I am the assigned ART-ART reviewer for this draft. Please treat these comments just like any other last call comments. Document: draft-ietf-tls-dtls-rrc

[TLS] Re: I-D Action: draft-ietf-tls-8773bis-08.txt

ity (TLS) WG of the IETF. > > Title: TLS 1.3 Extension for Using Certificates with an External > Pre-Shared Key > Author: Russ Housley > Name:draft-ietf-tls-8773bis-08.txt > Pages: 16 > Dates: 2025-06-02 > > Abstract: > > This document

[TLS] Re: I-D Action: draft-ietf-tls-8773bis-07.txt

TLS 1.3 Extension for Using Certificates with an External > Pre-Shared Key > Author: Russ Housley > Name:draft-ietf-tls-8773bis-07.txt > Pages: 16 > Dates: 2025-05-31 > > Abstract: > > This document specifies a TLS 1.3 extension that allows TLS

[TLS] Re: Working Group Last Call for RFC8773bis

Thanks for the PR. I have merged it. Russ > On May 29, 2025, at 6:06 AM, Loganaden Velvindron wrote: > > On Tue, 13 May 2025 at 20:44, Joseph Salowey wrote: >> >> Russ has made modifications to the rfc8773bis and published a new draft [1] >> to address the comments from the FATT. You can s

[TLS] Re: Working Group Last Call for RFC8773bis

Usama: Good catch. I will correct. Russ > On May 24, 2025, at 11:00 AM, Muhammad Usama Sardar > wrote: > > Based on the protocol diagram provided to me by Russ and some preliminary > working back then, I do not expect it to break any properties of the TLS > protocol under traditional adve

[TLS] Re: Working Group Last Call for RFC8773bis

Thom: > I think this looks good. Thanks for the careful read. > Small typo: > > "Of course, this places significant burden on the generation ane of > > external PSKs.” Fixed in my edit buffer. > ane -> and Fixed. > Another nit: > > > due to the break in the (EC)DH algorithm > > Is this

[TLS] Re: ASN.1 in draft-ietf-tls-trust-anchor-ids

In addition, you could mandate that the extension can never be critical: ext-trustAnchorIdentifier EXTENSION ::= { SYNTAX TrustAnchorIdentifier IDENTIFIED BY id-pe-trustAnchorIdentifier CRITICALITY { FALSE } } Russ > On May 12, 2025, at 4:44 PM, Russ Housley wr

[TLS] ASN.1 in draft-ietf-tls-trust-anchor-ids

Please include a full ASN.1 module in the document that follows the RFC 5912 conventions for defining extensions. I have attached it. I have assumed that the module identifier and the OID for the extension will be assigned from thr PKIX registries. Russ = = = = = = = TrustAnchorIdenti

[TLS] Re: I-D Action: draft-ietf-tls-8773bis-06.txt

yer Security (TLS) WG of the IETF. > > Title: TLS 1.3 Extension for Using Certificates with an External > Pre-Shared Key > Author: Russ Housley > Name:draft-ietf-tls-8773bis-06.txt > Pages: 16 > Dates: 2025-05-05 > > Abstract: > > This docum

[TLS] Re: WG Adoption Call for Use of ML-DSA in TLS 1.3

I support adoption, and I will review. I agree with EKR that key management is more urgent, but I do not think that should block adoption. Russ > -Original Message- > From: Sean Turner > Sent: Tuesday, April 15, 2025 1:32 PM > To: TLS List > Subject: [TLS] WG Adoption Call for Use of

[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

I support adoption. Russ > On Apr 1, 2025, at 8:58 AM, Sean Turner wrote: > > We are continuing with our pre-announced tranche of WG adoption calls; see > [0] for more information. This time we are issuing a WG adoption call for the > ML-KEM Post-Quantum Key Agreement for TLS 1.3 I-D [1]. If

[TLS] Re: A different approach to Attestation

Phill: This is really a description of IDevID certificates that are installed by a factory, and then replaced by LDevID certificates that are issed by the device owner at the time of installation. NETCONF already supports that model.What am I missing? Russ > On Mar 16, 2025, at 11:31 PM, Phi

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

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

[TLS] Re: I-D Action: draft-ietf-tls-8773bis-04.txt

xtension for Using Certificates with an External > Pre-Shared Key > Author: Russ Housley > Name:draft-ietf-tls-8773bis-04.txt > Pages: 15 > Dates: 2025-02-22 > > Abstract: > > This document specifies a TLS 1.3 extension that allows TLS clients >

[TLS] Re: I-D Action: draft-ietf-tls-8773bis-03.txt

available. It is a work > item of the Transport Layer Security (TLS) WG of the IETF. > > Title: TLS 1.3 Extension for Using Certificates with an External > Pre-Shared Key > Author: Russ Housley > Name:draft-ietf-tls-8773bis-03.txt > Pages: 15 > Dates: 2024

[TLS] Re: PQ Cipher Suite I-Ds: adopt or not?

+1. There are people that want to implement both hybrid and pure key exchange. This action would allow a path to RECOMMENDED = Y for both in the future. Russ > On Dec 16, 2024, at 5:21 PM, Martin Thomson wrote: > > On Tue, Dec 17, 2024, at 08:59, Sean Turner wrote: >> Is the WG consensus to

[TLS] Re: Disallowing reuse of ephemeral keys

I prefer option 1. Russ > On Dec 12, 2024, at 12:35 PM, Joseph Salowey wrote: > > Currently RFC 8446 (and RFC8446bis) do not forbid the reuse of ephemeral > keys. This was the consensus of the working group during the development of > TLS 1.3. There has been more recent discussion on the li

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

I hope so. Can we start an adoption call? Russ > On Dec 5, 2024, at 4:08 PM, Scott Fluhrer (sfluhrer) > wrote: > > How do we proceed with this draft? > > This draft is quite boring (which is good from a cryptographical > perspective); it just says ‘take ML-KEM and insert it as a key agreem

[TLS] Re: Adoption call for RFC 9147bis

I do not object, but I look forward to the FATT review. Russ > On Dec 2, 2024, at 12:38 PM, Joseph Salowey wrote: > > This is a call for adoption of draft-rescorla-tls-rfc9147bis-00[1] as the > basis for an RFC9147 bis document. This document is seeded with the content > of RFC 9147. If yo

[TLS] Re: ML-DSA in TLS

Indeed. This one should progress quickly. Russ > On Nov 15, 2024, at 9:33 AM, Alicja Kario wrote: > > Very happy to see it. > > I'm for workgroup adoption of it. > > On Friday, 15 November 2024 11:51:31 CET, Bas Westerbaan wrote: >> We have posted a -00. >> >> https://datatracker.ietf.org/d

[TLS] Re: DTLS 1.3 bis

I agree that a bis is needed for DTLS 1.3, but I think that some of the things that David Benjiman talked about would have been discovered, especially the keyUpdate-related things, if there had been formal analysis of DTLS 1.3. Please have the FATT take a look. Russ > On Nov 12, 2024, at 3:2

[TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt

Thanks for doing this work. I hope the TLS WG will promptly adopt it. Russ > On Nov 2, 2024, at 8:15 PM, tirumal reddy wrote: > > Hi all, > > This draft https://datatracker.ietf.org/doc/draft-tls-reddy-slhdsa/ specifies > how the PQC signature scheme SLH-DSA can be used for authentication in

[TLS] Re: TLS WG Interim summary (was Re: TLS WG Virtual Interim on FATT Process)

The minutes have not been posted to that page yet. Russ > On Oct 17, 2024, at 2:24 PM, Sean Turner wrote: > > Hi! We had a quick (45min) interim to discuss the FATT Process. Slides & > minutes for (and eventually a recording of) the session can be found here: > https://datatracker.ietf.org/mee

[TLS] Re: Consensus call for RFC8773bis Formal Analysis Requirement

I agree, and I think the Security Considerations already cover this point: If the external PSK is known to any party other than the client and the server, then the external PSK MUST NOT be the sole basis for authentication. The reasoning is explained in Section 4.2 of [K2016]. When t

[TLS]Re: Consensus Call: -rfc8446bis PRs #1360

Please do not merge. Russ > On Aug 26, 2024, at 9:23 AM, Sean Turner wrote: > > Hi! Loganaden submitted a PR to add x25519 as an MTI in TLS 1.3 that > addresses an Issue submitted by Stephen; links to both follow: > Issue: https://github.com/tlswg/tls13-spec/issues/1359 > PR: https://github.co

[TLS]Re: Adoption call for Extended Key Update for TLS 1.3

The FATT-related slides that were presented yesterday said: ~~~ Mechanism: triage, then maybe analyze At document/change adoption call, chairs email the triage panel, bring summarized analysis to the WG as part of the adoption discussion. ~~~ I now realize that this is ambiguous. At what point

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

> > Title: TLS 1.3 Extension for Using Certificates with an External > Pre-Shared Key > Author: Russ Housley > Name:draft-ietf-tls-8773bis-02.txt > Pages: 15 > Dates: 2024-07-07 > > Abstract: > > This document specifies a TLS 1.3 extensi

[TLS]Re: Kicking off the TLS 1.3 formal analysis triage panel

EKR: I agree with most of your points about the process, but I want to respond to this paragraph in particular. > Similarly here, if the WG feels that a change is sufficiently large to > require formal analysis then the WG -- and more specifically those who > want the work to move forward -- nee

[TLS]Re: Kicking off the TLS 1.3 formal analysis triage panel

Usama: During WG Last Call, several people asked for formal analysis, I reached out to one researcher to see if thet formal analysis could be provided in response. I was told the additions were too simple to get a published paper. So, nothing happened. This response says that formal analysi

[TLS]Re: Kicking off the TLS 1.3 formal analysis triage panel

Deirdre: I can figure out what to do with some on this input, but most of it seems to be aimed at an audience other than the document author. I can add text related to the authentication and confidentiality goals: - For confidentiality: The session keys remains secure if either the external PS

Re: [TLS] [Last-Call] Genart last call review of draft-ietf-tls-keylogfile-01

heers, > Martin > > On Fri, Apr 12, 2024, at 14:30, Russ Housley via Datatracker wrote: >> Reviewer: Russ Housley >> Review result: Ready >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF docume

[TLS] Genart last call review of draft-ietf-tls-keylogfile-01

Reviewer: Russ Housley Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version

Re: [TLS] Working Group Last Call for ECH

Thanks. This URL gives access without a paywall: https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-ccs22.pdf Russ > On Apr 2, 2024, at 10:31 AM, Stephen Farrell > wrote: > > > Hiya, > > On 02/04/2024 15:17, Russ Housley wrote: >> Joe: >> The

Re: [TLS] Working Group Last Call for ECH

Joe: The ECH Internet-Draft includes this reference: [ECH-Analysis] "A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello", November 2022. This reference does not provide enough information for anyone to locate the document. I think a reference

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

it didn't work out. :-) > > On Thu, Mar 28, 2024 at 5:08 PM Russ Housley <mailto:hous...@vigilsec.com>> wrote: >> Sean: >> >> I observe that ML-KEM is not a Elliptic curve group or a Finite Field >> Diffie-Hellman group. I really think we want to inclu

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

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

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

Bas: Thanks. I've adjusted the proposed text to address your comments: Implementations must use a ciphersuite that includes a symmetric encryption algorithm with sufficiently large keys. For protection against the future invention of a CRQC, the symmetric key needs to be at least 12

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

Stephen: > >> I've been thinking about your point. Some people want to use RFC >> 8773 to protect data that is transmitted today and recorded from the >> future invention of a quantum computer. To do this, the handshake >> includes the identifier for the external PSK, and an observer can get >>

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

Christian: >>> >>> Thanks. I am not 100% sure that we actually have an attack against the >>> [EC]DH+PSK combination, but I am confident than if the PSK secret is weak, >>> the attacker can get to the early data. If only for that, it is prudent to >>> use long enough PSK. >> As stated in draft

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

f the Encrypted Client Hello extension. I think you are correct, the "with algorithms that a secure against a CRQC" should be dropped. Russ > On Dec 6, 2023, at 4:21 PM, Stephen Farrell wrote: > > > Hiya, > > On 06/12/2023 21:06, Russ Housley wrote: >> S

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

John: > > 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. Thanks for getting back to me on this. Russ___ TLS mailing list TL

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 relev

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

Stephen: Maybe. ECH would need to be updated to use PQC algorithms to get that protection. Ill add that point: 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

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

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

Christian: > > Thanks. I am not 100% sure that we actually have an attack against the > [EC]DH+PSK combination, but I am confident than if the PSK secret is weak, > the attacker can get to the early data. If only for that, it is prudent to > use long enough PSK. As stated in draft-ietf-tls-877

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

> On Dec 5, 2023, at 12:01 PM, Christian Huitema wrote: > > On 12/5/2023 8:13 AM, Russ Housley wrote: >> At IETF 104, I presented a slide with informal reasoning about TLS 1.3 >> Security. >> Authentication: >> The certificate processing is exactly the same.

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

9360 >>> >>> On Sun, Dec 3, 2023, 3:23 PM Eric Rescorla >> <mailto:e...@rtfm.com>> wrote: >>>> What do we have in terms of formal analysis for this extension? >>>> >>>> -Ekr >>>> >>>> >>>

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

I think this should move forward. I am encouraged that at least two people have spoken to me about their implementations. Russ > On Nov 29, 2023, at 10:51 AM, Joseph Salowey wrote: > > RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with an > External Pre-Shared Key) was ori

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

khovni wrote: > > On Wed, Nov 29, 2023 at 10:49:42AM -0500, Russ Housley wrote: > >> People are implementing RFC 8773, so I would like to advance this to >> the standards track. In addition, this fixes the only errata that was >> posted against RFC 8773. >> >

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

xt is now available. It is a work > item of the Transport Layer Security (TLS) WG of the IETF. > > Title: TLS 1.3 Extension for Certificate-based Authentication with an > External Pre-Shared Key > Author: Russ Housley > Name:draft-ietf-tls-8773bis-00.txt > Pages

Re: [TLS] [EXTERNAL] New Version Notification for draft-ounsworth-lamps-pq-external-pubkeys-00.txt

Dennis: >> If we are going to allow a certificate to include pointers to externally >> stored public keys, I think a solution that works for the Web PKI and other >> PKI environment as well. > > I'm trying to understand the use case of certificates with pointers to > externally stored public k

Re: [TLS] [EXTERNAL] New Version Notification for draft-ounsworth-lamps-pq-external-pubkeys-00.txt

Dennis: If we are going to allow a certificate to include pointers to externally stored public keys, I think a solution that works for the Web PKI and other PKI environment as well. I would not object to the use of abridged certs as an option, but I would object if it is the only option. Russ

Re: [TLS] [Editorial Errata Reported] RFC8773 (7598)

al > Pre-Shared Key". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7598 > > ------ > Type: Editorial > Reported by: Russ Housley > > Section: 5.1 > > Original Text

Re: [TLS] Adoption call for draft-jackson-tls-cert-abridge

I support adoption and am willing to review. -Original Message- From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of Christopher Wood Sent: Tuesday, August 1, 2023 12:36 PM To: TLS@ietf.org Subject: [EXTERNAL] [TLS] Adoption call for draft-jackson-tls-cert-abridge

Re: [TLS] Minor RFC8446bis change

The proposed addition looks like excellent advice. Russ > On Jul 13, 2023, at 11:36 AM, Christopher Wood wrote: > > This final PR introduces some normative language, so we wanted to flag it on > the list before merging: > > https://github.com/tlswg/tls13-spec/pull/1325 > > If there are no

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

There have been attempts in the past to signal this to product planners: SHOULD+This term means the same as SHOULD. However, it is likely that an algorithm marked as SHOULD+ will be promoted at some future time to be a MUST. SHOULD-This term means the sa

Re: [TLS] E164 in X509

One could use a certificate that has a subjectAltName with a tel: URI or a DNS name ending with .e164.arpa. Russ > On Oct 12, 2022, at 5:35 PM, Eric Rescorla wrote: > > Yes, but (D)TLS is agnostic to credential format. > > Would the certificate format in https://www.rfc-editor.org/rfc/rfc8226

Re: [TLS] [lamps] Q: Creating CSR for encryption-only cert?

e could define an extension that > produced an empty signature, so that it could be used for any algorithm > without these complications... > > On Wed, Oct 5, 2022, at 03:05, Russ Housley wrote: >> Uri: >> >> You cannot do it with PKCS#10. That is why CRMF (RFC 421

Re: [TLS] [lamps] Q: Creating CSR for encryption-only cert?

Uri: You cannot do it with PKCS#10. That is why CRMF (RFC 4211) was created. RFC 2875 and RFC 6955 talk about the proof-of-possession (PoP) of 2875 Diffie-Hellman keys. A similar PoP specification will be needed for Kyber, and some folks agreed to write the -00 version before IETF 115 (nudge

Re: [TLS] Extensibility in SCVP draft

I was thinking the same thing during the presentation. An extension for SCVP seems fine to me. Then in the future, if another validation comes along some day, a new extension can be assigned for that protocol. Russ > On Jul 25, 2022, at 4:13 PM, Martin Thomson wrote: > > Take this: > > str

Re: [TLS] I-D Action: draft-ietf-tls-subcerts-13.txt

All of the changes are simple and straight forward. I did spot one typo: Section 4.2: s/This documnt defines/This document defines/ Russ > On May 9, 2022, at 8:37 PM, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > Th

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

> On Apr 29, 2022, at 8:24 PM, Stephen Farrell > wrote: > > On 27/04/2022 16:27, Christopher Wood wrote: >> This email commences a two week WGLC for draft-ietf-tls-hybrid-design, >> located here: >>https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ > > As I guess I've said b

Re: [TLS] Revised hybrid key exchange draft

I think that Martin is asking what properties this provides that justify the additional complexity. I'm sure that a few test vectors are sufficient to get interoperability, but what properties of the construction justify the effort to do something different? Russ > On Jan 22, 2022, at 6:35 A

Re: [TLS] Murray Kucherawy's No Objection on draft-ietf-tls-external-psk-guidance-04: (with COMMENT)

> -- > COMMENT: > -- > > Thanks to Martin Thomson for his ARTART review. > > A stylistic point: The Abstract is made up of five sentences all of which > start >

Re: [TLS] Erik Kline's No Objection on draft-ietf-tls-external-psk-guidance-04: (with COMMENT)

> -- > COMMENT: > -- > > > [S4; nit] > > * s/quantum computes/quantum computers/? > > [S4.2; nit] > > * "including, for example, including ..." -> "includin

Re: [TLS] Éric Vyncke's No Objection on draft-ietf-tls-external-psk-guidance-04: (with COMMENT)

> == COMMENTS == > > -- Section 4.1 -- > A wild guess (as I do not know the details of TLS 1.3), but if a group member > is compromised and no ephemeral keys were used, then isn't the attacker able > to > read even the past/recorded traffic ? The document saysL 3. If PSK is not combined wit

Re: [TLS] WGLC for delegated credentials

I have reviewed the diff, and I think this document is ready. Russ > On Sep 23, 2021, at 5:51 PM, Joseph Salowey wrote: > > This is a one week working group last call for draft-ietf-tls-subcerts-11. > Please focus on newer text for your review. Although it has been a while > since the last

[TLS] draft-ietf-tls-subcerts

What is going on with draft-ietf-tls-subcerts? A WG Last Call was held, and an issue was raised, but the document has not been updated since the WL Last Call closed about a year ago? Russ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/

Re: [TLS] [Editorial Errata Reported] RFC2246 (6680)

This is noise. Please delete it. Russ > On Sep 8, 2021, at 8:02 AM, RFC Errata System > wrote: > > The following errata report has been submitted for RFC2246, > "The TLS Protocol Version 1.0". > > -- > You may review the report below and at: > https://www.

Re: [TLS] [Last-Call] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

> In Section 7.1.4.1: the following text is removed: If the client supports only the default hash and signature algorithms (listed in this section), it MAY omit the signature_algorithms extension. > Since it’s a MAY, I am a-okay with deleting. Anybody else see harm? I don't se

Re: [TLS] WG adoption call for draft-tschofenig-tls-dtls-rrc: redux

This document seems fine to me, but the first paragraph of Section 3 needs some work. This can be sorted out after adoption. Section 3 begins with: When a record with CID is received that has the source address of the enclosing UDP datagram different from the one previously associated

Re: [TLS] [Editorial Errata Reported] RFC2818 (6503)

This one should just be deleted. > On Mar 29, 2021, at 12:33 PM, RFC Errata System > wrote: > > The following errata report has been submitted for RFC2818, > "HTTP Over TLS". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errat

[TLS] Genart last call review of draft-ietf-tls-dtls-connection-id-10

Reviewer: Russ Housley Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more

[TLS] RFC 8998

This RFC includes: 3.3.3. Certificate When a server sends the Certificate message containing the server certificate to the client side, several new rules are added that will affect the certificate selection: * The public key in the certificate MUST be a valid SM2 public key. *

Re: [TLS] WGLC for "Guidance for External PSK Usage in TLS"

Sean and Joe: The revision to address Ben' comments has now been posted. I believe that all WGLC comments have been addressed. I think this document is ready to go to the IESG. Russ > On Jan 22, 2021, at 3:27 PM, Russ Housley wrote: > > Ben: > > Thanks for you

Re: [TLS] I-D Action: draft-ietf-tls-subcerts-10.txt

Works for me. > On Jan 31, 2021, at 11:58 PM, Sean Turner wrote: > > Do you think this would be clearer: > > The maximum validity period is set to 7 days unless > an application profile standard specifies a shorter > period. > > spt > >> On Jan 25,

Re: [TLS] I-D Action: draft-ietf-tls-subcerts-10.txt

I have reviewed the recent update, and I notice one inconsistency. Section 2 says: In the absence of an application profile standard specifying otherwise, the maximum validity period is set to 7 days. Section 4.1.3 says: 1. Validate that DelegatedCredential.cred.valid_time is no more

Re: [TLS] WGLC for "Guidance for External PSK Usage in TLS"

Ben: Thanks for you review and comments. > We've only had one review in response to the last call so far, I'd like to > see a few more reviews of this document before moving it forward. Are there > any volunteers who can commit to a review in the near future? > > I've reviewed and have only

Re: [TLS] WGLC for "Guidance for External PSK Usage in TLS"

I made a PR with these changes. Russ > On Dec 21, 2020, at 9:30 AM, Jonathan Hammell wrote: > > Hi Russ, > > On Fri, Dec 18, 2020 at 1:55 PM Russ Housley wrote: >>> 1. Section 4 covers a lot of ground and is difficult to follow. I >>> suggest it be split

Re: [TLS] WGLC for "Guidance for External PSK Usage in TLS"

Jonathan: Thanks for the review. > Here are my comments on the draft. > > 1. Section 4 covers a lot of ground and is difficult to follow. I > suggest it be split into subsections (e.g. "4.1 PSKs Shared with > Multiple Group Members" and "4.2 Weak Entropy PSKs") and move the > attack description

Re: [TLS] Static DH timing attack

Peter: > Achim Kraus writes: > >> Does using x25519 for ECDHE is significant less secure than using it with >> e.g. secp384r1? > > The NIST curves AFAIK are never used that way, it's only done with 25519 > (there was something about it in an OpenPGP draft, but I think GPG went > straight to 255

Re: [TLS] comments on draft-subcerts

Yes, my first comment was addressed. Russ > On Aug 20, 2020, at 9:19 AM, Salz, Rich wrote: > > I've attempted to address the comments here: > https://github.com/tlswg/tls-subcerts/pull/80 >

Re: [TLS] comments on draft-subcerts

, which format do you think would be most useful for the extension? I'm > having a hard time finding another extension to model this after. > > On Fri, Aug 14, 2020 at 10:00 AM Russ Housley <mailto:hous...@vigilsec.com>> wrote: > I have two comments: > > 1) The OID assi

Re: [TLS] comments on draft-subcerts

I have two comments: 1) The OID assignment for the ASN.1 module was assigned already by IANA. Please fill it in. 2) I think it would be very helpful to have an example of the extension in an Appendix. There was discussion on the list about it, and an error was found in the proposed example,

Re: [TLS] comments on draft-subcerts

Watson: This does not look right to me. The extensions in the certificate are: extensions=Extensions: Extension: extnID=2.5.29.15 critical=True extnValue=0x03020780 Extension: extnID=2.5.29.37 critical=False extnValue=0x300a06082b06010505070301 Extension: e

Re: [TLS] comments on draft-subcerts

Rich: > Sec 4.2 doesn’t seem to agree with the complete ASN1 in Appendix A. The > latter has DelegatedCredentialExtn which is mentioned in prose and a TBD in > 4.2 Perhaps a comment or some other words to tie them together? Or does > that issue just go away when IANA does the registration?

Re: [TLS] 2nd WGLC for Delegated Credentials for TLS

This update resolves the comments that I posted on the previous version. Thanks. Russ From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of Joseph Salowey Sent: Monday, June 29, 2020 5:59 PM To: mailto:tls@ietf.org>> mailto:tls@ietf.org>> Subject: [TLS] 2nd WGLC for Delegated Credentials for

Re: [TLS] [Editorial Errata Reported] RFC8446 (6204)

> On Jun 4, 2020, at 12:37 PM, Eric Rescorla wrote: > > > > On Thu, Jun 4, 2020 at 9:24 AM Russ Housley <mailto:hous...@vigilsec.com>> wrote: > Eric: > >>> On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson >> <mailto:m...@lowentropy.net>> w

Re: [TLS] [Editorial Errata Reported] RFC8446 (6204)

Eric: >> On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson > > wrote: >> I think that this is a useful erratum and it should be approved/HFDU. The >> extension to which this text alludes is RFC 8773, not post_handshake_auth. >> >> Yes, although 8773 actually is not super

Re: [TLS] [Editorial Errata Reported] RFC8446 (6204)

Martin: > I think that this is a useful erratum and it should be approved/HFDU. The > extension to which this text alludes is RFC 8773, not post_handshake_auth. > > There is one other piece to this that is very confusing, and less clear. > > "Servers which are authenticating with a PSK MUST NO

  1   2   3   >