Re: [TLS] SCHC for DTLS

ing in on doing it. > > On 5/30/22 05:33, Hannes Tschofenig wrote: > > Bob, is this about compressing the DTLS record layer or the DTLS handshake > protocol? > > For the former, I wonder how much is there actually to compress (when > using DTLS 1.3)? > > > >

Re: [TLS] SCHC for DTLS

length. That may be easier. -Ekr > Anyway, this is good info. > > On 5/30/22 12:12, Eric Rescorla wrote: > > We spent a fair bit of time working to shrink the DTLS 1.3 record layer, > so I'm not sure how much room there is for optimization. > See: > https://www.rf

Re: [TLS] Why TLSA RR and not CERT RR?

Well, this really isn't a question for the TLS WG as DANE is external to TLS. With that said, ISTM that the primary purpose of DANE is to indicate which certificates are acceptable rather than to convey them, as TLS already knows how to convey them. -Ekr On Sun, Jun 26, 2022 at 5:05 AM Robert M

Re: [TLS] Why TLSA RR and not CERT RR?

skowitz wrote: > > Kind of thought so. > > So where do I ask where CERT records are being used? > > thanks > > On 6/26/22 09:22, Eric Rescorla wrote: > > Well, this really isn't a question for the TLS WG as DANE is external to > TLS. > > With that said, IST

Re: [TLS] Servers respond with BadRecordMac after ClientFinished, sent when PSK+EarlyData

On Mon, Aug 8, 2022 at 11:52 PM Ilari Liusvaara wrote: > On Mon, Aug 08, 2022 at 08:15:41PM +0200, Kristijan Sedlak wrote: > > Hello everyone. > > > > I decided to get involved here since I hit a dead end when resolving > > an Alert(20) error that I get from almost all servers when using PSK > >

Re: [TLS] Getting started, clock not set yet

On Mon, Aug 8, 2022 at 10:04 PM Peter Gutmann wrote: > Hal Murray writes: > > >Many security schemes get tangled up with time. TLS has time limits on > >certificates. That presents a chicken-egg problem for NTP when getting > >started. > > > >I'm looking for ideas, data, references, whatever?

Re: [TLS] Getting started, clock not set yet

On Tue, Aug 9, 2022 at 3:33 PM Rob Sayre wrote: > On Tue, Aug 9, 2022 at 3:15 PM Eric Rescorla wrote: > >> >> >> On Mon, Aug 8, 2022 at 10:04 PM Peter Gutmann >> wrote: >> >>> Hal Murray writes: >>> >>> >Many security schemes g

Re: [TLS] Getting started, clock not set yet

On Tue, Aug 9, 2022 at 3:47 PM Rob Sayre wrote: > On Tue, Aug 9, 2022 at 3:40 PM Eric Rescorla wrote: > >> >> P.S. I don't think that this tone "...but go on" is particularly helpful >> in this discussion. >> > > Well, it's easy. You said

Re: [TLS] Getting started, clock not set yet

n Tue, Aug 9, 2022 at 4:08 PM Benjamin Kaduk wrote: > On Tue, Aug 09, 2022 at 03:59:01PM -0700, Eric Rescorla wrote: > > > > Be that as it may, the browsers generally require conformance to the BRs > > (see, for > > instance > > > https://urldefense.com/v3/_

Re: [TLS] ECH not protect SNI

On Wed, Aug 24, 2022 at 12:06 AM 涛叔 wrote: > Hi, Christian, > > On Aug 24, 2022, at 14:23, Christian Huitema wrote: > > Yes, the server might tell its clients to use a fake external SNI, and > that might fool some of the current censorship services. But that will only > work until the next updat

Re: [TLS] ECH not protect SNI

On Wed, Aug 24, 2022 at 1:34 AM 涛叔 wrote: > > > On Aug 24, 2022, at 16:11, Eric Rescorla wrote: > > As a practical matter, most sites need to be deployed on cloud services > like AWS, Cloudflare, etc., so if this is true, > then ECH just isn't going to work at all.

Re: [TLS] ECH not protect SNI

On Wed, Aug 24, 2022 at 5:00 AM 涛叔 wrote: > > On Aug 24, 2022, at 18:12, Stephen Farrell > wrote: > > > I think Chris' answer wrt encrypting ALPNs etc is correct, > the ECH mechanism does still provide a (perhaps minor) > benefit in such cases, and as Ekr says, a client could send > a bogus SNI

Re: [TLS] ECH not protect SNI

clear to me that this is better. In the multi-domain case it seems like it makes it easier to determine whether ECH is in use, and in the single-domain case, you can just block on the random domain, as above. -Ekr > > On Aug 24, 2022, at 20:50, Eric Rescorla wrote: > > >

Re: [TLS] ECH not protect SNI

On Wed, Aug 24, 2022 at 7:48 AM 涛叔 wrote: > Hi, Eric, > > Thank your for reviewing. > > On Aug 24, 2022, at 22:25, Eric Rescorla wrote: > > Are these keys and names shared between the domains in the anonymity set? > > > This keys are only used for ECHConfig corre

Re: [TLS] ECH not protect SNI

On Wed, Aug 24, 2022 at 8:36 AM 涛叔 wrote: > Hi, Eric, > > Thanks for offering the detailed design considerations. > > On Aug 24, 2022, at 23:08, Eric Rescorla wrote: > > I'd like to take a step back here. > > There are two design considerations here: > &g

Re: [TLS] Securely disabling ECH

Are you referring to this text in 6.1.6 or something else? "If none of the values provided in "retry_configs" contains a supported version, or an earlier TLS version was negotiated, the client can regard ECH as securely disabled by the server, and it SHOULD retry the handshake with a new transport

Re: [TLS] OCSP and browsers

The TL;DR is that in the future we expect OCSP to be a lot less relevant. I checked with our team, and the general story is that currently if there is a valid OCSP stapled response we use it but otherwise do OCSP In the future when we have CRLite enabled and it applies to the certificate, then we

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

I wonder if MT is thinking forward to something like KEMTLS which used a KEM to prove possession to the peer? In any case, I think it would be good design criterion for TLS that it offer the same level of security -- including against identity misbinding attacks -- even if the CA does not verify P

Re: [TLS] Securely disabling ECH

If you are able to install a new trust anchor, then you should be able to use the enterprise configuration mechanisms in browsers to disable ECH. -Ekr On Fri, Oct 7, 2022 at 8:40 PM Safe Browsing wrote: > Hi Rich, > > When I say “authoritative”, I mean it in the true TLS sense, in the way > th

Re: [TLS] E164 in X509

Yes, but (D)TLS is agnostic to credential format. Would the certificate format in https://www.rfc-editor.org/rfc/rfc8226.html serve your needs? -Ekr On Wed, Oct 12, 2022 at 2:11 PM Soni L. wrote: > Hello, > > Is there a possibility to support E164 in X509, for DTLS over SMS? > > Thanks. > > __

[TLS] Published RFC 8446bis -05

Hi Folks, I have just published draft-ietf-tls-rfc8446bis-05, with the following changes: * Update the extension table (Issue 1241) * Clarify user_canceled (Issue 1208) * Clarify 0-RTT cache side channels (Issue 1225) * Require that message reinjection be done with the current hash. Potentially

Re: [TLS] Published RFC 8446bis -05

opening a new socket would suffice? > I don't see that this would help. 1. It would not be clear to the client what it had to do to provide an acceptable CH. 2. Without some sort of HRR-like coupling, it would allow downgrade attacks. -Ekr > thanks, > Rob > > On Mon, Oct 24,

Re: [TLS] Question regarding RFC 8446

Hi David, This question seems a bit out of scope for TLS, which is kind of indifferent to the transport interaction. Perhaps it might make sense to be in UTA, though unfortunately, RFC 7525-bis is in the editor queue now... -Ekr On Mon, Nov 7, 2022 at 1:37 AM David Barr wrote: > How can I ma

Re: [TLS] [Technical Errata Reported] RFC8446 (7250)

I don't believe this is correct. On Mon, Nov 14, 2022 at 8:50 AM RFC Errata System wrote: > The following errata report has been submitted for RFC8446, > "The Transport Layer Security (TLS) Protocol Version 1.3". > > -- > You may review the report below and

Re: [TLS] [Technical Errata Reported] RFC8446 (7250)

On Mon, Nov 14, 2022 at 9:55 AM Alan DeKok wrote: > On Nov 14, 2022, at 12:43 PM, Eric Rescorla wrote: > > I don't believe this is correct. > > I'd like to have a way to say "if you don't support session tickets, > just ignore them". > Ag

Re: [TLS] [Technical Errata Reported] RFC8446 (7250)

On Mon, Nov 14, 2022 at 11:28 AM Alan DeKok wrote: > On Nov 14, 2022, at 1:09 PM, Eric Rescorla wrote: > > I'd like to have a way to say "if you don't support session tickets, > just ignore them". > > > > Again this text is not quite right b

Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

How much of the TLS part of this objective is achieved by RFC 9102? -Ekr On Mon, Nov 28, 2022 at 11:21 AM Ollie wrote: > Hi folks, > > I'm new to the I-D/RFC process so apologies for any naivety! > > Firstly, I've done a quick search for any commentary around this but > haven't found anything

Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

Thanks for the elaboration, Viktor. I think the TL;DR here is that this isn't TLS-relevant work at present. Either you get the certs directly or you get them via RFC 9102 but in either case, TLS has the appropriate support. If you don't need CT--I'm not entirely persuaded by Viktor's argument but

Re: [TLS] [arch-d] Question regarding Connection ID (CID) in DTLS /QUIC.

This question should go to the TLS mailing list, not to architecture-discuss. I have CCed that list. On Fri, Dec 9, 2022 at 3:02 AM Kristijan Sedlak wrote: > Hello, everyone. > > I'm scratching my head on RFC 9146 and wonder about the correct > implementation strategy. Connection IDs in DTLS 1.3

Re: [TLS] Profile ID in CTLSServerPlaintext

On Wed, Jan 4, 2023 at 6:30 AM Ben Schwartz wrote: > On Wed, Jan 4, 2023 at 7:50 AM Kristijan Sedlak > wrote: > >> Hey, >> >> The record layer of the cTLS skips the "profile_id" in the >> CTLSServerPlaintext. I wonder how will an endpoint correctly distinguish >> between multiple, CID-ext-based

Re: [TLS] Profile ID in CTLSServerPlaintext

ion establishment. > > I hope the above makes sense. > > K > > On 4 Jan 2023, at 17:10, Eric Rescorla wrote: > > > > On Wed, Jan 4, 2023 at 6:30 AM Ben Schwartz 40google@dmarc.ietf.org> wrote: > >> On Wed, Jan 4, 2023 at 7:50 AM Kristijan Sedlak

Re: [TLS] Profile ID in CTLSServerPlaintext

lity and in that environment it seems to me that the roles are deterministic. If you can point me to a real world environment where this kind of tie breaker is needed, I might feel differently. -Ekr > K > > On 4 Jan 2023, at 19:06, Eric Rescorla wrote: > > > > On Wed, Jan 4,

Re: [TLS] Profile ID in CTLSServerPlaintext

ed > configuration for DTLS (with Connection IDs)? > > On Wed, 4 Jan 2023 at 17:10, Eric Rescorla wrote: > > When would this actually happen? > > Assuming this could happen, then the RFC should surely mention the > possibility, and perhaps be reworked to avoid raising an error.

Re: [TLS] Profile ID in CTLSServerPlaintext

On Fri, Jan 6, 2023 at 9:28 AM Kristijan Sedlak wrote: > > If I understand correctly, the issue here is a difference between DTLS > and > > "Datagram cTLS". In DTLS, the syntax allows a client to parse handshake > > messages from the server and discover that the message is actually a > > ClientH

Re: [TLS] Profile ID in CTLSServerPlaintext

On Fri, Jan 6, 2023 at 9:59 AM Kristijan Sedlak wrote: > > On 6 Jan 2023, at 18:39, Eric Rescorla wrote: > > > > On Fri, Jan 6, 2023 at 9:28 AM Kristijan Sedlak > wrote: > >> > If I understand correctly, the issue here is a difference between DTLS >>

Re: [TLS] Profile ID in CTLSServerPlaintext

-5 If you're aware of cases where this design does not correctly handle the situation, please surface them... -Ekr > Am 06.01.23 um 23:17 schrieb Eric Rescorla: > > > > > > On Fri, Jan 6, 2023 at 9:59 AM Kristijan Sedlak > <mailto:xpeperm...@gmai

[TLS] Question on draft-ietf-tls-deprecate-obsolete-kex-01.txt

Hi folks, I was just reading draft-ietf-tls-deprecate-obsolete-kex-01.txt and the combination of Section 3 and Appendix C is confusing to me. Specifically, the text says: Clients and servers MAY offer fully ephemeral FFDHE cipher suites in TLS 1.2 connections under the following conditions

Re: [TLS] Question on draft-ietf-tls-deprecate-obsolete-kex-01.txt

here before the meeting. > OK, so we don't need to spend too much time on this, but I'd still like to understand the intent :) -Ekr > > best, > Nimrod > > > > > On Thu, 2 Mar 2023 at 23:19, Eric Rescorla wrote: > >> Hi folks, >> >>

Re: [TLS] How are we planning to deprecate TLS 1.2?

Nimrod, Thanks for bringing this up. I don't think we really have had much of a discussion. I *do* think we should be thinking about deprecating TLS 1.2 at some point, not so much because it is bad (though of course we believe TLS 1.3 is better) but because it's better to just have one thing tha

[TLS] draft-ietf-tls-rfc8446bis-06 posted

Hi, I just submitted draft-ietf-tls-rfc8446bis-06. Here is a summary of the Changes since -05. I believe the following changes are largely uncontroversial and were widely reviewed. * Advice on key deletion (PR 1282) * Clarify what unsolicited extensions means (PR 1275) * close_noti

Re: [TLS] [TLS-NO-AUTH] Proposal to skip TLS authentication for entertainment purposes

Hans Petter, Before I address your technical points, I would observe that your tone here isn't ideal for getting people excited about your ideas. If you think there's something that people don't understand, then by all means explain it, but telling people that they have a "total lack of kernel-sid

Re: [TLS] Proposal to Enhance TLS Mutual Authentication Security

AS Viktor noted in a separate e-mail TLS 1.3 already encrypts the client certificate. -Ekr On Sun, Mar 26, 2023 at 4:00 PM Yannick LaRue wrote: > Dear TLS Working Group, > > > > I am writing to propose a new method for enhancing the security of mutual > authentication in TLS. The current TLS p

[TLS] draft-ietf-tls-rfc8446bis-07

I have just posted draft-ietf-tls-rfc8446bis-07 This incorporates the following changes: - Updated text about differences from RFC 8446. - Clarify which parts of IANA considerations are new to this document. - Upgrade the requirement to initiate key update before exceeding key usage limits to M

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

I would prefer to have any substantive changes in 8446-bis and the policy changes in 8447-bis -Ekr On Mon, Mar 27, 2023 at 2:10 AM Salz, Rich wrote: > > > Title : IANA Registry Updates for TLS and DTLS > > Authors : Joe Salowey > > Sean Turner > > Filename : draft-ietf-tls-rfc8447bis-04.txt >

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

On Mon, Mar 27, 2023 at 2:28 AM Salz, Rich wrote: > > > I would prefer to have any substantive changes in 8446-bis and the policy > changes in 8447-bis > > > > Now I’m more confused, since I consider policy changes substantive > things. And I’m not sure what policy is. > Looking at 8446 and 844

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

I support this proposal. On Tue, Mar 28, 2023 at 6:49 PM Christopher Wood 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. > >

Re: [TLS] TLS 1.2 deprecation and RFC 7627

On Sat, Apr 1, 2023 at 12:15 PM Dmitry Belyavsky wrote: > Dear Martin, > > On Sat, 1 Apr 2023, 19:36 Martin Thomson, wrote: > >> On Sat, Apr 1, 2023, at 20:28, Dmitry Belyavsky wrote: >> > Are the things like national-wide standards considered as new features >> > (until they don't pretend to be

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

Thanks for your feedback. Most of these are editorial comments and so I think they're my decision as editor about which ones to take absent some instruction from the chairs. On Tue, Apr 4, 2023 at 10:43 PM Rob Sayre wrote: > Hi, > > I'm still not sure about the list/vector rename. Aside from tha

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

This was discussed extensively when 8446 was published and there wasn't consensus to make such a change. If the chairs want to re-open this issue, please weigh in. -Ekr On Tue, Apr 4, 2023 at 7:32 PM Stephen Farrell wrote: > > Hiya, > > On 05/04/2023 02:47, Sean Turner wrote: > > A post IETF 1

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

On Wed, Apr 5, 2023 at 12:50 PM Rob Sayre wrote: > On Wed, Apr 5, 2023 at 12:26 PM Eric Rescorla wrote: > >> Thanks for your feedback. Most of these are editorial comments and >> so I think they're my decision as editor about which ones to take >> absent som

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

On Wed, Apr 12, 2023 at 12:15 AM Ilari Liusvaara wrote: > On Wed, Apr 12, 2023 at 01:18:17AM +, Peter Gutmann wrote: > > On the subject of clarification, the update also needs to explain why > PSK is > > split across two separate extensions, psk_key_exchange_modes and > > pre_shared_key, with

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

I agree with Ilari about the size of the registry. OTOH, I think it would be good to avoid confusion by creating a large number of code points which we know will be abandoned soonish. -Ekr On Thu, May 11, 2023 at 11:19 PM Ilari Liusvaara wrote: > On Thu, May 11, 2023 at 02:44:18PM +, Kampa

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

On Mon, May 22, 2023 at 1:09 PM Rob Sayre wrote: > On Mon, May 22, 2023 at 12:59 PM Christopher Wood > wrote: > >> We trust the editors will faithfully enact all editorial changes they >> agree with as the document moves forward in the process. If there were >> non-editorial comments that we ove

Re: [TLS] Tricking TLS library into crypto primitives library

I'm not aware of any. Why would you want to do this? Most such libraries I am aware of expose low-level primitives or are built on libraries which do. -Ekr On Sun, Jun 25, 2023 at 6:28 AM Soni L. wrote: > Has anyone done any work towards tricking a TLS library into providing > cryptographic pr

Re: [TLS] Tricking TLS library into crypto primitives library

s. > > On 6/25/23 14:15, Eric Rescorla wrote: > > I'm not aware of any. Why would you want to do this? Most such libraries I > am aware of expose low-level primitives or are built on libraries which do. > > -Ekr > > > On Sun, Jun 25, 2023 at 6:28 AM Soni L. w

Re: [TLS] Abridged Certificate Compression

Document: draft-jackson-tls-cert-abridge-00.txt Hi Dennis, Thanks for sending this. This seems like great work and a big improvement. I have a number of comments below, mostly minor. S 1.1. The existing compression schemes used in [TLSCertCompress] have been shown to deliver a substantial

Re: [TLS] Abridged Certificate Compression

On Fri, Jul 7, 2023 at 1:21 PM Dennis Jackson wrote: > Thank you for the comments. I'll fix most of them - responses inline for > the rest: > > On 07/07/2023 17:38, Eric Rescorla wrote: > > S 3.1.2. > >7. Order the list by the date each certificate was i

Re: [TLS] Abridged Certificate Compression

On Mon, Jul 10, 2023 at 10:54 AM Dennis Jackson wrote: > > On 07/07/2023 21:28, Eric Rescorla wrote: > > S 3.2.1 >> How much value are you getting from the CT logs? It seems like >> additional complexity. I agree with your comment about having >> this submitted

Re: [TLS] Abridged Certificate Compression

On Tue, Jul 11, 2023 at 12:45 PM Dennis Jackson wrote: > On 11/07/2023 15:48, Thom Wiggers wrote: > > > I enjoyed reading this draft. I think it is well-written. Aside from > > some to-be-figured-out details that have already been pointed out, it > > seems very practical, which is rather nice. >

Re: [TLS] Abridged Certificate Compression

On Tue, Jul 11, 2023 at 2:09 PM Dennis Jackson wrote: > On 11/07/2023 21:17, Eric Rescorla wrote: > > I wouldn't want to 'permanently' encode the root programs, CT > trusted log lists or end entity compressed extensions for example. > > > Arguably it will be

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

I support adoption and am willing to review. On Tue, Aug 1, 2023 at 12:38 PM Andrei Popov wrote: > I support adoption. > > Cheers, > > Andrei Popov > > -Original Message- > From: TLS On Behalf Of Christopher Wood > Sent: Tuesday, August 1, 2023 12:36 PM > To: TLS@ietf.org > Subject: [EX

Re: [TLS] Question about DTLS for the "no new features" draft

On Sun, Aug 6, 2023 at 9:58 AM Rob Sayre wrote: > There's also the fact that the TLS 1.3 was published in August 2018, but > DTLS 1.3 wasn't published until April 2022. So, it is kind of reasonable to > allow some extra time here. > > The WG could say this document doesn't apply to DTLS. Another

Re: [TLS] Question about DTLS for the "no new features" draft

Sure. Though with that said, DTLS-SRTP should use the same code points for 1.2 and 1.3, so I don't actually know if this is an exception after all. -Ekr On Sun, Aug 6, 2023 at 1:59 PM Rob Sayre wrote: > On Sun, Aug 6, 2023 at 11:48 AM Eric Rescorla wrote: > >> >> >

Re: [TLS] Question about DTLS for the "no new features" draft

On Mon, Aug 7, 2023 at 2:50 PM Jonathan Lennox wrote: > > > On Aug 6, 2023, at 5:22 PM, Rob Sayre wrote: > > On Sun, Aug 6, 2023 at 2:14 PM Eric Rescorla wrote: > >> Sure. Though with that said, DTLS-SRTP should use the same code points >> for 1.2 and 1.3, so I

Re: [TLS] [Technical Errata Reported] RFC8446 (7620)

Hi Ben, Before addressing the text, let's make sure we are on the same page about the situation. As you probably know, there are quite a few situations in which endpoints close the connection before receiving a close_notify, for instance, when they receive an end of data message in the applicatio

Re: [TLS] [Technical Errata Reported] RFC8446 (7620)

runcation attack; it'd surely be > better to have a SHOULD or SHOULD NOT. > > On Mon, 28 Aug 2023, 14:43 Eric Rescorla, wrote: > >> Hi Ben, >> >> Before addressing the text, let's make sure we are on the same page about >> the situation. >> >

Re: [TLS] [Technical Errata Reported] RFC8446 (7620)

On Tue, Aug 29, 2023 at 1:56 AM Ben Smyth wrote: > On Mon, 28 Aug 2023, Eric Rescorla, wrote: > >> ...there are quite a few situations in which endpoints close the >>>> connection before receiving a close_notify, for instance, when they receive >>>> an en

Re: [TLS] [Technical Errata Reported] RFC8446 (7620)

ding. -Ekr On Wed, Aug 30, 2023 at 2:42 AM Ben Smyth wrote: > > > On Tue, 29 Aug 2023, 14:31 Eric Rescorla, wrote: > >> On Tue, Aug 29, 2023 at 1:56 AM Ben Smyth wrote: >> >>> On Mon, 28 Aug 2023, Eric Rescorla, wrote: >>> >>>> ..

Re: [TLS] [Technical Errata Reported] RFC8446 (7620)

On Sat, Sep 2, 2023 at 4:38 AM Ben Smyth wrote: > On Sat, 2 Sept 2023, 13:30 Ben Smyth, wrote: > >> RFC8446 leans towards half closure but doesn't mandate it. >> >> [For full closure,] it makes sense for A to just flush the outgoing data >>> >> >> Yes. >> >> [For half closure], we want A to cont

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

Hi David, Thanks for posting this and for the discussion on the list. Before commenting on this proposal, I'd like to make sure we're all on the same page about the situation. # Background 1. RFC 8446 states that both supported_groups and key_shares are in client's preference order but does

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

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 de

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

What do we have in terms of formal analysis for this extension? -Ekr On Fri, Dec 1, 2023 at 11:40 AM Russ Housley wrote: > 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, Jos

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

m.org/doi/abs/10.1145/3548606.3559360 >> >> On Sun, Dec 3, 2023, 3:23 PM Eric Rescorla wrote: >> >>> What do we have in terms of formal analysis for this extension? >>> >>> -Ekr >>> >>> >>> On Fri, Dec 1, 2023 at 11:40 AM Russ Housl

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

ake it worse. > > I will be glad to work with someone that already has things set up for TLS > 1.3 without this extension to do a more formal analysis. > > Russ > > > On Dec 3, 2023, at 5:00 PM, Eric Rescorla wrote: > > To respond directly to the call: I think we shou

Re: [TLS] Media types "application/tls" and "application/ssl", and URIs for schemes "tls" and "ssl"

Can you explain why a URI type needs to be defined? If one needs to be defined, then: - It should not have a generic name like "ssl" or "tls". That will confuse people and there's no sense in which you would use it to initiate a TLS connection. - You shouldn't define different URIs for SSL and TLS

Re: [TLS] Media types "application/tls" and "application/ssl", and URIs for schemes "tls" and "ssl"

On Sun, Dec 24, 2023 at 8:46 PM arkiver wrote: > Thank you for your replies Eric and Rich, and thank you for looking into > this with me! I will reply to you both in this message (divided in sections > due to length). > That actually isn't that helpful, because it means that I need to trim the m

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

On Mon, Jan 1, 2024 at 7:05 PM Rob Sayre wrote: > Martin, > > You haven’t formed a complete sentence here. That’s usually allowable, but > not in this instance. > > Uri said there might be “special cases”. Anyone can make TLS 1.2 PQ, it > just won’t be called TLS. > I'm not Martin, but I believe

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

On Tue, Jan 2, 2024 at 6:20 AM Salz, Rich wrote: > I'm not Martin, but I believe that his point is that both TLS ciphersuites > and TLS supported groups/EC curves permit registration outside of the IETF > process based on the existence of.a specification. As long as PQC can fit > into new ciphers

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

On Tue, Jan 2, 2024 at 5:02 PM Rob Sayre wrote: > It might be better to describe TLS 1.2 as "overtaken by events". If you > want to use CSS Grid or Swift UI (name any newish thing), you'll find > yourself with a stack that supports TLS 1.3, so there's no need to bother > with TLS 1.2 in those cas

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

On Tue, Jan 2, 2024 at 8:17 PM Benjamin Kaduk wrote: > On Tue, Jan 02, 2024 at 07:17:44PM -0800, Eric Rescorla wrote: > >On Tue, Jan 2, 2024 at 5:02 PM Rob Sayre <[1]say...@gmail.com> wrote: > > > > It might be better to describe TLS 1.2 as "overtaken by

Re: [TLS] Media types "application/tls" and "application/ssl", and URIs for schemes "tls" and "ssl"

This is outside the scope of TLSWG, but there's not really a clean mapping from client->server and server->client packets to requests and responses, so I would suggest you introduce types that are clearer.. -Ekr On Mon, Jan 8, 2024 at 9:50 AM JustAnotherArchivist < justanotherarchiv...@riseup.ne

Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

On Tue, Jan 16, 2024 at 8:24 AM D. J. Bernstein wrote: > Bas Westerbaan writes: > > X-Wing is a KEM - not a combiner. > > Sure, but there's a combiner present inside it---and even advertised: > see "X-Wing uses the combiner" etc. at the beginning of this thread. > > If people are motivated by thi

Re: [TLS] [Errata Held for Document Update] RFC8446 (6205)

I believe that the current 8446-bis text addresses this. Martin? On Tue, Jan 16, 2024 at 4:59 PM RFC Errata System wrote: > The following errata report has been held for document update > for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". > >

Re: [TLS] Completion of Update Call for RFC 8773bis

Joe, Does this mean that this draft will be held pending resolution on that proposal? -Ekr On Tue, Jan 23, 2024 at 7:51 AM Joseph Salowey wrote: > The working group last call for RFC8773bis has completed > (draft-ietf-tls-8773bis). There was general support for moving the document > forward

Re: [TLS] [CFRG] Chempat-X: hybrid of X25519 and sntrup761

Hi folks, Replying to DJB's email but not really in direct response to him. I'm not a cryptographer and don't have a strong opinion on the technical merits of X-wing in particular, but I've been following this thread (lots of messages) and was hoping to try to summarize what I think is common gro

[TLS] Status of draft-ietf-tls-rfc8446bis

Hi folks, I went through the open issues on draft-ietf-tls-rfc8446bis this morning and addressed a few. There are two remaining open issues [0] #1338 client_early_traffic_secret and alert #1339 illegal_parameter vs protocol_version propose-close I intend to close both of these unchanged on 2/29

Re: [TLS] Status of draft-ietf-tls-rfc8446bis

r else do you want me to create an issue for this? > > Thanks, > > Usama > > [1] https://mailarchive.ietf.org/arch/msg/tls/ZGmyHwTYh2iPwPrirj_rkSTYhDo/ > > On 17.02.24 16:40, Eric Rescorla wrote: > > Hi folks, > > > > I went through the open issues on draf

Re: [TLS] Input on ECH specification

On Wed, Feb 7, 2024 at 2:06 PM Elardus Erasmus wrote: > Hi, > > I figured it would be better to send an email, rather than proposing and > discussing this on a PR (proposed edits/diffs are at the bottom of this > email). > > We have two suggestions regarding the specification text ( > https://dat

[TLS] Status of draft-ietf-tls-esni

Hi folks, I wanted to provide an update on draft-ietf-tls-esni. I went through all existing PRs and issues as well as some of the recent list discussion. This message provides a summary of the status: PRs * 594: A first proposal to fix the no-sni section [Arnaud Taddei] I think this is fine and

Re: [TLS] Status of draft-ietf-tls-esni

On Sat, Feb 17, 2024 at 11:09 AM Stephen Farrell wrote: > > > On 17/02/2024 18:56, Eric Rescorla wrote: > > I should be able to spin a WGLC-ready version of ECH before the > > draft deadline. > > Good stuff, thanks. I'll plan to review the proposed > changes wi

Re: [TLS] Status of draft-ietf-tls-rfc8446bis

On Sat, Feb 17, 2024 at 11:16 PM Muhammad Usama Sardar < muhammad_usama.sar...@tu-dresden.de> wrote: > On 17.02.24 17:31, Eric Rescorla wrote: > > > As I understand it, you think that the changes we made in PR#185 may > > have been unnecessary > > and that it would

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 wrote: > I have uploaded a preliminary version of ML-KEM for TLS 1.3 >

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

hare, but there is no equivalent for just using a KEM on its own, and > computing its shared secret once and advertising it as both standalone and > in a hybrid share. So I think defining these standalone ML-KEM > `NamedGroup`s also 'draws the rest of the owl' implied by -hy

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

ng hybrids be the new standard seems to be a nice win for security >> and pretty much negligible costs in terms of performance, complexity and >> bandwidth (over single PQ schemes). >> >> On 07/03/2024 00:31, Watson Ladd wrote: >> > On Wed, Mar 6, 2024, 10:48 AM Rob Sayre

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

On Tue, Mar 12, 2024 at 2:40 PM Stephen Farrell wrote: > > Hiya, > > On 12/03/2024 14:57, Sean Turner wrote: > > This is the working group last call for the SSLKEYLOGFILE Format for > > TLS Internet-Draft [1]. Please indicate if you think the I-D is ready > > to progress to the IESG and send any

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

On Tue, Mar 12, 2024 at 3:45 PM Stephen Farrell wrote: > > > On 12/03/2024 22:06, Eric Rescorla wrote: > > I don't think we should make statements about regulatory requirements > > in this kind of specification. That's not our lane. > > I'd weakl

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

On Tue, Mar 12, 2024 at 4:04 PM Stephen Farrell wrote: > > I'll argue just a little more then shut up... > > On 12/03/2024 22:55, Martin Thomson wrote: > > > >> Sorry also for a late suggestion, but how'd we feel about adding > >> some text like this to 1.1? > >> > >> "An implementation, esp. a s

Re: [TLS] Working Group Last Call for ECH

On Wed, Mar 13, 2024 at 2:15 AM Raghu Saxena wrote: > On 3/13/24 14:51, Watson Ladd wrote: > > > I'm not sure what problem you want us to solve here. In the case of > > server offering a single domain, an attacker can determine that > > connections to that domain go to the server and cheaply bloc

Re: [TLS] Working Group Last Call for ECH

ber of such names. [0] -Ekr [0] The value must be non-registrable -- or at least controlled by the server -- otherwise an attacker might register it and obtain a valid certificate, thus initiating the 6.1.6 recovery mechanism. > On Wed, Mar 13, 2024 at 11:26 AM Eric Rescorla wrote: > >>

Re: [TLS] Working Group Last Call for ECH

gt; sending a TCP reset when that SNI matches a censored domain. > > I'm wondering, are we losing that ability from ESNI with this plain text > field? Maybe there can be an understanding in the RFC that the client may > omit, or falsify this plaintext field for a bit of extra

<    1   2   3   4   5   6   7   8   9   10   >