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

(Resending since I don't see these two mails in the list archives, so I'm not sure if the list software broke again. Apologies if this is a duplicate mail!) On Thu, Sep 19, 2024 at 1:49 PM David Benjamin wrote: > On Thu, Sep 19, 2024 at 1:31 PM David Benjamin > wrote: >

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

On Thu, Sep 19, 2024 at 1:31 PM David Benjamin wrote: > Ah fun, another issue in this document. So not only are write epoch > lifetimes unspecified and complex with 0-RTT, but read epoch lifetimes > *are* specified but *wrong*. > > Section 4.2.1 says: > > > Becau

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

optionally waiting a spell for reordering) So the rule is actually that we close according to a partially ordered set: - 0 (unencrypted) < 2 (handshake) < 3 (first app data) < 4 < 5 < ... - 1 (early data) < 3 (first app data) < 4 < 5 < ... - 1 is not ordered relative to 0 and

[TLS] DTLS 1.3 and the 0-RTT <-> 1-RTT transition

Another issue with RFC 9147: when does the client switch from sending 0-RTT to 1-RTT app data, and when does the server start processing 1-RTT app data from the client? This is less of an open question (I think we match how we already resolved this for QUIC), but is something we should have writte

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

also interesting on the write side, though I'll start a separate thread for that. All this is subtle enough that it should not be left as an exercise to the reader. David On Wed, Sep 18, 2024 at 12:39 AM Bob Beck wrote: > > > > On Sep 17, 2024, at 5:28 PM, David Benjamin 40google.

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

just pause the ACK mechanism and hope you're in an OK state? This seems quite prune to send the implementation into unexpected and untested states. On Thu, Sep 12, 2024 at 4:31 PM David Benjamin wrote: > Hi all, > > I noticed another issue with the DTLS 1.3 ACK design. :-) > > So,

[TLS] DTLS 1.3 ACKs near the version transition

Hi all, I noticed another issue with the DTLS 1.3 ACK design. :-) So, DTLS 1.3 uses ACKs. DTLS 1.2 does not use ACKs. But you only learn what version you're speaking partway through the lifetime of the connection, so there are some interesting corner cases to answer. As an illustrative example, I

[TLS] Early codepoint allocation for tls_flags

Hi all, It was suggested that sending this more broadly might be helpful. I'm looking to implement draft-ietf-tls-cross-sni-resumption, which depends on draft-ietf-tls-tlsflags. Both WG drafts in the data tracker appear to be in "Waiting for Implementation" state. Looking back in the list, it seem

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

rver believes X25519 and P-256 are equivalent in security (and implements a policy as such), but then also fails to do point validation in P-256, its policy is demonstrably incompatible with its behavior and it is the server's responsibility to fix this. It sounds like you know of a TLS

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

On Wed, Sep 11, 2024 at 3:58 AM Ilari Liusvaara wrote: > On Wed, Sep 11, 2024 at 10:13:55AM +0400, Loganaden Velvindron wrote: > > On Wed, 11 Sept 2024 at 01:40, David Benjamin > wrote: > > > > > > Hi all, > > > > > > Now that we're working

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

Hi all, Now that we're working through the Kyber to ML-KEM transition, TLS 1.3's awkwardness around key share prediction is becoming starkly visible. (It is difficult for clients to efficiently offer both Kyber and ML-KEM, but a hard transition loses PQ coverage for some clients. Kyber was a draft

[TLS] Re: [EXTERNAL] Re: Planned changes to Cloudflare's post-quantum deployment

ate, >we'll roll the change out more fully. > > Are you planning to offer X25519MLKEM768 key share on the initial > ClientHello (in addition to X25519), or just advertise for those servers > willing to burn a round-trip? > > > > Cheers, > > > > Andre

[TLS] Re: Planned changes to Cloudflare's post-quantum deployment

Thanks Bas! We plan to do the same for Chrome, replacing X25519Kyber768Draft00 with X25519MLKEM768. X25519MLKEM768 should be live now to a small fraction of Chrome Canary, so that servers have some clients in the wild to test against. After a little time to give early Kyber adopters time to migrat

[TLS]Re: DTLS 1.3 sequence number lengths and lack of ACKs

we document it > somewhere. > > > > Ciao > Hannes > > > > *From:* David Benjamin > *Sent:* Tuesday, April 16, 2024 3:18 PM > *To:* Tschofenig, Hannes (T CST SEA-DE) > *Cc:* ; Nick Harper > *Subject:* Re: [TLS] DTLS 1.3 sequence number lengths and lack of AC

[TLS]Re: DTLS 1.3 epochs vs message_seq overflow

tement: “65K epochs should be enough for anybody, > perhaps DTLS 1.4 should update the RecordNumber structure accordingly and > save a few bytes in the ACKs“. Possibly correct. I am going to ask the > SCTP community for feedback to find out whether that is also true for them. > > >

[TLS]Re: Issues with buffered, ACKed KeyUpdates in DTLS 1.3

To follow up here, I've filed https://www.rfc-editor.org/errata/eid8047 with "option 7" from the thread. On Sat, Apr 27, 2024 at 8:11 AM Watson Ladd wrote: > > > On Sat, Apr 27, 2024, 8:03 AM David Benjamin > wrote: > >> What should the next steps be

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

I support adoption of the draft to solve this problem, but I suspect the construction will need some changes. I'm not sure the construction in the draft actually works. A single extended key update flow in the draft sends NewKeyUpdate in *both* directions. Now, imagine if both client and server in

[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks

On Tue, Jul 23, 2024 at 11:10 AM Watson Ladd wrote: > On Tue, Jul 23, 2024, 11:04 AM Salz, Rich 40akamai@dmarc.ietf.org> wrote: > >> I don't think its possible to go one API / method at a time. If we want >> to turn on a feature by default, it has to either be non-backwards >> compatible or

[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks

On Mon, Jul 22, 2024 at 8:58 AM Mike Shaver wrote: > On Sat, Jul 20, 2024 at 2:23 PM David Benjamin > wrote: > >> On Sat, Jul 20, 2024, 06:13 Mike Shaver wrote: >> >>> In what way are these non-web systems not allowed to use other PKI >>> models toda

[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks

On Sat, Jul 20, 2024, 06:13 Mike Shaver wrote: > > > On Sat, Jul 20, 2024 at 8:59 AM Ilari Liusvaara > wrote: > >> Allowing various embedded and IoT stuff to migrate off of WebPKI would >> be of immense value. Such stuff using WebPKI has been source of gigantic >> amount of pain. > > > I agree w

[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks

Hi Rich, Have you read the second draft (draft-beck-trust-anchor-ids)? I think it's conceptually much simpler overall and is hopefully easier to wrap one's head around. There's no JSON structure or relying party / root program split or anything. The complexity of trust expressions doesn't come fr

[TLS]Trust Expressions Update

Hi all, Thanks for all the feedback and spirited discussion on trust expressions. We have several updates we’d like to share here: First, we’ve been gradually updating the draft and supplementary text in our repository to cover the various topics being discussed. The supplementary text is at: htt

[TLS]Re: [EXTERNAL] Consensus Call: -rfc8446bis PR #1361

ctions, so that PR fixes it. On Fri, Jun 21, 2024 at 1:46 PM Andrei Popov wrote: > Added a couple of minor comments; overall this change seems OK. > > Cheers, > > Andrei > > -Original Message- > From: Sean Turner > Sent: Friday, June 21, 2024 10:15 AM >

[TLS]Re: TLS trust expressions and certificate_authorities

On Mon, Jun 17, 2024 at 9:10 AM Dennis Jackson wrote: > David Benjamin wrote: > > Broadly, the fingerprinting story is the same as the > certificate_authorities extension, in that trust expressions targets the > cases where the trust anchor list is common to your desire

[TLS]Re: TLS trust expressions and certificate_authorities

> If this is implemented by user agents, how do we envision the fingerprinting impact for this? The privacy considerations section discusses this a little bit: https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#name-privacy-considerations Broadly, the fingerprinti

[TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345

this would make the requirement more clear, and avoid enforcement > of a requirement that can’t be strictly followed. > > > > *From:* David Benjamin > *Sent:* Thursday, June 6, 2024 5:48 PM > *To:* Kyle Nekritz > *Cc:* Sean Turner ; TLS List > *Subject:* Re: [TLS]Re:

[TLS]Re: TLS trust expressions and certificate_authorities

Hi Stephen, We added some text to the most recent draft that addresses some of the PKI dynamics that seem to underly the discussion. https://author-tools.ietf.org/iddiff?url1=draft-davidben-tls-trust-expr-02&url2=draft-davidben-tls-trust-expr-03&difftype=--html We've also been gradually updating

[TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345

Regarding 1343, the PR is a rule on the sender, not the receiver. After all, it says "The sender MUST NOT". It is not a rule on the receiver. We have interop problems *today* when one side sends too many KeyUpdates, triggered by data received. The PR does not ask receivers to enforce stuff, but (m

[TLS]Re: TLS Trust Expressions risks

On Fri, May 24, 2024 at 3:46 PM Watson Ladd wrote: > To be clear, in Denis's scenario Ebonia requires all servers to obtain > a cert from Honest Ahmed's > (https://bugzilla.mozilla.org/show_bug.cgi?id=647959) Ebonian Secure > CA. Server operators who complain that this will break clients are > to

[TLS]Re: WG Adoption for TLS Trust Expressions

o one has to agree to this because you have not backed this claim at all. > Nick sent two long emails explaining why this was not the case, both of > which you have simply dismissed [...] > > This is something that I believe David Benjamin and the other draft > authors, and I all

[TLS]Re: Working Group Last Call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

On Wed, May 22, 2024 at 10:27 AM Salz, Rich wrote: > > This email starts the working group last call for "Legacy > RSASSA-PKCS1-v1_5 codepoints for TLS 1.3” I-D, located here: > > No comments, ship it. > > > The only comment/question I have about this I-D (and I hope this is not > too much of a b

[TLS]Re: WG Adoption for TLS Trust Expressions

Hi Richard. Thanks for the comments! Replies inline. On Mon, May 6, 2024 at 10:23 AM Richard Barnes wrote: > Hi all, > > Coming in late here. Appreciate the discussion so far. FWIW, here's how > I'm thinking through this: > > I would frame the basic problem here as follows, since I think the u

[TLS]Re: WG Adoption for TLS Trust Expressions

(replies inline) On Sun, May 5, 2024 at 6:48 PM Dennis Jackson wrote: > Hi David, Devon, Bob, > > I feel much of your response talks past the issue that was raised at IETF > 118. > > The question we're evaluating is NOT "If we were in a very unhappy world > where governments controlled root cert

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

ue of this whole draft. On Tue, May 21, 2024, 09:56 A A wrote: > In my opinion, to prevent downgrade attack, server MUST or SHOULD using > DNSSEC when announcing DNS record. > > > 21.05.2024, 21:48, "David Benjamin" : > > Off the cuff, folding it into the trans

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

Off the cuff, folding it into the transcript sounds tricky, since existing TLS servers won't know to do it, and, as with any other DNS hints, we need to accommodate the DNS being out of sync with the server. It'll also be more difficult to deploy due to needing changes in the TLS stack and generall

[TLS]Re: WG Adoption for TLS Trust Expressions

Resending this since it seems IETF lists were broken recently ( https://www.ietf.org/blog/ietf-mailing-list-delivery-issues/). Hopefully it works this time. On Thu, May 9, 2024 at 10:45 AM David Benjamin wrote: > Hi Richard. Thanks for the comments! Replies inline. > > On Mon, May 6, 2

[TLS]Re: WG Adoption for TLS Trust Expressions

Resending this since it seems IETF lists were broken recently ( https://www.ietf.org/blog/ietf-mailing-list-delivery-issues/). Hopefully it works this time. On Thu, May 9, 2024 at 10:40 AM David Benjamin wrote: > (replies inline) > > On Sun, May 5, 2024 at 6:48 PM Dennis Jackson

[TLS]Re: HTTPS-RR and TLS

On Wed, May 8, 2024 at 3:50 PM Watson Ladd wrote: > On Tue, May 7, 2024 at 8:07 AM David Benjamin > wrote: > > > > [changing the subject since I expect this to mostly be a tangential > discussion] > > > > On Sat, May 4, 2024, 09:12 Stephen Farrell > wr

[TLS]HTTPS-RR and TLS

[changing the subject since I expect this to mostly be a tangential discussion] On Sat, May 4, 2024, 09:12 Stephen Farrell wrote: > I hope, as the WG are processing this > [draft-davidben-tls-key-share-prediction], we consider what, > if anything, else could be usefully added to HTTPS RRs > to m

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

on that > in the document. > > —Roelof > > > On May 3, 2024, at 6:09 PM, David Benjamin wrote: > > Unsurprisingly, I support adoption. :-) > > On Fri, May 3, 2024 at 6:05 PM Joseph Salowey wrote: > >> This is a working group call for adoption >> for draft-dav

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

Slight clarification, this is an adoption call for a DNS hint for which key shares send in the ClientHello, not trust expressions. :-) On Fri, May 3, 2024, 20:33 Salz, Rich wrote: > I think it might be trying to be a cure-all for all PKI transition > problems/issues, but I support adoption and h

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

Unsurprisingly, I support adoption. :-) On Fri, May 3, 2024 at 6:05 PM Joseph Salowey wrote: > This is a working group call for adoption > for draft-davidben-tls-key-share-prediction. This document was presented > at IET 118 and has undergone some revision based on feedback since then. > The cu

Re: [TLS] WG Adoption for TLS Trust Expressions

minutes > <https://notes.ietf.org/notes-ietf-118-tls#TLS-Trust-Expressions---Devon-O%E2%80%99Brien-David-Benjamin-Bob-Beck---30-min>). > > > Although the authors acknowledged the issue in the meeting, no changes > have been made since to either address the problem or document

Re: [TLS] WG Adoption for TLS Trust Expressions

Hi all. Thanks for the discussion! While we're digesting it all, one quick comment regarding the feedback in Prague: >From talking with folks at the meeting, it seemed part of this was due to a misunderstanding. Trust expressions are not intended to capture per-user customizations to root stores,

Re: [TLS] Issues with buffered, ACKed KeyUpdates in DTLS 1.3

What should the next steps be here? Is this a bunch of errata, or something else? On Wed, Apr 17, 2024 at 10:08 AM David Benjamin wrote: > > Sender implementations should already be able to retransmit messages > with older epochs due to the "duplicated" post-auth state m

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

d provide input. On Tue, Apr 23, 2024 at 11:31 AM David Benjamin wrote: > Having worked on a TLS implementation and removed code for this, I can > tell you that is *not* simply a natural side-effect of supporting DH > certificates. These modes interact with the TLS handshake logic a f

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

Having worked on a TLS implementation and removed code for this, I can tell you that is *not* simply a natural side-effect of supporting DH certificates. These modes interact with the TLS handshake logic a fair bit. They omit the ServerKeyExchange message and change the ClientKeyExchange message. T

Re: [TLS] Issues with buffered, ACKed KeyUpdates in DTLS 1.3

quot; post-auth state machine. > > Marco > > On Tue, Apr 16, 2024 at 3:48 PM David Benjamin > wrote: > >> Thanks, Hannes! >> >> Since it was buried in there (my understanding of the issue evolved as I >> described it), I currently favor option 7. I.e. the send

Re: [TLS] Issues with buffered, ACKed KeyUpdates in DTLS 1.3

reat feedback. Give me a few days to respond to this issue with > my suggestion for moving forward. > > > > Ciao > > Hannes > > > > *From:* TLS *On Behalf Of *David Benjamin > *Sent:* Saturday, April 13, 2024 7:59 PM > *To:* > *Cc:* Nick Harper > *Subje

Re: [TLS] DTLS 1.3 sequence number lengths and lack of ACKs

More explanation about this aspect never hurts. Of course, nobody raised > the need for such text so far and hence we didn’t add anything. As a way > forward, we could add text to the UTA document. In the UTA document(s) we > already talk about other configurable parameters, such as th

Re: [TLS] IANA Recommendations for Obsolete Key Exchange

>From the meeting, I remember there being some confusion around a table that split things up between TLS 1.2 and TLS 1.3, and differences in how they negotiate things, which makes this listing a bit ambiguous. In particular, there aren't any *cipher suites* with FFDH or FFDHE in their name in TLS 1

Re: [TLS] Issues with buffered, ACKed KeyUpdates in DTLS 1.3

pplies for the handshake, and not post-handshake messages, I think option 5 (process KeyUpdate out of order) might become viable? I'm not sure. Either way, this seems like a significant protocol break, so I don't think this is an option until some hypothetical DTLS 1.4. On Fri, Apr 12,

[TLS] Issues with buffered, ACKed KeyUpdates in DTLS 1.3

Hi all, This is going to be a bit long. In short, DTLS 1.3 KeyUpdates seem to conflate the peer *receiving* the KeyUpdate with the peer *processing* the KeyUpdate, in ways that appear to break some assumptions made by the protocol design. *When to switch keys in KeyUpdate* So, first, DTLS 1.3, u

[TLS] DTLS 1.3 sequence number lengths and lack of ACKs

Hi all, Here's another issue we noticed with RFC 9147: (There's going to be a few of these emails. :-) ) DTLS 1.3 allows senders to pick an 8-bit or 16-bit sequence number. But, unless I missed it, there isn't any discussion or guidance on which to use. The draft simply says: > Implementations M

Re: [TLS] DTLS 1.3 epochs vs message_seq overflow

On Thu, Apr 11, 2024 at 7:12 PM David Benjamin wrote: > Hi all, > > In reviewing RFC 9147, I noticed something a bit funny. DTLS 1.3 changed > the epoch number from 16 bits to 64 bits, though with a requirement that > you not exceed 2^48-1. I assume this was so that you'r

[TLS] DTLS 1.3 epochs vs message_seq overflow

Hi all, In reviewing RFC 9147, I noticed something a bit funny. DTLS 1.3 changed the epoch number from 16 bits to 64 bits, though with a requirement that you not exceed 2^48-1. I assume this was so that you're able to rekey more than 65K times if you really wanted to. I'm not sure we actually ach

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

I don't believe we need a separate range, just to unmark the elliptic curve range. TLS does not usually ascribe meaning to ranges of codepoints because TLS implementations do not need to categorize codepoints they don't understand. The only reason supported groups was partitioned was because of a

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

+1 to removing the "Elliptic curve groups" note. That partition came out of RFC 7919's (unfortunate ) decision to repurpose the existing DHE cipher suites (see RFC 7919, section 4), so we're stuck treating 256-511 as special. B

[TLS] KeyUpdate storms from buggy update_requested logic

Hi all, MT and I were discussing KeyUpdate at the meeting, and I realized I never got around to writing up an issue we'd observed in real world TLS 1.3 deployments. rfc8446bis is pretty far along now, but MT suggested I write this up anyway: We ran into a fun bug with a major TLS implementation t

Re: [TLS] Question about Large Record Sizes draft and the TLS design

I can't say what was going on in the SSLv3 days, but yes record size limits are important for memory. Whatever the maximum record size is, the peer can force you to buffer that many bytes in memory. That means the maximum record size is actually a DoS parameter for the protocol. On Wed, Mar 20, 20

Re: [TLS] A suggestion for handling large key shares

T” language from -00 section 3.2 and 3.4 ought to be > in draft-ietf-tls-hybrid-design. > > > > I definitely want to see draft-davidben-tls-key-share-prediction move > forward too. > > > > Rgs, > > Panos > > > > *From:* TLS *On Behalf Of * David Benja

Re: [TLS] A suggestion for handling large key shares

> If the server supports P256+ML-KEM, what Matt suggested is that, instead of accepting P256, it instead a ClientHelloRetry with P256+ML_KEM. We then continue as expected and end up negotiating things in 2 round trips. I assume ClientHelloRetry was meant to be HelloRetryRequest? If so, yeah, a se

Re: [TLS] [EXTERNAL] Re: Next steps for key share prediction

yet opted for a PQ-incompatible >selection criteria, has clearly documented this so it isn't a surprise to >you. ;-) > > Correct. > > > >- Between all that, we probably can reasonably say that's the server >operator's responsibility? > >

Re: [TLS] TLSFlags ambiguity

got to add this issue. I have corrected this now so that we won’t > forget again: > https://github.com/tlswg/tls-flags/issues/36 > > spt > > > On Mar 17, 2024, at 13:53, David Benjamin wrote: > > > > Did this ever get resolved? I noticed that there was a draft-

Re: [TLS] TLSFlags ambiguity

that this document does not define any particular bits for this string. That is left to the protocol documents such as the ones in the examples from the previous section. Such documents will have to define which bit to set to show support. David On Wed, Sep 27, 2023, 17:50 David Benjamin wrote: &

Re: [TLS] Next steps for key share prediction

On Thu, Mar 7, 2024 at 6:34 PM Watson Ladd wrote: > On Thu, Mar 7, 2024 at 2:56 PM David Benjamin > wrote: > > > > Hi all, > > > > With the excitement about, sometime in the far future, possibly > transitioning from a hybrid, or to a to-be-developed better PQ a

[TLS] Next steps for key share prediction

Hi all, With the excitement about, sometime in the far future, possibly transitioning from a hybrid, or to a to-be-developed better PQ algorithm, I thought it would be a good time to remind folks that, right now, *we have no way to effectively transition between PQ-sized KEMs at all*. At IETF 118

Re: [TLS] Time to first byte vs time to last byte

This is good work, but we need to be wary of getting too excited about TTLB, and then declaring performance solved. Ultimately, TTLB simply dampens the impact of postquantum by mixing in the (handshake-independent) time to do the bulk transfer. The question is whether that reflects our goals. Ulti

Re: [TLS] Trust Expressions Follow-up

te > ellison here: > https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#name-intermediate-elision > > The idea was that if you had stable receipts from a transparency service > you trusted, you might not need to care about all the parts of a cert cha

Re: [TLS] Trust Expressions Follow-up

obably adapt some of that text back into the draft, after some more wordsmithing.) On Thu, Feb 29, 2024 at 7:18 PM David Benjamin wrote: > Circling back to this thread, we're now looking at prototyping the TLS > parts in BoringSSL, on both the client (Chrome) and the server side. Let

Re: [TLS] Trust Expressions Follow-up

here, we'd like to get some experience with things.) On Thu, Jan 25, 2024 at 5:00 PM David Benjamin wrote: > Hi all, > > Now that the holidays are over, I wanted to follow up on > draft-davidben-tls-trust-expr and continue some of the discussions from > Prague: > > &

Re: [TLS] Trust Expressions Follow-up

On Fri, Jan 26, 2024 at 5:15 AM Ilari Liusvaara wrote: > On Thu, Jan 25, 2024 at 05:00:19PM -0500, David Benjamin wrote: > > > > Second, I wanted to take a step back and try to better articulate our > > goals. I think the best way to look at this draft is in three parts: &

[TLS] Trust Expressions Follow-up

Hi all, Now that the holidays are over, I wanted to follow up on draft-davidben-tls-trust-expr and continue some of the discussions from Prague: https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html https://datatracker.ietf.org/meeting/118/materials/slides-118-tls-t

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

On Thu, Jan 18, 2024 at 5:25 PM Rob Sayre wrote: > On Thu, Jan 18, 2024 at 1:26 PM David Benjamin > wrote: > >> >> I think sometimes we spend a little more energy than is actually useful >> in figuring out these implied lower bounds. :-) In practice, the only >>

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

The extension list cannot actually be empty because we also say: > The "signature_algorithms" extension > MUST be specified, and other extensions may optionally be included > if defined for this message. That said, enforcing this by rejecting the empty list doesn't do much because the receiver wi

Re: [TLS] TLS Suite Naming Conventions

On Sat, Jan 6, 2024 at 12:23 PM David Benjamin wrote: > I think this thread stems from a misunderstanding of what TLS is doing, > and what "Ed25519" means. > > > In the thread, Neil said that it is better to negotiate for key > (representations), instead of algor

Re: [TLS] TLS Suite Naming Conventions

I think this thread stems from a misunderstanding of what TLS is doing, and what "Ed25519" means. > In the thread, Neil said that it is better to negotiate for key (representations), instead of algorithms, and that TLS has been moving away from fully specifying things. This is the exact opposite

Re: [TLS] Key Update for TLS/DTLS 1.3

Skimming the draft, I am not following the timing of this process. Suppose the client initiates an extended key update. It cannot update the keys yet, because it does not know the server's response. It needs to keep reading from the server. In doing so, it will hopefully see a responding ExtendedKe

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

I agree that IANA registrations aren't a great place to constrain this. First, constraining the registry for TLS 1.2 and not DTLS 1.2 makes a lot of things very weird. For a feature that's TLS/DTLS-agnostic, like post-quantum, it helps no one to define it for DTLS 1.2 and not TLS 1.2. Most of the

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

I don't think that quite captures the tradeoffs. Sure, TLS 1.2 will be around for quite some time, but that *does not mean it is worth adding new features to TLS 1.2*. Those two statements are not directly related. Protocol changes generally require both client and server changes to take effect. P

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

I support adoption and am willing to review. On Wed, Dec 6, 2023 at 12:34 AM Deirdre Connolly wrote: > At the TLS meeting at IETF 118 there was significant support for the draft > 'TLS 1.2 is in Feature Freeze' ( > https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/) This > call is t

Re: [TLS] Adoption call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

under this name? It would be better to have in the > tlswg repo, we'll follow up offline. > > Thanks, > > Joe > > On Wed, Nov 29, 2023 at 9:41 AM David Benjamin > wrote: > >> Done, although I'm not sure if I got all the metadata right. (How does &

Re: [TLS] Adoption call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

Done, although I'm not sure if I got all the metadata right. (How does one mark it as replacing the old one?) https://datatracker.ietf.org/doc/draft-tls-tls13-pkcs1/ The GitHub is still under my account, but happy to move it to the TLSWG if preferred. (How would we go about doing that?) On Wed, N

Re: [TLS] Design Rational for Key Exporter

An unhelpful answer is that the key exporter interface was already set by prior versions of TLS and any TLS 1.3 key exporter needs to remain analogous. :-) A more helpful answer is that we cannot simultaneously believe that key update is a transparent feature of TLS, and that exporters are sensiti

Re: [TLS] Request mTLS Flag

a mess. Client certificates are the bane of my existence. :-) On Tue, Nov 7, 2023 at 10:46 PM David Benjamin wrote: > On Tue, Nov 7, 2023 at 3:43 PM Ilari Liusvaara > wrote: > >> On Mon, Oct 23, 2023 at 01:37:55PM -0400, Viktor Dukhovni wrote: >> > >> > - Some

Re: [TLS] Request mTLS Flag

On Tue, Nov 7, 2023 at 3:43 PM Ilari Liusvaara wrote: > On Mon, Oct 23, 2023 at 01:37:55PM -0400, Viktor Dukhovni wrote: > > > > - Some Java TLS libraries (used to?) fail the handshake when the > > client has no configured certs, or the list of issuer CA DN hints > > does include

Re: [TLS] Adoption call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

I support adoption and am willing to contribute text, but this is perhaps not surprising. :-) On Mon, Nov 6, 2023 at 12:25 PM Joseph Salowey wrote: > At the TLS meeting at IETF 118 there was significant support for the > draft Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 >

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

thenticated > signals, such as DNS or falling back on apparent network error > (e.g., due to apparent intolerance of large CH), then the attacker > can exploit the behavior described in (3) to downgrade the selected > groups. > > > Is this a reasonably accurate summary of the si

Re: [TLS] Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

On Fri, Oct 27, 2023 at 2:07 PM Benjamin Kaduk wrote: > On Tue, Oct 24, 2023 at 10:12:56PM -0400, David Benjamin wrote: > >Additionally I want to emphasize that, because of the negotiation > order > >between versions and client certificates, there is no way to do an

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

rfc8446bis is still open for substantive changes (though my impression was it isn't?), I don't mind putting things in there. Though we'd still need to expend a lot of text to define prediction-safe and prediction-unsafe groups, precisely because we do *not* want to define duplicate gr

Re: [TLS] Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

Some changes from the last time this was posted: - Apparently we got early codepoint allocation for this and I forgot about it? Anyway the allocated codepoints are now in the draft. - We've crisped up the motivation a bit. One thing I'll call out is that the previous discussion mentioned one could

Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

On Tue, Oct 24, 2023, 13:07 Viktor Dukhovni wrote: > On Tue, Oct 24, 2023 at 12:54:08PM -0400, David Benjamin wrote: > > > Is the concern here errors or prompting? From the original email, it > > sounded like the issue was that requesting client certificates showed > >

Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

Is the concern here errors or prompting? From the original email, it sounded like the issue was that requesting client certificates showed undesirable UI to human-backed clients. That one is a bit harder to avoid since no one is acting incorrectly per se. Clients for humans need to ask the human f

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

On Sat, Oct 21, 2023 at 5:41 AM Ilari Liusvaara wrote: > On Fri, Oct 20, 2023 at 04:07:21PM -0400, David Benjamin wrote: > > On Thu, Oct 19, 2023 at 3:17 PM Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > - The multiple certificates from on

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

e very many words to say. :-) But I'm fine with whatever order. The goal was to just pick *some* defined sort order, so that it's easy to find duplicates, and to hint that maybe you should put this into some structure that can binary search easily. Happy to do "a" before &qu

Re: [TLS] New Version Notification for draft-davidben-tls-trust-expr-00.txt

Quick update: we pushed a draft-01. It's basically the same, but we noticed we referred to the wrong name of some structs in places and figured it was worth a draft-01 to be less confusing. :-) On Thu, Oct 19, 2023 at 11:38 AM David Benjamin wrote: > Hi all, > > We just published

Re: [TLS] Request mTLS Flag

d user agent (and a bunch of > ML), which isn't always reliable. > > The web crawler case is where the dedicated endpoint falls over, because > crawlers are indexing the human visible web. > > I don't think this leaks more info than a dedicated endpoint (even > accounting

Re: [TLS] Request mTLS Flag

Would you expect a browser user to send this flag? On the browser side, we don't know until the CertificateRequest whether a client certificate is configured. We have to do a moderately expensive query, dependent on information on the CertificateRequest of the OS's cert and key stores to get this i

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

On Fri, Oct 20, 2023 at 4:07 PM David Benjamin wrote: > Thanks for the comments! Responses inline. > > On Thu, Oct 19, 2023 at 3:17 PM Ilari Liusvaara > wrote: > >> Some quick thoughts: >> >> - The multiple certificates from one ACME order really scares me. It

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

the compression was actually needed, so we omitted it. (These are not sent in TLS connections, just in the root program -> CA -> subscriber flow. We don't want them to be *humongous*, but we don't need to squeeze them that tightly.) But if folks prefer ranges, that's easy enough

  1   2   3   4   5   >