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

[TLS]Re: WG Adoption for TLS Trust Expressions

; No 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

[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

[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

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

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 transcript soun

[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

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

[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

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

t; 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-davidben-tls-

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

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

Re: [TLS] WG Adoption for TLS Trust Expressions

tes > <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 it a

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

. 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 fair bit. &g

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.

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

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 sender-only fix to

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

k. 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 > *Subject:* Re: [TLS]

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

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 the timeout. >

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

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

ost-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, 2024 at 6:59 PM David Benjamin wrote: >

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

[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

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're abl

[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

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.

[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

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,

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

.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 Benjamin > *Sent:* Tuesday, Marc

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

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

patible >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? > > Yes. > > > > Cheers, > &g

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

Re: [TLS] TLSFlags ambiguity

oes 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: > Nice catch! I ag

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 P

[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

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.

Re: [TLS] Trust Expressions Follow-up

sions/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 chain > that they validated before including the cert in their transpa

Re: [TLS] Trust Expressions Follow-up

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 us > know if yo

Re: [TLS] Trust Expressions Follow-up

, 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: > > > https:

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

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

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

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.

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

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

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,

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

Re: [TLS] Request mTLS Flag

ss. 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 Java

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

ls, 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 situation? > > -

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

n 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 groups. > Thanks, > Michael > > > > > > *From:* Rob Sayre &g

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

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

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 fro

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

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 "ab" before "b" instead. Is there a canonical way to say that in IETF-ese without expending a lot of te

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 a

Re: [TLS] Request mTLS Flag

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 for ECH), and from a security perspectiv

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

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.

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

-> 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 to add. > > -- Forwarded message - > > From: > > Date: Thu, Oct 19, 2023 at 11:36 AM > > S

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

Notification for draft-davidben-tls-trust-expr-00.txt To: Bob Beck , David Benjamin , Devon O'Brien A new version of Internet-Draft draft-davidben-tls-trust-expr-00.txt has been successfully submitted by David Benjamin and posted to the IETF repository. Name: draft-davidben-tls-trust-expr Revision: 00

Re: [TLS] weird DHE params p length in TLSv1.2

If I recall, TLS 1.2 was ambiguous on this point, so it's unclear what the sender is expected to do. I believe there were some implementations that expected a fixed-width public key (which would have been the better option to pick, but we don't have a time machine), so zero-padding on send is

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

Answering a few questions that have come up thus far: > Downgrade by attacker is only possible if the client attempts insecure fallback (e.g., offer PQ key share, connection failed, retry without PQ key share)? > Or am I missing some other possible downgrade attack? A fallback is certainly one

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

On Fri, Oct 13, 2023 at 1:29 AM Rob Sayre wrote: > On Wed, Oct 11, 2023 at 8:43 AM David Benjamin > wrote: > >> Tossed onto GitHub and removed the discussion of authenticated records >> in >> https://github.com/davidben/tls-key-share-prediction/commit/cabd76f7b320a

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

On Tue, Oct 10, 2023 at 1:24 PM Bas Westerbaan wrote: > OK, I see. It's worse than a compatibility risk, though, isn't it? If you >> just let them break in case (a), and then maybe try again with (b), that >> opens up a downgrade attack. Intermediaries can observe the size of the >> Client Hello

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

On Tue, Oct 10, 2023 at 12:42 PM Rob Sayre wrote: > On Tue, Oct 10, 2023 at 8:28 AM David Benjamin > wrote: > >> On Tue, Oct 10, 2023 at 6:06 AM Dennis Jackson > 40dennis-jackson...@dmarc.ietf.org> wrote: >> >>> To make sure I've understood correctly, we'r

Re: [TLS] TLSFlags ambiguity

Nice catch! I agree those don't match. I think bit zero should be the least-significant bit. That is, we should leave the examples as-is and then fix the specification text. Ordering bits MSB first doesn't make much sense. Unlike bytes, there is no inherent order to bits in memory, so the most

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

ntroducing downgrades. Thoughts? David -- Forwarded message - From: Date: Mon, Sep 25, 2023 at 6:56 PM Subject: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt To: David Benjamin A new version of Internet-Draft draft-davidben-tls-key-share-prediction-00.tx

Re: [TLS] SVCB codepoint for ECH

How do we want to handle the rest of draft-sbn-tls-svcb-ech? It got WG adoption in May, but I don't think anything's happened with it since. (Unless we decided something and I forgot?) In particular, the section on switching to SVCB-reliant mode is important for a client:

Re: [TLS] Early IANA Allocations for draft-ietf-tls-esni

d more problematic.) > Do we believe the draft is stable enough that we should reference it > informationally for that code point? > > > On Wed, Sep 20, 2023 at 3:01 PM David Benjamin > wrote: > >> I don't think what we do with the registry has any bearing on whether

Re: [TLS] Early IANA Allocations for draft-ietf-tls-esni

I don't think what we do with the registry has any bearing on whether the codepoint is burned. There are already draft ECH deployments today, on both the client and server side, independent of what we later put in the registry. Rather, the ECHConfigList structure is internally versioned, so as

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

On Mon, Aug 7, 2023 at 9:27 PM Eric Rescorla wrote: > 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

Re: [TLS] Merkle Tree Certificates

On Wed, Mar 22, 2023 at 11:22 AM Ilari Liusvaara wrote: > On Wed, Mar 22, 2023 at 01:54:22PM +0100, Bas Westerbaan wrote: > > > > > > Unpopular pages are much more likely to deploy a solution that > > > doesn't require a parallel CA infrastructure and a cryptographer > > > on staff. > > I don't

Re: [TLS] Merkle Tree Certificates

Thanks for such detailed feedback! Responses inline. On Wed, Mar 22, 2023 at 12:49 PM Ilari Liusvaara wrote: > Some quick comments / ideas: > > - I think it would be easier for subscribers to get inclusion proofs > from transparency service than certificate authority. > > This is because

Re: [TLS] Merkle Tree Certificates

On Tue, Mar 14, 2023 at 1:47 PM Watson Ladd wrote: > Come embrace the temptations of the Sea-SIDH! > > Intermediate certs are rarely used, so that would achieve 204 byte sig > on intermediate+ 64 byte intermediate key + 204 byte sig of EE cert > since the signing time doesn't matter. Then with

Re: [TLS] Merkle Tree Certificates

I > > mechanisms that might be selected via negotiation. > > > > Thoughts? We're very eager to get feedback on this. > > > > David > > > > On Fri, Mar 10, 2023 at 4:38 PM wrote: > > > >> > >> A new version of I-D, draft-davidben

Re: [TLS] Servers sending CA names

Chrome also uses this to filter the set of client certificates when asking the user to pick one. We also sometimes use this to figure out what intermediates to send, in cases where the server does not already have all its intermediates available. (Though this is not very reliable and OS-dependent.

Re: [TLS] TLS 1.2 deprecation

post_handshake_auth was only in TLS 1.3 because some folks relied on an existing (and terrible :-) ) corresponding mechanism in TLS 1.2: trigger a renegotiation and request a client certificate in the new handshake. I don't think it makes sense to backport post_handshake_auth to TLS 1.2. Such a

Re: [TLS] WG Adoption call for draft-sbn-tls-svcb-ech

I support adoption. On Tue, Mar 28, 2023 at 2:20 PM Stephen Farrell wrote: > > > On 28/03/2023 05:57, Salz, Rich wrote: > >> At TLS@IETF116, the sense of the room was that there was WG support to > adopt draft-sbn-tls-svcb-ech [1]. This message is to confirm the consensus > in the room. Please

Re: [TLS] Merkle Tree Certificates

On Tue, Mar 21, 2023 at 8:01 AM Hubert Kario wrote: > On Monday, 20 March 2023 19:54:24 CET, David Benjamin wrote: > > I don't think flattening is the right way to look at it. See my > > other reply for a discussion about flattening, and how this does > > a bit more than t

Re: [TLS] Merkle Tree Certificates

imilar, to shrink the amount of auth data. > > > > -Original Message- > From: TLS On Behalf Of Hubert Kario > Sent: Monday, March 13, 2023 11:08 AM > To: David Benjamin > Cc: ; Devon O'Brien > Subject: RE: [EXTERNAL][TLS] Merkle Tree Certificates > > CAUTIO

Re: [TLS] Merkle Tree Certificates

1 public key) for server > cert + (1 Sig + 1 Public key) per ICA cert in the chain). If we borrowed > the same flat PKI logic though and started “trusting” on a per issuer CA > basis then the comparison becomes (1 public key + 2 signatures + some small > tree structure) vs (1 public key + 4 sigs)

[TLS] Merkle Tree Certificates

10, 2023 at 4:38 PM wrote: > > A new version of I-D, draft-davidben-tls-merkle-tree-certs-00.txt > has been successfully submitted by David Benjamin and posted to the > IETF repository. > > Name: draft-davidben-tls-merkle-tree-certs > Revision: 00 > Tit

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

artle < > cbartle...@gmail.com> > *Date: *Thursday, 15 December 2022 at 20:15 > *To: *David Benjamin > *Cc: *TLS List > *Subject: *Re: [TLS] consensus call: deprecate all FFDHE cipher suites > > > > Hi David, > > > > My understanding is that we'r

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

Small clarification question: is this about just FFDHE in TLS 1.2, i.e. the TLS_DHE_* cipher suites, or also the ffdhe* NamedGroup values as used in TLS 1.3? I support deprecating the TLS_DHE_* ciphers in TLS 1.2. Indeed, we removed them from Chrome back in 2016

Re: [TLS] RFC 5746 applicable for session resumption?

The exact contents and structure of StatePlaintext and ticket itself are up to the implementation to decide. This format is merely a recommendation or example. The only interop requirements are that the server maintain enough state that it can correctly resume a session on the subsequent request.

Re: [TLS] [EXTERNAL] Opt-in schema for client identification

Depending on what the server does, there may also be downgrade implications, if the server uses some unauthenticated prior state to influence parameter selection. On Fri, Sep 16, 2022 at 11:53 AM David Benjamin wrote: > I too am not seeing the use case here. Could you elaborate? > &

Re: [TLS] [EXTERNAL] Opt-in schema for client identification

I too am not seeing the use case here. Could you elaborate? Since browsers were mentioned as an example, when Chrome makes several connections in a row (e.g. to measure impacts of a removal more accurately), we generally do *not* expect the server to change its selection algorithm across the two

  1   2   3   4   5   >