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

e value anyway. > > > > > I agree that it would be good to require replay protection at this > > time. Perhaps we should just publish a short RFC requiring it. > > > > Cheers, > > John > > > > *From: *John Mattsson > *Date: *Thursday, 28 December

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

I am against adoption. As Nick and Watson note, this is not just a profile of TLS 1.2 but is rather a set of negotiated with a new extension code point, i.e., it's effectively a new version of TLS with as yet only lightly analyzed security properties. We already have a new version of TLS which has

[TLS] Re: MLKEM or Khyber KX

On Sat, Nov 2, 2024 at 12:12 AM John Mattsson wrote: > Eric Rescorla wrote: > >Is reuse of ML-KEM keys worse in some way than the reuse of ECDHE keys? > > No reuse of ephemeral keys is always bad. > Right. Based on the discussion so far, I think it would be reasonable to have

[TLS] Re: MLKEM or Khyber KX

On Fri, Nov 1, 2024 at 11:30 AM John Mattsson wrote: > >and would warmly welcome it being a MUST in the IETF specification of > the ML-KEM TLS hybrids. > > > +1 > > Let’s try to make that happen > > https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem/pull/25 > Is reus

[TLS] Re: ML-DSA in TLS

rting PQ ahead of time >> because the client will have to make a cost/benefit decision in >> terms of breakage, and the more servers support PQ, the easier >> this decision is. >> >> >> >> >> >> >> >> >> >> >> >> &

[TLS] Re: ML-DSA in TLS

> > It's uncomfortable though if the first blessed SignatureScheme would be a > non-hybrid. (Also regulators don't make the distinction between > authentication and encryption, but at least most of them insist on hybrids > for both though.) > > So I agree it makes sense to

[TLS] Re: [Last-Call] Artart last call review of draft-ietf-tls-svcb-ech-06

I don't think a MUST would be totally inappropriate but it's possible to get into a state where you have a mismatch due to DNS latency or partial rollback, so this MUST will be violated in practice in some cases (though as you indicate, that's not good). ECH has a way to recover from these conditio

[TLS] Re: ML-DSA in TLS

I think an adoption call is a bit premature here. We've got some time, especially in the WebPKI setting. In particular, we should have a discussion of whether we want to standardize pure ML-DSA or hybrid ML-DSA/EC algorithms; I currently lean towards the latter, but I, at least, would like to hear

[TLS] Re: X25519MLKEM768 in draft-kwiatkowski-tls-ecdhe-mlkem-02

My $.02. * We should have a consistent ordering of [EC, PQ] in both the names and the key schedule. I.e., the code should be consistent with the naming and either the EC or the PQC ought to always come first. * I don't have a strong opinion about which should go first. * Can we please have a separ

[TLS] Re: X25519MLKEM768 in draft-kwiatkowski-tls-ecdhe-mlkem-02

Can we get a ruling on this from NIST? Quynh? -Ekr On Thu, Oct 17, 2024 at 2:32 AM Joseph Birr-Pixton wrote: > Please could we... not? > > It certainly is one interpretation of that section in SP800-56C. Another > is that TLS1.3 falls outside SP800-56C, because while HKDF kinda looks like > se

[TLS] Re: AD review of draft-ietf-tls-esni-22

On Tue, Oct 15, 2024 at 7:15 PM Paul Wouters wrote: > On Fri, 11 Oct 2024, Eric Rescorla wrote: > > > Thanks you for your review. I have created a PR that addresses a number > of these. > > > > https://github.com/tlswg/draft-ietf-tls-esni/pull/632 > > That look

[TLS] Re: AD review of draft-ietf-tls-esni-22

Paul Thanks you for your review. I have created a PR that addresses a number of these. https://github.com/tlswg/draft-ietf-tls-esni/pull/632 Detailed responses below: > Section 1 > > that allows clients to encrypt their ClientHello to such a deployment. > > What is "such a deployment"

[TLS] Re: [DNSOP] Re: Re: Re: Re: AD review draft-ietf-tls-svcb-ech

CB draft, other > than that I am concerned about the > illusion of ECH privacy being lost because of a "trusted by the network > via ADD" resolver being used. > > Paul > > On Mon, Oct 7, 2024 at 9:36 PM Eric Rescorla wrote: > >> Paul, >> >> I don

[TLS] Re: [EXTERNAL] Re: Consensus Call: early code point request for draft-ietf-tls-key-share-prediction

I'm OK with a code point assignment so that people can test this out. I don't think we're at the point where we know the draft won't change. -Ekr On Wed, Sep 25, 2024 at 2:36 PM Bas Westerbaan wrote: > If we want a new name, then I propose kex_hint — keyshare is a DH concept. > I'm happy with

[TLS] Re: [DNSOP] Re: Re: Re: Re: AD review draft-ietf-tls-svcb-ech

y when the client already is using a TRR. -Ekr [0] DNSSEC validation at the recursive might help, but that's not what we're talking about. On Mon, Oct 7, 2024 at 9:16 AM Paul Wouters wrote: > > On Mon, Oct 7, 2024 at 9:26 AM Eric Rescorla wrote: > >> >>

[TLS] Re: [DNSOP] Re: Re: Re: Re: AD review draft-ietf-tls-svcb-ech

On Mon, Oct 7, 2024 at 6:01 AM Paul Wouters wrote: > > On Sun, Oct 6, 2024 at 12:17 PM Eric Rescorla wrote: > >> This is explicitly prohibited rfc9460 as it would provide linkability. >>>> See rfc9460 section 12: "Clients MUST ensure that their DNS cache is

[TLS] Re: [DNSOP] Re: Re: Re: Re: AD review draft-ietf-tls-svcb-ech

On Sun, Oct 6, 2024 at 9:09 AM Paul Wouters wrote: > [kind of off-topic here, and also speaking as just an individual] > > On Fri, Oct 4, 2024 at 3:28 PM Erik Nygren wrote: > >> >> On Fri, Oct 4, 2024 at 3:20 PM Stephen Farrell >> wrote: >> >>> >>> On 10/4/24 19:30, Paul Wouters wrote: >>> > Wh

[TLS] Re: [DNSOP] Re: Re: Re: Re: AD review draft-ietf-tls-svcb-ech

ve onto these kind of networks and use ECH without > requiring to do further DNS lookups :P > > Maybe just an aggressive prefetch of ECH related records :P > > Which makes me wonder if it makes sense to advise long TTLs on these > records so that they move along on your phone

[TLS] Re: [DNSOP] Re: Re: Re: Re: AD review draft-ietf-tls-svcb-ech

I don't really think it's helpful to re-litigate the broader topic of the merits of ECH; nothing we say in security considerations will make a material difference there. With that said, I don't love the last sentence as we know users don't really choose their resolvers. How about simply stating th

[TLS] Re: [DNSOP] AD review draft-ietf-tls-svcb-ech

On Sun, Sep 29, 2024 at 7:34 PM Paul Wouters wrote: > Hi, > > I have done my AD review of draft-ietf-tls-svcb-ech. Some history was well > summarized by the Document > Shepherd: > > Please note that the text in this I-D was initially developed in the DNSOP WG, > went through IETF LC, and IESG rev

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

Yes, but the question is whether the protocol actually *provides* the property that authentication is based on certificates. The point of the analysis is to determine that. -Ekr On Mon, Sep 23, 2024 at 3:55 PM Russ Housley wrote: > I agree, and I think the Security Considerations already cover

[TLS] Re: DTLS 1.3 ACKs near the version transition

Hi David, Thanks for digging in here. I haven't fully processed your comments, but it does seem like we probably do need a -bis. Now that we've gotten 8446-bis and ECH out the door, I don't think this is implausible. Do you feel like you are getting close to a complete list of issues to be address

[TLS] Re: draft-ietf-tls-key-share-prediction next steps

On Wed, Sep 11, 2024 at 12:41 AM John Mattsson wrote: > "To avoid downgrade attacks, the client MUST continue to send its full > preferences in the supported_groups extension." > > > > I don't think sending full preferences is a requirement in RFC 8446. As > far as I can see there is no normative

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

This is done: https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/ -Ekr On Tue, Sep 10, 2024 at 10:30 AM Sean Turner wrote: > Hi! Thanks to all who participated in this consensus call (and those who > participated at IETF 120). Based on both the TLS WG sessions at IETF 120 > and this th

[TLS] Re: [TLS]Re: [Editorial Errata Reported] RFC6347 (8089)

Sure, that's fine On Wed, Sep 4, 2024 at 8:07 AM Sean Turner wrote: > Since this is correctly marked as “Editorial” are there any objections to > changing the state to “Hold For Document Update”? > > spt > > > On Aug 23, 2024, at 18:18, Eric Rescorla wrote: > &

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

I do not think we need to make Curve25519 MTI. The purpose of MTIs is to provide a minimum baseline for interoperability, and we have that already with the existing MTI. That's entirely compatible with most people preferring X25519 because they believe it's better than the MTI. -Ekr On Mon, Aug

[TLS] Re: [TLS]Working Group Last Call for "Hybrid key exchange in TLS 1.3"

It's not specified one way or the other in ECH but HPKE S 4.1 strongly suggests you should not be reusing these values: Namely: def Encap(pkR): skE, pkE = GenerateKeyPair() And skE means you are generating a key of type E: Ephemeral (E): Role of a fresh random value meant for one-time

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

Let's try to disentangle two questions: 1. Whether we should require this document to have some sort of formal analysis prior to advancing 2. Whether the feedback from the triage panel should be handled in some other way I don't have a strong opinion on (2), but I don't see that the answer to (1)

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

Unsurprisingly, I am in favor of requiring formal alnalysis (option 1), as I think all nontrivial extensions to TLS should have some formal analysis. I would note that the main rationale for this specification is as future-proofing for PQ. With the publication of ML-KEM by NIST, PSKs become less a

[TLS]Re: [Editorial Errata Reported] RFC6347 (8089)

I don't think this is an erratum. I agree it would be better, but I don't think that rises to "error". -Ekr On Fri, Aug 23, 2024 at 11:17 AM Rebecca VanRheenen wrote: > Hi Paul, > > We are unable to verify this erratum that the submitter marked as > editorial, so we changed the Type to “Techni

[TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH

Hi folks, I'd like to make sure we're all on the same page about this draft. The IESG has already approved the original TLS document on SSLKEYLOGFILE [0], which contains the keying material necessary to decrypt the connection. It's currently in the RFC Editor Queue. The draft under discussion wou

[TLS]Re: Discussions on Trust Anchor Negotiation at IETF 120

I agree that an interim focused on this topic would be a good idea. IMO the best place to start would be to try to build some consensus on which problems we want to solve (including whether existing approaches are sufficient) rather than on the details of specific proposals. Once we've done that,

[TLS]Re: TLS trust expressions and certificate_authorities

On Wed, Jun 12, 2024 at 5:16 PM Nick Harper wrote: > On Wed, Jun 12, 2024 at 3:17 AM Dennis Jackson > wrote: > >> You can't argue that T.E. contains the functionality of >> certificate_authorities as a subset, then conclude that having additional >> functionalities makes it less risky. You would

[TLS]Re: Curve-popularity data?

On Fri, Jun 7, 2024 at 11:41 AM D. J. Bernstein wrote: > Eric Rescorla writes: > > I'm struggling to understand what people think is at stake here. > > The WG will soon be faced with decisions regarding which curve+PQ > hybrids to recommend for TLS. It's importan

[TLS]Re: Curve-popularity data?

On Fri, Jun 7, 2024 at 8:52 AM John Mattsson wrote: > >so we should also remove X448, as it's much slower than X25519? > > That does not follow from what I said. I think the important metric is > performance/security. P-256 does basically not have any benefits compared > to X25519 (excepts a few

[TLS]Issue 1358: Require sending MTI curves in CH.key_share

In the long curve popularity thread, there has been some discussion [0] of what curves should be included in CH.key_shares and specifically if clients should be required to send key shares from one or more of the MTI curves [1]. I don't believe the specification currently requires this, but it woul

[TLS]Re: Curve-popularity data?

On Wed, Jun 5, 2024 at 6:54 AM Peter Gutmann wrote: > Eric Rescorla writes: > > >One more thing: we are finalizing RFC 8446-bis right now, so if there is > WG > >consensus to require that clients offer all MTI curves in the key_shares > of > >their in

[TLS]Re: Curve-popularity data?

On Wed, Jun 5, 2024 at 6:35 AM Eric Rescorla wrote: > > > On Wed, Jun 5, 2024 at 6:19 AM Peter Gutmann > wrote: > >> Nick Harper writes: >> >> >I see no requirement in section 9 nor in section 4.2.8 requiring MTI >> curves >> >be present

[TLS]Re: Curve-popularity data?

On Wed, Jun 5, 2024 at 6:19 AM Peter Gutmann wrote: > Nick Harper writes: > > >I see no requirement in section 9 nor in section 4.2.8 requiring MTI > curves > >be present in the key_share extension if that extension is non-empty. > > Just because it's possible to rules-lawyer your way around som

[TLS]Re: Curve-popularity data?

I largely agree with Richard here. To recap some basic facts 0. TLS is algorithm agile and Supported Groups [0] are listed in an IANA registry 1. The TLS Supported Groups registry has the "Specification Required" policy which means that in practice anyone can register groups. 2. Setting a group t

[TLS]Re: [EXTERNAL] Re: Curve-popularity data?

On Mon, Jun 3, 2024 at 11:55 AM Stephen Farrell wrote: > > I'm afraid I have no measurements to offer, but... > > On 03/06/2024 19:05, Eric Rescorla wrote: > > The question is rather what the minimum set of algorithms we need is. My > > point is that that has to

[TLS]Re: [EXTERNAL] Re: Curve-popularity data?

rather what the minimum set of algorithms we need is. My point is that that has to include P-256. It may well be the case that it needs to also include X25519. -Ekr > > > Cheers, >> >> >> >> Andrei >> >> >> >> *From:* Eric Rescorla >>

[TLS]Re: Curve-popularity data?

Indeed. I'd like to pull this back a bit to the question of what we specify/mandate. As I understand the situation, there are a number of environments that require P-256, so it seems like it would not be practical to just standardize/mandate X25519 + MLKEM if we want to get to 100% PQ algorithms.

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

On Sun, Jun 2, 2024 at 10:17 AM Russ Housley wrote: > 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

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

On Fri, May 31, 2024 at 7:55 AM Cas Cremers wrote: > Hi Usama, > > I think there is some possible misunderstanding of the panel's comments > from your side. The panel did not discuss using any tool over any other. If > someone writes "a Tamarin-like" analysis then this doesn't necessarily > mean

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

Thanks for posting this. It's great to see the triage panel coming together. This is very thorough and helpful. My take-home from this report is that the security properties of 8773-bis are not immediately obvious and therefore that prior to advancing it we should actually have some sort of more

[TLS]Re: Adoption Call for draft-davidben-tls-key-share-prediction

ause they believed the options roughly equivalent. So I > took all that out and replaced it with text to that effect. > > David > > > On Tue, May 21, 2024, 08:54 Eric Rescorla wrote: > >> I agree that it's attractive to be able to hint in the HTTPS RR, but I'm

[TLS]Re: Adoption Call for draft-davidben-tls-key-share-prediction

I agree that it's attractive to be able to hint in the HTTPS RR, but I'm less sure about addressing the basic insecurity of the DNS channel with the approach this draft takes. I don't have a complete thought here, but what if we were to somehow fold the hint into the handshake transcript? I suppose

Re: [TLS] WG Adoption for TLS Trust Expressions

On Tue, Apr 30, 2024 at 4:30 PM Dennis Jackson wrote: > On 01/05/2024 00:07, Watson Ladd wrote: > > On Tue, Apr 30, 2024 at 3:26 PM Dennis > Jackson > wrote: > > > Let's assuming for a moment we could a) get most of the world to use ACME (a > worthy but challenging goal) and b) get them to c

Re: [TLS] WG Adoption for TLS Trust Expressions

I agree with you about this. -Ekr [0] I also don't think (not that you suggested it) that one should infer from the client advertising support for DCs that it has an accurate enough clock for every purpose. On 30/04/2024 16:33, Eric Rescorla wrote: > > > > On Tue, Apr 30, 2024 a

Re: [TLS] WG Adoption for TLS Trust Expressions

On Tue, Apr 30, 2024 at 8:29 AM Watson Ladd wrote: > On Tue, Apr 30, 2024 at 8:25 AM Eric Rescorla wrote: > > > > > > On the narrow point of shorter lifetimes, I don't think the right way to > advertise that you have an accurate clock is to advertise that y

Re: [TLS] WG Adoption for TLS Trust Expressions

On Tue, Apr 30, 2024 at 8:14 AM Brendan McMillion < brendanmcmill...@gmail.com> wrote: > Of course this is possible in theory, there are no standards police, but >> this argument overlooks the gargantuan technical and economic costs of >> deploying this kind of private extension. You'd need to con

Re: [TLS] [EXTERNAL] Re: WG Adoption for TLS Trust Expressions

Hi folks, I haven't yet formed an opinion on this document yet, but I did want to observe that calls for adoption are issued by the chairs, not by individual participants. Of course, anyone can start a thread and comments in this thread are information for the chairs, but if adoption does happen,

Re: [TLS] Deprecating Static DH certificates in the obsolete key exchange document

Yes. -Ekr On Mon, Apr 15, 2024 at 11:14 AM Joseph Salowey wrote: > At IETF 119 we had discussion that static DH certificates lead to static > key exchange which is undesirable. Although the current draft deprecates > static DH ciphersuites, it seems that RFC 5246 allows the client to provide >

Re: [TLS] Adoption call for TLS Flag - Request mTLS

t sounds like there’s an > alternative design that might need to be hammered out, but since it appears > a document may be needed for either path, let’s adopt and argue about that > later. > > > > *From:* TLS *On Behalf Of *Eric Rescorla > *Sent:* Wednesday, April 3,

Re: [TLS] Adoption call for TLS Flag - Request mTLS

On Tue, Apr 2, 2024 at 10:36 PM Watson Ladd wrote: > > On Tue, Apr 2, 2024, 5:08 PM Eric Rescorla wrote: > >> Adoption should not be required to register a code point [0], as the >> policy is Specification Required. >> >> I'm mildly negative on adopting thi

Re: [TLS] Adoption call for TLS Flag - Request mTLS

Adoption should not be required to register a code point [0], as the policy is Specification Required. I'm mildly negative on adopting this document. What is the reason we need to spend WG time on this, rather than just having a code point assignment? -Ekr [0] As an aside the IANA considerations

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

On Sat, Mar 30, 2024 at 11:09 AM Ted Lemon wrote: > Encrypted dns transport works if you can trust the provider you are > talking to. DNSSEC works even if you can’t. And if your provider is > trustworthy, DNSSEC validation of results acquired through this tunnel > should work. So it’s silly in th

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

Hi Ted, Doesn't this section of RFC 9460 address this case and say what you are recommending: https://www.rfc-editor.org/rfc/rfc9460.html#section-3.1 -Ekr On Fri, Mar 29, 2024 at 6:49 PM Ted Lemon wrote: > Okay, I think I see the disconnect, maybe. The issue I'm pointing to is > that you ma

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

On Fri, Mar 29, 2024 at 1:42 PM Deirdre Connolly wrote: > > KEMs are not "key agreement" algorithms as suggested by this draft > name. In a key agreement algorithm, both parties contribute to the shared > secret. With a KEM, only one party generates the the shared secreat value. > > This is not

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker wrote: > Reviewer: Ted Lemon > Review result: Almost Ready > > This is a DNS Directorate review for draft-ietf-tls-svcb-ech-01. > > Section 4.1 advises disabling fallback, but does not talk about DNSSEC, > which > is surprising given that

Re: [TLS] Working Group Last Call for ECH

On Wed, Mar 20, 2024 at 10:39 PM Raghu Saxena wrote: > > On 3/15/24 00:02, Eric Rescorla wrote: > > > > > > So, if I understand correctly, for my domain "abc.com > > <http://abc.com>", I could > > purposely choose to have m

Re: [TLS] Working Group Last Call for ECH

On Sun, Mar 17, 2024 at 11:53 PM Karthikeyan Bhargavan < karthikeyan.bharga...@inria.fr> wrote: > Is there value in citing the security analysis for ECH as an informative > reference? > > [image: 3548606.cover.jpg] > > A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello | > Proc

Re: [TLS] should we say anything about ECH in the face of fragmentation?

On Fri, Mar 15, 2024 at 2:23 PM Stephen Farrell wrote: > > Hiya, > > I think the outcome here is maybe most likely to do nothing but > since the WGLC is ongoing I figured it best to bring it up in > case others have better ideas. > Yes, I think the answer is "do nothing". TLS assumes that TCP co

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

g to skate where the puck is going. >>> >>> But also, the fact that CNSA 2.0 explicitly requires ML-KEM _only_ key >>> agreement in the next ~6-9 years is a strong vote of confidence in any >>> protocol doing this at all, so, TLS wouldn't be out on a limb to suppor

Re: [TLS] Working Group Last Call for ECH

On Wed, Mar 13, 2024 at 8:40 PM Raghu Saxena wrote: > > On 3/14/24 00:45, Eric Rescorla wrote: > > There are two questions here: > > > > 1. What the specification says > > 2. What implementations choose to do within the envelope of that > > specification

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

On Wed, Mar 13, 2024 at 4:10 PM Blumenthal, Uri - 0553 - MITLL < u...@ll.mit.edu> wrote: > Also, what are the WG's thoughts on including standalone PQC signatures in > the same draft? > > > > I think that including standalone PQC sigs would be very desirable. > > > > I don't think there is any par

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

On Wed, Mar 13, 2024 at 2:36 PM Rebecca Guthrie wrote: > Greetings Deirdre and TLS, > > > > I read through draft-connolly-tls-mlkem-key-agreement-00 (and > https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/blob/main/draft-connolly-tls-mlkem-key-agreement.md) > and I have a few c

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

On Wed, Mar 13, 2024 at 3:07 PM Blumenthal, Uri - 0553 - MITLL < u...@ll.mit.edu> wrote: > Also, what are the WG's thoughts on including standalone PQC signatures in > the same draft? > > > > I think that including standalone PQC sigs would be very desirable. > I don't think there is any particul

Re: [TLS] Working Group Last Call for ECH

n-shared IPs. One might imagine that some special purpose clients would choose to do so, but that's not the case I'm talking about. -Ekr > On Wed, Mar 13, 2024 at 12:03 PM Eric Rescorla wrote: > >> >> >> On Wed, Mar 13, 2024 at 8:49 AM A A 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

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

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 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 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 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] 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] 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

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] 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] 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

[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] 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

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

[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] [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

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] [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] [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] 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] [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] [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 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 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] 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] 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] 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] 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

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] 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

  1   2   3   4   5   6   7   8   9   10   >