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,
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
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.
ument. :-)
On Mon, Sep 23, 2024 at 6:10 PM Watson Ladd wrote:
> Backing up a bit, at what point do we say QUIC Datagram is the right
> way to do this?
>
> This whole adventure sounds like a mess.
>
> On Fri, Sep 20, 2024 at 8:20 AM David Benjamin
> wrote:
> >
> >
rally skip over early data. So rather than the text in D.3, I think we
just say that you treat a DTLS 1.2 ServerHello as an implicit 0-RTT reject
and continue on.
On Wed, Sep 18, 2024 at 4:13 PM David Benjamin
wrote:
> Another issue with RFC 9147: when does the client switch from sending
>
rted
> to preferred. (Assuming we agree that the HTTPS RR values
> will typically reflect overall group preferences for the
> target and not everything actually supported by all the
> server instances concerned.)
>
> Cheers,
> S.
>
> On 9/24/24 19:17, Sean Turner wrote:
.3 already handles that.
Whether DNS servers the new or old population of servers isn't really going
to change that. We could maybe include a suggestion to pick like the
majority one or something, but it doesn't hugely matter.
David
On Tue, Sep 24, 2024 at 6:49 PM Stephen Farrell
wrote
"groups"
and another rename would do it again. Honestly, we should have just kept it
at "curves", and saved our disruption budget for a more appropriate name,
but so it goes. :-)
On Tue, Sep 24, 2024 at 7:07 PM David Benjamin
wrote:
> Ah, I see. I don't think "suppor
On Tue, Sep 24, 2024, 12:12 Martin Thomson wrote:
> On Thu, Sep 12, 2024, at 13:31, David Benjamin wrote:
> > 1. If a DTLS 1.2 (i.e. does not implement RFC 9147 at all)
> > implementation receives an ACK record for whatever reason, what
> > happens? This decision we don&#x
On Tue, Sep 24, 2024, 12:35 David Benjamin wrote:
> On Tue, Sep 24, 2024, 12:12 Martin Thomson wrote:
>
>> On Thu, Sep 12, 2024, at 13:31, David Benjamin wrote:
>> > 1. If a DTLS 1.2 (i.e. does not implement RFC 9147 at all)
>> > implementation receives an ACK re
I've now
switched from staring at the spec to writing code, so that round is done.
Of course, we'll realize something else in the course of writing code, I
dunno.
But I think there'll also be plenty of time in between now and the WGLC for
the as-yet-nonexistent -bis document for that.
On Tue, Sep 24, 2024, 13:03 Martin Thomson wrote:
>
>
> On Tue, Sep 24, 2024, at 09:35, David Benjamin wrote:
> > On Tue, Sep 24, 2024, 12:12 Martin Thomson wrote:
> >> No DTLS implementation should treat unauthenticated packets as being
> fatal. Though perhaps
I support this as well. As an implementer interested in providing an
implementation, I would like to help progress draft-ietf-tls-tlsflags, but
I cannot do so without a codepoint, so this seems necessary to break the
deadlock.
On Fri, Sep 27, 2024 at 3:03 PM Bas Westerbaan wrote:
> I support thi
(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:
>
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
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
wire protocol is needed.
>
> I do think changing the presentation syntax name used may help
> avoid future problems if e.g. someone reads "supported" and
> figures that means they ought add all the mappings to TLS
> codepoints they can envisage from what the get running the
&g
On Tue, Sep 24, 2024 at 8:19 PM Watson Ladd wrote:
> On Tue, Sep 24, 2024 at 5:07 PM Stephen Farrell
> wrote:
>
> > >
> > > Could you elaborate on how a long list could result in a failure or add
> > > complexity?
> >
> > Again, I'll try:-)
> >
> > Let's say we have targets T1 and T2. And serve
f the WG wants to
make them match the widely deployed one. (Though, of course, of they are
also widely deployed in some other context, we should probably leave them
alone too.)
On Thu, Oct 17, 2024, 08:33 David Benjamin wrote:
> While this whole situation is indeed ridiculous (there is obvi
While this whole situation is indeed ridiculous (there is obviously no
security reason to use one or the other order and any certification systems
that believe otherwise are clearly wrong and should be fixed), this draft
with this order is now running code in several large deployments. I don't
thin
I agree with David's analysis. I think, when reasoning about this, we
should separate the "how to profile TLS 1.2 down" parts from the "extend
TLS 1.2 with more protocol fixes" parts. That's not a knock against those
fixes... it's a good thing! Profiling things down is often a
configuration-only ch
I did notice one odd thing about the TLS-LTS protocol change (keep in mind
this document is *not* deployment considerations, but a whole new
incompatible mode for TLS 1.2), regarding domain separation. Unless TLS LTS
can fully enforce that the same key is never used for TLS 1.2 LTS and
regular TLS
Unsurprisingly, I support adoption.
On Mon, Dec 2, 2024 at 12:41 PM Joseph Salowey wrote:
> This is a call for adoption of draft-rescorla-tls-rfc9147bis-00[1] as the
> basis for an RFC9147 bis document. This document is seeded with the
> content of RFC 9147. If you object to the adoption of th
Sorry to revive an old thread. I saw John reference this in another thread
and wanted to understand what the issue is.
I don't think there is actually a problem here, unless I'm missing
something. Even without replay protection at the record layer,
post-handshake messages still have sequence numbe
Talking about providing "excellent security" also will get out-of-date
and/or subjective once someone decides post-quantum, or any other 1.3-only
improvement, is the bar for "excellent". I would suggest just not having
the draft opine on such things when it doesn't need to.
We could just delete th
Thanks for the thoughts!
> To that end, perhaps it's most useful to focus in on the post-quantum
case, as I think that's the one that the WG finds most compelling.
That's certainly not the use case I find most compelling. It's one among a
class of PKI scenarios, just as PQ is not the only reason
Accepting both labels gets super messy because then we have to make a bunch
of decisions like whether you output both labels on the logging side.
But we can just do a bit of research here:
- In IETF land, EARLY_EXPORTER_MASTER_SECRET dates to the start of the I-D,
but...
- The shorter EXPORTER_SEC
Changing it would be incompatible, but at a glance it looks like
EARLY_EXPORTER_MASTER_SECRET is the only label that would be impacted? We
definitely should not rename that to ...MAIN... because that's not the new
name. It's simply EARLY_EXPORTER_SECRET.
As for the right name, maybe we can still r
On Fri, Feb 7, 2025 at 1:55 PM David Benjamin wrote:
> Accepting both labels gets super messy because then we have to make a
> bunch of decisions like whether you output both labels on the logging side.
>
> But we can just do a bit of research here:
> - In IETF land, EARLY_EXPORTE
On Fri, Feb 7, 2025 at 9:44 AM Mike Shaver wrote:
> Hi Watson,
>
> On Thu, Feb 6, 2025 at 8:10 PM Watson Ladd wrote:
>
>> A negotiation where what is advertised is an inherently opaque
>> pointer, and where each side must maintain an idea of what that could
>> mean, does not have this property.
On Fri, Feb 7, 2025 at 12:17 PM David Benjamin
wrote:
> On Fri, Feb 7, 2025 at 9:44 AM Mike Shaver wrote:
>
>> Hi Watson,
>>
>> On Thu, Feb 6, 2025 at 8:10 PM Watson Ladd wrote:
>>
>>> A negotiation where what is advertised is an inherently opaque
>>
Uploaded https://github.com/tlswg/sslkeylogfile/pull/22 to fix the typo.
On Fri, Feb 7, 2025 at 1:56 PM David Benjamin wrote:
> On Fri, Feb 7, 2025 at 1:55 PM David Benjamin
> wrote:
>
>> Accepting both labels gets super messy because then we have to make a
>> bunch of d
Hi all,
There's been a lot said about root store divergence and fragmentation. We
discussed this quite a bit in the interim, but with the continued interest
in the topic, and some arguments being brought up on repeat, I wanted to
clear some misconceptions, in a separate thread to avoid cluttering
Hi Christian,
Thanks for the thoughts!
By TLSA usage value 0, you mean this thing?
https://www.rfc-editor.org/rfc/rfc7671.html#section-5.4
Skimming it, I think it does not *quite* do what our draft had in mind.
That record seems to be something along the lines of certificate pinning,
where a tru
On Thu, Feb 6, 2025 at 4:40 PM Salz, Rich wrote:
>
>
> First, to correct a misrepresentation: this draft is not a veiled attempt
> to completely diverge from the Web PKI and fragment the ecosystem.
>
>
>
> I never said that the draft is such a veiled attempt, and I don’t recall
> any other postin
I also support adoption. The draft has long been ready for it. The various
details being discussed here sound like something that can be resolved
after adoption. (Or in parallel since folks seem eager to discuss them now,
but they need not block adoption.) Adoption is the start of the process,
not
On Sun, Nov 17, 2024 at 12:05 PM Ilari Liusvaara
wrote:
> On Sun, Nov 17, 2024 at 07:54:17AM -0500, David Benjamin wrote:
> > On Sat, Nov 16, 2024 at 10:40 AM Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > On Wed, Nov 13, 2024 at
On Sat, Nov 16, 2024 at 10:40 AM Ilari Liusvaara
wrote:
> On Wed, Nov 13, 2024 at 01:39:43PM -0500, David Benjamin wrote:
> >
> > Not to say that every implementor would have noticed every issue (I'm
> sure
> > I overlooked some issues too), but I think DTLS'
Thanks for the comments! Some thoughts inline.
On Sat, Dec 21, 2024 at 8:59 AM Ilari Liusvaara
wrote:
> Some issues I have been thinking about (this all concentrates on server
> certificates):
>
>
> 1) Certificate chain mismatches between services on the same server:
>
> Trust Anchor IDs uses Se
Unsurprisingly, I support adoption.
To recap from the interim where we took on this problem, server operators
need to be compatible with all their supported clients, while clients need
to curate accepted certificates to maintain user security.
This client function is security-critical: accepting
Aha, that sounds like the disconnect! One trust anchor identifier indeed
only represents a one trust anchor. And, yeah, absolutely agreed that's a
significant difference!
I'm guessing this mixup came from the talk of user agent strings in the
problem-space-focused interm? TBH, I was quite perplexe
On Sun, Mar 23, 2025 at 8:59 PM Martin Thomson wrote:
> On Sun, Mar 23, 2025, at 10:20, David Benjamin wrote:
> > This case is a protocol error and should abort the handshake,
>
> Is it though? It would appear that the probability of this occurring is
> about 50% after a
On Mon, Mar 17, 2025 at 6:17 AM Eric Rescorla wrote:
> On Sun, Mar 16, 2025 at 11:52 AM Rob Sayre wrote:
>
>> On Sat, Mar 15, 2025 at 7:21 PM Laura Bauman > 40apple@dmarc.ietf.org> wrote:
>>
>>> Thanks to everyone that has taken a look at draft-bmw-tls-pake13-01.txt
>>> and provided feedback
Hi all,
We recently published draft-ietf-tls-trust-anchor-ids-00:
URL:
https://www.ietf.org/archive/id/draft-ietf-tls-trust-anchor-ids-00.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-tls-trust-anchor-ids/
HTML:
https://www.ietf.org/archive/id/draft-ietf-tls-trust-anchor-ids-00.html
HT
Hi all,
I recently spent some time debugging an interop issue between WebRTC + DTLS
1.3 in Chrome and WebRTC + DTLS 1.3 in Firefox. The cause of the issue was
a minor but interesting incompatibility between (D)TLS 1.2 and (D)TLS 1.3
that doesn't seem to have been flagged in RFC 8446 anywhere. Noth
Hi Luke! Thanks for the thoughts!
I don't remember if there was a particular reason originally, probably just
an artifact of them being in separate sections. :-) Reusing it makes sense,
although there are some differences here:
Regarding mismatching signatures and whatnot, the original thinking w
I support adoption. X25519MLKEM768 has already been widely deployed, and it
is time for the standards track to catch up.
David
On Wed, Feb 26, 2025, 13:35 Sean Turner wrote:
> At IETF 121, the WG discussed “Post-Quantum Hybrid ECDHE-MLKEM Key
> Agreement for TLSv1.3”; see [0] and [1]. We also h
On Wed, Feb 26, 2025 at 3:20 PM Christopher Wood
wrote:
> Being concerned about the WG's time makes sense, but given that this is a
> case where the WG has gotten very very behind running code, hopefully we
> can try to stamp this one with minimal fuss and time spent. After all,
> we've already b
I've definitely had folks ask whether it's OK to deploy this yet, so I
think it would be valuable. I can't really fault them for asking---the
usual story is that draft things are doomed to be replaced by their final
standards and this one hasn't even been adopted. Really, I'm appreciative
that thos
This case is a protocol error and should abort the handshake, not handle
retry configs. I think that's the correct behavior. This is spelled out in
the draft already:
https://www.ietf.org/archive/id/draft-ietf-tls-esni-24.html#section-6.1.5-5
https://www.ietf.org/archive/id/draft-ietf-tls-esni-24.h
ecifying tight bound is already how TLS 1.3 is defined:
>
> CipherSuite cipher_suites<2..2^16-2>;
> SignatureScheme supported_signature_algorithms<2..2^16-2>;
> struct {
> ...
> Extension extensions<0..2^16-2>;
> } NewSessionTicket;
>
>
> On Friday, 9 M
FWIW, I don't think this is an *error* in the specification per se. Both
2^16-2 and 2^16-1 to describe the exact same structure, precisely because a
length of 2^16-1 is impossible. One isn't inherently more correct than the
other. The question is which is clearer, the loose bound or the tight bound
I share the confusion about what this is for. SLH-DSA is handy, but it
seems to not fit TLS very well at all.
There's also rather a lot of algorithms proposed to be added here, so I am
correspondingly that many missing use cases worth of confused.
On Fri, May 16, 2025, 17:06 Watson Ladd wrote:
Whoops, I cut a new version just to snapshot an old "identifier" -> "ID"
change hanging around in GitHub before I saw this message! Just replying to
acknowledge this and that I did not ignore it intentionally! Will add this
to the document, probably tomorrow. Thanks for putting that together!
On M
On Tue, May 20, 2025 at 3:10 PM Viktor Dukhovni
wrote:
> On Tue, May 20, 2025 at 07:31:23PM +0200, Alicja Kario wrote:
>
> > I would like to point out that we need the same kind of codepoints no
> matter
> > if we want to use SLH-DSA in the end entity certificates or in CA
> > certificates.
>
> T
s://github.com/tlswg/tls-trust-anchor-ids/commit/dc9906a8db09d781f951467595b936d4dac4716d
On Wed, May 14, 2025 at 5:50 PM David Benjamin wrote:
> Whoops, I cut a new version just to snapshot an old "identifier" -> "ID"
> change hanging around in GitHub before I saw this
On Wed, May 21, 2025, 20:24 Martin Thomson wrote:
> Doesn't this same basic problem happen in this simple case?
>
> On Thu, May 22, 2025, at 00:59, David Benjamin wrote:
> > 1. Client sends request
> >
> > 2. Server reads request
> >
> > 3. Ser
(Whoops, accidentally hit reply instead of reply all.)
On Thu, May 22, 2025, 22:19 David Benjamin wrote:
> On Thu, May 22, 2025, 20:48 Martin Thomson wrote:
>
>> On Fri, May 23, 2025, at 06:17, Jeremy Harris wrote:
>> > Bad programming.
>>
>> I might not have
Hi all,
We ran into an interesting interaction between 0-RTT in TLS 1.3 and TCP
resets that I wanted to pass along for general awareness. If you recall an
earlier message,
https://mailarchive.ietf.org/arch/msg/tls/hymweZ66b2C8nnYyXF8cwj7qopc/,
this is a similar interaction to those.
Recall that t
On Fri, May 30, 2025 at 11:14 AM Eric Rescorla wrote:
> > # (nit) 4.2.8: omission and inclusion
> >
> > OLD:
> >For this reason, the omission of a share for group A and inclusion of
> >one for group B does not mean that the client prefers B to A.
> >
> > NEW:
> >For this reason, the o
Hi all,
A while ago, we presented Merkle Tree Certificates, a certificate
optimization for Web-PKI-like PKIs with a transparency requirement.
We’ve since updated it with a new version, draft-05, which we’ve been
informally calling “Photosynthesis”, so named because I enjoy silly puns
too much: we
On Fri, Jun 20, 2025, 15:27 Nico Williams wrote:
> On Tue, Jun 17, 2025 at 02:16:19PM -0400, David Benjamin wrote:
> > (As always, wearing an individual hat here. In particular, I am *not*
> > speaking on behalf of the Chrome Root Program.)
>
> Can we somehow inquire
(As always, wearing an individual hat here. In particular, I am *not*
speaking on behalf of the Chrome Root Program.)
This draft is not the way to solve this problem.
The point of markers like EKUs is to avoid cross-protocol attacks. Client
and server here do not refer to abstract classifications
I believe this is broadly covered by
https://www.ietf.org/archive/id/draft-ietf-tls-tls12-frozen-08.html
Defining PQC algorithms in TLS 1.2 would not magically make existing TLS
1.2 software PQC-capable. You would need to update those
systems regardless. So, as a practical matter, the backport doe
I would add that there is a cost to unnecessary variability in this space.
Whether or not SLH-DSA is appropriate for 3GPP (I'm very skeptical it is),
it clearly is inappropriate for the vast, vast majority of TLS uses, and
not jus HTTP. That means anyone using it would not be on the well-trod
path.
On Mon, Jul 7, 2025 at 12:11 PM Eric Rescorla wrote:
> On Mon, Jul 7, 2025 at 8:23 AM David Benjamin
> wrote:
>
>> Hmm, these MUSTs puzzle me too. I recall a ton of fuss during ECH's
>> design in ensuring that frontend -> backend communication in split mode
Hmm, these MUSTs puzzle me too. I recall a ton of fuss during ECH's design
in ensuring that frontend -> backend communication in split mode didn't
require any special channels (e.g. how the ECH acceptance signal depends
only on ClientHelloInner and not the HPKE secret). Having a backend server
know
I still do not support adoption. To first- and second- order approximation,
these should never be used for the per-connection TLS signature in the
CertificateVerify message, and risks being an attractive nuisance.
The claim that folks want this for X.509 signatures is slightly more
plausible to me
On Tue, Jul 22, 2025 at 12:35 AM Eric Rescorla wrote:
> On Mon, Jul 21, 2025 at 7:08 AM Laura Bauman wrote:
>
>> Thank you for the feedback! I’ve responded inline below.
>>
>> > On Jul 17, 2025, at 8:23 PM, Eric Rescorla wrote:
>> >
>> > Overall, this draft seems clear and useful. I have concer
URL correction:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-pkcs1/03/
I think it is ready for publication.
On Thu, Jul 24, 2025 at 9:05 AM Salz, Rich wrote:
> Ship it.
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email t
I support adoption. We've already implemented an earlier iteration of this
in BoringSSL.
On Thu, Jul 24, 2025, 11:00 Richard Barnes wrote:
> We should adopt this draft. It adds useful new functionality to TLS, and
> it is correctly agnostic as to the specific PAKE.
>
> I believe some of my Cisc
Note that enterprise PKI and this draft are not the same thing. This draft
is proposing to add it to enterprise PKI *and* online TLS keys.
The right way to do this for just PKI use cases is to define the codepoints
to only do anything for the X.509 half of their use in TLS, not the
CertificateVeri
501 - 572 of 572 matches
Mail list logo
